Simple workflow for solving binary conflicts

[SesamProductions]

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

Questions:

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)

[Seth]

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.

[SesamProductions]

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

[Seth]

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.

[Filippo Bollini]

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.