在github设置中，我选择了Allow squash merging选项，以便来自develop分支的拉取请求（带有多个提交）成为主分支中的单个提交。
我不明白的两件事：
合并PR后，开发分支仍然在主分支之前提交xx。下次我将执行PR，即使它们已经在主分支中合并，那些xx提交也将存在。在PR合并后，如何使开发分支与主服务器同步？
在PR合并之后，我在开发分支上git pull origin master并继续工作。它创建了一个合并提交，而它的内容完全相同。我怎么能避免这种情况？
答案 0 :(得分：1)
1.在合并之前，假设master的历史记录为A-B-C且PR的历史记录为A-D-E。压缩合并后，master变为A-B-C-F，PR保持不变。 F包含D和E的更改。 squash-merge不会将D和E合并为一个提交。它只是在F上创建新的提交master。 git log master..develop返回D和E，因此develop提前master提交2次。可以从develop访问2次提交，但不能从master访问。虽然这两个更改已应用于master，但它是由新提交完成的，而不是由两个提交完成的。通过正常合并或压缩合并，代码将是相同的，但历史将是不同的。实际上，在这种情况下涉及到A is ahead of B by n commits时，如果它是正常合并或压缩合并并不重要，因为git log master..develop会返回相同的结果。< / p>
2.由于develop和master分歧，将master拉到develop会带来合并提交。您可以从master创建新的PR分支。另一个选项是git rebase master develop。它将develop移动到master指向的提交，但也使本地develop与远程存储库中的develop分歧，因此它不是一个好的想法。
答案 1 :(得分：1)
您描述的症状 - develop仍然在master之前“ - 正是壁球合并（如您所做）和真正合并之间的区别。
人们对squash合并感到兴奋，因为当你使用它们时，默认历史记录不再显示来自合并分支的各个提交;但是（1）你可以在真正的合并之后使用git log --first-parent之类的东西来获得简化的历史记录，以及（2）当你最后一次从目标分支带来变化时，压缩合并真的有用当前分支（通常是因为你要放弃目标分支）。
那么......在PR之后你怎么能让分支同步？通过禁用squash merge。
第二个问题的AS ...将主人合并到你的分支正是git pull master的含义。如果要避免这种情况，运行命令的预期效果是什么？我的意思是，你可以通过不运行pull命令来避免合并，但不知道你想要做什么pull我不能说你应该运行什么。
答案 2 :(得分：0)
这两个问题的解决方案不适用于单个develop分支。
对于您正在处理的每个修补程序/功能 - 创建一个新分支。 修复开发后，创建PR，将其合并到master，然后删除开发分支。
对于下一个修复/功能 - 使用基于最新主数据的新分支。
这是常见的工作流程。