Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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 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 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?

share|improve this question

migrated from stackoverflow.com Dec 27 '11 at 3:17

This question came from our site for professional and enthusiast programmers.

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 Dec 25 '11 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 Dec 25 '11 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. –  larsmans Dec 25 '11 at 16:57
    
@larsmans & carbonbasednerd - Your comments should have been answers, they would have got up-votes from me. *8') –  Mark Booth Jan 4 '12 at 17:48

2 Answers 2

up vote 3 down vote accepted

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.

share|improve this answer

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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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