与其他开发分支合并时如何开发分支

如何解决与其他开发分支合并时如何开发分支

假设有两个分支：124（我的）和 158，都在开发中。

1. 我将 158 个的 commitA 合并为 124 个。

2. 在158-commitA文件被重命名，重命名后内容改变，现在是158-commitB。

3. 158 提出了一个 PR，它被压缩合并到 master。之后 158 的远程分支被关闭。

4. 我不知道 #2 和 #3，所以没有保持 124 同步。

5. 我开始打开 ​​124 的 PR，发现我从 158-commitA 合并的文件现在在 124 的 PR/merge 中显示为新文件。

6. 我检查了 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 重写他们的 历史以匹配。不过，在可能的情况下，通常更容易避免这种情况。