Merging, Rebasing, Arguing – A Presentation on Git Workflows – Arguing About Two Things
Merging, Rebasing, Arguing
A Presentation on Git Workflows
Arguing About Two Things
Often when you have two things with similar use cases, it's important to pick a side and have heated arguments over which is better.
You know the ones. Those age old battles dividing even the most sanguine of individuals:
- IPA vs Stout
- VHS vs Betamax
- LoL vs DoTA2
- Coke vs Pepsi
And now: Merge vs Rebase
But not really
Me Being Hilarious Aside
Git is a swiss army knife with an eye-watering array of little fold out tools. Select the right little fold out tool that's right for you.
This may involve merge or rebase, or even both -- yikes
Let's do a quick recap of merge and rebase
Merge
Brings changes from named commits into the current branch. The changes brought in are based on when the histories of the two diverged.
Rebase
Replays a number commits ontop of a base commit
Both merge and rebase work by replaying commits. Merge is often not discussed in these terms, but that's how it do.
What follows and procedes this slide reflects my opinion (except where it's cold hard facts. The difference is left as an exercise to the viewer)
'All these facts and opinions look the same. I can't tell them apart.'' - Joy (of Inside Out)
How I Feel
Merge and rebase are underpinned by the same tech, they don't do anything radically different.
- They don't result in different underlying data referenced by commits
- Conflict resolution is not handled differently with either
- Both are viable ways to integrate changes from branches into other branches
There are Some Differences
The above said, a really important difference to note is that rebase rewrites commits by chaning their parent, while merge does not.
Rebase is sometimes described as destructive because of this.
So What's to Care About?
Managing your workflow and history is important. Merge and rebase give you different tools to manage these things.
There are Plenty of Workflows
People and teams use many different workflows and stratergies for managing history. I don't really believe in telling you to use one in particular, and would encourage you to try and find one that suits you and/or your team.
Easy for Me to Say, Right?
Absolutely. Groovy things can take time, and often do. Let me give you some examples of workflows that work well for me, in the context of discussing merge and rebase.
New to Git?
Caveat: when getting started with git I'd recommend keeping your workflow simple and gradually expanding your knowledge out. I'd say start out with just merge, and then throw some rebases in there once you're comfortable. In my opinon bad merges are a little less vile to undo than bad rebases.
What Kind of Workflow?
There's a number of workflows I've encountered in my travels, let me talk about some of them and how merge and rebase can fit into them.
Branch and Merge
It can be that you have branches that are merged into master, and then those branches are left to exist (the following commands are executed on master):
git merge my_branch
Maybe you want to merge the branch but then delete it:
git branch -d my_branch
Branch and Merge + Grooming Branches
Maybe you want to clean that branch by squashing some commits, or rewriting their commit messages, before merging said branch? In this case interactive rebase may be your friend (executed while on your branch):
git rebase -i
Branch and Rebase
Instead of merging changes into master, you can rebase your changes onto master (the following commands are executed on master):
git rebase my_branch
Or do so interactively, so you can mess with the commits while you rebase:
git rebase -i my_branch
It's About Workflows
Those examples are simple, but exemplify the importance of bearning in mind different workflows people want:
- Some people don't mind branches being messy because they're going to be deleted
- Some people think you shouldn't alter history via rebase because the commit graph should reprsent what actually happened
- Some people value a concise history over the above
Make an Informed Decision
There are certainly places where merge and rebase can overlap. Decide which is best for you/your team/whatever based on the outcomes you want.
Use both merge and rebase -- we're living in the future!
Arguing
Once you've considered that there are many different workflows, and that one size doesn't fit all, and thought through the pros and cons of your preferred workflow: well then I guess you can start flaming people on the internet.