The hard core 'unix/linux' build-from-scratch approach is to not store binary artefacts because, well, you should rebuild from scratch, and its a continuous process of development and fixes, so... Core Git is designed around this source code versioning approach, with the basic unit being a line of code (\n terminated) as seen in diffs, exchanged in plain text emails. (Not easy to do in binary) .
However others take different views, noting that you can't always go back and rebuild old versions because the tool chain has been updated and has different bugs, so... Binary size is also an issue for repos, and corporate IP protection. Some use Git LFS, which has a central server for the large binary artefacts., Microsoft has adopted Git, and has a single mega repo. so is contributing to git so that users can feel as if they have the whole repo locally, with the hidden-missing bits being auto fetched when required. There is no one 'right' solution. It's more important to have a clear understanding our your own 'corporate' situation and likely future, so that you can get the best of all worlds. Do you even need distributed version control? etc. On Tuesday, April 21, 2020 at 11:13:52 AM UTC+1, lbd...@gmail.com wrote: > > We are having a discussion at work on storing binary artifacts generated > from the creation of programs in the git repository. > > > > Seeking advice and wisdom on this. > > > > Thank you in advance > > > > > > Lionel B. Dyck <sdg>< > Website: https://www.lbdsoftware.com > > "Worry more about your character than your reputation. Character is what > you are, reputation merely what others think you are." - John Wooden > > > -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/git-users/bbe91ec1-c907-49a1-ac93-72446aff10fc%40googlegroups.com.
