Что подвергнуть управлению версиями?

Эмпирические правила:

1. Включите все, что влияет на результат сборки (параметры компилятора, кодировки файлов, настройки ASCII / двоичного кода и т. Д.)
2. Включите все, чтобы сделать это возможно открыть проект из чистой кассы и иметь возможность компилировать / запускать / тестировать / отлаживать / развертывать его без какого-либо дополнительного ручного вмешательства
3. Не включать файлы, содержащие абсолютные пути
4. Избегайте включения личных предпочтений (размер табуляции, цвета, положение окон)

Следуйте правилам в этом порядке.

[Обновление] Всегда возникает вопрос, что должно происходить с сгенерированным кодом. Как правило, я всегда помещаю их под контроль версий. Как всегда, относитесь к этому правилу с недоверием.

Мои причины:

Управление версиями сгенерированного кода кажется пустой тратой времени. Он генерируется правильно? Я могу вернуть его одним нажатием кнопки!

Правда?

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

И даже если бы вы могли, могли ли вы когда-нибудь быть уверены, что это не так? Вы что-то пропустили?

Так что, с одной стороны, помещение сгенерированного кода в систему контроля версий имеет смысл, поскольку это значительно упрощает выполнение того, для чего предназначена VCS: вернуться в прошлое.

Кроме того, это позволяет легко увидеть различия. Генераторы кода тоже содержат ошибки. Если я исправляю ошибку и получаю 150 000 файлов, это очень помогает, когда я могу сравнить их с предыдущей версией, чтобы увидеть, что а) ошибка исчезла и б) ничего остальное не изменилось неожиданно. Это неожиданная часть, о которой вам следует беспокоиться. Если нет, дайте мне знать, и я позабочусь о том, чтобы вы никогда не работали в моей компании и : -)

Основная проблема генераторов кода - стабильность. Этого не происходит, когда ваш генератор кода просто выплевывает случайный беспорядок байтов при каждом запуске (ну, если вы не заботитесь о качестве). Генераторы кода должны быть стабильными и детерминированными . Вы запускаете их дважды с одним и тем же входом, и выход должен быть идентичным до младшего разряда.

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

Сгенерированный код, который я не мог бы поставить под контроль версий, будет документацией. Документация - довольно мягкая цель. Это не имеет большого значения, когда я регенерирую неправильную версию документов (скажем, в ней есть несколько опечаток). Но для релизов, Я мог бы сделать это в любом случае, чтобы увидеть разницу между релизами. Это может быть полезно, например, чтобы убедиться, что примечания к выпуску полны.

Я также не проверяю файлы JAR. Поскольку у меня есть полный контроль над всей сборкой и полная уверенность в том, что я могу вернуть любую версию исходников за минуту, плюс я знаю, что у меня есть все необходимое для ее сборки без какого-либо дополнительного ручного вмешательства , почему мне нужны исполняемые файлы для? Опять же, может иметь смысл поместить их в специальный репозиторий релизов, но тогда лучше храните копию за последние три года на веб-сервере вашей компании для загрузки. Подумайте: сравнивать двоичные файлы сложно и мало что вам скажет.

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

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

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

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