3

I have a branch and I merged it into the master branch (via Pull Request).Then I un-ticked the box to not delete the branch. Now when I look at the branches this particular branch shows as 1 commit behind the master branch.

I don't understand this, how can it be a commit behind when the commit was what was merged from my branch into master? Is there a way to fix this so that it knows it's the same commit?

2
  • It gets worse, I made another change to my branch so now it shows as 1 commit behind and ahead at the same time. Jul 9 at 13:27
  • 2
    Welcome to DevOps.SE, Paul. While it should work that you could do multiple PRs from the same branch I'd say that it is a best practice to make a new branch for each PR. One benefit of this is that you start with any other changes that have been merged to master while your branch has been continuing on.
    – chicks
    Jul 14 at 12:13
2

From what you've described, it seems the "one commit" is a merge commit. This is due to how git works: depending on the steps you performed to get your code merged, it will or will not create a merge commit in the target branch. Check your git history to confirm it.

If that is the case, you can safely ignore it. In a typical git workflow, your "feature branches" are short-lived, getting deleted when merged, so you won't even notice this difference.

If you don't want a merge commit, merging with fast-forward won't produce one, but you may need to rebase (or squash, depending on your preference) the source branch before the merge, which will change your branch history to allow a fast-forward. ​

Since you've tagged Azure DevOps in your question, you can avoid the merge commit using the "Squash merge" or "Rebase and fast-forward" PR merge types.

P.S.: Also, if you are new to git, be extra careful when rewriting history. Things can get messy if you don't know what you are doing. I strongly recommend getting to know git better to get the most out of it.

1

First, from your description, it is clear that you are using a graphical engine for git. That can sometimes present issues.

Second, this message means that you have not pushed your commit and someone has made an additional commit in your current branch (and pushed their changes) after you last pulled and comitted.

To resolve the issue:

  1. Push your commit. How to do this in your graphical engine we cannot speak to because you have not provide details about what you are using
  2. If you have conflicts, you will need to merge or resolve them. That can be difficult if there is a collision (wherein you are editing the same sections of code)
  3. To prevent this in the future, be sure to push your commits and pull every time you begin to make changes.
5
  • I have pushed my commit otherwise how could I have merged it into master. Nobody else has done any commits. What I am using is Azure DevOps (dev.azure.com) and from what I can see merging a branch into master does not work properly. Jul 14 at 9:00
  • Simply because you merge your working copy does not mean that you have pushed those changes to the remote. Jul 14 at 14:25
  • Sheway - so you are telling me that I can merge something to master on the remote and see it without having pushed the change that I can see? Jul 15 at 9:53
  • @PaulMcCarthy, no. I'm telling you that you can merge something to master on your local copy and you can see it on your local copy and it will not be merged on the remote until your changes are pushed with "git push [origin master]" or equivalent. When that state happens (you have not pushed to your remote) and someone else makes a commit to master and pushes, you will receive the message "This branch is n commits behind master" Jul 15 at 15:37
  • the whole point of the question is to do the merge on devOps, not the local copy. No one else made a commit. Jul 15 at 16:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.