Git分支合并为何提交数累加？合并结果是否符合预期？

这是个非常典型的Git疑问，很多刚接触分支合并的开发者都会有类似困惑，我来一步步给你讲明白：

为什么合并时提交总数会累加？ #

这核心取决于Git使用的合并方式，Git默认有两种主要的合并逻辑：

1. 快进合并（Fast-Forward Merge） #

这是Git默认的合并方式，当你合并的目标分支（比如你说的Branch A）在分出Feature分支（Branch B）之后，没有产生任何新的提交时，Git会直接把Branch A的指针“移动”到Branch B的最新提交位置。

这种情况下，Branch A的提交历史会直接包含Branch B的所有提交——相当于把B的提交“追加”到A的历史里，所以提交总数自然是A原来的提交数加上B的提交数，也就是你看到的5+7=12次。

2. 非快进合并（No-Fast-Forward Merge） #

如果你希望合并操作本身被记录为一个单独的提交（也就是你原本以为的“合并是单次提交”的情况），可以用git merge --no-ff branchB命令强制Git生成一个新的合并提交。

这种情况下，Branch A的提交总数会变成5+7+1=13次：原来的5次A提交、7次B提交，再加上1次专门记录“合并B到A”的提交。这个合并提交会包含两个父节点，分别指向A和B的最新提交，能清晰看到这次合并操作的存在。

合并后A的提交数为12次是否符合预期？ #

完全符合预期！这说明Git使用了快进合并的方式完成了合并。

如果你想要让合并操作被视为单次提交，下次合并时可以加上--no-ff参数，比如：

git checkout branchA
git merge --no-ff branchB

执行这个命令后，你就会看到Branch A多了一个专门的合并提交，总提交数变成13次。

简单总结一下：

• 快进合并：无新提交，提交数是两边总和
• 非快进合并：生成1个合并提交，提交数是两边总和+1

内容的提问来源于stack exchange，提问作者pstatix