Rebasing in Git

The day’s end dilemma

It’s the end of the day and everybody is anxious to get their code merged onto the integration branch and go home. Problem: everyone is trying to do this at the same time so it’s like the 7–1 lane merge at rush hour on the Lion’s Gate bridge. It’s a classic computer science dilemma but luckily with git there’s a simple solution: Rebasing to the rescue!

If, like me, you’re part of a small team or you’re the only one who commits to your repos you may never have come across this. Back in my web development days we only had one dev on a site at a time and this problem simply never came up. Now that I’m collaborating with a few developers on the same repository it can get a little hairy when we try to bring everything back together. We’ve had to add a few rebasing workflows to our toolbelt in order for things to be smooth and orderly with as few surprises as possible.

Rebasing?

Think of it exactly as it sounds: re-base: “Move your base”. The idea is that you put all your new commits on top of all the commits that have piled up since you left. It’s kind of like code Jenga. A picture is worth a thousand words:

Here’s what’s happening:

1. I check out the integration branch (dev) at the start of the day.
2. I do my work (feature commit 1–4).
3. At the end of the day I look and someone has made two (green) commits on the feature branch.
4. Instead of merging, I rebase my changes on top of theirs.

When we do this we’re actually creating new, identical commits and deleting the old ones so it’s important to know that we will get new hash addresses for our commits once we rebase them. This is especially if we’re using child repos since we could very easily rebase-away a commit that’s referenced by a parent and break everything.

How do I create a new feature?

The following is a standard steps for the checkout->branch->work->rebase->Push workflow. At first it seems like a lot of steps but after a few iterations it really started to make a lot of sense and now it’s second nature.

Ok, here we go:

1. Checkout: Check out the latest dev
2. Branch: Create a local feature branch dev-featurename. Note: do not push this branch. It will make rebasing harder later.
3. Work: Ugh, but it’s so nice outside…. Code, coffee, code code code commit coffee code commit etc.
4. Test: Yes, we all hate it but it’s easier than explaining why you broke the build.
5. Rebase: dev may have advanced in the time I took to create my feature so I need to rebase before I can merge with it:
6. Checkout dev and pull so my local integration branch is up to date
7. Checkout dev-featurename and rebase on top of local dev. Fix any conflicts or problems.
8. Checkout dev again and merge with dev-featurename. Merge should be smooth without any commits. If you get a commit. Rollback the merge commit and start over.
9. Push: Push dev up to master.
10. Get distracted by a shiny object and wander off.

Phew! That wasn’t so bad. There are a few gotchas though:

Troubleshooting and gotchas:

Rebasing after pushing

Let’s say you pushed your integration branch by accident. Oops. It’s definite fixable but it’s a little trickier though and takes a little bit of thought. Also you will have to do a git push -f from the command line. This command should not be used lightly so make sure you understand what you’re trying to do before hitting return. If anyone else is working on your remote branch they will get a nasty surprise.

When’s the best time to rebase?

The best time to rebase is just before you merge your feature branch back onto the integration branch. This will keep your feature branch moving along in a straight line with the dev (integration) branch.

That’s all folks

Overall rebasing has made our trees a lot straighter and our git commands a lot less gnarly. With git there are many pathways to do everything though. If you have a better one Let us know.

Some More Reading

Originally published at www.northarrowresearch.com.