Recommendation
Do not use git pull --rebase or git rebase on public branches such as master.
Original Text
This article is transcoded by SimpRead, original source at ryderfang.com
Git operations are essential skills every programmer must master. When I just graduated, everyone was still using svn as the version control tool.
However, in recent years, everyone has basically switched to git, and even within our project, UI slicing has started to be managed with git.
Thanks to the great invention of Linus Torvalds!
In general, the commonly used commands are nothing more than:
$ git init
$ git checkout
$ git add
$ git pull
$ git push
$ git merge
Before talking about rebase, let’s emphasize the golden rule:
Never use rebase on a public branch!!
Rebase is an advanced command often compared with merge.
rebase vs merge
$ git checkout feature
$ git merge main
// or
$ git merge feature main
Merging the main branch into feature:
This will create a new commit on the feature branch, which is a merge commit.
As for rebase:
$ git checkout feature
$ git rebase main
You can see that all commits on the feature branch are placed before main, forming a straight line in the history.
It is noteworthy that all commits in feature are rebuilt, their hashes are no longer the original ones!
Therefore, compared to merge, the advantages of rebase are:
- The timeline is cleaner, which satisfies those with perfectionism and neatness preferences.
To achieve this, it compromises on safety and traceability[1]. If you do not follow the rebase golden rule, it will bring disaster!
The drawbacks of rebase are obvious:
- Improper use can cause serious consequences.
- Difficult to trace history, for example, after rebasing the feature branch above, you cannot know when it was branched from main or when it was merged back.
git pull
First, git pull is a combination of two actions: git fetch + git merge FETCH_HEAD.
For example, git pull origin master first fetches origin/master, then merges the local branch with origin/master.
If you have a commit locally that has not been pushed to remote, and meanwhile your colleague has committed to the same branch, when you fetch, you will find that the local branch is both ahead and behind:
- If you perform the merge operation at this time:
Merge made by the ‘recursive’ strategy.
It will generate a merge node!
- What if you perform rebase?
The local commits will be rebuilt and placed on top. (You can see the commit IDs are different.)
After pushing, the timeline becomes a straight line!
Therefore, for the git pull operation, in most cases, using the --rebase option is more appropriate!
We can set git pull to use rebase by default:
# Only effective for master branch
git config branch.master.rebase true
# Effective for all tracking branches
git config branch.autosetuprebase always
# Effective for all pull operations
git config pull.rebase true
The above only affects git in the current directory. To apply globally, remember to add the
--globaloption.
# Editing manually is more convenient!
git config --global --edit
Taboo of rebase
Let’s review the golden rule again:
Never use rebase on public branches!!
If you and your colleagues share a feature branch and you use rebase to sync with the mainline, there is a high chance of losing your colleagues’ code!
Let’s see how this happens:
- First, we branch a feature from master:
At this point, two colleagues are developing on this branch peacefully.
- One day, a colleague suggests syncing some updates from the mainline to the feature branch:
- “Sure, sure,” but how to sync? Should we try the newly learned
rebasecommand?!
3.1. Your colleague says “sure” and commits several times on their local feature and pushes to remote!
You are unaware that your local feature branch does not fully include your colleague’s commits. Meanwhile, you start the dreadful rebase operation:
Then, you find the push fails:
- So, impulsively you decide to force it with
--force:
At this point, your colleague updates their code and finds: “Where did my code go??!!”
What to do? #
Is there a way to remedy this? Yes!
Have your colleague use git reflog:
Find the lost commit and submit it back to the feature branch with git cherry-pick [commit-id]!
But! We still should not casually use --force to cause such dangerous situations.
Consider this scenario:
As mentioned earlier, ahead means the local branch has three changes; behind means the remote branch has four changes not synced locally.
If we force push, remote commits will be lost, so we try the --force-with-lease option:
No difference, the push still goes through!
In this case, knowingly being behind locally but still forcing a push, --force-with-lease acts the same as --force!
The normal practice is:
git pull --rebase to update the local branch
And git push --force-with-lease can handle scenarios where others have pushed to the branch during the rebase-push. This push will be rejected, which is comparatively safer.
Therefore, all in all, the golden rule is:
Never use rebase on public branches!!
For collaborative branches, to sync mainline, please use merge!!