Rebase is the black sheep of git tools, and generally is shied away from in favour of normal merges by those learning git purely for work.
Why make your history pretty when
Merged fix-api-calls into mainis just an automated click away?
“Why take the risk of losing commits if you make mistakes?”
Pathological risk taking behaviour.
“Nobody reads git history anyway!”
Understandably so.
Here’s some merge soup:
How to
Typically there’s a checkbox on pull, or a dropdown on git guis that mention something about rebase.
GitKraken keeps it in a dropdown
If you’re feeling vanilla, you can use:
git pull --rebase
or
git pull -r
Lazy Config Changes
If you really don’t feel like changing anything, you can set it per repository or globally by updating your git config.
Current Repo Only
git config pull.rebase true
Globally
git config --global pull.rebase true
More info on StackOverflow.
So what is this doing?
Rebase is a tool within the git ecosystem, which lets you rewrite the past.
Fundamentally what rebase does, is allow you to change which commit you branched off initially. You can use this to merge in changes someone pushed to your current branch, without using that messy merge commit.
The actual intricacies are pretty useful to know if you’d like to use interactive rebase, or use it to squash some commits you have locally together, a good description is here.
Force Push and Detatched HEAD
To wrap up, one of the risks that rebase poses is the rewrite of commits already existing. If you run into issues with your work, see git reflog, which keeps track of all your recent dropped or deleted commits so you can restore them. I’d also err on the side of caution and recommend against doing Force Push unless you understand the related risks, and how to mitigate them.
Writeup by – Matthew Davies
