Reputation: 1299
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 ?
Upvotes: 2
Views: 704
Reputation: 6458
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.
Upvotes: 0
Reputation: 142332
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.
Upvotes: 2
Reputation: 1326554
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:
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.
Upvotes: 2