Что поставить под контроль версий?

Ответ 1

Правила большого пальца:

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

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

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

Мои причины:

Исполнение сгенерированного кода кажется пустой тратой времени. Это сработало правильно? Я могу вернуть его одним нажатием кнопки.

Действительно?

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

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

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

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

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

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

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

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

Ответ 2

Я думаю, что лучше всего поставить что-либо под контролем версий, что поможет разработчикам быстро начать работу, игнорируя все, что может быть автоматически сгенерировано средствами IDE или сборки (например, Maven eclipse плагин генерирует .project и .classpath - нет необходимости проверьте их). Особенно избегайте часто изменяющихся файлов, которые не содержат ничего, кроме пользовательских настроек, или конфликтуют между IDE (например, другая среда IDE, которая использует .project, как это делает eclipse).

Для пользователей eclipse мне особенно удобно добавлять стиль кода (.settings/org.eclipse.jdt.core.prefs - автоматическое форматирование при включенном сохранении), чтобы получить последовательно отформатированный код.

Ответ 3

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

Истина не только для "нежелательных файлов" IDE, но и для промежуточных файлов (например,.pyc в python,.o в c и т.д.).

Ответ 4

Здесь автоматизация сборки и файлы сборки входят.

Например, вы все равно можете построить проект (разработчикам потребуется одно и то же программное обеспечение для сборки), но затем они могут использовать две разные IDE.

Что касается "нежелательной", которая генерируется, я предпочитаю игнорировать большинство, если она. Я знаю, что это означает, что язык не агностик, но рассмотрим Visual Studio. Он генерирует пользовательские файлы (пользовательские настройки и т.д.), Это не должно быть под контролем источника.

С другой стороны, файлы проекта (используемые процессом сборки), безусловно, должны. Я должен добавить, что если вы находитесь в команде и все согласны с IDE, тогда проверка в определенных файлах IDE прекрасна, поскольку они являются глобальными, а не определенными пользователем и/или не нужны.

Эти другие вопросы хорошо помогают объяснить, что нужно и не следует проверять в контроле источника, поэтому я не буду их повторять.

Ответ 5

Все, что было бы разрушительно, если бы оно было потеряно, должно быть под контролем версий.

Ответ 6

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

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

Ответ 7

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

Что-нибудь еще? Храните его где-то в другом месте. Разработчики должны как можно больше выбирать свою рабочую среду.

Ответ 8

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

Что касается сгенерированных файлов IDE (я предполагаю, что это те, которые не генерируются во время процесса сборки, такие как файлы решений для Visual Studio) - ну, я думаю, это будет зависеть от того, работаете ли вы самостоятельно, Если вы работаете в одиночку, то идите дальше и добавляйте их - они позволят вам вернуть настройки в решении или что бы вы ни делали. То же самое касается других не-подобных файлов. Однако, если вы сотрудничаете, тогда моя рекомендация не является большинством файлов, сгенерированных IDE, как правило, характерна для пользователя, так как они работают на вашей машине, но не обязательно на других. Следовательно, вам может быть лучше не включать файлы сгенерированных IDE в этом случае.

tl; dr вы должны поместить большинство вещей, которые относятся к вашей программе, в управление версиями, исключая зависимости (такие вещи, как библиотеки, графика и звук, должны обрабатываться какой-либо другой системой управления зависимостями). Что касается вещей, непосредственно созданных IDE - ну, это будет зависеть от того, работаете ли вы в одиночку или с другими людьми.