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.

CodePudding user response：

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.

CodePudding user response：

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.