Push a merge conflicted branch

Question

In our project we have quarterly release out which 2 months are for development and 1 months is for UAT. Our is a very big project and there are around 20 teams in our project each working on some different module.

So how we follow is that we keep working on master and after 2 months we create a release branch with release version e.g. RELEASE_VERSION_20.1. After the release we merge back the RELEASE branch into master.

Now we are bound to get conflicts between RELEASE_VERSION branch and master. Now one of the developer takes the responsibility to merge the RELEASE_VERSION into master. So we create branch out or master say merge_RV20.1_into_master. Then, he/she tries to resolve the conflict but they may not have knowledge about every module and may end up doing wrong merge i.e. some of the changes in master might be overridden or some changes from release branch might get lost.

So is there a way that we create a merged branch merge_RV20.1_into_master. which has all the conflicts and we can push this branch to remote, so that 1 developer from each team can checkout this branch and resolve the conflicts for which they have knowledge and push to remote ?

Answer 1

You could, in theory, add and commit files with their merge markers, for future resolution.

git checkout -b merge_RV20.1_into_master master
git merge RELEASE_VERSION_20.1
# add everything, including files with conflict markers in them
git add .
git commit -m "merge with conflicts"

But:

• you wouldn't be able to see them in a merge tool anymore.
• you will have to grep for those merge markers in order to resolve them, file by file.
• the default conflict marker don't mention the base (common ancestor), which would make any future resolution complicated (see "Why is a 3-way merge advantageous over a 2-way merge?")

If you still want to do that, at least set the merge.conflictstyle to diff3. See "Checking Out Conflicts":

def hello
<<<<<<< ours
  puts 'hola world'
||||||| base
  puts 'hello world'
=======
  puts 'hello mundo'
>>>>>>> theirs
end

That way, a future review will be base not just on "ours" and "theirs", but also "common": you will know which side has changed since the last common version.

Answer 2

So is there a way that we create a merged branch merge_RV20.1_into_master.

which has all the conflicts and we can push this branch to remote, so that 1 developer from each team can checkout this branch and resolve the conflicts for which they have knowledge and push to remote ?

If you can you should use a pull request to do it. Pull request will show you the differences so you can go over them before making any commits back to your master branch.

Here is an example from github how they display the pull request changes.

Answer 3

For my opinion, no commit should be done directly on the release branch. Instead, developers should have feature branches which they'll perform 2 merged from it - one into the release branch and one into merge. This will prevent all (or most of) the conflicts.

Also, please explain the motivation for the need to merge back to master from the release branch and also what changes (and how it is managed) are done on the release branch.