DEV Community

loading...

Discussion on: Explain to me git rebase

Collapse
jmau111 profile image
Julien Maury • Edited

Hi, nice question!

Git commands such as merge and rebase allow you to integrate modifications in your branch.

Git merges take all histories into account without changing anything in your branch that's why it's called a non-destructive operation. Git rebases might be riskier.

But why/when rebasing? Merging all the time may pollute your history with a lot of unnecessary merge commits. You want linear histories that's why pull by rebasing is better than pull by merging IMHO (default is merge):

git config --global pull.rebase true

You won't have a history full of messages like "merge master into master". You can verify this assertion with the git log command.

Pull by rebasing is super extra cool. If someone pushes modifications before you and you have made some commits locally in the meantime, you just have to pull and Git will automatically apply your commits after. So history remains nice and clean.

BUT manual rebasing is quite risky. So be extra cautious with this command. You might destroy Gotham :)
For example, if you run a manual rebase of master in your branch:

git rebase master

you cannot push just after. You need to run a push --force to override the remote master branch to match the rebased one from your local. You might run this only in very particular cases. Otherwise, you could mess up things for you and your teammates.

source

Forem Open with the Forem app