为何有人会在变基分支后使用merge --no-ff强制生成合并提交？

你说的没错，变基确实是把分支的基准移到最新提交上，让分支历史看起来像是从新节点直接分出来的，正常走快进合并就能得到干净的线性历史。但有些场景下，变基后再用merge --no-ff生成合并提交，是为了兼顾线性历史和分支的“任务边界”，常见的适用场景有这几个：

• 保留分支的任务上下文：就算把功能分支变基到主分支最新提交上，这个分支本身还是对应一个完整的功能开发、bug修复任务。merge --no-ff生成的合并提交，能明确标记“这个任务的所有提交在这一刻合并进主分支”，以后看历史时，一眼就能知道哪些提交属于同一个任务，不用翻提交信息猜关联。比如修复复杂bug时，分支里有3个提交分别对应定位、修复、验证，合并后的合并提交写着“修复XX模块内存泄漏bug”，后续查问题能快速定位整个任务的范围。

• 便于回滚整个任务：如果合并后发现功能有问题，线性历史下得一个个回滚分支里的提交；但有了合并提交，只需要回滚这个合并提交就能一次性撤销整个任务的所有改动，操作更简单，也不容易漏回滚某个提交。

• 符合团队的历史规范：有些团队既想要主分支历史尽量干净（所以先变基解决冲突），又不想完全丢失分支的任务划分，就会要求变基后用--no-ff合并。这样主分支历史里既有线性的提交（变基后），又有清晰的任务节点（合并提交），平衡了整洁性和可追溯性。

• 记录合并时的额外说明：有时候变基后合并，可能需要补充合并时的信息——比如功能合并后主分支需要注意的点，或者和其他模块的兼容情况。合并提交的信息正好可以用来写这些内容，而线性历史的快进合并不会产生额外提交，没法添加这类说明。

内容的提问来源于stack exchange，提问作者NFeruch - FreePalestine