Refactor "Resolve conflicts" workflow in order to avoid directly committing on source branch

Problem to solve

In some projects, especially projects that works with multi-stricted-dest branches (you have multiple development branches with strict access to it, like: master (prod), staging, dev, etc.), directly committing on source branch creates a consistency problem, during the "Resolve conflicts" workflow, which is make "Resolve conflicts" option is dangerous.

Intended users

User experience goal

The developer should be able to decide what "merge conflicts" operation will do.

Proposal

  1. Simply, we can replace "Commit to source branch" button with a brand new Group Box button, in the "Resolve conflicts" page.

MR page:

Screen_Shot_2020-10-14_at_09.28.09

Resolve conflicts page:

Screen_Shot_2020-10-14_at_09.30.47

  1. Provide some options like: "Resolve conflicts on source branch", "Resolve conflicts on destination branch"
  • "Resolve conflicts on source branch": as-is
  • "Resolve conflicts on destination branch": It should not create any commit on source branch. All conflicts should be fixed in destination branch, just like how git merge --continue works after we fixed conflicts, which do not make any commit on source branch.

Further details

In order to reproduce, let's create a sample Git workflow that proves that in what situation make "directly committing on source branch" is dangerous during "Resolve conflicts" stage:

  • You have multiple development branches: master (production), staging, dev
  • Each developers create feature branches from this main branch and work on them.
  • Once the tasks are done, they should create 3 merge requests on each dest branches: master, staging, dev
  • After dev MR is merged, QA reviews and tests dev branch for that specific feature
  • Client always tests staging branch after tasks are done and passed QA tests. Which means, we have to merge that feature branch to staging just before staging test start.
  • After client and QA tests are passed, it means that feature is ready to deploy production. Let's merge that opened feature MR to master in order to deploy prod.

As you've already seen, this workflow is not trunk-based. Which means, if there are multiple awaiting opened MR for different destination branches on same source branch, Resolve conflicts causes this:

Screen_Shot_2020-10-14_at_09.32.26

In this screen shot, there was one source branch with single commit. After I resolved conflicts on dev MR using GitLab's way, GitLab just added a new merge branch ... commit on source branch, which is caused consistency problem on master and staging branches.

Normaly, If we resolve conflicts with an IDE or in terminal:

  • git checkout dev
  • git merge feature-branch-to-merge
  • Fix conflicts by hand or an IDE
  • git merge --continue This is the correct way to resolve conflicts in this situation. And does not create a new merge commit on source branch.

Permissions and Security

Any user would be able to resolve merge conflicts without running into permissions problems.

P.S: Since as a native English speaker, I am sorry in advance for any grammatical mistakes.