В централизованном управлении версиями всегда хорошо обновлять часто?

При условии, что:

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

Так как это централизованное управление версиями, вам нужно будет обновить локальную проверку в какой-то момент: по крайней мере, один раз перед фиксацией новой функции.

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

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

Останетесь ли вы, это всегда хорошая идея, чтобы часто обновлять?

Лично я обновляю свои локальные версии ежедневно.

В сценарии, который вы описываете, я бы

• Создание ветки для новой, длинной функции.
• Слияние часто от основной линии до этой новой ветви.

Сюда,

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

Недостатки, как я их вижу,

• Слияние с основной должно быть сделано вручную (или по сценарию)
• Требуется больше "администрации"

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

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

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

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

Третий пункт в вопросе просто неверен :

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

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

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

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

Обычно в CVCS рекомендуется регулярно обновлять. Но если вы работаете над веткой, то вопрос «часто обновляйтесь или нет» становится «объединяться часто или нет». И ответ в любом случае да. Просто убедитесь, что перед выполнением слияния из другой ветки передайте все ожидающие изменения (в ветке), чтобы при необходимости можно было безопасно откатить слияние.

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

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

На самом деле мне удобнее использовать распределенный контроль версий локально. То есть я использую git как клиент Subversion. Это имеет следующие преимущества:

• Локальные изменения сохраняются перед обновлением, поэтому, если я ошибаюсь в слиянии, я всегда могу вернуться и сделать это снова.
• Делая большие изменения, я могу сохранить готовые детали. Это облегчает рассмотрение оставшихся изменений в процессе.
• Когда я исправляю ошибку во время какой-то более крупной работы, я могу зафиксировать только это исправление, временно зафиксировать остальное и «dcommit» исправление в subversion, сохраняя при этом другую выполняемую работу локально.

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

Я обеспокоен тем, что «новая функция» имеет широкое значение? Ориентация на объект может больше не быть модным словом, каким оно было когда-то, но в этой парадигме есть смысл.

Таким образом, вы могли бы создать фреймворк (внешний интерфейс, плюс функции-заглушки) и зафиксировать, что тогда должны быть минимальные сторонние эффекты, пока вы заканчиваете остальную часть своей разработки?

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

Чем он отличается для централизованного управления версиями от распределенного?

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

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

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

Это зависит от того, насколько вы хороши в «обновлении», когда кто-то еще нарушает сборку. С одной стороны, вы хотите обновить как можно меньше кусков. Лично я обновляюсь почти каждый раз, когда замечаю, что обновления доступны. С другой стороны, если сборка не работает, и кому-то еще понадобится день, чтобы ее починить, вы все равно захотите поработать над своей новой функцией.

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