linermini.blogg.se - Git submodule point to branch

#Git submodule point to branch update
#Git submodule point to branch software
#Git submodule point to branch code
#Git submodule point to branch download

However, it probably helps you to understand that the internal maintenance of Git submodules is quite complex. git/modules folder.Īll of these are technical details you don’t have to remember. git/config, which now ends like this: Īnd finally, Git also keeps a copy of each submodule’s. gitmodules file is one of multiple places where Git keeps track of the submodules in our project. gitmodules file has been created in the root folder of our main project. The submodule, however, makes sure that the library files don’t “leak” into our main project’s repository. The crucial difference is indeed that they are contained in their own Git repository! Had we just downloaded some files, thrown them into our project and then committed them - like the other files in our project - they would have been part of the same Git repository. After all, the third-party library’s files are here, just like they would be if we had copy-pasted them.

“So what’s the difference?” you might ask. Resolving deltas: 100% ( 5159/5159 ), done.Īnd if we take a look at our working copy folder, we can see that the library files have in fact arrived in our project. When we run this command, Git starts cloning the repository into our project, as a submodule: Cloning into 'carparts-website/lib/spacetime'. Let’s say we need a little “timezone converter” JavaScript library: $ git submodule add

#Git submodule point to branch code

Now we’re ready to pump some third-party code into our project - but in an orderly fashion, using submodules. Before we go get any code, it makes sense to create a separate folder where things like these can have a home: $ mkdir lib

Let’s take the classic example and say we’d like to add a third-party library to our project. Maybe you just want to share your own code between two projects - a situation where submodules might offer the simplest possible workflow.

Not every piece of code might be available over a package manager.

Submodules, on the other hand, always work the same. Especially if you’re working with multiple technologies, each one might have its own package manager with its own set of rules and commands.

Submodules provide a consistent, reliable interface - no matter what language or framework you’re using.

However, you could argue that Git’s submodule architecture comes with a couple of advantages: You could also use one of the various “package manager” systems that many modern languages and frameworks provide. Luckily, Git’s submodule concept was made for exactly these situations.īut of course, submodules aren’t the only available solution for this kind of problem. And it’s certainly true for managing third-party code in your own projects.

#Git submodule point to branch software

The general rule in software development to “keep separate things separate” exists for a reason.

#Git submodule point to branch update

Whenever you need to update the library code (because its maintainer delivered a great new feature or fixed a nasty bug) you again have to download, copy, and paste.

The line between your own project and that of someone else (the library) starts to get blurry.

By brute force copying third-party code into your project, you’re effectively mixing multiple projects into one.

While certainly quick, this approach is definitely dirty for a couple of reasons:

#Git submodule point to branch download

When you need to include third-party code (such as an open-source library) you can of course go the easy way: just download the code from GitHub and dump it somewhere into your project. To make clear why Git’s submodules are indeed an invaluable structure, let’s look at a case without submodules.