Visual Studio Team Services 根据拉取请求创建提交答案

【问题标题】：Visual Studio Team Services creates commit on pull requestVisual Studio Team Services 根据拉取请求创建提交
【发布时间】：2017-12-22 18:58:12
【问题描述】：

我有三个分支master、dev 和feature1（gitflow 进程）。 dev 和 master 应用了分支策略（至少 2 条评论），因此不能直接提交或合并到。标准设置对吗？我对feature1 分支做了一些提交。我创建并完成了一个拉取请求，以将来自feature1 的提交提交到dev。然后我创建并完成一个拉取请求，以将更改从 dev 转换为 master。 VSTS 现在告诉我dev 落后于master。由于政策，我无法将 master 合并到 dev。

这是从dev 到master 的四个拉取请求后我的分支的状态。

我能做什么？

根据 Tim Biegeleisen 的建议，我已尝试将 dev 合并到 master，但由于分支政策，我无法这样做。

将dev 合并到master

提交已准备好推送到dev

由于政策，同步失败

推送到远程存储库时遇到错误：rejected dev -> dev（TF402455：不允许推送到此分支；您必须使用拉取请求来更新此分支。）

【问题讨论】：

您不应该检查一下dev现在是否处于良好状态吗？
@LasseVågsætherKarlsen “良好状态”是什么意思？
你问“我能做什么”，但你没有真正解释你想要做什么。你真的需要dev 和master 指向同一个提交吗？为什么？
您将更改合并到分支中，看起来您的审核过程要求您验证这些更改是否可以安全地合并到主分支。我知道您已经审查了从功能分支到 dev 的它们，但是对 dev 的更改与在 dev 上完成的其他更改集成在一起，您不应该在将其合并到 master 之前审查该集成吗？
@KevinBrydon 你能提供提交历史图吗（在本地 git repo 中，执行两个命令：git fetch 和git log --oneline --decorate --graph --all，然后显示最后一个命令的输出图）？以及您是如何完成将dev 合并为master 的 PR，默认合并策略或 squash 合并策略？

标签： git azure-devops

【解决方案1】：

你所描述的一切都没有让我感到异常。例如，如果自从上次 dev 与该分支同步以来，其他人已经向 master 提交了一些提交，那么您很容易陷入这种情况。

解决此问题的两种典型方法是合并和变基。让我们考虑合并，因为它可能是您已经在使用的策略，并且描述起来更简洁。您可以通过首先将 master 合并到您的 dev 分支来解决这种情况。然后，从dev 向master 打开一个拉取请求（如果尚未保持打开状态）。让你的审阅者在上面签字，然后拉取请求应该通过。

这里的关键步骤是将master 合并到您的dev 分支中。在这个操作之后，Git 应该不会再告诉你dev 落后于master。

附注：从技术上讲，master 本身也落后于dev。实际上，两个分支相互落后于另一方，因为自上次同步以来，每个分支都有新的提交。

【讨论】：

由于政策的原因，我无法将master 合并到dev（这将解决问题）。问题似乎是 pullr 请求在 master 中创建了一个新的提交。这似乎与我使用的其他系统不同，例如 bitbucket 和 github。
@KevinBrydon 我对此表示怀疑；那么拉取请求的目的是什么？如果你不能将master 合并到dev，你可以在master 上rebase dev 吗？
我已更新答案以显示 master 到 dev 合并过程。只是为了确认，我是目前唯一一个致力于这些分支的人。进入dev 的唯一代码来自feature 分支的拉取请求。进入master 的唯一代码是来自dev 的拉取请求。
当然，但是分支策略阻止他推动合并或变基。如果您的集成点是通过拉取请求，dev 和 master不能相同，因为 VSTS 在合并拉取请求时创建了提交。
@EdwardThomson 在合并拉取请求时是否只有 vsts 会创建此额外提交？我不记得它是在使用 bitbucket 或 git 时创建的。但也许我错了？