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
- Simply, we can replace "Commit to source branch" button with a brand new Group Box button, in the "Resolve conflicts" page.
MR page:
Resolve conflicts page:
- 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 testsdev
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 tostaging
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:
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.