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:
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)
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.
Supported Platforms macOS Windows We recently introduced support for additional hosting services such as GitHub Enterprise, GitLab (Cloud, Community Edition, Enterprise Edition), and...
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!
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