Simple workflow for solving binary conflicts

I'm currently evaluating using Git and Sourcetree at our company for all our development, not just programming. This involves a lot of CAD-projects, mainly in SolidWorks, and therefore a lot of binary files.

The people who will use it are non-programmers and can not be expected to learn the advanced concepts of Git. I have only used Git for about six months and can't say I can handle a lot of the advanced concepts yet. I intend to teach them how to do cloning, pushin, pulling, committing, branching and merging to start with and then see how well that works.

My question is about how to do conflict solving when merging with binary files, expecially when one is not 100% certain of what changes have been made in the two branches. I've tested a bit myself in Sourcetree and have come up with a workflow that is simple enough in my eyes and now I just want to verify that it don't involve anything stupid that might cause problems in the future.

The workflow is as follows:

  1. Merge, and discover there's a conflict
  2. Right-click on the file in File Status and select Reselove Conflict / Launch External Merge Tool
  3. Click Abort on the dialog Visual Merge In Progress
  4. Open and view the LOCAL and REMOTE (and possibly BASE) versions of the file in a suitable program and decide which one to use
  5. Delete the BACKUP, LOCAL, REMOTE and BASE files
  6. Right-click on the file in File Status and select Resolve Conflict / Resolve Using 'Mine'/'Theirs'
  7. Commit the merge


Is this a bad idea?

Is there a simpler way to bring out the LOCAL and REMOTE file versions? (single button or menu option)

If I want to use the BASE version, can I choose that without having to delete the original file and then renaming the BASE version to that filename? (equivalent to choosing Mine or Theirs)

4 answers

To answer your question, I think the approach you are using is the best available.

If you can find some sort of CAD diff/merge tool, you could probably set that as your external diff tool, which would make the process much simpler.

I don't think you can use the SourceTree UI to choose the BASE file for resolving the conflict - renaming is probably the only way to go.

Beware that storing "a lot of binary files" in git has additional challenges: the size of your repository is likely to increase significantly with each and every new version of the binaries. This will affect the time your users will have to wait when cloning the repo and the amount of disk space required to work with it. Depending on the amount of data and the number of commits, this can quickly become intractable.

Filippo is right, but you can workaround this by using git-lfs (large file storage) if your host supports it. If you aren't already doing this, you should do it sooner rather than later. You'll have to use a tool like the bfg repo cleaner to re-write your history to use the large file storage, and everyone on the team will have to re-clone repositories.

Thanks for the warning. I will definitely look into git-lfs.

Suggest an answer

Log in or Sign up to answer
Community showcase
Published Oct 23, 2018 in Sourcetree

Tip from the team: configure your repos for hosting goodness!

Supported Platforms macOS Windows We recently introduced support for additional hosting services such as GitHub Enterprise, GitLab (Cloud, Community Edition, Enterprise Edition), and...

1,230 views 4 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