Rebase is one of the most powerful tools in Git’s arsenal, but it can trip up people coming from centralized version control systems. This is just a quick example of why, and when, you’d want to use it.
Let’s say we’ve got a team of three developers. Monday morning they all come in, Bob makes a quick commit, and shares it with everyone. They all do a git pull and suck it into their repos.
Tuesday Mary does some work, but Bob and Tom are taking the day off and don’t pull in her changes yet.
Wednesday Tom makes a change and everyone pulls it into their repos.
Now depending on what changes Mary has made Bob and Tom may be able to pull them in without problem. Then again it could result in a conflict. But Mary’s a pro who thinks of her teammates, so she’s going to rebase her repository and reorder the commits so that her change is on top of Tom’s. Now, if Mary’s changes were such that they’d cause a conflict when Bob and Tom pulled them in then they’ll cause a conflict for Mary when she rebases, but they’re Mary’s changes so she’s the one most capable of resolving those quickly. Also, if Mary takes care of it in the rebasing then no-one else is going to have to deal with the conflict. It’s much better to have the person who wrote the change resolve it than have everyone else on the team have to deal with it.
So, Mary reorders her commits with git rebase, and if there were any conflicts she resolves them. When the others pull down her changes it’ll look like she wrote them on top of the changes they already had.
Another reason Mary might want to rebase is if she made a bunch of partial commits along the way. She might do this to give herself multiple roll-back points, or maybe she committed every time she finished working on one of the files related to the current feature she’s implementing, just so she wouldn’t have to worry about loosing anything. Now, she wouldn’t want to share those partial commits because they’d probably break something in other people’s system. So, when she finishes with her work, she uses rebase to squash the partial commits into one nice clean commit and then tells people to pull that, or maybe pushes it to some common repo they all push changes to.
Rebase is an incredibly powerful tool, but there’s one thing you must remember to never do and that’s rebase commits that have already been shared with others. For example: Git wouldn’t prevent Mary from rebasing the “Bob - Monday” commit up after all the other commits, or merge it into the commit she made on Tuesday, but doing so is guaranteed to cause problems for anyone who tries to pull from her. So rebase your own work before you set it free, but once others have it you can’t touch it.
This work is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 United States License
If you found this useful you might be interested in some of the other git posts here.