Git的merge命令实例分析

这篇文章主要介绍"Git的merge命令实例分析"的相关知识，小编通过实际案例向大家展示操作过程，操作方法简单快捷，实用性强，希望这篇"Git的merge命令实例分析"文章能帮助大家解决问题。

它是如何运行的

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

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

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

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

准备合并

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

确认接收合并的分支

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

获取最新的远程提交

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

合并

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

快进合并

当前工作分支到合并目标分支之间的提交历史是线性路径时，可以进行快进合并。在这种情况下，不需要真实的合并两个分支，Git只需要把当前分支的顶端指针移动到目标分支的顶端就可以了（也就是快进的意思）。在这种情况下快进合并成功的将提交历史合并至一处，毕竟目标分支中的提交此时都包含在当前分支的提交历史中了。

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

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

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

# Start a new featuregit checkout -b new-feature main# Edit some filesgit add git commit -m "Start a feature"# Edit some filesgit add git commit -m "Finish a feature"# Merge in the new-feature branchgit checkout maingit merge new-featuregit branch -d new-feature

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

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

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

git merge --no-ff 

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

三路合并

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

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

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

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

解决冲突

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

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

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

冲突是如何显示的

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

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

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

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

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

关于"Git的merge命令实例分析"的内容就介绍到这里了，感谢大家的阅读。如果想了解更多行业相关的知识，可以关注行业资讯频道，小编每天都会为大家更新不同的知识点。