【Git】git rebase 命令合并分支

 

目录

一. 问题

二. 解释

2.1 git merge

2.2 git rebase

三. 参考

---

 

一. 问题

一般意义上来说，git 合并分支有2种方式:

// 1. merge 方式
git merge --no-ff other_branch_to_current

// 2. rebase 方式
git rebase other_branch_to_current

 

实际上，我观察到好多小伙伴用的都是merge 的方式，有关merge 合并方式参考如下列举的参考部分;

如果用到了fast-forwards 模式，建议使用rebase 方式;

 

那啥是fast-forwards 模式呢？

按照中文翻译就是快速前进的意思，按照我自己的理解就是线性递增的意思;

 

二. 解释

新建三个分支master，developer，anonym 节点结构如下:

首先切换到master 分支:

git checkout master

使用如下命令，查看当前分支节点结构:

git log --graph --pretty=oneline --abbrev-commit

如下图所示:

// master 分支
$ git log --graph --pretty=oneline --abbrev-commit
* 14ed38e (HEAD -> master) G
* 0a95e58 F
* 29a608d E
* 778d30f D
* d4440c7 C
* d4fddd3 B
* 0415305 to add A files

// developer 分支
$ git log --graph --pretty=oneline --abbrev-commit
* 5869af6 (HEAD -> developer) B5
* ed44e13 B4
* 43379af B3
* 0bfce2b B2
* aff3f09 B1
* 0fd3e3f to add B files
* d4440c7 C
* d4fddd3 B
* 0415305 to add A files



// anonym 分支
$ git log --graph --pretty=oneline --abbrev-commit
* 8abf577 (HEAD -> anonym) C5
* 0dc605f C4
* 87ad1d0 C3
* 866a379 C2
* 10bd9c3 C1
* f72b441 to add C files
* 0bfce2b B2
* aff3f09 B1
* 0fd3e3f to add B files
* d4440c7 C
* d4fddd3 B
* 0415305 to add A files

节点顺序都是线性递增关系，看着比较干净和清爽，其实为了注释好看，有洁癖的还可以节点压缩合并(git rebase -i HEAD^n);

2.1 git merge

如果使用merge 方式，如下所示：

// 切换到 master 分支
$ git checkout master

// 合并 developer 分支到current(master)
$ git merge --no-ff developer

可以看出就是简单的两个分支合并，且生成一个分支合并节点，非线性合并方式;

实际执行过程:

dc836e2 (HEAD -> master) HEAD@{0}: merge developer: Merge made by the 'recursive' strategy.

使用场景:

1. 远程公共开发分支developer 和各个小伙伴特性分支feature_xyz 合并的情况，此时优先建议使用merge 方式，不建议使用rebase 方式;

2. 工作流方式下的合并，比如feature -> developer，developer -> release/master，hotfix -> master 等的过程，建议使用pull requests(merge) 方式;

 

2.2 git rebase

如果使用rebase 方式，如下所示:

// 切换到 master 分支
$ git checkout master

// 合并 developer 分支到current(master)
$ git rebase developer
First, rewinding head to replay your work on top of it...
Applying: D
Applying: E
Applying: F
Applying: G

可以看出两个分支合并，成线性合并方式了，且没有相应的分支合并节点出现;

实际执行过程为，master 分支和developer 分支，向上溯源，找到共同的节点B2，以developer 分支为基准，master[D,G] 节点从节点分支上拆分暂存出来，HEAD 指向B5，然后[D,G]追加到B5 后面，完成合并过程，如果此过程有冲突，需要解决冲突后继续变基合并;

执行过程:

903f0b7 (HEAD -> master) HEAD@{0}: rebase finished: returning to refs/heads/master
903f0b7 (HEAD -> master) HEAD@{1}: rebase: G
f053ec5 HEAD@{2}: rebase: F
a1d1cbd HEAD@{3}: rebase: E
6143f13 HEAD@{4}: rebase: D
5869af6 (developer) HEAD@{5}: rebase: checkout developer

使用场景:

1. 本地分支和远程分支同步的情况，强烈建议在本地分支提交到远程分支上的时候，先fetch，远程有更新则rebase，再push;
2. 在本地分支上，高频次提交生成的commit 信息或本地终端，多个特性调研分支，demo 研究分支上可多次commit，最终输出到远程分支上应该提前rebase 压缩合并或保持线性递增方式，再push 到远程分支;

 

三. 参考

1. https://blog.csdn.net/DovSnier/article/details/88663860
2. https://blog.csdn.net/DovSnier/article/details/103763516
3. https://blog.csdn.net/DovSnier/article/details/106327106
4. https://www.git-scm.com/docs/git-merge
5. https://www.git-scm.com/docs/git-rebase
6. https://git-scm.com/book/zh/v2
7. https://git-scm.com/book/zh/v2/Git-%E5%88%86%E6%94%AF-%E5%8F%98%E5%9F%BA

 

 

(完)