使用分支——Git Merge命令

在Git中merge是用来把分叉的提交历史放回到一起的方式。git merge命令用来将你之前使用git branch命令创建的分支以及在此分支上独立开发的内容整合为一个分支。

请注意下面的所有命令都会是将其他分支合并到当前所在工作分支上。当前工作分支的内容会由于merge操作产生更新,但是目标分支则完全不受影响。再次强调,这意味着git merge通常与其他几个git命令一起使用,包括使用git checkout命令来选择当前工作分支,以及使用git branch -d命令来删除已经合并过的废弃分支。

它是如何运行的

git merge会将多个提交序列合并进一个统一的提交历史。在最常见的使用场景中,git merge被用来合并两个分支。在本文档接下来的部分,我们会专注于这种合并场景。在这种场景中,git merge接受两个commit指针,通常是两个分支的顶部commit,然后向前追溯到这两个分支最近的一个共同提交。一旦找到这个共同提交,Git就会创建一个新的"merge commit",用来合并两个分支上各自的提交序列。

比如说我们有一个功能分支由main分支派生出来,现在我们希望将这个功能分支合并回main分支。

01 Branch-2 kopiera.png

执行合并命令会将指定分支合并到当前工作分支上,我们假设当前工作分支为main。Git根据两个分支自行决定合并提交的算法(将在下面具体讨论)。

02 Branch-1 kopiera.png

合并commit与普通commit不一样,因为合并commit会有两个父提交。创建一个合并commit时Git会尝试自动将两个独立的提交历史合并为一个。不过当Git发现某一块数据在两边的提交历史中都含有变更,它将无法自动对其进行合并。这种情况被称为版本冲突,此时Git需要人为介入调整才能继续进行合并。

准备合并

在实际进行合并操作之前,需要进行一些准备步骤,以保证合并过程能够顺利进行。

确认接收合并的分支

执行git status命令查看当前分支的状态,确保HEAD指正指向的是正确的接收合并的分支。如果不是,执行git checkout命令切换到正确的分支。在我们的示例中,执行git checkout main

获取最新的远程提交

确保合并操作涉及的两个分支都更新到远程仓库的最新状态。执行git fetch拉取远程仓库的最新提交。一旦fetch操作完成,为了保证main分支与远程分支同步,还需执行git pull命令。

合并

当上面提及的准备工作都已完备,合并就可以正式开始了。执行git merge <branch>命令,其中<branch>为需要合并到当前分支的目标分支名称。

快进合并

当前工作分支到合并目标分支之间的提交历史是线性路径时,可以进行快进合并。在这种情况下,不需要真实的合并两个分支,Git只需要把当前分支的顶端指针移动到目标分支的顶端就可以了(也就是快进的意思)。在这种情况下快进合并成功的将提交历史合并至一处,毕竟目标分支中的提交此时都包含在当前分支的提交历史中了。对于将功能分支快进合并到main分支的流程可以参见下图所示:

03-04 Fast forward merge.png

然而快进合并在两个分支出现分叉的情况下是不允许执行的。当目标分支相对于当前分支的提交历史不是线性的,Git只能通过三路合并算法来决定如何对两个分支进行合并。三路合并算法需要使用一个专用commit来整合两边的提交历史。这个名词源于Git要想生成合并commit,需要用到三个commits:两个分支的顶端commit,以及它们的共同祖先commit。
05-06 Fast forward merge.png

虽然实际上可以选择使用这些不同的合并策略,但是大多数开发者更喜欢快进合并(通过利用 rebasing 命令),尤其是用于小功能的开发或者bug修复;反之对于合并长期开发的功能分支,则更倾向于使用三路合并的方式。在第二种场景中,merge产生的合并commit会作为两个分支合并的标志保留在提交历史中。

接下来我们用下面第一个例子来展示如何进行快进合并。下面的命令会先创建一个新分支,在新分支上进行两次提交,然后用快进合并把新分支合并回main分支。

# Start a new feature
git checkout -b new-feature main
# Edit some files
git add <file>
git commit -m "Start a feature"
# Edit some files
git add <file>
git commit -m "Finish a feature"
# Merge in the new-feature branch
git checkout main
git merge new-feature
git branch -d new-feature

这个例子中的工作流程通常用于短期功能的开发,这种开发流程更多地被当做是比较独立的一次开发流程,与之对应的则是需要协调和管理的长期功能开发分支。

另外还需注意到,在此例中Git不会对git branch -d命令发出警告,因为new-feature的内容已经合并到主分支里了。

在某些情况下,虽然目标分支的提交历史相对于当前分支是线性的,可以进行快进合并,但你仍然希望有一个合并commit来标志合并在此commit发生过,那么可以在执行git merge命令时使用--no-ff选项。

git merge --no-ff <branch>

以上命令将指定分支合并到当前分支,但总会生成一个合并commit(即便这一合并操作可以快进)。当你需要在仓库的提交历史中标记合并事件时这一命令相当有用。

三路合并

接下来的例子与上面比较像,但是因为main分支在feature分支向前发展的过程中,自身也发生的改变,因此在合并时需要进行三路合并。在进行大的功能开发或者有多个开发者同时进行开发时这种场景相当常见。

Start a new feature
git checkout -b new-feature main
# Edit some files
git add <file>
git commit -m "Start a feature"
# Edit some files
git add <file>
git commit -m "Finish a feature"
# Develop the main branch
git checkout main
# Edit some files
git add <file>
git commit -m "Make some super-stable changes to main"
# Merge in the new-feature branch
git merge new-feature
git branch -d new-feature

需注意在这种情况下,由于没有办法直接把main的顶端指针移动到new-feature分支上,因此Git无法执行快进合并。

在大多数实际工作场景中,new-feature应该是一个很大的功能,开发过程持续了相当长的时间,这也就难免同时期在main分支上也有新的提交。如果你的功能分支大小像上面的例子一样小,则完全可以使用rebase将new-feature分支变基到main分支上,然后再执行一次快进合并。这样也会避免在项目提交历史中产生过多的冗余。

解决冲突

如果将要合并的两个分支都修改了同一个而文件的同一个部分内容,Git就无法确定应该使用哪个版本的内容。当这种情况发生时,合并过程会停止在合并commit提交之前,以便给用户留下机会手动修复这些冲突。

在Git的合并过程中,很棒的一点是它使用人们熟知的 编辑 / 暂存 / 提交 这样的工作流程来解决冲突。当碰到合并冲突时,执行git status命令会列出哪些文件含有冲突并需要手动解决。比如说当两个分支都修改了hello.py文件的同一部分,你会看到类似下面这样的信息:

On branch main
Unmerged paths:
(use "git add/rm ..." as appropriate to mark resolution)
both modified: hello.py

冲突是如何显示的

当Git在合并过程中碰到了冲突,它会编辑受影响的文件中的相关内容,并添加视觉标记用以展示冲突中双方在此部分的不同内容。这些视觉标记为:<<<<<<<,=======,>>>>>>>。要找到冲突发生的具体位置,在文件中搜索这些视觉标记会非常便捷地达成目的。

here is some content not affected by the conflict
<<<<<<< main
this is conflicted text from main
=======
this is conflicted text from feature branch
>>>>>>> feature branch;

通常来说在 ====== 标记之前的内容来自于接收合并的分支,而在这之后的内容来自于要合并的分支。

一旦找到冲突的部分,就可以根据需要来修正冲突。当你完成了冲突的修复并准备好继续进行合并,只需要执行git add命令把已经解决好冲突的文件添加暂存区,告诉Git这些冲突已经解决完毕即可。这之后就像正常提交代码一样执行git commit完成合并commit。这个过程跟正常情况下提交代码是完全一样的,也就是说对于普通开发者来说处理冲突也是小菜一碟。

还需注意合并冲突只可能出现在三路合并过程中,在快进合并中不会出现冲突。

总结

本文是关于git merge命令的概览。在使用Git的过程中,合并是非常重要的操作。本文讨论了合并操作背后的机制,以及快进合并与三路合并的区别。需要读者记住的要点如下:

  1. Git 合并流程是把不同的提交序列合并到一个统一的提交历史中
  2. Git合并过程中有两个主要的方式:快进合并 和 三路合并
  3. 除非两个提交序列中出现冲突,Git通常可以自动对提交进行合并
最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 204,053评论 6 478
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 85,527评论 2 381
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 150,779评论 0 337
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 54,685评论 1 276
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 63,699评论 5 366
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,609评论 1 281
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 37,989评论 3 396
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,654评论 0 258
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 40,890评论 1 298
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,634评论 2 321
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,716评论 1 330
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,394评论 4 319
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 38,976评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,950评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,191评论 1 260
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 44,849评论 2 349
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,458评论 2 342

推荐阅读更多精彩内容