Question

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, core and additional contain data that are part of that platform.

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 additional/includes

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 platform submodule.

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 platform
• AND the projects using platform don’t mess up the repo of platform?

---

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!

---

EDIT 2:
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.

Answer 1

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
master branch.

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

Init

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
bare repo.

$ editor some-file
$ git add -p some-file
$ git commit
$ git push

Pull changes made by other developers to the projects bare repo
by using git pull.

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 branch
or git status. Now you make your changes and commit them (to
central, where your on). As central is connected to
platform/master (checkout 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.

Use 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

The 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.