Github & 发布分支显示不应该存在的差异

Github & Release Branch Showing diffs that shouldn't be there

我们正在尝试创建一个带有 PR 的工作流，以不断发布我们应用程序的新版本。

我创建了一个回购作为正在发生的事情的例子。 https://github.com/austinbv/test-pr

我们正在尝试的一般工作流程：

  1. 开发人员在功能分支中工作 (https://github.com/austinbv/test-pr/tree/flowthrough)
  2. 开发者推送 Feature 分支并从 Feature 分支创建 PR 到 master (https://github.com/austinbv/test-pr/pull/1)
  3. 功能分支被合并到主分支（https://github.com/austinbv/test-pr/pull/1）
  4. 过了一会儿，我们通过创建 PR 从 master 到 prod (https://github.com/austinbv/test-pr/pull/2)
    5. 来削减发布
  5. master合并为prod (https://github.com/austinbv/test-pr/pull/2)
  6. 冲洗并重复！

当我们从 master 创建到 prod 的合并时，我们总是会看到合并冲突，并且应用自 prod 创建以来在 master 上发生的所有提交。

你可以在这里看到 (https://github.com/austinbv/test-pr/pull/5)。

看起来不对劲的事情：

欢迎对我们正在做的事情或我们是否滥用 git/github 提出任何意见

您观察到的问题肯定是由您项目中的合并请求的方式引起的 "merged"（我把这个词放在引号之间是因为它似乎没有实际发生合并）。

更准确地说，GitHub 提供了三种方式在另一个分支中集成拉取请求，参见。以下截图来自 official GitHub documentation:

在集成拉取请求的三种可能方式中：

  • 创建合并提交
  • 压缩并合并
  • 变基并合并

只有第一个导致 true merge 并创建 so-called merge commit，即 ≥2 parents 的提交.

其他策略实际上依赖于 git rebase 命令（squash 是 git rebase -i … 的变体），它具有以下 "drawbacks":

  • git rebase 是一个破坏性操作：它改变了变基提交的 SHA1 并且有可能 部分或全部变基提交变基后不要再编译！ （虽然最初的提交确实编译）；
  • 随着 rebased 提交的 SHA1 发生变化，Git 通常看不到这些提交与它们在另一个分支中的初始对应项相关。因此，当您尝试从 master 到 prod;
    • 创建 PR #5 时，会出现虚假的、意外的 合并冲突

  • 最后，当你观察提交的图表时，在 rebase 或 squash 之后你再也看不到，PR 集成的贡献的确切 "history" 是多少, 鉴于 git rebase 调整的历史已被制作 "linear", cf.以下屏幕截图由 gitk prod 然后 gitk --all 在您的示例项目中生成：

    gitk prod

    gitk --all

    虽然基于 git merge 的标准历史看起来像 "directed graph"，请参见。例如下面的截图来自 this older SO answer:

    gitk in another example project

所以在这种情况下，您可能希望系统地使用 创建合并提交 GitHub PR 策略，这似乎更适合您的两步工作流程（在 master 中合并，然后在 prod 中合并）。

顺便说一句，此工作流程看起来与 so-called Git flow 非常相似，其中两个主要分支被称为 (develop, master) 而不是 ( master, prod).

  1. Developers work in a feature branch (https://github.com/austinbv/test-pr/tree/flowthrough)

  2. Developer pushes Feature branch and creates a PR from Feature branch into master (https://github.com/austinbv/test-pr/pull/1)

您遗漏了 1a：开发人员拉取 master 并在推送之前将功能分支变基到 master。

如果这样做，您将不会获得所有这些额外的历史记录，因为合并到 master 的每个分支都会在 master 的顶部发散。