时间戳

首页 > 解决方案 > git分支历史没有更新

git - git分支历史没有更新

问题描述

我有两个分支development，我成功地master合并了一个拉取请求。我试图通过从to创建一个新的 PR 来验证合并，令人惊讶的是，我在新 PR 中再次看到了相同的提交和文件差异。但实际上，当我在 master 分支中手动验证更改时，更改已成功合并。developmentmasterdevelopmentmaster

知道 PR 中这些错误差异的原因是什么，我们该如何解决？我已经尝试将主人合并到开发中，但这没有帮助。

标签： gitazure-devops

解决方案

tl;dr：看起来第二个 PR 将再次重新合并您的更改的原因是由于您在完成第一个 PR 时选择的合并策略。要将一个长期运行的分支合并到另一个，您应该考虑使用常规的“合并”策略，这将防止这个问题在未来再次发生。

详细信息： 在 Azure DevOps（和大多数 SCM 工具）中，完成拉取请求后，您可以从各种合并策略中进行选择。AzDev 中的 4 种可用策略是：

  1. 合并（无快进）：保留所有提交的非线性历史记录。
  2. Squash commit：线性历史，目标上只有一次提交（squash merge your pull request）。
  3. 变基和快进：将源提交变基到目标并快进。
  4. 半线性合并：将源提交重新定位到目标并创建双父合并。

只有第一个选项“合并”将保证来自源分支的每个提交 ID 都会显示在目标分支中。在您的情况下发生的情况是，您选择了类型 2、3 或 4，并且来自的提交 IDdevelopment不是 on master，即使所有代码更改都是。

创建 PR 时，AzDev 会显示源分支上存在但目标分支中不存在的所有提交，然后使用两个分支的合并基础从源分支的角度确定哪些文件已更改. 如果要查看完成 PR 时实际会更改哪些文件，则需要查看“合并提交”或“合并更改”。在您的情况下，您的第二个 PR 显示已经合并的提交（因为它们的 ID 不在 中master），但是当您查看“合并更改”时，您什么也看不到，这是您所期望的，因为所有代码已经被合并。

为防止将来发生这种情况，我建议您在合并时使用合并策略 #1（不快进的合并），development反之亦然master。请注意，您可以在完成普通 PR 时使用其他合并策略。development我个人最喜欢将功能/主题分支合并到长期运行的分支中，例如master类型 4，半线性合并。

推荐阅读