Должен ли я хранить сгенерированный код в системе контроля версий

Question

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

У нас есть несколько классов, которые генерируются во время сборки для обработки операций с БД (в данном конкретном случае с SubSonic, но я не думаю, что это очень важно для вопроса). Генерация задается как шаг перед сборкой в ​​Visual Studio. Поэтому каждый раз, когда разработчик (или официальный процесс сборки) запускает сборку, эти классы генерируются, а затем компилируются в проект.

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

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

Есть аргументы или встречные аргументы?

---

ОБНОВЛЕНИЕ: я задал этот вопрос, так как я действительно верил, что есть один окончательный ответ. Глядя на все ответы, я могу с уверенностью сказать, что такого ответа нет. Решение должно быть принято на основе более чем одного параметра. Чтение ответов ниже может послужить хорошим ориентиром для типов вопросов, которые вы должны задавать себе, когда решаете эту проблему.

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

Answer 1

Сохранение в системе контроля версий - это больше проблем, чем стоит.

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

Обычно мы оставляем сгенерированный код (idl, jaxb и т. Д.) Вне системы контроля версий, где я работаю, и это никогда не было проблемой

Answer 2

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

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

Оставьте их, а затем после сборки добавьте 'ignore' в каждый из сгенерированных файлов.

Answer 3

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

Answer 4

Посмотрите на это так: проверяете ли вы свои объектные файлы в системе контроля версий? Сгенерированные исходные файлы являются артефактами сборки, такими же, как объектные файлы, библиотеки и исполняемые файлы. К ним следует относиться одинаково. Большинство будет утверждать, что вы не должны проверять сгенерированные объектные файлы и исполняемые файлы в системе контроля версий. Те же аргументы применимы к сгенерированному источнику.

Если вам нужно просмотреть историческую версию сгенерированного файла, вы можете выполнить синхронизацию с исторической версией его источников и перестроить.

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

Answer 5

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

Answer 6

Я называю принцип СУХОЙ. Если у вас уже есть «исходные файлы» в хранилище, которые используются для генерации этих файлов кода во время сборки, нет необходимости повторять один и тот же код «дважды».

Кроме того, вы можете предотвратить некоторые проблемы таким образом, если, например, когда-нибудь генерация кода прекратится.

Answer 7

Я действительно не думаю, что вы должны проверить их.

Конечно, любое изменение в сгенерированном коде будет либо шумом - изменениями между средами, либо изменениями в результате чего-то другого, например изменение в вашей БД. Если сценарии создания вашей БД (или любые другие зависимости) находятся в управлении исходным кодом, то зачем вам также нужны сгенерированные сценарии?

Answer 8

Нет, по трем причинам.

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

2. Я не хочу, чтобы кто-то испытывал искушение попытаться сократить сборку из первоисточников, используя промежуточный код, который может быть или не быть текущим (и что более важно, за что я не хочу принимать ответственность. И не слишком заманчиво для некоторых людей увлекаться бессмысленным процессом отладки конфликтов в промежуточном коде на основе частичных сборок.

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

Answer 9

Общее правило: нет , но если для генерации кода требуется время (из-за доступа к БД, веб-служб и т. Д.), Возможно, вы захотите сохранить кэшированную версию в системе контроля версий избавь всех от боли.

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

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

Answer 10

Мы также не храним сгенерированный код БД: поскольку он сгенерирован, вы можете получить его по желанию в любой заданной версии из исходных файлов. Хранить его будет все равно, что хранить байт-код или что-то подобное.

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