git - 如何 merge 一个只导致一次提交的 git 分支(比如使用 --squash)，但允许 future 的 merge 而不会发生冲突？

Question

我有一个分支，自创建以来其中有很多提交，我想进行一次 merge 提交以将其移回主分支，使用一次提交。所以我知道的唯一解决方案是使用 git merge --squash branchname。这很好用，但如果有人向 branchname 添加更多提交，并且我再次将其 merge 到 master 中，我会从 branchname 上的初始新提交中得到冲突。如何防止 merge 冲突，同时仍然只在 master 中为每次 merge 保留一次提交？我研究过使用 git merge --no-ff 但它仍然将所有提交从 branchname 移动到 master。

Answer 1

echo $(git rev-parse $result $result^ $merged) > .git/info/grafts
git merge topic

其中 $result 是由压缩 merge 产生的提交，$merged 是您 merge 的提交(即给定 git checkout master; git merge topic ，$result为 merge 后的master，$merged为 merge 后的topic) .

info/grafts 文件包含临时的、repo-local 祖先覆盖。上面的 echo 记录，仅在此 repo 中，挤压 merge 的结果也将挤压 merge 提交作为其父项——即它记录了准确的 merge 历史。仅当两个分支的后续 merge 仍以相同方式看到 merge 更改时，未记录的 merge 才有效。

不要忘记 rebase 和 filter-branch 也会看到嫁接的祖先，如果他们重写 $result 提交，他们会在新提交中记录该祖先。

---

merge 功能分支当然很常见，只是不记录就做这件事并不常见，因为这使得 git(或任何 vcs)不可能总能找到正确的 merge 基础。许多未记录的 merge 在历史记录中根本没有留下正确的 merge 基础，您必须创建一个才能在以后获得良好的 merge 。只要在进一步的修改掩盖匹配的更改 block 之前通过记录的 merge 来支付技术债务，Cherry-picks 和 squash merge 就很棒。

如果您要 merge 的历史很丑陋，您会喜欢交互式 rebase 。它可以让您创建提交历史记录，如果您首先有远见地这样做的话。为发布清理更改是许多项目工作流程的基本组成部分。