CODEWITHSUNDEEP
gitgithub
David
David

Reputation: 1963

GIT - two branches and order of merging to avoid conflict

Ok, so this is the scenario I'm facing. I'm working with two different branches and I'm editing the same file. Let's assume that first branch name is WORK-001 and second is WORK-002. Within WORK-001 branch I've provided changes shown below:

file: update.php

function test_update_7001() {
  dsm('work 001');
}

On the branch WORK-002 I've provided changes shown below:

file: update.php

function test_update_7002() {
  dsm('work 002');
}

I finished work on both branches, pushed changes and made two separate pull requests. The problem is that if the changes from branch WORK-002 are going to be merged first then the changes from WORK-001 won't ever be triggered (function test_update_7001() never gonna be run). These functions works this way: if 7002 is triggered first then number of this function is saved to database and next available number is 7003, system will never allow to run 7001. Of course I can provide both numbers the same, so it could be 7001 in both cases, but when the pull request is merged (doesn't really matter which one first) then conflict appear.

Is there a way to avoid conflict and force (somehow) the person who is responsible for mergeing to merge WORK-001 as first and WORK-002 as second so the order of merge is correct? Maybe some kind of sub branches?

Upvotes: 0

Views: 250

Answers (1)

Mark Adelsberger
Mark Adelsberger

Reputation: 45659

The only way to control the order in which the pull requests will be merged would be to not create the pull request for WORK-002 until after WORK-001 has been merged. If this seems clunky, I would reply that it is a symptom of a clunky scheme of function naming conventions that allows the validity of one piece of code to depend on whether an unrelated change got committed before or after.

A few other notes:

A premise built into your question is that giving them the same function name would cause a merge conflict. This is (probably) incorrect.

The default merge tool determines conflicts by where in the file (line number) a change is made, not by function names. So my expectation would be that you'll get a conflict even if you give the functions distinct names (if the new functions are at the same position in the respective versions of the file), or no conflict even if they use the same name (if the new functions are at different positions in the respective versions of the file).

The branch topology could arguably be considered to be the problem.

Two branches independently rooted from master should be independent of one another. If Change A has to be merged before Change B, even though in this case it's for a somewhat non-standard reason, you could interpret that as Change B depending on Change A. In that case, the branch for Change B should be rooted on the branch for Change A, far enough down the branch that it includes the changes it depends on.

That last statement may be confusing, and without knowing more about the system you're using that requires test_update_7001() to be merged before test_update_7002() it's hard for me to clarify; so the "safe" thing would be to root WORK-002 at the HEAD of WORK-001.

There are two problems with that:

First, it doesn't force merging WORK-001 first; what it does is make it so that the WORK-002 PR would show changes including WORK-001, unless WORK-001 had already been merged. If these changes are meant to be reviewed and accepted independently, that could cause problems.

Second, it sounds like you've already pushed the branches in their current topology, so rebasing WORK-002 (which is what you'd have to do) may be disruptive.

If you really need function names to be merged to master in a particular order, then maybe assignment of the function names should be part of the merge process.

But that's also hard to implement reliably, and in the end that brings me back to thinking your problem is a clunky system for identifying what functions can be run.

Upvotes: 3

Related Questions