How to resolve conflicts in a separate commit

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?

2 answers

1 accepted

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.

  1. I branched the development branch to a merge branch.
  2. Then I merged the feature branch to the development branch and unstaged all files with conflicts.
  3. Then I merged the feature branch to the merge branch, unstaged all the files without conflicts, and resolved the ones with conflicts.
  4. Finally I merged the merge branch to the development branch, resolving all conflicts using the ones from the merge branch.

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.)

Suggest an answer

Log in or Sign up to answer
How to earn badges on the Atlassian Community

How to earn badges on the Atlassian Community

Badges are a great way to show off community activity, whether you’re a newbie or a Champion.

Learn more
Community showcase
Published May 30, 2018 in Sourcetree

Tip from the team: configuring Git or Mercurial in Sourcetree

Supported Platforms macOS Windows To make using Sourcetree as simple yet powerful as possible we embed (bundle) dependencies such as Git, Git LFS, and Mercurial. We strive to keep these...

563 views 1 2
Read article

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you