4

所以 GitHub有能力为 PR 合并 + 压缩提交。

dev我们从->遵循 PR'ing 代码的过程master。

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

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

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

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

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

请记住：这里的目标是避免那些糟糕的“合并拉取请求 #2..”合并气泡消息。

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

4

3 回答 3

5

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

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

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

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

于 2016-10-21T10:31:08.617 回答
1

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

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

于 2016-07-26T09:04:59.047 回答
-1

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

于 2016-07-25T05:14:55.283 回答