Git：当将外部分支合并到主分支时，如何防止快进式合并

Question

为了方便查看功能分支何时合并到主分支，可以在将功能分支合并到主分支时使用Git的--no-ff选项。

一种无需输入--no-ff即可实现的方法是完全禁用快进式合并到主分支：

git config branch.master.mergeoptions --no-ff

然而，这种方法很笨拙，因为它也会阻止在将主线上游更改合并到本地主线副本时进行快进式合并（正常的git pull会创建合并提交）。

是否有一种方法可以配置Git，仅在将特性分支合并到主线时防止快进式合并到主线，以便在从主线进行git pull时允许快进，但总是在合并特性分支时创建合并提交？或者明确使用--no-ff是实现这一点的唯一方法？

- segfault

---

Git 如何区分特性分支和上游分支？对于 Git 来说，它们都只是分支，名称并不重要。我能想到的唯一可能有效的方法是使用跟踪分支，并让 master 跟踪 origin/master。这可能需要通过预合并钩子来实现。 - asm

我只是希望可能有一些特殊的配置选项，我可能在阅读手册时错过了，认为（正如你所暗示的那样）Git可以区分从“内部”合并跟踪分支（将更改从origin / master -> master合并）与在不同分支中合并。 - segfault

@segfault 我现在正在考虑这个问题。你在过去的一个月里有找到解决方案吗？ - SilverSnake

还没有解决方案，很遗憾。 - segfault

VonC在2014年第二季度为一个类似的问题提供了一个更新的答案。 - user1936123

Answer 1

注意：没有预合并钩子。
它是在2008年引入的，当时受到批评（因为最好使用更新钩子在服务器上实现控制）。
它正在重新引入过程中（2012年9月）。

而且，预/后提交钩子不会运行在由git merge自动提交完成的情况下。

所以：

• 要么你在开发人员推送代码的git服务器上设置一个更新钩子（但那时他们意识到快进了功能分支可能为时已晚）
• 要么你编写（并分发、维护...）一个git-merge包装器，在本地仓库级别进行控制。

话虽如此，正如我在 "使用 pull 时快进和不使用 --no-ff 的区别" 中提到的那样，不使用 --no-ff 也有其优点，因为它不会破坏 git bisect 和 git blame。
因此，开发人员可能希望在将功能提交（如果提交太多）快进到主分支之前重新组织他/她的功能提交（稍微压缩一下它们）。
有关更多信息，请参见 "理解 Git 工作流程"。

- VonC

---

所以你的意思是，没有优雅的方法可以做到我想要的。我正在尝试找出一种积极主动的工作流，让所有开发人员都能轻松配置，而不是像你提到的更新钩子那样，开发人员只能在犯错之后才能被告知。最简单的方法可能是告诉开发人员，在将特性分支合并到主分支时，只需使用--no-ff即可。 - segfault

@segfault 我同意（关于 --no-ff）。通常情况下，使用分布式版本控制系统来强制执行政策是在中央仓库上完成的，这样可以避免在每个下游仓库上部署该政策。 - VonC

我创建这个问题的整个原因是因为我不希望人们必须记住要么输入--no-ff，要么在第一次克隆时下载/配置专有包装器。我希望尽可能减少日常人为错误的可能性。 :) - segfault