Git自学成才——git merge

1,640 阅读3分钟

概念

git merge 和 git rebase 是使用率非常高的两条指令 本文对git merge的日常使用场景做一个梳理,git rebase请看 Git自学成才——rebase完整版

假设我有一个开发分支dev,有一个主干分支master

关于哪个分支合并到哪个分支,很多人会有混淆和困惑。其实,你需要往哪个分支上面合并,就要切换到哪个分支

比如,现在要 把dev分支merge到master分支

首先,保证两个分支都是最新的状态

切换到master分支,执行merge操作

git checkout master
git merge dev

git merge 命令用于合并指定分支到当前分支

基础

上面是最基本的git merge,git merge默认采用快进(fast-forward)的方式,产生类似如下的log

Updating f42c576..3a0874c
Fast-forward
 index.html | 2 ++

何为 快进(Fast-forward)?

在合并的时候,你应该注意到了"快进(fast-forward)"这个词。 由于当前master分支所指向的提交是你当前提交的直接上游,所以 Git 只是简单的将指针向前移动。 换句话说,当你试图合并两个分支时,如果顺着一个分支走下去能够到达另一个分支,那么 Git 在合并两者的时候,只会简单的将指针向前推进(指针右移),因为这种情况下的合并操作没有需要解决的分歧——这就叫做 “快进(fast-forward)”。

如果merge的时候没有冲突, 没有新的commit节点产生,只是移动分支的指针,来实现merge

如果merge的时候有冲突, 产生类似如下的log

Auto-merging index.html
CONFLICT (content): Merge conflict in index.html
Automatic merge failed; fix conflicts and then commit the result.

需要手动解决冲突,然后执行add,再commit

git add index.html 
git commit -m "conflict fixed Your message..."

实战

基本知识了解完,来看一下实战中的三种操作

无节点merge

很多公司或者组织会大量使用分支,他们不喜欢在master分支看到错综复杂的merge节点,所以他们的要求是无节点的merge(看起来所有的commit都是一条直线),这样的视觉效果清晰可读性很强。

实现无节点merge,其实是用到merge指令的默认特性——快进(Fast-forward),因为快进方式的merge不会产生节点,只会移动分支的HEAD指针。

问题是,快进的特性是在没有冲突的情况下产生,而执行merge大概率的情况会有很多冲突。这里搭配rebase变基操作更加合适,具体的rebase操作请看 Git自学成才——rebase完整版

完成rebase操作之后,在master分支上执行

git merge dev

...
Fast-forward
...

你会在SourceTree里看看master分支已经包含了dev分支的commit,并且是 一条直线

有节点merge

另外一些情况,被要求所有的merge操作必须要保留节点

如果merge有冲突,手动解决完冲突后,add 冲突的文件,再commit,这样已经产生了一个merge节点。

如果要求强制产生merge节点,使用 --no-ff 参数告诉merge,我们不需要快进(no-ff : no fast forward)

git merge --no-ff -m "merged dev" dev

这样会产生一个 “merged dev” 的commit节点

单节点merge

在某些情况下,需要我们的merge只产生一个commit节点

这时,我们需要压扁参数squash(可以理解为压缩提交),squash和no-ff非常类似,区别是不会保留对合入分支的引用。也就是说,squash把dev分支的代码压缩在一起,在master分支只提交一次。

git merge --squash dev
git commit –m "squash dev"

这样的操作会在你的master分支上只产生一个"squash dev"节点(包含了dev分支上的多个commit内容)

以上三种merge方式基本涵盖了日常实战的场景,一图以蔽之

merge.png

更多内容请参考官方手册 Git 分支 - 分支的新建与合并 git-merge