在 GitHub 中将 PR 合并+压缩到 master 后，如何同步您的 git dev 分支？

Question

所以请到 GitHub has the ability to merge+squash commits 申请 PR。

我们按照dev->master的PR'ing代码流程。

以前，我一直在“合并” PR，但这会生成一个新的提交，上面写着：“Merge Pull Request #1 from foo/bar”。 :( 呜呜……

所以我想我可以试试 GH 的新 Squash Commits 东西。这创建了一个新的提交，我之前的所有提交都被压缩了。好的，到目前为止一切顺利。

我然后回到我的dev 分支（在我的开发人员机器上）.. 拉下upstream/master（这是 PR 和 squash-merge 发生的地方））现在 添加了另一个提交到我的本地历史！它没有去“哦..哇。你太不合时宜了..让我们同步”。它只是做了一个合并。

所以 Squash+Merge 按钮压缩了 4 个提交并将其替换为 1 ... 我的 localhost 机器上的 pull upstream/master 现在仍然有我的 4 个提交，PR 所做的 Squashed-commit 和一个新的提交，即“Merge branch master .. blah ... noise ..spam”提交 :( :( :(

在发生合并挤压之后，我应该做一个特殊的技巧/工作流程吗.. 以确保我的 dev 分支正确同步？就像 .. 每个人都只是删除他们的 localhost dev 分支，然后再将 upstream/master 拉回他们的 localhost 并进入（新创建的）dev 分支吗？

记住：这里的目标是避免那些蹩脚的“Merge Pull Request #2..”merge bubble 消息。

或者人们暂时只是通过 CLI 执行此操作，直到 GitHub 学会如何执行此操作:(

Answer 1

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

如果您真的想坚持使用一个长期存在的分支进行所有开发（您称为 dev 的分支），您必须牢记一些注意事项：

• 如果您不是唯一在该分支上工作的人，则必须避免任何类型的历史重写。没有变基，没有挤压，没有重置，甚至没有修改提交。这基本上排除了使用 squash 合并。
• 如果您确定您是唯一在该分支上工作的人，并且您使用 GitHub 的 squash 选项来合并拉取请求，那么 您必须将本地 dev 分支重置为最新的upstream/master，然后再继续在那里工作。这也意味着稍后您将需要强制推送到上游以创建新的拉取请求。

最后一点很容易出错，会影响之前的代码审查，所以我个人会选择只使用短期功能分支。

Answer 2

如果您的 dev 分支被合并并压缩，那么您就不再需要它了。只需将其重置为upstream/master。

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

Answer 3

有一个更好的解决方案可以合并和压缩您的提交，而无需额外提交“Merge Foo branch in Bar”。你应该总是更喜欢变基而不是合并然后挤压。因此，rebase 将帮助您合并两个分支，而无需任何额外的提交。您应该尝试重新设置分支而不是合并。这是同一here 的详细说明。