Git VisualStudioTeamServices根据请求创建提交

我有三个分支

master

，

dev

和

feature1

（gitflow流程）

dev

和

master

应用了分支策略（至少2次审核），因此无法直接提交或合并到。标准设置，对吗？我对

feature1

分支做了一些承诺。我创建并完成一个pull请求，以将提交从

feature1

获取到

dev

。然后，我创建并完成一个pull请求，以获取从

dev

到

master

的更改。VSTS现在告诉我

dev

在

master

后面。由于策略原因，我无法将

master

合并到

dev

这是我的分支在四次从

dev

拉入

master

后的状态

我能做什么

正如Tim Biegeleisen所建议的，我已尝试将

dev

合并到

master

中，但由于分支机构的策略，我无法这样做

将

dev

合并到

master

提交已准备好推送到

dev

由于策略原因，同步失败

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

---

你所描述的一切都没有让我觉得不寻常。例如，如果自上次

dev

与该分支同步以来，其他人对

master

做出了一些承诺，则很容易出现这种情况

解决这一问题的两种典型方法是合并和重新定基。让我们考虑合并，因为它可能是你已经使用的策略，更简洁的描述。您可以通过首先将

master

合并到

dev

分支中来解决这种情况。然后，从

dev

向

master

打开一个拉入请求（如果尚未保持打开状态）。让你的审核人在上面签字，然后拉取请求就应该通过了

这里的关键步骤是将

master

合并到

dev

分支中。在此操作之后，Git不应该再告诉您

dev

在

master

之后

---

旁注：从技术上讲，

master

本身也落后于

dev

。实际上，这两个分支都相互支持对方，因为自从上次同步以来，它们都有新的提交。

你不应该回顾一下

dev

现在是否也处于良好状态吗？@LasseVågsætherKarlsen“良好状态”是什么意思？你问“我能做什么”，但你没有真正解释你想做什么。您真的需要

dev

和

master

指向相同的提交吗？为什么？您将更改合并到分支中，看起来您的审查过程要求您验证这些更改是否可以安全地合并到主分支中。我知道您已经从功能分支到开发人员进行了审查，但是对开发人员的更改与在开发人员上所做的其他更改进行了集成，您是否应该在合并到master之前审查该集成？@KevinBrydon您可以提供提交历史图吗（在本地git repo中，执行两个命令：

git fetch

和

git log--oneline--decoration--graph--all

，然后显示最后一个命令的输出图）？您是如何完成将

dev

合并到

master

、默认合并策略或挤压合并策略的PR的？我无法将

master

合并到

dev

（这将解决问题）由于策略的原因。问题似乎是pullr equest在master中创建了一个新的提交。这似乎与我使用过的其他系统（如bitbucket和github）不同。@KevinBrydon我对此表示怀疑；那么pull请求的作用是什么？如果您不能将

master

合并到

dev

，您是否可以改为重新设置

dev

关于

master

？我更新了答案，将

master

显示为

dev

合并过程。只是确认一下，我是目前唯一一个提交到这些分支的人。进入

dev

的唯一代码来自

功能

分支的pull请求。进入

master的唯一代码e> 是来自
dev
的拉请求。当然可以，但分支策略阻止他推动合并或重基。如果您的集成点是通过拉请求，
dev
和
master
不能相同，因为拉请求合并时VSTS创建了提交。@EdwardThomson是否只有VSTS创建了此addit合并拉请求时是否提交？我不记得它是在使用bitbucket或git时创建的。但可能我弄错了？