在github设置中，我选择了Allow squash merging的选项，以便从开发分支（有几个提交）中的拉动请求成为主分支中的一个提交。
我不明白的两件事：
-
PR合并后，开发分支仍然是XX提交的。下次我将进行PR时，即使已经在主分支中合并了这些XX提交也会在那里。在合并公关后，如何使开发分支与大师同步？
-
PR合并后，我在开发分支机构上git Pull origin Master并继续工作。它创建合并提交，而完全相同的内容。我该如何避免？
1.在合并之前，假设master的历史记录是A-B-C，PR的历史记录为A-D-E。南瓜合并后，master变为A-B-C-F，PR保持不变。F包括D和E的更改。Squash-Merge不会将D和E组合到一个提交中。它只是在master上创建了新的COM F。git log master..develop返回D和E，因此develop乘以master乘2个提交。这2个提交是可以从develop达到的，但不能从master达到。尽管两者的更改已应用于master，但它是由新提交而不是由两个提交完成的。代码将通过普通合并或南瓜合并而相同，但是历史记录将有所不同。实际上，在这种情况下，当涉及A is ahead of B by n commits的事情时，无论是正常合并还是南瓜合并都没关系，因为git log master..develop返回相同的结果。
2.由于 develop和 master分解，将 master拉到 develop带来了按预期的合并提交。您可以从master创建一个新的PR分支。另一个选择是git rebase master develop。它将develop移至master指向的提交，但也使本地develop在远程存储库中与develop差异，因此这不是一个好主意。
您描述的症状 - develop仍然是"在 master"之前 - 正是南瓜合并（如您完成的）和真实合并之间的差异。
人们对南瓜合并感到兴奋，因为当您使用它们时，默认历史记录不再显示个人从合并的分支中提出的。但是（1）相反，您可以在真实合并后使用git log --first-parent之类的东西来获取简化的历史记录，并且（2）壁球合并才真正有用，只有您最后一次将目标分支更改到当前分支（通常是因为您要放弃目标分支）。
那么... PR之后如何使分支同步？通过禁用南瓜合并。
至于第二个问题...将主人合并到您的分支中是git pull master的含义。如果要避免这种情况，运行命令的预期效果是什么？我的意思是，您可以通过不运行pull命令来避免合并，但是在不知道您打算使用pull的情况下，我不能说您应该运行什么。
解决这两个问题的解决方案都不适用于单个develop分支。
对于您正在处理的每个修复/功能 - 创建一个新分支。开发后，创建PR，将其合并为掌握并放下开发分支。
对于您，下一个修复/功能 - 使用基于最新主人的新分支。
这是常见的工作流程。