GitLab flow production branch conflicts

I am trying to design a Git workflow based on GitLab Flow as described in this document:

I am using GitLab (of course) and I have a pipeline setup where:

  • master branch deploys to staging
  • production branch deploys to production

When I am ready to deploy, I create a merge request from master > production.

My issue is that after a while, I start to see conflicts in these merge requests which need to be manually resolved before merging to production.

What is the correct way to update a production branch for GitLab flow? It seems strange that I would have to manually fix conflicts to release to production. I never push changes to production directly, everything goes via master so I’m not sure why I get conflicts.

Am I doing something wrong?

The process you describe looks fine. Why you get conflicts? Apparently there were changes in production not coming from master. It’s easy to check. Look whether there are commits in production, which are not results of merges from master.

1 Like

Thanks for the response @alexk, I suspect you are right, and somehow there were changes in production which were not result of master. Next time I get the issue, I’ll do some more investigation and check the commits.

Hey @alexk / anyone who might be curious…

I had the issue again and looked into the commits as you suggested.

I noticed there were some commits in production that are not in master. These were the merge commits created by GitLab when merging because I checked the “squash commits” button.

I think the issue was with squashing the commits when doing a production release.

Is it best practice not to use that feature for GitLab flow releases?

Hi @londonappdev,

I dare not claim that I know what is the best practice, but personally I don’t like anything that changes the history, in particular squashing commits. Who knows, maybe one day you will want to return to that commit…

1 Like

I have a simmilar setup and I have the same problems.

We do squash merge request commits to development and from there merge to master with a new merge request.

@londonappdev did you every come across a solution for this?