Правила SVN Commit

Question

Следует ли выполнять коммиты, только если решение компилируется и строится успешно?допустимы "промежуточные" коммиты в очень больших изменениях, из-за которых код не работает, скажем, несколько часов?

Answer 1

Да, это приемлемо.

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

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

Answer 2

В дополнение к комментариям Брайана и Аарона я бы только добавил, что даже этот компромисс между стабильностью и обновленным кодом может быть смягчен с помощью веток или, в качестве более экстремального решения, децентрализованной системы, такой как Git. «Регулярно выполняйте фиксацию и пусть сборочный бот находит ошибки» - моя любимая политика, но если вам нужно более стабильное место для извлечения кода, вам нужна ветка (но, конечно, кто-то должен ее поддерживать).

Answer 3

Обеспечение того, чтобы код не оставался сломанным слишком долго, является задачей непрерывной интеграции , а не контроля версий.

Answer 4

На мой взгляд, это зависит от типа используемой VCS:

• если вы используете централизованный такой как SVN, я бы сказал да, это приемлемо после Ааронов аргументов.
• если вы используете DVCS , такой как Git, я бы сказал нет, это не приемлемо , потому что каждый разработчик может выполнить свои локальные коммиты, протестировать реализацию и затем нажать вернуться к (голому) публичному репо, как только его работа будет завершена.

Поскольку вы отметили свой вопрос svn , следуйте Аарон .

Answer 5

По моему опыту, важно как минимум попробовать , чтобы не фиксировать критические изменения. Тем более, если команда больше или темпы развития быстрее. Идея состоит в том, чтобы все члены команды были в курсе последних изменений. Никто не должен бояться делать svn update после каждого коммита члена команды .

Это невозможно, если в последней версии регулярно появляются ошибки компиляции. Даже неудачный тест может раздражать, потому что не всегда легко определить, была ли проблема вызвана вашими незафиксированными изменениями или теми, которые вы только что получили от svn update. Работа останавливается, так как все пытаются понять, почему вдруг все перестает работать.

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

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

• к фиксации xyz : рефакторинг fuzz при подготовке аспект foo
• к исправлению xyz : аспект foo теперь работает
• исправлено xyz : аспектная панель теперь работает