0

I am testing a scenario where devs create feature branches and push them into a dev branch (which is my compare branch). Once per week, we then merge dev into main, which triggers our CI/CD pipeline.

My intention was that main and dev should always match up. However, currently main is showing ahead of dev.

We don't work out of or push to our main branch, so how would it be ahead of our compare branch?

enter image description here

Millhorn
  • 2,953
  • 7
  • 39
  • 77
  • Does this answer your question? [Your branch is ahead of 'origin/master' by 3 commits](https://stackoverflow.com/questions/16288176/your-branch-is-ahead-of-origin-master-by-3-commits) – JBallin Mar 02 '23 at 17:53
  • Not really because we didn't make any changes in our main branch. That's not the branch we work out of or push to. This is what's causing my confusion. – Millhorn Mar 02 '23 at 17:57
  • 1
    To your side note... yes. And when it didn't match up, that's what started me on my road of confusion. – Millhorn Mar 02 '23 at 19:32
  • You are also right about the word syntax I was using. I've updated my original post. – Millhorn Mar 02 '23 at 19:32
  • I would just look at the 1 commit on `main` to see what it is. If it's 1 ahead before you merge `dev` into `main`, then someone added a commit to `main` on the side (for example, a hotfix, or maybe the pipeline running on `main` makes a commit). If `dev` was fully up to date with `main` before the merge, and then after the merge `main` gets a new commit, then that's because you did a merge that creates a merge commit, even if one wasn't necessary. BTW, the default merge type in AzDO (and many popular tools) does create a merge commit, so if you used that then that's why. – TTT Mar 02 '23 at 19:44

2 Answers2

1

This is because you have merge commit. Your branches will have equal contents. But if you merge dev->master you always create one additional merge commit.

Shamrai Aleksander
  • 13,096
  • 3
  • 24
  • 31
1

In Azure DevOps, there are 4 merge types to choose from:

  1. Merge (no fast forward): Merge with a non-linear history that preserves all commits.
  2. Squash commit: Merge with a linear history that combines all source commits into a single commit on the target, or squash merges the PR. Be aware that a new commit will be created for the target branch without keeping the commit history from the source branch.
  3. Rebase and fast-forward: Rebase the source commits onto the target and fast-forward.
  4. Semi-linear merge: Rebase source commits onto the target and create a two-parent merge.

When your source branch is a shared branch, such as dev or main, (usually) the only sensible option to use is #1, "Merge", and in this case you will be creating a new merge commit on main when completing a Pull Request from dev into main.

Given that, you have a few options that you can consider:

  1. If for some reason you really don't want to see the merge commit on main, you could theoretically avoid it by selecting merge type #3 (rebase and fast-forward). This is slightly dangerous though because if dev isn't fully up to date with main at the time of the merge, then dev will get re-rewritten. If it is fully up to date, it won't touch dev and you'll effectively do a merge with fast-forward (if possible, and it would by definition be possible).1
  2. Allow, the merge commit, and then immediately afterwards merge main back into dev with a regular merge. Now dev would be 1 commit ahead of main instead, but this is fine since the norm for your workflow is for dev to be ahead of main anyway. Note that if you ever have a hotfix into main, you'd need to also merge main back down to dev, so the rule here is something like "Anytime new commits appear on main, merge them back down into dev."
  3. You could setup a pipeline job that does the merge of dev into main for you. It could be setup to do a fast-forward merge into main, and then push it out when it's finished. (Assuming you've protected main, you'll also need to give the account that runs the pipeline permission to bypass pull requests.)

1 In AzDO Server, I've seen semi-linear merge fail to even attempt a rebase when more than 25 commits would be rebased. It wouldn't surprise me if that's also true for rebase and fast-forward, however, someone should check whether the number of commits matters when a rebase isn't necessary. If you can't have more than 25 commits regardless of whether a rebase is necessary or not, then this may sometimes thwart the idea to do a fast-forward type merge by cheating with option 3.

TTT
  • 22,611
  • 8
  • 63
  • 69