问题描述
假设有两个分支：124（我的）和 158，都在开发中。
-
我将 158 个的
commitA合并为 124 个。 -
我不知道 #2 和 #3，所以没有保持 124 同步。
-
我开始打开 124 的 PR，发现我从 158-
commitA合并的文件现在在 124 的 PR/merge 中显示为新文件。 -
我检查了 158 的 PR，发现了变化，也在 124 上修改了这些。
#6 似乎是 git 应该能够自动处理的不必要的工作。有什么办法可以避免这种手动工作吗？
解决方法
在任何 git 工作流程中强制执行的一个非常有用的规则是，永远不要重写已经共享的历史记录。
在您的示例中，分支 158 的早期工作与分支 124 共享。但是，您随后使用了“挤压”合并选项，该选项重写历史，从多个提交中创建单个提交。这意味着 git 无法知道 124 中的更改与 158 的新版本相关，因此当您将 124 合并到 master 时，它会尝试将那些重新合并。 >
如果您改为执行直接合并（合并到分支 124 和最终合并到主分支时），创建一个保留 158 的完整历史的合并提交，合并 124 的 PR 将简单地跳过分支之间共享的提交。
然而，听起来您还有一个更组织化的问题：如果开发人员从正在进行的分支中获取更改，他们与该分支的作者进行沟通是必不可少的。如果发现158有问题，在158合并之前就开了124的PR怎么办？如果 158 的作者放弃了他们最初的分支并重新开始怎么办？
如果两个开发者沟通正常，158 的作者有可能安全地重写他们分支的历史（通过 rebase、squash 合并等） - 124 的作者只需要了解它，并使用 git rebase 重写他们的 历史以匹配。不过，在可能的情况下，通常更容易避免这种情况。