Github和Release分支显示不应存在的差异

时间：2020-06-05 18:46:42

标签： git github pull-request

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

我创建了一个回购协议来说明正在发生的事情。 https://github.com/austinbv/test-pr

我们正在尝试的常规工作流程：

  1. 开发人员在功能分支（https://github.com/austinbv/test-pr/tree/flowthrough）中工作
  2. Developer推送Feature分支并从Feature分支创建PR到master（https://github.com/austinbv/test-pr/pull/1）
  3. 功能分支已合并到主（https://github.com/austinbv/test-pr/pull/1）
  4. 过一会儿，我们通过将master的PR创建为prod（https://github.com/austinbv/test-pr/pull/2）来削减发行版
  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提出任何意见

2 个答案:

答案 0 :(得分：1)

您观察到的问题肯定是由于项目中的“合并请求”已被“合并”的方式引起的（我在引号之间加上了这个词，因为似乎实际上没有发生合并）。

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

merging-a-pull-request

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

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

只有第一个会导致true merge并创建所谓的合并提交，即具有≥2个父母的提交。

其他策略实际上依赖于git rebase命令（壁球是git rebase -i …的变体），该命令具有以下“缺点”：

  • git rebase是一种破坏性操作：它更改了重新提交的 SHA1 ，并且一些或所有重新提交的提交可能不再编译了。强势>改头换面后！ （虽然最初的提交确实可以编译）；
  • 随着重新提交的提交的SHA1发生更改，Git经常看不到这些提交与其在另一个分支中的初始对应项有关。因此，当您尝试从master到prod创建PR＃5时，会出现虚假的，意外的合并冲突；

  • 最后，当您观察提交的图形时，在重新设置基础或壁球之后，您再也看不到了，只要对历史进行了调整，PR整合的贡献的确切“历史”是什么？由git rebase制成的“线性”，请参见。以下是您的示例项目中gitk prod然后gitk --all生成的屏幕截图：

    gitk prod

    gitk prod

    gitk --all

    gitk --all

    而基于git merge的标准历史记录看起来像是“有向图”，参见。例如下面的屏幕截图取自this older SO answer：

    gitk在另一个示例项目中

    gitk master

因此，在这种情况下，您可能需要系统地使用创建合并提交 GitHub PR策略，该策略似乎更适合您的两步工作流程（合并到master中，然后合并到prod中。

顺便说一句，此工作流程看起来与所谓的Git flow非常相似，其中两个主要分支称为（develop，master）而不是（{{1} }，master。

答案 1 :(得分：1)

  1. 开发人员在功能分支（https://github.com/austinbv/test-pr/tree/flowthrough）中工作

  2. Developer推送Feature分支并从Feature分支创建PR到master（https://github.com/austinbv/test-pr/pull/1）

您遗漏了1a：在推送之前，开发人员将master拉到master上并将功能分支重新建立基础。

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

相关问题
最新问题