0

The situation is as follows:

For a database system each developer creates patch scripts which modify the database. Those scripts are executed from one big master script, called "db_patch". Since every developer is working on his/her feature branch, they independently edit the script "db_patch" to call their own database scripts (which are unique). Every developer will add the code for the current changes (also called "changeset") after the already existing changes.

The code (business logic and the mentioned database patches) will then be committed for a pull request on Azure DevOps. After the review is approved, the pull request is closed, and DevOps will automatically merge all changes from the feature to the master branch.

Now, this is the situation where the conflicts occur: the script "db_patch" will be in conflict because of other feature branches which are already merged.

Question:

What options do we have to avoid constant merge conflicts after the code review?

  • Is there a way to tell git to merge changes in the file "db_patch" always after existing code?
  • Is there a way to help git recognize hunks successfully in a file that is edited in different branches? Note that the code exists in the same line, thus the conflict...

I know that from an organizational viewpoint we could just merge the master branch into the feature before approving the code review. However, this shall not be the task of the reviewer! So I'm looking for other options.

For the sake of completeness here's how a code block from the master script "db_patch" looks like:

if (changeset ABC not deployed yet) then
  execute my_script1
  execute my_script2
  compile
  set changeset ABC deployed
end if

This code block will be repeated for every changeset with different (unique) scripts to be called.

Markus L
  • 932
  • 2
  • 20
  • 38

2 Answers2

1

The short answer is no.

There is a kind of merge operation called a union merge that takes changes (normally, "additions") from both sides of the merge. But this isn't guaranteed to produce the right result, because Git works on a line-by-line basis and may match the wrong lines, so that the inserted parts mix badly. Even if they don't mix together like this, they might happen in the wrong order: for instance, when doing database migrations, they typically need to be done in the right order, and merging migrations A and B might produce a file that does migration B, then migration A, which is simply wrong.

That said, you can use union-merge. See How to resolve a git conflict by keeping all additions from both sides? for an example.

torek
  • 448,244
  • 59
  • 642
  • 775
  • The union merge is an interesting option but I think it really applies only to unstructered text (ie. changelogs) where the order of lines is not so important. Doing to merge _after_ the conflict appears woudn't really improve the current situation. The merge of the conflicted file is trivial but we want to avoid it at all. – Markus L Oct 04 '22 at 09:49
1

I can think of a couple of options:

  1. Make your master script call all the DB scripts in a "DB-scripts" folder. Then your devs add their DB scripts as separate files to this DB-scripts folder.

  2. Your devs need to merge the latest master db_patch into their own branch before committing for a pull request. You seemed to mention this option, but I didn't understand what "this shall not be the task of the reviewer!" has to do with it.

ETA 3. Devs add a "stub" code block to master db_patch when they start working on a feature, and make a separate initial PR for that stub code block. Then when the completed feature containing the real code block gets merged, hopefully Git merge can recognize the updated code blocks and merge automatically.

Conrad Albrecht
  • 1,976
  • 2
  • 15
  • 19
  • Thanks for thinking of different approaches. 1- Then the DB scripts need to have a unique order number and the developers must pick one (like from a sequence). Yes, this could be an approach. 2- During the pull request creation and the finalization of it could be some time. During this time other features may change the master script and finish the pull request review earlier. Thus the merge must be done right before approving the feature - which is done by the **reviewer** (but not the original developer). – Markus L Oct 05 '22 at 15:14
  • 3- I think the stub would just move the merge conflict to another pull request situation. Anyway, I was also thinking about stubs (plural!) which the devs use to fill out. Each one has just to agree on _his/her_ stub... – Markus L Oct 11 '22 at 06:33