We are going to start using Git (not using it yet), and I want to define the workflow.

We have 4 teams at 4 different global locations, developing together the same product. Each team owns a part of the product's code, but sometimes they also have to make changes in the code owned by other teams.

Is there a recommendation for a Git workflow for such an environment?

I have already seen this article, but the approach here is "we create additional branches as seldom as possible", and I believe more in "branch for each user story" approach.

Also, this article presents a nice approach.

I had in mind having a master branch, a permanent branch per each team periodically merging to master, and a per-user-story branches merging to the teams' branches. Does it make sense, or it wouldn't work?

  • 2
    We use this branching model, but I think if you read "feature branch" as "story branch", it jives really well with your second article.
    – sczizzo
    Commented Dec 25, 2011 at 16:44
  • 2
    I'm sure 10 people could respond back to this with 10 different responses. Here is what works for me: We have one master repo hosted on github which denotes the 'current' release. Older releases are branched (though tagging works too). Team members are encouraged to create branches for tasks they are working on. When complete, they make a pull request to master (or where ever it needs to merge to) and then someone else reviews the pull request and is reponible to merge it into master. They are also responsible for clearing out the branch once it has been merged.
    – carbonbasednerd
    Commented Dec 25, 2011 at 16:50
  • 2
    You might be interested in submodules to keep the different teams' codebases apart. They can then fork each others' codebases and send patches around when editing each others' parts of the code.
    – Fred Foo
    Commented Dec 25, 2011 at 16:57
  • @larsmans & carbonbasednerd - Your comments should have been answers, they would have got up-votes from me. *8')
    – Mark Booth
    Commented Jan 4, 2012 at 17:48

2 Answers 2


Take a look at Successful Git Branching Model, which has a nice branching strategy for feature development across releases.

A Successful git branching model

You could implement something similar with one extra level for team branches between the 'develop' branch and the 'feature branches'. Having team branches would also allow two teams to collaborate more effectively by merge between their team branches.


I would say that each team has its own version of the repository, with one global repository where everyone commits to (like in Linux kernel, where the Linus repository IS the kernel and central repository).

Then for maintaining the product code, you could use submodules like @larsmans said, then each team can only work mainly on the part that is most important to them and if they need to work with other part, they can do it to, but they will have to remember to update the submodule, and this is where the problem lies (since it is very easy to get things wrong when using git, thankfully it is also easy to get away from them).

But since your teams are used to this, and are aware that they are changing other team code, it is easier for them to remember to do the submodule update, before changing a foreign module.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.