Выбор направления слияния

Question

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

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

Answer 1

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

Вы начинаете с development.

 --o--o--o    development

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

 --o--o--o--o         production
          \
           o--o--o    development

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

 --o--o--o--o             production
         |\
         | \------o--o    bugfix-1
          \
           o--o--o        development

Как только исправление готово, оно объединяется в production и development. Это возможно, потому что bugfix-1 разветвляется от общего предка обеих ветвей.

 --o--o--o--o----------o    production
         |\           /
         | \------o--o      bugfix-1
          \           \ 
           o--o--o-----o    development

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

«Исправление» ветвится с Удачная модель ветвления Git является разновидностью этого типа рабочего процесса. У сопровождающего Git есть запись в блоге о целях ветвей , которая также может помочь прояснить, как / почему следует создавать ветви и как их эффективно использовать, когда их контент может использоваться в нескольких дочерних ветвях (например, почему вы можете хотите избежать слияния ветки 'upstream' с веткой Feature).

---

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

Исправить ошибку «поверх» development.

 --o--o--o--o              production
          \
           o--o--o         development
                  \
                   b--b    bugfix-1

Объедините его с development (пример показывает, что в Git называется слиянием без ускоренной перемотки), и перебазируйте / cherry-pick коммит исправления ошибки (b) на production (b'), поскольку объединение development в production было бы плохой идеей - не весь его контент готов к производству:

 --o--o--o--o--b'--b'      production
          \
           o--o--o------o  development
                  \    /
                   b--b    bugfix-1

Зафиксированных взаимосвязей между фиксациями b и b' в ветке production нет. Это отсутствие взаимосвязи означает, что вам нужно спросить о коммитах b и b', если вы хотите быть в состоянии ответить на вопрос «Есть ли у какой-нибудь ветви, W, исправлена ​​ли ошибка?» Автоматически.

Answer 2

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

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

По этой причине я бы предпочел исправить в стволе, а затем объединить с веткой.

Answer 3

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

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

Answer 4

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

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

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

Многие новые пакеты scm реализуют слияния с GUID или другими уникальными идентификаторами, чтобы упростить отслеживание слияний.

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