Merge Conflicts in MR with dev and main branch

General
,
1

I have a problem, that confuses me quite much, because I thought that should work without problems.

  • I have a main and a develop branch and only develop can merge into main, all other branches merge into develop, so a quite straight forward setup.

  • At the beginning main and develop are the same, no commits before or the other one.

  • I open a new branch from develop (e.g. feature_42). When I start, it is obviously at the same level like main and develop.

  • I go with GitLab Merge Request from feature_42 into develop, which works fine. After the merge, the develop branch is 2 ahead and after an automated version update on the develop branch, it is 3 commits ahead of main. (Somehow a merge requests generates 2 commits…?)

  • I open a merge request from develop to main, which also works fine…but only the first time!!

- After the merge from develop into main, develop is 2 commits behind main, which now is a serious problem

Since different developers are working on features and merging them to develop, we could also merge new features in develop, which works good. But when we want to merge development into main, GitLab refuses and sees merge conflicts, because it is 2 commits behind.

FYI: In GitLab a merge-request uses a classical “merge request” no ff or similar.

I am confused, that this seems so hard to solve, because I thought that is the basic idea of Gitflow :frowning:

Has someone an idea?

Thanks in advance.

2

Hey :facepunch:
I’d start by looking into why and how 2 commits are generated. Are you on SaaS or self hosted?

1 Like
3

I use GitLab SaaS.
I have taken a look at the commits into the main branch to see, why 2 commits were created.
Based on the commit messages the first one is the Squash commit and directly followed by a merge commit. Should it be that way? I have compared both commits and get “Showing
with 0 additions and 0 deletions”, so they are the same.
But the problem would remain also with one commit ahead in the main branch, because the merge request dev->main seem not to work good, if main is also a commit after dev, even it was just from the last the merge from dev to main.

4

Was just discussing my last answer with ChatGTP. Takeaway:

  • 2 commits are normal, the first one is the squash commit, that changes the code in main, the second one is the classical merge commit, that is not changing code, but can be used for housekeeping.
  • It seems to be a good practice, to update the develop branch after the merge with the main branch, not because in main is codewise differently, but contains commits, that are not in the history of develop, which can confuse git.

Somehow this all seems overly complicated, but it seems like the way to go (so git is like life in general, so to say)

Thanks for the question, was bringing me to the right point.