How to resolve git conflict locally (with some constraints)?

Question

I want to resolve a git merge conflict (between feature and test branches), but there are some limitations:

1. cannot push directly to test and master branches
2. cannot merge feature branch into the test branch (because I cannot push to origin test)
3. cannot merge test branch into the feature branch (because later, when it is tested I should merge feature branch into the master branch)
4. the conflict is caused by the test branch NOT the master branch
5. I want to avoid duplicating branches
6. cannot resolve conflict on Gitlab UI, because it merge the target branch (test) into the source branch (feature) after resolving

The workflow of my team is the following:

• every feature branch must be based on master branch
• commit/push the feature branch then create a merge request to test (default) branch (then wait for testing)
• create a merge request to master branch

I tried with these workarounds:

1. turn off the "anti-push" constraint temporarily (if there are a lot of conflicts, this is not ideal)
2. turn off the "anti-push" constraint permanently (I do not want this...)
3. using duplicated branches (I do not want this, because it is confusing)
4. using Gitlab UI (break my workflow, mentioned above)
5. manually edit the feature branch (does not work, because it is not a "real" merge)

I think I cannot use git rebase, because the conflict is not caused by the master branch, and I want to preserve the "master based" feature branch, so I also cannot use rebase based on test branch.

In few cases, this solution can solve the problem, but not in my case.

I am looking for a "simple" solution which resolve the problem above. Temporary branches on local (but not on remote) are okay.

Answer 1

Heavily Updated Answer

After reading the problem more closely and also agreeing with sentiments expressed by @j6t I need to alter my advice... this workflow as a whole is problematic. Don't do what I said ( don't branch feature from test ). Branch from master, then make a variant of the branch called feature-test which you create in case of a conflict by doing one of the two conflict resolution paths i mentioned ( merge feature into test, or test into feature and resolve the conflicts ) and that branch can be requested for merge to test.. if items come up make fixes to your initial branch and then merge that branch into feature-test again. this way you keep fixes found from testing in feature in feature and you keep conflict resolutions in feature-test, so that in the end you can merge feature to master, with stronger safety that fixes of issues from feature's testing are in feature but not conflict resoultion or stray materials from test.

My big issue with this is that test shouldn't generally exist or be used. They should test your branch by merging master into it and testing it. Otherwise what you are testing is not what you are merging to master, and it doesnt sound like testing is performed on master.

Now if you have a bunch of related features, or you have a big change such that other things SHOULD be aware of and take account for it things change. In that case you should use an integration branch that you merge into for testing, and you should potentially branch off the integration branch for the features that are targeted for the integration branch, which will all go to master together.

Overall if test is not merged to master but you test off of it, and you keep fixing things on test you end up in a wierd state where you aren't testing what will actually go to master which could both hide and introduce bugs that you would otherwise catch in testing.

Some things I said before still hold:

• There is no SIMPLE solution for resolving merge conflicts; you have to resolve them manually otherwise git would have done it for you.

• The workflow and constraints make this a horrible situation. They are effectively testing a branch can significantly vary from what master will be.

• I honestly don't see value from the test branch currently, if test is not merged to master and vice versa, and only see negatives stemming from it.

Personally if this was the workflow I was presented with I would be discussing changing it, or heading toward a new job unless there is significant test automation that is carried out by CI/CD before the branch is allowed to merge to master. It's a recipe for disaster. You're going to constantly be wasting time crafting conflict resolutions to be able to merge to test that are thrown away, and then possibly doing different resolutions to merge to master.

The testers should do their testing and have automation in place on your branch once its PR is opened to be merged to master. They should mark it passed when they have validated it. I would do this by having two different sets of gatekeeper approvals required for the merge to master, someone from code review group, and someone from qa ( if that can't be done via CI/CD ).

• Whoever is in the appropriate leadership role, to be deciding which changes should be merged when, should be initiating the merges to master once a feature is both validated (reviewed and tested) and desired to be brought into master.
• If a feature is validated and sits because it's not yet wanted in master, than it sits there ready and waiting.
• If additional commits go to the feature after testing, the testing needs to be verified again (this is why automation/CI/CD is best), and someone should update the code review to approve it again.
• Finally, there should also be a run of the testing on master commits to make sure that if something is independently added to master that didn't conflict with feature that the two both being present doesn't cause a problem.

It also boils down to goals: should master always be deployable? Or should it always be buildable, mostly stable, where you work from, and periodically you cut a release from master that has been more deeply tested? ( In which case you should absolutely tag a release commit so that patches can be created on top of the released version, and then ported/merged/cherry-picked as needed to master. There is no right or wrong answer to this question. Different projects/workflows and scenarios have different requirements.

Answer 2

I'd still suggest rebasing feature branch onto test: you can later rebase the result back onto master (possibly making that easier if the conflicting features from test get merged onto master, too).

On the other hand, if the conflicting changes in test are temporary (i.e, won't be merged to master) then just create a copy of your feature branch (e.g feature-test) and rebase that copy onto test and do the testing that you want. And when you add new commits, you can use either feature or feature-test, whichever is more convenient, and then cherry-pick the commits into the other one as well.