- git merge
- git rebase
- merge VS rebase
- References
Write at the beginning:
There are always doubts about the usage of merge and rebase. It seems that both can complete "get commits from other branches to my branch". What is the difference between the two. Through some articles and experiments, they are organized as follows, and the reference materials are attached.
1.git merge
Let's look at the different ways of merging in the two scenarios.
- Scenario 1: After cutting out the feature branch, there are no new commits on the develop branch.
fast-forward, if there is no difference, the file pointer will be moved directly. The starting point of the feature branch is not visible.
no-fast-forward (--no-ff), preserve the integrity of the commit chain.
squash, compresses unnecessary commits; it cannot be seen that the feature branch is merged into develop; feature and develop remain relatively independent.
- Scenario 2: After cutting out the feature branch, C6 and C7 are submitted on the develop branch.
C6 and C7 have been submitted on the develop branch, which cannot be fast forwarded.
three way merge，
-
- Find the latest node C7 of the develop branch;
- Find the latest node C5 of the feature branch;
- Find the common ancestor node C3 of the develop branch and the feature branch;
- Three-way merge of C3, C5, and C7 to generate the latest C8.
2.git rebase
Rebase/rebase, rebase from the old base to the new base, reproduce the modification process of another branch on the basis of the new base, the version tree is like two chains strung together into a chain to achieve linearity Effect.
rebase has no effect on the specified base itself; it just rewrites the commit history after the base.
Let's look at a few scenarios:
- In the process of continuing development, it is synchronized with the main branch develop
Pull the branch from develop to do some development work. During this process, the develop branch may continue to move forward, so we need to keep it in sync with develop frequently (maybe someone else has submitted a common module, or repaired it for everyone.) Affected bug). I used pull to do this before, but pull often has merge built in (the effect of pull looks like fetch+merge, think about the mentioned "merge should reflect business-level merge, not technical behavior" , and at this point merge will produce some messy history).
This is equivalent to that our local development work (a series of commits) is carried out on the old base, and the rebase operation should be used to rebase the local development work to the latest node of the development.
git pull --rebase
- Pick up the shelved work
I may have started a parallel work a long time ago (developing new features or optimizing some functions that are not in a hurry to launch), but I haven't had time to deal with it, so I put it on hold, and now I have time to pick it up again, and then I found that the base it was based on was really too much. old. Now definitely want to work on the latest base so you can benefit from bugfixes that have been resolved or new features that have been done.
- Organize my local history before push
git rebase -i <myBaseCommit>
This is a more frequently used scenario: not to rebase, but to clean up local commits. In many cases we need to commit:
-
- It may take multiple consecutive commits to complete a bugfix;
- Switching branches needs to save local modifications (of course, it stands to reason that at this time you should use the shelve provided by stash or idea);
- Some historical commits write wrong msg (msg of the latest commit can be modified by commit --amend);
With -i (--interactive, interactive), we can intervene in the scripting process that rebase will execute, so as to achieve the purpose of cleaning up the local commit history.
Proficient in using rebase, you can easily commit, you only need to do a cleanup before the final push, and you don't have to worry about affecting the public repository.
git fetch origin develop
git rebase origin/develop
... do sth ...
git push
- rebase的场景和用法还有待探索，慢慢更新了。
记住这个：
只能rebase私有分支，一旦发布到公共仓库，不要再rebase了。
3.merge V.S. rebase
什么时候用merge；基于上述不同的merge行为（fast-forward，--no-ff，squash），什么场景下用哪种merge：
merge执行一个合并，这个合并应该反应业务层面的合并，而非技术行为。我们希望在当前分支上往前走，这样它就包含了其他分支的工作。
所以问题的关键是：这个“其他分支”是什么样的分支？这个“其他分支”需要在历史图谱中展示么？
- 本地的、临时的分支，使用它仅仅是为了使master保持clean。
1.若拉出本地分支后，master往前走了，此时在本地分支：
git rebase -i master
将本地分支变基到最新的master节点（重新梳理本地历史提交信息比如合并成一个commit），好似本地分支就是在最新的master节点上做的开发工作，以保证合并到master后呈现线性增长。
2.在master上：
git merge (fast-forward)
最终以一个或几个commit展现在master上。
- 知名分支，团队明确定义的，可能是用来追踪bug/feature。
永远不要用rebase，而是用
git merge --no-ff
以保留清晰完整的历史图谱。
4.参考材料
GETTING SOLID AT GIT REBASE VS. MERGE
Git team workflows: merge or rebase?
A successful Git branching model