因此，GitHub具有合并PR的+ squash提交的能力。
我们遵循从dev->中PR代码的过程master。
以前，我只是在“合并” PR，但这会生成一个新提交，内容为：“ Merge Pull Request #1 from foo/bar”。:(嘘...
所以我想我可以Squash Commits和GH一起尝试新事物。这创建了一个新提交，而我之前的所有提交都被压缩了。好的，到目前为止很好。
我再回到我的dev分支（我的开发机器上）..拉下来upstream/master（这是在PR和壁球合并发生的事情）），现在又增加了承诺，我当地的历史！它并没有显示“哦..哇。你太过分了..让我们同步”。它只是合并了。
因此，Squash + Merge按钮压缩了4次提交，并将其替换为1 ... ...upstream/master在我的本地主机上，现在我的本地主机上还有4个提交，而Squashed-commit PR做了一个新的提交，即“ Merge branch master .. blah ... noise ..spam“提交:(： （:(
在发生壁球合并之后，我应该做些特殊的技巧/工作流程以确保我的dev分支正确同步吗？就像..每个人dev在upstream/master撤回其本地主机并进入（新创建的）dev分支之前，是否只是删除其本地主机分支？
请记住：这里的目标是避免那些笨拙的“合并请求2”合并气泡消息。
还是人们暂时只是通过CLI这样做，直到GitHub学习如何做到这一点:(
我认为问题出在您的工作流程上：通常，一旦合并合并请求（无论使用哪种方法），就都可以使用该分支。如果要进行进一步的更改，最好从当前的上游/主节点创建一个新的功能分支，然后再打开另一个拉取请求以将其合并回去。
如果您真的想为所有开发坚持一个长期存在的分支（您称为dev的分支），则需要牢记一些警告：
最后一点很容易出错，并且会影响以前的代码审查，因此我个人选择只使用短暂的功能分支。
本文收集自互联网，转载请注明来源。
如有侵权，请联系[email protected] 删除。
我来说两句