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?

1 Answer 1


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.

  • Nice, this blog post seems identical to what you describe. Do you ever find that you miss the squashed and deleted commits?
    – eykanal
    Commented Sep 27, 2012 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. Commented Sep 27, 2012 at 23:00

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.