更改显示在 DEVELOP 分支中，但它们已存在于 GIT Bitbucket 的 DEVELOP 分支中

Question

我一次又一次地面临一个问题，当从“release”分支创建的分支“A”到“Develop”创建合并请求时，我发现代码更改已经存在于“develop”分支中知道为什么正在发生？

Answer 1

tl;dr：这通常会发生，因为您在 Pull Request 的源分支和目标分支上有不同的提交，其中的更改相同。 这可能来自共享分支的 cherry-picking/squashing/rebase 提交，或者独立地进行相同的更改。 虽然有时这是不可避免的，但如果您可以调整工作流程以降低其频率，那么这种情况就不会经常发生。 否则，你只需要习惯它。

细节：

发生这种情况的原因是因为 Pull Request 实际上并没有向您显示“将发生什么变化”，而是向您显示“自源分支和目标分支分离以来分支上发生了什么变化”。 要查看实际会发生什么变化，您需要执行合并。 许多（可能是所有？）SCM 工具，当创建合并请求时，实际上会在幕后执行合并，有些工具允许您直接在 UI 中查看临时合并提交。 如果您找不到该选项，您可以从任何 Git 客户端执行相同的合并，以查看 PR 完成后实际会发生什么变化。

如果您对上一段的直觉反应是“但是为什么？向我展示正在更改但实际上不会更改的内容并没有帮助”，那么您并不孤单。 这是对 Pull Request 功能（在最流行的 SCM 工具中）的一个非常普遍的抱怨，但是，事实证明大多数时候都是这样。 从分支合并的角度来看发生了什么变化是首选，如果你认为你总是宁愿看到什么会真正发生变化，而且它通常与 PR 默认视图（听起来像你的）不同。 那么您可能需要考虑调整您的工作流程，使 PR 看起来像您期望的最简单方法是使用目标分支更新源分支：这意味着：

1. 如果您的源分支是非共享功能分支，那么将您的分支重新定位到develop分支，所有相同的更改都会消失。
2. 如果您的源代码分支是共享的，那么您不应该对其进行变基，而是考虑先将develop合并到其中，然后当您将分支 PR 到develop时，只会显示实际的更改。

至于为什么你在两个分支上都得到重复的更改，通常是由以下原因之一引起的：

1. 不同的人在每个分支上进行了相同的更改，没有人意识到这一点，直到为时已晚而无法阻止这种情况的发生。
2. 完成 PR 时，提交被压缩或变基，并且在完成该 PR 后源分支没有被删除。 如果源分支是另一个共享分支（例如main或release ），或者如果有人仅仅因为他们想在以后继续处理而没有删除该分支，则可能会发生这种情况。
3. 一些提交是从一个共享分支（比如develop ）挑选到另一个分支（比如release ）的。 也许你这样做是因为你决定比原先想象的更早地发布对生产的更改。

当#1 发生时，您真的无能为力，所以您只能忍受它。 幸运的是，在大多数情况下这种情况不会经常发生，除非两个人在没有沟通的情况下处理同一个问题。

#2 非常简单且易于修复。 如果您正在使用 Squash 或变基来完成合并请求并且源分支是共享分支，请停止这样做。 仅使用常规合并将一个共享分支合并到另一个共享分支。 如果有人在功能分支上通过压缩或变基来完成 PR，那完全没问题，但是他们应该删除该分支并重新开始一个新分支，即使他们继续在同一功能上工作也是如此。 在这种情况下，重用分支会将其与共享分支放在同一类别中。 这里的一个很好的经验法则是：

不要重写共享分支。

一个推论是：

不要重复使用被重写的旧版本分支。

#3 有时是不可避免的，如果你过早地将 PR 完成到像develop这样的分支，但随后意识到你需要更快地发布它并且必须将它放到release分支上。 在那种情况下，您没有太多选择，并且可能不得不在稍后将release合并回develop时挑选提交并处理不正确的 PR 视图。 但是如果你知道在将它合并到任何一个分支之前你需要它在两个分支上，你可以先将它合并到release中，然后立即将release合并回develop （如果你使用像 Git Flow 这样的工作流，在所有时间），或者您可以从两个分支的合并基础分支出来，进行新的提交，然后将其合并到两个目标分支而不更改提交 ID。 有些人甚至建议，特别是为了修复错误，从导致错误的提交中分支出来，即使它是超级旧的，这也可以将它合并到许多需要它的分支中，而无需使用 cherry-picking。 这里的一个很好的经验法则是：

尽可能合并而不是挑选。