3 ms·

> Do not include your compiled files or binaries in a git repository! Binaries (or executable files) will almost always be operating-system-dependent. This will

> Do not include your compiled files or binaries in a git repository! Binaries (or executable files) will almost always be operating-system-dependent. This will cause major headaches if you have some developers using Macs, some using Windows, and some using Linux I think you're doing something wrong if this is an issue. Unless you run on Windows, Mac, and Linux in production, your developers should not be locally running disparate platforms, they should be running whatever the production server does. There may be other reasons not to include binary programs, but this isn't really it. > Furthermore, there are certainly good reasons (read: file-insurance) to commit these kinds of files. What he calls "insurance", is basically the whole point of using revision control to me. I want everything linked together in a versioned dependency tree that's stored and manipulated with one interface. Whether it's code, text, or images, if it's logically part of the project, then it all goes together. If git can't do that for you, it's not the right tool for the job. > Do not include downloaded dependencies in a git repository! Works great if Github or whoever is around for as long as you want to have a complete history, and the project owner doesn't push out new incompatible code under the same revision, and the project owner doesn't delete "that old version nobody uses anymore"...

manicdee 11y ago
That's what submodules help you with. Locally stored version of the dependency, but it's not in your main project repository, and you get to send pull requests for bug fixes easily.
SOLAR_FIELDS 11y ago
There are some use cases to include compiled files in Git. As a practical example, I run a project that is mainly Java at my place of work, but has a Node.js dependency that will likely never change. We aren't sure that wherever we deploy internally will have Node installed, so we use nexe to compile into UNIX executable that the Java then consumes. Its unreasonable to ask our user base to wait for nexe to compile the entire node library every time (which takes around10 mins if you've never dealt with nexe) they want to make a small change to the Java classes, so we bundle the compiled node to drastically cut down on build times with Gradle. Granted this is a pretty edge case but there are definitely reasons you would want to completely disregard this article's advice on that front.

manicdee 11y ago

That's what submodules help you with. Locally stored version of the dependency, but it's not in your main project repository, and you get to send pull requests for bug fixes easily.

SOLAR_FIELDS 11y ago

There are some use cases to include compiled files in Git. As a practical example, I run a project that is mainly Java at my place of work, but has a Node.js dependency that will likely never change. We aren't sure that wherever we deploy internally will have Node installed, so we use nexe to compile into UNIX executable that the Java then consumes. Its unreasonable to ask our user base to wait for nexe to compile the entire node library every time (which takes around10 mins if you've never dealt with nexe) they want to make a small change to the Java classes, so we bundle the compiled node to drastically cut down on build times with Gradle. Granted this is a pretty edge case but there are definitely reasons you would want to completely disregard this article's advice on that front.