Kevin Brydon
Kevin Brydon

Reputation: 13112

Visual Studio Team Services creates commit on pull request

I have three branches master, dev and feature1 (gitflow process). dev and master have branch policies applied (minimum of 2 reviews) so cannot be committed to directly or merged to. Standard setup right? I make some commits to the feature1 branch. I create and complete a pull request to get the commits from feature1 into dev. I then create and complete a pull request to get the changes from dev into master. VSTS now tells me that dev is behind master. I can't merge master into dev due to the policies.

This is the state of my branchesafter four pull requests from dev into master.

dev is four behind master

the four pull requests

What can I do?

As suggested by Tim Biegeleisen, I have attempted to merge dev into master but am unable to do so due to the branch policies.

Merge dev into master

enter image description here

Commits are ready to be pushed to dev

enter image description here

Sync fails due to policies

enter image description here

Error encountered while pushing to the remote repository: rejected dev -> dev (TF402455: Pushes to this branch are not permitted; you must use a pull request to update this branch.)

Upvotes: 2

Views: 4216

Answers (1)

Tim Biegeleisen
Tim Biegeleisen

Reputation: 521093

Nothing you described struck me as anything out of the ordinary. You could easily end up in this situation if, for example, others had made some commits to master since the last time dev had synched with that branch.

The two typical ways to resolve this are merging and rebasing. Let's consider merging, because it is probably the strategy you are already using, and it is more succinct to describe. You could resolve this situation by first merging master into your dev branch. Then, open a pull request back into master from dev, if one does not already remain open. Have your reviewers sign off on it, and then the pull request should go through.

The key step here is merging master into your dev branch. After this operation, Git should not longer be telling you that dev is behind master.

A side note: Technically speaking, master itself was also behind dev. Actually, both branches were mutually behind the other party, because each has new commits since the last time they both synched.

Upvotes: 1

Related Questions