Reputation: 1517
I am working on a big project that has a number of repos, that sit in separate folders.
1 - a shared Library
2 - an API (that uses the library)
3 - a mobile app (that uses the api)
4 - a website with a CMS (that uses the api and library)
5 - a customer info system (that uses the api and library)
The library is sym-linked to prevent duplication, and the API is rest based which can be called externally...
I have been getting a few issues with other devs where by we work on new feature in a repo that requires a new branch in the library the api and then say the website. When another dev comes to work on this feature it is not obvious that a branch has dependencies on another branch. Is there a way to have branches dependencies linked across repos? So if I checkout the feature-1 branch on the website, git also checks out the corresponding feature banches on the dependant library and api repos?
Upvotes: 1
Views: 1620
Reputation: 1517
Edited from http://git-scm.com/book/en/Git-Tools-Submodules
A common issue arises in this scenario: you want to be able to treat each projects as separate projects yet still be able to use one from within the other. 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. 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. Git addresses this issue using submodules. Submodules allow you to keep a Git repository as a subdirectory of another Git repository. This lets you clone another repository into your project and keep your commits separate.
The first thing you should do is clone the external repository into your subdirectory. You add external projects as submodules with the command:
git submodule add
You can go into that subdirectory, make changes, add your own writable remote repository to push your changes into, fetch and merge from the original repository, and more. If you run git status right after you add the submodule, you see two things:
$ git status
# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# new file: .gitmodules
# new file: <name_of_cloned_repo>
#
First you notice the .gitmodules file. This is a configuration file that stores the mapping between the project’s URL and the local subdirectory you’ve pulled it into:
$ cat .gitmodules
[submodule "rack"]
path = rack
url = git://github.com/chneukirchen/rack.git
Although is a subdirectory in your working directory, Git sees it as a submodule and doesn’t track its contents when you’re not in that directory. Instead, Git records it as a particular commit from that repository. When you make changes and commit in that subdirectory, the superproject notices that the HEAD there has changed and records the exact commit you’re currently working off of; that way, when others clone this project, they can re-create the environment exactly.
This is an important point with submodules: you record them as the exact commit they’re at. You can’t record a submodule at master or some other symbolic reference.
You can treat the directory as a separate project and then update your superproject from time to time with a pointer to the latest commit in that subproject. All the Git commands work independently in the two directories...
Upvotes: 1