Last Updated: 2024-04-25

1. So what does rebase actually do?

# Let's put this in context with some sample code.

# You first checkout the branch that want to rebase
$ git checkout feature
# Then you carry out the rebase using format: git rebase [base]
$ git rebase master

Generally, git rebase moves a branch from one base commit to another. In this case it moves the entire "feature" branch so that it starts at the tip of "master". Or "rebasing feature onto master".

Under the lid, it works by collecting each commit that is an ancestor of the current commit but not of base, putting these changes aside, setting the current head (briefly) to base, then replaying these commits that were set aside.

2. When is rebasing typically used?

• Rebasing is a common way to integrate upstream changes into your local repository
• Its chief advantage is that it avoids extra merge commits (which reduce history readability), as would happen if you used git merge instead.
• With rebase, the commit history will be simpler and easier to follow.
• You should only do it before you go public with your local branch.
• Note, however, that it's fine for you (and probably advisable) to do git pull --rebase to grab upstream changes on your feature branch for local commits you have that were never pushed yet to remote.

3. Why should you never merge any public branch (esp. master) onto a feature branch?

i.e. such a command would be

# Checkout master
git checkout master
# Rebase it into `feature` as a base
git rebase feature

• When you push to remote, the history now differs so it won't result in a fast-forward merge like a feature-branch merge would. Therefore your push will be rejected unless you force push.
• Rebasing rewrites history, so, if this was force-pushed, anyone with branches that were checked out from this history will deal with a mess. Specifically, git pull will override any commits they have locally based off that branch. (If this happens, you can at least recover with git reflog)
• Thus, if someone else is possibly looking at your branch, yet you want to rebase it (e.g. to squash or remove commits), you should instead make these change in a non-destructive way (e.g. git revert)

References

• https://www.atlassian.com/git/tutorials/merging-vs-rebasing
• https://benmarshall.me/git-rebase/