Getting geeky with Git #5. Improving merge workflow with rebase
- 1. Getting geeky with Git #1. Remotes and upstream branches
- 2. Getting geeky with Git #2. Building blocks of a commit
- 3. Getting geeky with Git #3. The branch is a reference
- 4. Getting geeky with Git #4. Fast-forward merge and merge strategies
- 5. Getting geeky with Git #5. Improving merge workflow with rebase
Merging is not the only utility that can integrate changes from one branch onto another. In this article, we look into rebasing and learn how we can use it as an alternative to merging.
The basics of rebasing
In the previous part of this series , we’ve learned that merging can result in an additional merge commit . This might not be the desired outcome if we aim for the readability of our git logs.
Rebase aims to rewrite git history so that it is simple and straightforward. To visualize it, let’s start with a clean repository:
echo "# rebase-repo" >> README.md git init git add README.md git commit -m "Initial commit" git remote add origin email@example.com:mwanago/rebase-repo.git git push -u origin master
If you want to know the importance of the - u flag, check out the first part of this series .
Below, we simulate a very common situation. Imagine creating a new branch from master and starting to work on it. Before you finish up and want to merge it back to master, it contains some new changes.
git branch feature-two echo "console.log('Feature one')" > feature-one.js git add ./feature-one.js git commit -m "Added the first feature" git push origin master
Above, we create the feature - two branch and add some changes to the master. Now, our feature - two is 1 commit behind the master branch. Let’s continue by adding some stuff to the feature - two .
git checkout feature-two echo "console.log('Feature two')" >> feature-two.js git add ./feature-two.js git commit -m "Added the second feature" git push origin feature-two
Now, both the master and the feature - two contain some new code. Let’s check the current state of the feature - two with git log :
commit 536676c27b51922b6e65568cebc1b7a9932704e0 (HEAD -> feature-two, origin/feature-two) Author: Marcin Wanago <firstname.lastname@example.org> Date: Sun Jul 26 18:35:46 2020 +0200 Added the second feature commit b828ed40f9edd2aa56d99d4d351c624d7c6fbcef Author: Marcin Wanago <email@example.com> Date: Sun Jul 26 18:22:35 2020 +0200 Initial commit
Performing a rebase
To integrate those two, we could merge the feature - two into master, but that would create a merge commit. Instead, let’s use rebase .
git rebase master
First, rewinding head to replay your work on top of it… Applying: Added the second feature
Now, let’s see the git log again:
commit 6c943d260b6aa0fabfe77899babb8bb67ebb1e95 (HEAD -> feature-two) Author: Marcin Wanago <firstname.lastname@example.org> Date: Sun Jul 26 18:35:46 2020 +0200 Added the second feature commit 318ff57e470d10dfe5924da38455b85dac667898 (origin/master, master) Author: Marcin Wanago <email@example.com> Date: Sun Jul 26 18:35:30 2020 +0200 Added the first feature commit b828ed40f9edd2aa56d99d4d351c624d7c6fbcef Author: Marcin Wanago <firstname.lastname@example.org> Date: Sun Jul 26 18:22:35 2020 +0200 Initial commit
With rebasing, we re-wrote the history of the feature - two branch. When doing that, we moved all of the changes from master to the feature - two branch and applied our changes on top of it.
The important thing is that when we rebased, Git created brand new commits when applying our changes on top of the commits from the master branch. To see it better, take a closer look at the above logs. We can see that the hash of our new commit changed.
commit 536676c27b51922b6e65568cebc1b7a9932704e0 Added the second feature commit 6c943d260b6aa0fabfe77899babb8bb67ebb1e95 Added the second feature
Even though the above commits bring the same set of changes, they are different from the Git point of view.
Pushing our rebased changes
There is one important thing to cover here. If we would like to push the rebased version of our feature - two branch to our remote repository, we might encounter some issues. Let’s try to do so:
git push origin feature-two
To github.com:mwanago/rebase-repo.git ! [rejected] feature-two -> feature-two (non-fast-forward) error: failed to push some refs to ‘email@example.com:mwanago/rebase-repo.git’ hint: Updates were rejected because the tip of your current branch is behind hint: its remote counterpart. Integrate the remote changes (e.g. hint: ‘git pull …’) before pushing again. hint: See the ‘Note about fast-forwards’ in ‘git push –help’ for details.
The reason for the above is because we rewrote the history of our local feature - two branch and it no longer matches its remote counterpart. The most straightforward way to deal with it is to force push it.
git push --force origin feature-two
Using the -- force option allows us to overwrite the remote branch even if our local version of it does not strictly match it.
This is not safe, though. Imagine someone else building up on top of your branch while you are rebasing. Using the -- force flag would cause all of that work to be erased. Instead, we can use the -- force - with - lease flag.
git push --force-with-lease origin feature-two
The above flag is a safer option that refuses to update the branch if somebody updated the remote branch. Aside from that, you should use this option with some caution and perform it only on branches that you don’t expect anybody else to push to.
If you want to read more about -- fore - with - lease , check out this article on the Atlassian Developer blog.
Advantages of rebasing
In the previous part of this series , we’ve learned about the fast forward merge . It can occur if there is a linear path between the source branch and the target branch.
We’ve committed to master after creating the feature - two branch. Even though that’s the case, we rewrote the history in a way that our feature - two contains all the commits from the master branch.
Now, we can switch to the master branch and merge our changes.
git checkout master git merge feature-two
Updating 318ff57..6c943d2 Fast-forward feature-two.js | 1 + 1 file changed, 1 insertion(+) create mode 100644 feature-two.js
The crucial thing above is the fact that we’ve performed a fast-forward merge . Let’s look into the git log now:
commit 6c943d260b6aa0fabfe77899babb8bb67ebb1e95 (HEAD -> master, origin/feature-two, feature-two) Author: Marcin Wanago <firstname.lastname@example.org> Date: Sun Jul 26 18:35:46 2020 +0200 Added the second feature commit 318ff57e470d10dfe5924da38455b85dac667898 (origin/master) Author: Marcin Wanago <email@example.com> Date: Sun Jul 26 18:35:30 2020 +0200 Added the first feature commit b828ed40f9edd2aa56d99d4d351c624d7c6fbcef Author: Marcin Wanago <firstname.lastname@example.org> Date: Sun Jul 26 18:22:35 2020 +0200 Initial commit
As you can see, there is no merge commit whatsoever. By sticking to rebasing, we end up with a linear project history that we can easily follow from the tip down to the bottom.
When not to rebase
The most important thing about rebasing is not to do it on public branches. Above, we rebased master into our feature - two branch. Then, we’ve merged the feature - two branch back to master using a fast forward merge . While this is fine, doing it the other way would cause trouble.
Rebasing overwrites history, and we need to acknowledge that everybody on our team uses the master branch. Therefore, if we would rewrite the history in remote master, it would cause all of its local copies not to match. Since rebasing results in creating new commits under the hood, Git will think that the history of the remote master diverged from the local copies that our teammates maintain. Avoiding that is sometimes referred to as the golden rule of rebasing .
In this article, we’ve learned what rebase is and how to perform it. It certainly does have advantages and can simplify our Git history. On the other hand, before rebasing, we need to think if anyone else might use the branch that we are working on. When considering if we should rebase, we should take it into account. The goal should be improving our Git flow and not the other way around.
Rebasing has more functionalities that we can describe as interactive rebasing . It is a cool topic, and you can expect it in this series.
- 使用 Git 和 Npm 规范管理 npm 包
- Xcode Tips 011：minimap 显示所有信息列表
- Discourse 如何安装插件
- Windows 版本的 Webrtc 的编译 ( 基于声网镜像 )
- （六）整合spring cloud云服务架构 - 企业云架构common-service代码结构分析
- windows server 下自动编译部署asp.net webapi 和 vue项目实例