GIT: Должен ли я фиксировать выходные файлы (например, * .exe, * .lib), когда проект в стабильной ревизии?

Question

Версия 1.0 моего проекта успешно собирается в Visual Studio 2008, но когда я обновляю Visual Studio до версии 2010, сборка моего проекта не удалась (по некоторым причинам).

Мой проект изменился, и новый выпуск готов (Версия 2.0).Он успешно работает на Visual Studio 2010.

Теперь, если я хочу получить доступ к «my-project-version-1.0.exe», я должен получить версию 1.0, установить Visual Studio 2008 и собрать ее с помощью Visual Studio 2008Я не могу собрать его с помощью Visual Studio 2010.

Я не зафиксировал никакие выходные файлы моего проекта.

Должен ли я фиксировать выходные файлы (например, * .exe, * .lib) когда проект в стабильной ревизии для доступа к более старым версиям моего проекта в следующий раз?

Есть ли идея получше?

Answer 1

Поместить не исходные файлы под контроль версий, как правило, не очень хорошая идея.Если вы настаиваете, вы можете добавить его в один коммит, а затем удалить его в следующем и пометить этот коммит.

Однако вы можете хранить отдельно исполняемые файлы.Например, если вы используете github, вы можете загружать файлы, чтобы позже их можно было загружать, например, уже скомпилированные исполняемые файлы или библиотеки.

Answer 2

Лучшей идеей было бы заставить его работать в Visual Studio 2010.

Лично я и во всех профессиональных контекстах, в которых я работаю, предпочитаю хранить скомпилированные файлы вне хранилища. Двоичные различия просто не имеют смысла.

Вместо этого сохраняйте резервную копию всех версий вне репозитория (или в другом репо), чтобы ваш исходный код был чисто отделен от ваших скомпилированных файлов.

Answer 3

Вам необходимо настроить непрерывную интеграцию, чтобы при наличии стабильной версии всегда был опубликован артефакт (исполняемые файлы, документация и т. Д.).

Для получения дополнительной информации ищите Дженкинс .

Просто примечание: репозиторий предназначен только для исходного кода и всех других файлов, которые можно использовать для генерации исполняемых файлов. Как правило, следует избегать помещения исполняемых файлов в хранилище.

Answer 4

Мы ставим двоичные файлы под контроль версий. Они находятся в отдельном каталоге от кода, и наши скрипты cmake копируют двоичные файлы в / из каталогов, в которые они выводятся.

Каталог / src / имеет внешнюю ссылку на / bin /, поэтому любой, кто проверяет / src /, автоматически получает двоичные файлы. Затем сценарии cmake копируют двоичные файлы из / src / bin / в / build / debug или / build / release (для Visual Studio). После компиляции обновленные двоичные файлы копируются обратно в / src / bin /

Я могу внести изменения во что-то низкоуровневое, скомпилировать, зафиксировать, и когда коллега обновляется, им не нужно перекомпилировать мой код, когда они работают над чем-то на несколько уровней вверх.