如何在GitHub上将PR合并压缩到主分支后同步git dev分支？

Question

所以GitHub 具有合并和压缩提交的能力。

我们遵循从dev到master的PR'ing代码的流程。

以前，我只是在合并PR时进行“合并”，但这会生成一个新的提交，其中包含“Merge Pull Request＃1 from foo / bar”的信息。 :( 呸......

因此，我想我可以尝试一下GH的新的压缩提交功能。这将创建一个新的提交，并将所有先前的提交压缩在一起。到目前为止还不错。

然后，我回到我的开发者机器上的dev分支，拉取了（PR和压缩合并发生的）upstream / master，它现在在我的本地历史记录中添加了另一个提交！它没有说：“哦..哇，你远离了轨道..让我们同步一下。”它只是进行了合并。

所以，Squash+Merge 按钮压缩了 4 个提交并用一个替换了它... 现在，在我的本地主机上拉取 upstream/master 仓库时，我的 4 个提交仍然存在，并且 PR 所做的 Squashed-commit 和一个新的提交 "Merge branch master .. blah ... noise ..spam" 也存在 :( :( :( 有没有特殊的技巧/工作流程，我应该在合并压缩之后进行操作，以确保我的 dev 分支已正确同步？比如...每个人是否都会在从 upstream/master 拉回到他们的本地主机和 (新创建的) dev 分支之前删除他们的本地 dev 分支？ 记住：这里的目标是避免那些糟糕的“合并拉取请求 #2..”merge bubble 消息。 或者人们只是暂时通过 CLI 来完成这个操作，直到 GitHub 学会如何做到这一点 :(

- Pure.Krome

---

最简单的选择是从主分支(master)创建一个独特的功能分支(feature branch)，并在CI通过后将其压缩合并回主分支(master)。然后删除该分支。 - osowskit

实际上，“变基而不是合并”的整个想法是非常误导人的。使用合并的历史记录是正确的。它具有功能开发历史，其中包含有关为什么进行更改的信息。它具有合并提交，显示功能合并的时间。重新基于或合并压缩的分支与原始分支没有任何链接，因此丢失了重要信息。如果您不喜欢git log或UI显示合并历史的方式，则应该修复那个问题。例如，使用选项--first-parent。 - max630

Answer 1

我认为问题出在你的工作流程上：通常情况下，一旦你合并了一个拉取请求（无论使用哪种方法），你就完成了该分支。如果你想进行进一步的更改，则最好从当前的upstream/master创建一个新的功能分支，然后稍后可以打开另一个拉取请求以将其合并回去。

如果你真的想坚持单一的长期存活分支用于所有开发（你所称的dev），则你必须记住以下几点：

- 如果不是只有你在该分支上工作，你必须避免任何形式的历史重写。不要变基、不要压缩、不要重置，甚至不要修改提交。这基本上排除了使用压缩合并。 - 如果你确定只有你在该分支上工作，并且像你之前那样使用GitHub的压缩选项来合并拉取请求，那么在恢复你的工作之前，你必须将本地的dev分支重置为最新的upstream/master。这也意味着稍后你需要强制推送到upstream来创建一个新的拉取请求。 - 最后一点容易出错，并且会影响以前的代码审查，因此我个人选择只使用短期的功能分支。

- Diego V

Answer 2

如果您的dev分支已被合并并压缩，则不再需要它。只需将其重置为upstream/master即可。

如果有一些更新的更改，您可以调用git rebase -i upstream/master，然后删除所有已合并的提交，重新应用其余的提交。

- max630

Answer 3

有一种更好的解决方案可以合并和压缩您的提交，而不需要额外的提交来说明“在Bar中合并Foo分支”。 您应该始终优先选择变基（Rebase）而不是合并（Merging）和压缩（Squashing）。 因此，变基将帮助您在没有任何额外提交的情况下合并两个分支。 您应该尝试对分支进行变基而不是合并。 这里是相同内容的详细解释here。

- pjoshi

---

所以Github需要在“合并”按钮上增加一个新选项：“确认变基”（与“确认合并”和现在的“确认压缩合并”并列）？ - Pure.Krome

合并操作总是会创建一个新的提交记录。不管您是通过用户界面(UI)还是控制台进行操作。但如果您想避免额外的合并提交，应该使用变基(rebase)操作。目前用户界面(UI)中没有提供这个变基(rebase)选项。 - pjoshi