Storing generated files in Git

Question

We have a reasonably large, and far too messy code base that we wish to migrate to using Git. At the moment, it\'s a big monolithic chunk that can\'t easily be split into smalle

Answer 1

I am not a git-guru, but I guess this could be solved with submodules. Add the precompiled binaries as submodules, to get them then one simply has to do this:

git submodule update --init

How to ignore changes in submodules is described here. So, if the dev rebuilts something it will NOT be committed with git commit -a and not added with git add .. They just have to make sure they do not commit something from within the submodule directly. This Vimcast shows how to use submodules for keeping your vimfiles under controll, but this should be easy to adapt for your problem.

Answer 2

The ideal solution is to avoid versioning binaries and store them in an artifact repository like Nexus.

The issue with deliveries in a VCS is that a VCS is design to record and keep the history of all files it manages, whereas:

• many versions of a delivery are intermediate builds that will need to be cleaned up at one point or another
• cleaning (removing old versions) is quite hard to do in a VCS, very easy to do in an artifact repository.
• the size of a repo will become an issue (especially for a DVCS, unless you always get the latest version, in which case a shallow clone might alleviate that issue)
• there is no way of comparing a version of a binary with another (so "versioning" don't make a lot of sense)

Answer 3

I would keep these in a separate repository to the source files. You can use 'git submodules' to keep a reference between the two; so the 'compiled libs' becomes the parent and the source becomes the submodule. That way, when you commit the libs you commit a reference to the exact point of the source code at the time.

Further, since developers don't need the full history, you can use git clone --depth 1 libs.git which gives you only the latest version of the libs. It doesn't pull further history, and doesn't allow you to commit (which is OK since the server should be doing that for you) and you'll give them access to the latest versions (or whatever branch you specify on the clone command with -b).

Ideally you don't want the main git repository containing, or pointing to, the binary repository.