I've been using the branching model you mentioned for a while and this is the flow I've settled on:
- Create feature branch.
- Do work. Possibly several commits happen in the feature branch depending on the feature.
- When feature work is complete, do interactive rebase, squashing all the feature branch commits into one commit.
- Merge feature branch back into dev branch.
- 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.