Git merge 分支合并与 --no-ff 冲突处理详解

用途

git merge 主要用于分支合并

演示

如下是我们 master 的 commit 记录

然后我们基本 master 创建一个需求分支 feature，再在 feature 中提交两个 commit，下面是 feature 分支的 commit 记录

这时我们需求分支开发完了，需要将代码合并至 master，我们在 master 分支中执行下面的命令

git merge feature

执行合并后 master 分支的 commit 记录如下

如上述操作我们便完成了合并，但是我们直接使用 git merge 进行合并的时候会发现，feature 分支的 commit 记录会与主分支合并为一条直线。 这是因为 git megre 默认采用的是快进式合并 git merge --ff feature。

--no-ff

--no-ff：禁止快进式合并

git merge --no-ff feature

如下图所示，我们使用了 --no-ff 进行合并，会发现 feature 分支的 commit 记录并不会和 master 在一条主线上， 而且 git 指针会指向一个新的 commit

从合并后的代码来看，--ff 与 --no-ff 是没有区别的，但是快进式合并 --ff 会将 feature 分支的 commit 记录混入 master，这是没有必要的。

同时使用 --no-ff 合并我们使用 git reset HEAD~ 回退一个版本时，会直接回退到 feature 分支没有提交之前的 commit，而 --ff 由于提交记录混入至了 master， 并不能直接回到没有 feature 分支的记录。

git merge --abort

git merge --abort 会抛弃合并过程并且尝试重建合并前的状态。 但是，当合并开始时如果存在未 commit 的文件，git merge --abort 在某些情况下将无法重现合并前的状态。 （特别是这些未 commit 的文件在合并的过程中将会被修改时）

警告：运行 git-merge 时含有大量的未 commit 文件很容易让你陷入困境，这将使你在冲突中难以回退。 因此非常不鼓励在使用 git-merge 时存在未 commit 的文件， 建议使用 git-stash 命令将这些未 commit 文件暂存起来，并在解决冲突以后使用 git stash pop 把这些未 commit 文件还原出来。

• 合并分支时，如果可能，Git 会用 Fast forward 模式，但这种模式下，删除分支后，会丢掉分支信息。
• 合并分支时，加上 --no-ff 参数就可以用普通模式合并，合并后的历史有分支，能看出来曾经做过合并，而 Fast forward 合并就看不出来曾经做过合并。
• --ff是指 Fast forward 命令。当使用 Fast forward 模式进行合并时，将不会创造一个新的 commit 节点。默认情况下，git-merge 采用 fast-forward 模式。

git merge wfd_test
等同于
git merge --ff wfd_test

使用 --no-ff

git merge --no-ff -m '合并test' wfd_test

merge 时出现代码冲突

出现的报错信息如：CONFLICT (content): Merge conflict 冲突的文件信息如下 解决完冲突后，重新提交

git add .
git commit -m '解决冲突'

merge 问题 you need to resolve your current index first

解决方法：

• 第一种：处理冲突文件
• 第二种：回退到冲突前

git reset --merge