Место для хранения дешево, и поэтому это не очень убедительный аргумент в пользу того, почему вы должны или не должны регистрировать файлы.
Вместо этого Вы можете обратиться к цели СКМ. Каждый файл, отслеживаемый SCM, представляет собой некоторую потребность в управлении параллельными распределенными изменениями, которые выполняет ваша команда. Ничто из этого не очевидно, пока два члена команды не попытаются изменить один и тот же файл. Решение этих изменений - это то, для чего на самом деле нужен SCM, предотвращая случайную перезапись работы другого разработчика и, надеюсь, автоматизируя процесс объединения этих изменений.
Слияние бинарных файлов обычно представляет собой серьезную проблему, потому что для универсального инструмента слияния нет нормального способа угадать, как должен работать слитый бинарный файл. Он не может знать достаточно о том, как работают индексы или указатели смещения в файле, если он специально не предназначен для распознавания этого конкретного типа файла.
Это означает, что разработчик должен объединить двоичный файл вручную, а затем сообщить SCM, что файл был так объединен. Поскольку это делает разработчик, объединение может не охватывать все изменения обеих предыдущих проверок, и поскольку файл является двоичным, автоматического способа проверки объединения не существует.
Для двоичных форматов, которые действительно представляют источники проекта, такие как художественные активы, это неудачный, но необходимый шаг. Однако выходные данные сборки не являются источниками. Нет необходимости объединять их, потому что источники могут быть объединены, и полученный результат сборки может быть восстановлен. Отслеживание и управление этими изменениями - это 100% отходов. Он тратит ресурсы SCM, хотя и не так сильно, но также тратит время разработчика на преодоление ложных слияний. Время разработки очень дорого, и все, что тратит его впустую, является раком.
С другой стороны, есть частный случай, когда результаты сборки должны быть заархивированы. Любая версия проекта, которая когда-либо была отправлена или развернута, должна быть сохранена на неопределенный срок. Наличие точной побайтной копии фактической сборки, с которой у клиента возникают проблемы, может значительно облегчить поддержку этого клиента, поскольку у вас будет точная версия, которую он имеет.
Эта резервная копия, вероятно, не должна находиться в том же хранилище, что и исходный код, так как они обычно следуют другому расписанию и имеют в основном разные структуры.
Кажется излишним включать как исходные, так и объектные файлы (исходные файлы, очевидно, требуются). В дополнение к ненужным объектным файлам может занимать много места. Если ваша фирма использует распределенный SCM (Git, Hg, Bzr), эти двоичные файлы должны быть скопированы и сохранены среди всех разработчиков.
источник