feature 分支在 master 后面，feature 和 master 在同一个文件上不会改变，在合并 PR 之前是否必须将 master 合并到 feature 中？

Question

有一个功能分支 x，它在文件 A 上有一个提交。然后创建了一个拉取请求。

然后 master 在文件 B、C、D 上有一个新的更新。

所以功能分支在 master 后面有 1 个提交。 但是由于功能和主文件处理不同的文件，因此不会出现合并冲突。

对于这种情况，我通常在合并 PR 之前将 master 合并到 feature 分支中。

问题是，如果 feature 和 master 在不同的文件上工作，在 PR 合并之前将 master 同步到 feature 分支是必须做的吗？ 什么是最佳实践？

并且没有同步 master 到 feature 分支，PR 合并后，在 master 上，A 文件应该更改为 feature 分支的提交，并且 fild B、C、D 不会被 feature 分支覆盖并保持不变掌握？

在 Bitbucket 中，通过单击 bitbucket-GUI 中的 Merge 按钮，有 3 个选项：

1. 合并提交
2. 壁球
3. 快进

请在 bicbucket GUI 中查看 bitbucket 的此文档，对于这种情况，第三个选项“快进”是不可能的： https ://community.atlassian.com/t5/Bitbucket-questions/What-happens-if-I -merge-a-PR-that-is-out-of-sync-from-master/qaq-p/1291041

但是我只使用另一个按钮“合并提交”或“壁球”呢？ 它还会起作用吗？

谢谢你。

Answer 1

git中没有技术限制可以阻止您执行您的建议。 但是，即使合并时没有冲突，文件 B、C、D 中的编辑可能与您在 A 中的编辑不兼容。git 不会关心是否是这种情况，但我猜你关心合并是否不会导致master中的代码无法正常工作。 所以你可能不想做你建议的事情，但不是因为 git 的工作方式。

以下是您可以考虑的一些最佳做法：

rebase x on master - 这会将 B、C、D 中的编辑带到分支x 。 如果这些文件中的编辑与如何在文件 A 中实现编辑相关，请执行此操作。变基后，在分支x中测试您的代码，如果没有问题，则合并到master 。 这是最常见的方法，但可能会在x上引入错误。

新版本分支- 创建master的新分支并将x合并到新分支中。 在新分支中测试您的代码，因为其中包含 A、B、C 和 D 中的所有编辑。 如果代码有效，则将新分支合并到master 。 当您创建一个新分支并进行多次合并时，这需要大部分工作，但要确保错误永远不会出现在x或master上。 对于一个小的编辑可能有点矫枉过正。

直接合并- 如果您确定对 A 的编辑与 B、C 和 D 中的编辑结合时不会导致错误，那么您可以直接合并。

在将x合并到master时，B、C 和 D 中的文件不会被覆盖，即使x具有这些文件的原始版本。 可以这样想； 分支x跟踪在该分支中完成的编辑。 将x合并到另一个分支时，仅合并这些编辑。 由于没有在分支x中对 B、C 和 D 进行任何编辑，因此合并到的分支x中的那些文件不会发生任何事情。

Answer 2

非常感谢@TheIceBear！ 对于我的用例，“直接合并”B、C 和 D 中的文件在将 x 合并到 master 时不会被覆盖，即使 x 具有这些文件的原始版本。

现在我的总结：对于我的用例，有不同的方法可以做到这一点。

有 3 个选项：

1. rebase feature to master （另见TheIceBear的回答）这是git histroy最清晰的方法。 命令：#首先从上游存储库中获取新的主库，然后在此基础上重新设置您的功能分支：

（更新源/主）

git 获取原点

（将当前分支重新定位到 origin/master 上）

git rebase 起源/主

2.合并master到feature

从上游分支合并到特性分支会导致不“好的”历史记录，因为总是会创建另一个合并对象

命令：

git结账大师

git 拉

git 结帐功能/x

git 拉

git 合并大师

git 推送

3.直接合并

在 bitbucket 中，使用“fast-forward” Merge 将不起作用，但使用“squash”和“merge commit”进行 Merge 将起作用，在将 x 合并到 master 时，B、C 和 D 中的文件不会被覆盖，即使 x有这些文件的原始版本。

如果 feature 和 master 在不同的文件上工作，这意味着没有冲突，你也可以考虑不做 rebase。 合并后的结果当然是一样的。

但是你会在历史上“跨越”支线，这也不是特别好。

总而言之：这不是必须做的，但特性分支最好总是来自 master 的当前状态，然后它也被合并到