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.

There's two of us working on something. We're using this branch structure

  • master
  • dev-A
  • dev-B

We both work on separate branches (dev-A,B) and whenever we're done - we promote our changes to master.

But the drawback of this is we can't get changes the other developer makes. Everything exists in the master tree - but we can't get the latest updates the other developer made.

Is there a way to resolve this or should we change our branch structure (per feature?)?

share|improve this question
add comment

3 Answers 3

I've seen developer branches used in two main scenarios:

  1. The open-source community, where these branches are actually repository forks, so that project maintainers can lock down access to the master repository and require integration through pull requests. This makes life more difficult for contributors, but much easier for the maintainers, which of course is exactly the point, and this is a very successful model on GitHub.

  2. Teams and organizations which do not have continuous integration and a track record of instability in their deployments, or worse, instability in their builds. These teams generally try to use developer branches as a way to protect the stability of the mainline, and the result is - typically - a long and very painful merge period before the release, followed by an even longer and more painful stabilization period, which sometimes doesn't happen until after the release.

I don't want this to be a rant about why you need CI, but it's clear from your question that you know you aren't integrating your changes often enough, so IMO there's no point in dancing around the issue.

Unless you're actually working in a geographically distributed team with a need to "gate" changes from outside developers, the branch-per-developer model really doesn't make much sense. It especially doesn't make sense with git, because every developer already technically has his/her own repository. Most organizations should be integrating very frequently - as in, several times per day.

I'm currently part of a group of about 35 contributors divided into 4 separate teams, most people check in at least 2-3 times a day, some people 10-15 times; it's unusual to see builds broken and extremely rare for them to stay broken for more than a few minutes. Git handles merges so effortlessly most of the time that remote developer branches are just unnecessary overhead. Just pull, merge locally, and run commit tests before you push, it's simple.

If you absolutely must defer integration in order to protect the stability of the master branch, the typical, proven model is to use an unstable branch - sometimes called a development branch, as described in A successful Git branching model. If developers can't successfully merge into this branch (which only needs to build, not run flawlessly) at least once a day, then you have a quality/discipline problem and not a revision control problem; covering it up by using non-integrated developer branches only defers the problem, and by doing so, actually makes the eventual merges a lot more painful and unstable than they really need to be.

Feature branches aren't the worst, but IMO very few projects are actually big enough to warrant them; if your project is very large (i.e. tons of features being worked on at once) then you'll see better results from splitting it up into separate autonomous components than you will from papering over the problem with source control.

You can ignore this advice if you want, and many teams do, but one of the reasons the branching model linked above is so popular and successful is that it's designed to work with continuous integration, not against it.

share|improve this answer
    
I think the importance of continuous integration cannot be stressed enough, both in the sense of integrating everything into one branch, and in the sense of daily/hourly builds (using Jenkins or similar). –  sleske Apr 9 at 7:17
add comment

In your working branch if you go:

git commit -am "Committing changes before merge"
git merge master

you can also merge from the other developers branch

git checkout dev-A
git merge dev-B

What that will do is merge the changes in master to your development branch.

share|improve this answer
    
Yes - that's one way. I was hoping git would have an elegant workflow for this. –  Utkarsh Sinha Oct 7 '12 at 0:42
1  
Well git usually works best if each developer has their own local work repository and a shared central repository that developers push to and pull from. That way you can each work in the same branches and get updates by pulling and put changes by pushing to the central repository. That is probably the elegance you're looking for. git will handling the merging for you automatically unless there is a conflict. git flow is a nice addition for workflow. –  scaryrawr Oct 7 '12 at 0:55
add comment

If dev-A and dev-B are different branches for different project then what @scaryrawr answered would be best.

But if dev-A and dev-B is actually precisely the same code (same project) then an alternative would be that both work on one of the branches. For example you create a branch off master called 'devWork'. You both checkout devWork, work on it, commit and push changes. Pushed changes would not be on Master but in devWork, then the other users of the branch simply need to do a PULL locally to get pushed changes.

You could then follow standard methods to get work done on devWork back to Master etc.

share|improve this answer
add comment

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.