Out project is using a modified version of Git Flow and A Successful Git Branching Model. What usually happens is our tasks are broken down in small pieces and then those are committed to a separate branch for that sub task. We create a pull request to merge those into a feature branch. Eventually the feature branch will be reintegrated into a development branch which contains multiple feature.
When reintegrating a feature branch into a development branch I want to separate non conflicting changes into the first commit (no fast forwards here) and then commit all the conflict resolutions in a separate commit. The purpose of this is so that I don't have to get someone to re-review all the trivial changes, they can just look at the one commit for the conflict resolutions and approve those.
When I try and do this in SourceTree the initial merge operation will stage everything. I then unstage the files with a conflict and commit what is left. The problem is that as soon as the files are unstaged the conflicts are marked as resolved. So to do the second commit I have to manually find the conflict markers and see what to do. It also makes it difficult to launch an external merge tool.
It's been a while since I have used Git from the command line but I thought the conflict was only resolved when it was added? Is there a way to achieve this in SourceTree?
I tried various approaches and sort of found a way to do it. There were some changes missing but it may have been because of an invalid conflict resolution.
There is no Git client that would let you do what you want, because when you are merging, you cannot commit until you have resolved all the conflicts one way or another. Also, If you merge two branches twice, the second merge will not merge anything before the first merge. (=It excludes the files you "resolved" in the first merge by not merging them.)
I guess you do not want to change your workflow. (If you had only one level of feature branches, this whole problem would not exist.)
One thing you could do is to have the review of the conflict resolution at the time when it is happening, i.e. have the reviewer be there when the changes are merged.
Another thing you could do is to resolve the conflicts by merging the development branch into the feature branch first (at this point you have all the feature changes + conflict resolution in the feature branch, this can be reviewed nicely) and only allow clean merges when the feature branch is merged into the development branch. (This is how pull requests work in Stash.)
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Online forums and learning are now in one easy-to-use experience.
By continuing, you accept the updated Community Terms of Use and acknowledge the Privacy Policy. Your public name, photo, and achievements may be publicly visible and available in search engines.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.