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 Git branching model recommends branching for all development efforts and merging when complete:

  1. Branch
  2. Develop
  3. Merge when complete

I'm wondering how this works in practice, given that performing a merge off this model will simply add a commit to the develop with whatever commit message happened to be the last one in line. Do people using this model do an interactive rebase on the feature branch before committing? If not, how do you ensure that the commits make sense on the main branch?

share|improve this question
add comment

1 Answer

up vote 1 down vote accepted

I've been using the branching model you mentioned for a while and this is the flow I've settled on:

  1. Create feature branch.
  2. Do work. Possibly several commits happen in the feature branch depending on the feature.
  3. When feature work is complete, do interactive rebase, squashing all the feature branch commits into one commit.
  4. Merge feature branch back into dev branch.
  5. Delete feature branch.

The important step here is number three. You need to write a really good commit message when you rebase. It should have a single line at the top that gives a good overview of the commit followed by an empty line, then as many lines as you need to describe the commit in detail. For example:

Adds Feature Name (with reference to bug tracker/project management tool ticket)

This is a paragraph that describes this commit in detail. I usually use it to 
describe decisions I've made, why I made them and potential limitations of the    
implementation. I might follow this up with some bullet points:

- Detail 1
- Detail 2
- Detail 3

This way when you run git log --oneline it's clear from the first line what's going on in this particular commit. If you then run git log or git show {sha} you can see the full commit message.

Of course you can make use of gitk and git log --graph to get a graphical representation of all your commits.

share|improve this answer
    
Nice, this blog post seems identical to what you describe. Do you ever find that you miss the squashed and deleted commits? –  eykanal Sep 27 '12 at 20:56
    
No, but I was initially concerned about that which is why I go out of my way to write a good, comprehensive commit message when I squash. –  NoobsArePeople2 Sep 27 '12 at 23:00
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.