All work happens in a topic branch. Nothing gets done in master — master should always be stable, clean, and ready for a release. Let’s imagine that I am adding some responsive features in a branch called feature/responsive.
Firstly, I make sure my local copy of master is fully up to date with remote. After pushing and pulling, I create my topic branch off of master:
git checkout -b feature/responsive && git push -u
There are two things happening here, firstly I check out a branch called feature/responsive (that didn’t yet exist). Next, I want to set feature/responsive to track a remote branch of the same name, this is the git push -u. This second command just means that I can run git push and git pull as just that. Without setting up remote tracking, I would have to run git push origin feature/responsive and git pull origin feature/responsive every time.
If the feature does have finite scope—and can be deemed ‘done’—then once I’m happy with it, I diff it against master:
git diff master feature/responsive
This allows me to review any changes visually. If this final check goes well then I’m almost ready for merging it into master.
This next thing divides the Git community. I find rebasing, when used properly, incredibly useful. Because feature/responsive is a private non-production branch, I can rebase it. Rebasing allows you to reword, reorder and squash commits. This is the important bit; it fiddles with your Git history, and this is why people dislike it.
I like to commit a lot. Frequent commits, committing as I think, not taking great care over them, writing them for my train of thought as opposed to for anyone else to make sense of. As such, it’s not unusual to end up with a commit history like this:
- Add media query mixin
- Add missing semi colon
- Put MQs into use in grids file
- Fix typo
- Add comments explaining stuff
- Whitespace
Looking at these commits, it’s pretty slapdash. That’s cool though, I committed as I worked, this is an accurate representation of what I did, however there are a few things to note:
In a team environment they’re seeing a lot of pointless commits. It’s more for them to read and review There will be no desire to ever roll back to a stage in the commit history where the code didn’t have that semi-colon, so being able to roll back to that point seems silly If we’re being totally honest, these could all be summed up in one as ‘Add responsive grid system’
What we do now is:
git rebase master -i
What this does is replays those commits against master and interactively (-i) allows us to modify them. Running that command might leave you looking at something a little like this:
pick 64073f0 Add media query mixin
pick 4ebe438 Add missing semi colon
pick 987d093 Put MQs into use in grids file
pick 324f2a2 Fix typo
pick df0321b Add comments explaining stuff
pick 1ed9323 Whitespace
The word pick can be replaced with a number of things, but the most common ones I use are r, for reword (we want to edit the commit message) and s, for squash (we want to squash that commit into the previous one).
What we want to do here is squash all of those commits into one nice one, something like ‘Add responsive grid system’. We need to modify the above to look like this:
pick 64073f0 Add media query mixin
s 4ebe438 Add missing semi colon
s 987d093 Put MQs into use in grids file
s 324f2a2 Fix typo
s df0321b Add comments explaining stuff
s 1ed9323 Whitespace
Now we can continue on our way and squash all those commits into the top one. Please use discretion when rebasing; only rebase if you really feel you need to, and only squash into as many commits as makes sense, no less. If you end up with ten commits and you feel that you need to keep all ten then by all means, please do so. Only rebase if and when necessary and/or appropriate.
Now we have all our work completed and our commits nicely tidied up, we need to get feature/responsive back into master, ready for release.
To do this, simply check out master with:
git checkout master
And then merge feature/responsive into master with:
git merge feature/responsive --no-ff
This simply merges our topic branch back into master and forces a merge commit. Git will, if it can, merge branches using fast forward, which basically means that it will create a ‘seamless’ merge. Merging without --no-ff will just add the commits from feature/responsive onto the end of master as though feature/responsive never existed; it fast forwards master to be at the same point as feature/responsive. A git log has no mention or idea of any other branches and might look like:
- Add normalize.css
- Add responsive grid system
To leave a neater paper trail, and show where everything came from, merging with --no-ff would make our git log look like this:
- Add normalize.css
- Merge branch 'feature/normalize'
- Add responsive grid system
- Merge branch 'feature/responsive'
So --no-ff basically just gives us a merge commit and a nicer paper trail.