#GIT SUBMODULE GET INSTALL#
#GIT SUBMODULE GET SOFTWARE#
#GIT SUBMODULE GET CODE#

#GIT SUBMODULE GET CODE#

This additional complexity may be worth it if you’re trying to work on shared code and project code simultaneously and if there are methods of managing this complexity in a way that a) keeps us moving quickly and b) helps us avoids costly mistakes. There’s additional complexity that comes along with using git submodules, and this complexity isn’t worth it if there are simpler ways of sharing code. So, if you’re using git submodules merely as a way of sharing code, that’s probably misguided, as it’s a use case that git submodules weren’t designed to handle. Otherwise you would probably instead be using a simpler dependency management system (such as Maven or Rubygems). It’s quite likely that if you’re using submodules, you’re doing so because you really want to work on the code in the submodule at the same time as you’re working on the code in the main project (or across several submodules). If you’re not trying to change the shared code along with the consumer of that code, there are better options for sharing your code. Its more accurate to say that git submodules are useful when you want to share code that you also need change along with the consumer of that code. As the above example from the docs suggest, that’s not entirely true. I used to think submodules were designed for the purpose of sharing code. It is not uncommon at all when working on any kind of larger-scale project with Git to find yourself wanting to share code between multiple different repositories – whether it be some core system among multiple different products built on top of that system, or perhaps a shared utility library between projects.Īt first glance, Git submodules seem to be the perfect answer for this Interestingly, this is very different from what we might call the “naive perceived purpose” of git submodules, which is well captured by the opening paragraph of the aforementioned article arguing against git submodules:

The issue with vendoring the code into your own project is that any custom changes you make are difficult to merge when upstream changes become available. The issue with including the library is that it’s difficult to customize the library in any way and often more difficult to deploy it, because you need to make sure every client has that library available.

#GIT SUBMODULE GET INSTALL#

You’re likely to have to either include this code from a shared library like a CPAN install or Ruby gem, or copy the source code into your own project tree. Instead of writing your own Atom-generating code, you decide to use a library. Suppose you’re developing a web site and creating Atom feeds. The docs actually provide a very helpful example to answer this question:

What follows are some more nuanced thoughts on how and when git submodules can be used effectively.

A part of the reason I had this simplistic view was because of an article called “Why your Company Shouldn’t use Git Submodules.” I took a second look at this article recently and I read the docs on git submodules.

#GIT SUBMODULE GET SOFTWARE#

This was naive, as most choices in software development are about tradeoffs. I used to think git submodules were categorically evil.

Git submodule get