gitworkflows

Выпуск

По мере того, как определённая функция переходит от экспериментальной к стабильной, она также «выпускается» между соответствующими ветками программного обеспечения. git.git использует следующие integration branches:

Существует четвёртая официальная ветка, которая используется несколько иначе:

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

По сути, функция входит в нестабильную ветку (обычно next или seen), и «выпускается» в master для следующего релиза, как только она считается достаточно стабильной.

Слияние вверх

«Спуск» (выпуск в предыдущие ветки), обсуждаемый выше, не может быть выполнен путём фактического слияния вниз, поскольку это слило бы all изменения в нестабильной ветке в стабильную. Отсюда и следующее:

Это обеспечивает очень контролируемый поток исправлений. Если вы заметите, что применили исправление, например, к master, которое также требуется в maint, вам нужно будет выбрать отдельные коммиты (используя git-cherry-pick[1]) вниз. Это произойдёт несколько раз и не должно вызывать беспокойства, если вы не делаете это слишком часто.

Ветки тем

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

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

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

Тогда многие вещи можно сделать очень естественно:

Обратите внимание, что последний пункт противоречит двум другим: тему, которая была слита в другое место, не следует перебазировать. См. раздел ВОССТАНОВЛЕНИЕ ПОСЛЕ ПЕРЕБАЗИРОВАНИЯ ВЕРСИЙ В git-rebase[1].

Мы должны отметить, что «по привычке» (регулярно без реальной причины) сливать ветку интеграции в ваши темы — и, как следствие, сливать что-либо upstream в downstream регулярно — не приветствуется:

В противном случае тема, которая была слита, вдруг содержит больше одного (хорошо отделённого) изменения. Многочисленные полученные небольшие слияния сильно загромоздят историю. Любой, кто позже изучит историю файла, должен будет выяснить, повлияло ли это слияние на тему, находящуюся в разработке. Upstream даже может непреднамеренно слиться в «более стабильную» ветку. И так далее.

Жертвенная интеграция

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

Конечно, решение состоит в том, чтобы сделать слияние, которое мы можем отменить: слить в жертвовательную ветку.

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

Управление ветками для релиза

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

Релиз функции создаётся из ветки master, поскольку master отслеживает коммиты, которые должны войти в следующий релиз функции.

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

Чтобы убедиться, что master является супермножеством maint, используйте git log:

Эта команда не должна выводить какие-либо коммиты. В противном случае переключитесь на master и слийте maint в неё.

Теперь вы можете продолжить создание релиза функции. Примените тег к концу master, указывающий версию релиза:

Вам необходимо передать новый тег на публичный сервер Git (см. «РАСПРЕДЕЛЁННЫЕ РАБОЧИЕ ПРОЦЕССЫ» ниже). Это делает тег доступным для других, отслеживающих ваш проект. Передача может также запустить обработчик после обновления для выполнения задач, связанных с выпуском, таких как создание скомпилированных архивов релиза и страниц документации в предварительно отформатированном виде.

Аналогично, для релиза обслуживания maint отслеживает коммиты, подлежащие выпуску. Поэтому в шагах выше просто поставьте тег и передайте maint, а не master.

Управление ветками обслуживания после релиза функции

После релиза функции вам необходимо управлять ветками обслуживания.

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

Для этого текущая ветка обслуживания копируется в другую ветку с номером предыдущей версии релиза (например, maint-X.Y.(Z-1), где X.Y.Z — текущий релиз).

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

Если слияние не удаётся, потому что это не быстрое перенаправление, то возможно, некоторые исправления в maint были пропущены в релизе функции. Этого не произойдёт, если содержимое веток было проверено, как описано в предыдущем разделе.

Управление ветками для «следующей» и «просмотренной» после релиза функции

После выпуска функции интегрированная ветка next может быть необязательно перемотана и перестроена с вершины master с использованием оставшихся тем в next:

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

Если вы это сделаете, необходимо опубликовать объявление о том, что next была перемотана и перестроена.

То же самое перемотка и перестройка могут быть применены к seen. Общественное объявление не обязательно, так как seen является временной веткой, как описано выше.