How do I organize my Git repo
I’m facing the following problem and don’t have an answer to it:
We have a repo that was cloned from an SVN repo. The project stored in that repo is something like a platform software that gets used by various projects. The structure of the repo is like this:
platform |- core |- additional
The structure of that repo cannot be changed for some reasons. Both,
additional contain data that are part of that
If a project wants to use the platform and add some functionality, it creates a new folder under
additional containing the sources and adds a header for that functionality to
Currently, we simply branch off new projects from
master and everything goes into the same repo. This leads to a branch inflation and my (central) repo grows more and more because all of the commits being made in the single projects go to the central repo (my colleagues are used to SVN, so they
push nearly after each
commit — just to be sure…).
First I had in mind were submodules: keep
platform as a submodule under a superproject (called
super) and then go to
super/platform/additional/mystuff, create the sources there and add them to
super. But this obviously doesn’t work because the files are inside the
Is there any better way to organize my repo, so that:
- users of the platform are able to update their working copy from the central repo
- AND users of the platform are able to apply bug fixes to the repo of
- AND the projects using
platformdon’t mess up the repo of
EDIT 1: Highly coupled git submodules covers quite a bit of the scenario I’m in: tightly coupled stuff, me the only one knowing a bit more than absolute basics of git, “Most of the developers have only a very cursory knowledge of git”. Perfect match!
While the answer from Michael looks promising, I think that it’s a bit too complex to use. I’m looking for some really simple thing that doesn’t need that much interaction.
One Solution collect form web for “How do I organize my Git repo”
I found your usage of
master a bit confusing as I never knew
whether you meant the platform repository as a whole or just its
My solution to this would be the following:
- You have one central repository for the platform.
- You have one central repository per project.
- Every developer has his/her own repository local.
The central platform repository
This is where only the platform code goes to. Use e.g. your
existing repo as a starting point here.
The central project repository
This is a clone of the platform repository and keeps all the code
of a project. Init it with
$ git clone --bare /path/to/platform
The developer’s local repository
You, as a developer, start by cloning the project repository.
$ git clone /path/to/project
Making changes to the project
Now, make your changes, commit them and push them to the projects
$ editor some-file $ git add -p some-file $ git commit $ git push
Pull changes made by other developers to the projects bare repo
Making changes to the platform
As you also want to make changes to the platform itself, you also
need a way to access the platform repo. So you add it as a
remote repo to your local repo:
$ git remote add platform /path/to/platform $ git fetch platform
As you can see now with
git branch -a, your local repo knows
about the platform. Now you want to make some changes to the
platform. First you create a local branch central which is a
clone of the master branch of the platform repo:
$ git checkout -b central platform/master
You can always check which branch you’re on by using
git status. Now you make your changes and commit them (to
central, where your on). As central is connected to
cat .git/config) you can push your
changes to the platform repo by simply using
git push. Also
git pull works without any other arguments.
git checkout master and
git checkout central to change
between your branches.
Get a new platform version into your project
Note: You need to have done the work from the previous section.
First change to your platform branch and pull in the new version
of the platform:
$ git checkout central $ git pull
Now go back to your project branch and merge the changes made in
the platform into your project branch.
$ git checkout master $ git merge central
If a conflict occurs, something like this happens:
$ git merge central Auto-merging index.html CONFLICT (content): Merge conflict in index.html Automatic merge failed; fix conflicts and then commit the result.
Open the files with the conflicts, resolve them, add them to the
staging area and commit the merge:
$ editor index.html $ git add index.html $ git commit
Now push your changes to the project’s bare repo:
$ git push
More about merge conflicts: Pro Git: Basic Merge Conflicts
If you do not want to change the platforms repo, but merge
changes from there into your project use
$ git remote add platform /path/to/platform $ git fetch platform $ git merge platform/master
git remote add is only needed the first time you merge.
The other two are always required.
The part about merging is based on the Pro Git Book which is
licensed under cc-by-sa. All other content of this post may be
considered public domain.