这是我参与「第四届青训营 」笔记创作活动的第3天

前言

这次青训营的大项目开发，我们队许多人都是第一次经历团队任务，对Git在团队开发中的各种知识都还不熟悉，不了解。在开发的过程中我们也踩了不少大大小小的坑，其中最大的坑莫过于合并分支了。遂将踩坑历程记录下来。

分支的合并

首先，分支是多人合作的基础，大家从main上分出一条，各自开发，当完成任务后再合入。这是现在的git工作流的基本操作。那么，分支的合并的原理是什么，什么时候可以自动合并，什么时候又会自动合并失败，需要人工介入进行干预呢？

原理

git 合并文件是以行为单位进行一行一行进行合并的，是靠三路合并算法进行合并的。在单人开发中，总是本地开发-->提交-->推送，因为没有其他人来对你的仓库做修改，所以本地的提交一定是最新的，也不会有冲突等一系列问题，整个工作流就像一条射线：

但是，但有其他人开发时，如果没有分支，大家全部在一条线上提交的话，就会出现非常混乱的景象：

此时c1就无法提交了，必须先拉取c2的内容，每次提交都要拉取，而且拉取的时候可能别人已经把你的内容改掉了，就非常的不方便。

策略

git会有很多合并策略，最常见的几种是 Fast-foward，Recursice，Ours 。默认git会帮你自动挑选合适的合并策略，也可以通过git merge -s 策略名来指定使用的策略类型。

Fast-foward

这适用于没有分叉的分支，Git可以直接将head指向最新提交，在多人开发中并不常用。

Recursive

Recursive是最常用的合并策略，描述为：通过算法寻找两个分支的最近公共祖先节点，再将找到的公共祖先节点作为base节点使用三向合并的策略来进行合并。当遇到冲突时，git会进行修改提示，你可以手动修改，也可以指定参数-Xours， -Xtheirs参数，前者意思是遇到冲突时全使用本地的，后者则相反。

Ours

该策略与-Xours参数有些类似，但是比它更激进，该策略是无论有无冲突，git会完全丢弃被合并分支上的内容，只保留合并分支的上的修改。

后记

以上便是最基础的git分支操作，用来应付基础的多人合作已不成问题，当然，还有类似rebase这些更高级的操作，有待于日后更深入的学习了。