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.

This question already has an answer here:

I a little while ago I joined a new development team and recently we had our first major release. We've used Git since the beginning of the project and by now are somewhat comfortable with it. However, now that the product is in the field, we are discovering new issues/processes that need to be established. Up to this point, everything we've done was by referencing the very popular successful branching model post, which indeed has been very helpful

Currently we have the following branches, all live and all being updated:

  • master - only released, stable code (tagged every time release is cut)
  • develop - wide open. used for long term development
  • hotfix-1.0.1 - branched off master's 1.0.0 tag for small, very targetted fixes which are already lining up
  • release-1.1 - This is a small incremental release that we want to push relatively soon so we wanted to manage it separately from develop and to limit scope of changes.

These are the merging rules we are establishing:

  1. If a code change is made in release-1.1, it must be merged up to develop.
  2. If a code change is made in hotfix-1.0.1, it must be merged up to release-1.1.
  3. Nobody except for one team member should merge anything into master and that merge only happens when a product version is about to be shipped.

My questions are:

  1. When should the merges take place? As soon as the fix is applied in lower-level branch? Or periodically in chunks of changes? If periodically, how do you typically determine merge period?
  2. Who should do the merges? Person making the original code change? Or one individual who would be designated as "Director of Git Services"?

Reason I'm asking all this is because it seems that while Git is very flexible (and I do love that part about it), it also allows you to easily shoot yourself in the foot. With just few commands, someone could easily, and hopefully not on purpose, merge new development right into hotfix that should ship out in 2 days.

Many of us are new to Git and we are still feeling our way around the tool. I was thinking how my other companies/teams handled such concepts in the past and I think the biggest difference is that most other source control products that I've used, work with individual commits, so each developer could be responsible for making sure his fixes are applied to the correct places. But with Git, when one developer runs:

git checkout release-1.1
git merge hotfix-1.0.1

... after his commit, those commands will end up merging an entire branch including code that he has never seen before and may not be the best person to resolve, if there are any conflicts.

share|improve this question

marked as duplicate by gnat, BЈовић, Dynamic, Dan Pichelman, MichaelT Jun 24 '13 at 3:06

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

add comment

2 Answers

You hit the nail on the head -- git is a powerful tool. And like any other powerful tool you can just as easily cut off your hand as you can build a countertop.

The best way to address this stuff is have a continuous integration system backing everything -- it will let you get notified when commits happen and can do things like run your test suite to ensure nobody broke anything. Which is an issue no matter what SCM you are using or even if you are using SCM at all.

share|improve this answer
    
thanks, we do have CI server. Problem is that people could inadvertently check-in experimental code into branches that should be for targeted fixes only but code will still compile. I was trying to ask more about general process that teams that use Git follow to minimize some of these risks –  DXM May 24 '13 at 20:25
add comment

Implementing a commit and release process is one way to minimize the risks. As for committing to the wrong branches, that can be difficult to enforce. But you just need to manage it so that people understand the process and that it isn't too difficult. Generally, that they only work on one branch and should not be merging at all.

Another option would be to add a code review tool so that features are vetted before going into production.

  • Gerrit - prevents commits from being pulled until they are approved
  • ReviewBoard - another code review tool, just review the diff before merging into the production branch (with no one actually making commits to that branch)

The main thing is creating a simple, documented process that people can follow. Generally, having people know which branch that they are supposed to be working on and designating who is responsible for merging branches can help keep things simple.

share|improve this answer
add comment

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