Кредиты

Этот пост является португальской версией оригинала, На английском языке, “Успешная модель ветвления Git“, должным образом уполномоченный автором, Винсент Дриссен. Спасибо человеку!

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

Введение

Это не пост, обучающий использованию Git. Если это то, что вам нужно, предложите взглянуть на Инструкция do Git. Мы также не ставим перед собой цель показать, как сделать управление версиями программного обеспечения., в этом случае, смотреть Семантическое управление версиями.

Здесь предложение состоит в том, чтобы управлять сотрудничеством команды в управлении версиями программного обеспечения. Вы знаете, когда у вас есть несколько программистов “Волнующий” в том же исходном коде? Это важно для ускорения разработки, но это может вызвать много головной боли (травмы и переделки) если нет контроля. Чтобы один разработчик не перезаписывал работу другого и не обеспечивал прогрессивное и организованное развитие, минимизация конфликтов и управление версиями программного обеспечения, это то, что мы используем Git и Ветви затем.

Модель филиалов

В этом посте я представляю модель разработки, которую я использовал в некоторых своих проектах (как на работе, так и в частном порядке) О 1 лет назад, и это было очень успешно. Я давно хотел написать об этом, но так и не нашел свободного времени, до сих пор. Я не буду говорить о деталях проекта, только о стратегиях Ветви и управление Релизы.

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

Почему git?

Для подробного обсуждения плюсов и минусов git по сравнению с централизованными системами управления версиями, смотреть в паутина. Есть потрясающий “война” вокруг того, что. Как разработчик, Я предпочитаю Git всем другим существующим инструментам сегодня. Git, несомненно, изменил то, как разработчики думают о создании Слияние или создайте филиал. Я родом из классического мира CVS/Подрывная деятельность, где слияние/ветвление это то, что вы делаете только время от времени и всегда кажетесь немного страшным (“Остерегайтесь конфликтов Слияние, они кусают тебя!”).

С Git эти действия [слияние/ветвление] чрезвычайно просты и представляют собой одну из основных частей нашей рабочей рутины, Верить. Например, в книга CSV/Подрывная деятельность, ответвление и Объединение впервые рассматриваются только в последующих главах (для опытных пользователей), в то время как в любом книга на Git, Это видно из главы 3 (основной).

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

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

Децентрализованный, но централизованный

Конфигурация репозитория, который мы используем и который очень хорошо работает с этой моделью ответвление состоит из центрального репозитория. Обратите внимание, что этот репозиторий является только “рассматривается как” центральный (потому что Git является DVCS [Распределенные системы управления версиями], IE, На техническом уровне нет ничего лучше центрального репозитория). Мы будем ссылаться на этот репозиторий как на происхождение, так как это имя знакомо всем пользователям Git.

Каждый разработчик делает Тянет и Толкает для происхождение. Но за пределами отношений двухтактный для централизованного [происхождение], каждый разработчик также может забрать [Тянуть] Изменение других пар для формирования подгрупп. Например, Это может быть полезно для совместной работы с двумя или более разработчиками над новой большой функциональностью, предыдущая отправка [напористый] работа, выполняемая для происхождение. На рисунке выше, есть подкоманды Алисы и Боба, Алиса и Дэвид, и Клэр и Дэвид.

Технически, Это означает не что иное, как то, что Алиса определила удаленный Git с именем Bob, указывая на репозиторий Боба, и наоборот.

Основные отрасли

В фоновом режиме, Эта модель разработки вдохновлена существующими моделями. Центральный репозиторий имеет две ветви [Ветви] с бесконечной жизнью:

• Мастер
• Разработка

В мастер филиала в происхождение должен быть знаком каждому пользователю Git. Параллельно мастер филиала, есть еще один филиал звать Разработка.

Рассматривать происхождение/мастер как основная ветвь, где исходный код ГОЛОВА всегда отражает состояние готовность к производству [готов к производству].

Рассматривать происхождение/развитие как существо филиал где исходный код ГОЛОВА Всегда отражает состояние с последними изменениями разработки, которые будут представлены в следующем выпуске. Некоторые назвали бы это “филиал интеграция”. Вот где происходят самые зловещие здания.

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

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

Вспомогательные филиалы

Рядом с Ветви Главный, Мастер и Разработка, наша модель разработки использует различные Ветви поддержка для содействия одновременному развитию среди членов команды, что 1) позволяет легко отслеживать новые функции [Функции], 2) готовит к поставке новую версию [релиз] и 3) помогает быстро устранять производственные сбои [исправление]. В отличие от Ветви Главный, эти Ветви имеет короткий срок службы, так как в конечном итоге они будут удалены.

Различные типы Ветви [Вспомогательный] которые мы можем использовать, Являются ли:

• Ветви функций
• Выпускные ветви
• Ветви исправлений

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

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

Ветви функций

– Он может ветвиться [филиал] От:
Разработка
– Необходимо объединить [Слияние] снова:
Разработка
– Конвенция о назначении филиал:
Что-нибудь, кроме Мастер, Разработка, релиз-*, ИЛИ исправление-*

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

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

Ветви функций Как правило, существуют только в репозитории Разработка, не в происхождение.

Создание ветвей объектов

$ git оформить заказ -b развивать myfeature
# Switched to a new branch "myfeature"

Включение готовой функции в разработку

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

$ Разработка git checkout
# Перешел на филиал «разработка»
$ Слияние git --в-ff myfeature
# Обновление ea1b82a.. 05е9557
# (Сводка изменений)
# $ git ветвь -d myfeature
# Удалена ветвь myfeature (был 05e9557).
$ GIT push происхождение разработка

Флаг –но-фф Вызывает слияние [Слияние] всегда создавайте новый объект Совершать, даже если слияние может быть выполнено с помощью перемотка вперед [Ff]. Это предотвращает потерю информации об истории существования ветвь функций, группировка всех Совершает которые были добавлены в особенность. Сравнивать:

В последнем случае [из рисунка выше], из истории GIT невозможно увидеть, какой из Совершает были реализованы в рамках особенность; Необходимо вручную прочитать все сообщения журнала. Обратный ход особенность Целый (IE, группа Совершает), это настоящая головная боль в последней ситуации, в то время как это легко сделать, если флаг –но-фф был использован.

Да, Это создаст еще несколько объектов Совершает (Пустой), но выигрыш намного выше стоимости.

Выпускные ветви

– Он может ветвиться [филиал] От:
Разработка
– Необходимо объединить [Слияние] снова:
Разработка и Мастер
– Конвенция о назначении филиал:
релиз-*

Тем выпускает ветви помощь в подготовке новой производственной версии [выпуск продукции]. Они позволяют ставить капельницы в последнюю минуту i's. В дополнение, они допускают незначительные исправления Ошибок и определение метаданные для релиз (номер версии, даты сборки, etc). Выполняя всю эту работу в ветвь релиза, в развивать отрасль становится чистым, чтобы получить Функции следующего большого релиз [Версия].

Ключевой момент для создания нового ветвь релиза ответвление от Разработка это когда Разработка уже (почти) отражение желаемого состояния нового релиз [Версия]. Все Функции заявители на релиз чтобы быть построенным, должен быть включен [Слияние] в Разработка на этом этапе. Кроме того, Функции направленные на Релизы фьючерсы должны ожидать следующего релиз [Версия].

Это точно в начале ветвь релиза что следующий релиз получает номер версии – не ранее. До этого момента, в развивать отрасль отраженные изменения в “следующий релиз” [следующая версия], но неясно, является ли это “следующая версия” в конечном итоге будет 0.3 или 1.0, до ветвь релиза запущен. Это решение принимается в начале ветвь релиза и осуществляется по правилам проекта по версионированию [Я предлагаю посмотреть о “Семантическое управление версиями“].

Создание ветви релиза

Тем выпускает ветви создаются из развивать отрасль. Например, скажем, версия 1.1.5 является текущей производственной версией и у нас есть отличная релиз Грядущий. Состояние Разработка готов к “следующая версия” [следующий релиз] и мы решили, что это станет версией 1.2 (Вместо 1.1.6 или 2.0). Так, мы разветвляемся и даем ветвь релиза Имя, отражающее новый номер версии:

$ git оформить заказ -b выпуск-1.2 Разработка
# Switched to a new branch "release-1.2"
$ ./Шишка-Версия.Ш 1.2
# Файлы успешно изменены, версия увеличена до 1.2.
$ GIT-фиксация -в -m "Bumped version number to 1.2"
# [версия-1.2 74d9424] Увеличен номер версии до 1.2
# 1 Измененные файлы, 1 Вставки(+), 1 Удаления(-)

После создания нового филиал и получить к нему доступ, мы наткнулись на номер версии. Здесь, bump-version.sh — это сценарий оболочки, который изменяет некоторые рабочие файлы копирования в соответствии с новой версией. (Это может, Конечно, быть ручным изменением – Дело в том, что некоторые файлы меняются.) Так, сделано Совершать измененного номера версии.

Это новое филиал может существовать там какое-то время, до релиз быть запущенным на постоянной основе. В этот период, исправления ошибок могут быть применены в этом филиал (вместо развивать отрасль). Добавление новых и больших Функции здесь строго запрещено. Они должны быть объединены [слившийся] в Разработка и, Типа того, ждите следующего большого релиз.

Завершение работы над ветвью релиза

Когда ветвь релиза готов стать реальной версией, необходимо принять некоторые меры. Первый, в ветвь релиза объединяется в Мастер (начиная с каждого Совершать в Мастер является новой версией по определению, помнить). Затем, этот Совершать в Мастер должны быть помечены, чтобы облегчить будущую ссылку на эту историю версий. В конечном счете, изменения, внесенные в ветвь релиза необходимо объединить [слившийся] снова в Разработка, чтобы Релизы фьючерсы также содержат эти исправления ошибок.

Первые два шага в Git:

$ мастер оформления заказа git
# Переключился на ветку 'master'
$ Слияние git --в-Релиз ff-1.2
# Слияние, выполненное с помощью рекурсивного.
# (Сводка изменений)
$ тег git -в 1.2

В релиз в настоящее время завершено и помечено для дальнейшего использования.

Примечание: Можно также использовать флаги -s или -u чтобы подписать тег криптографически.

Сохранение изменений, внесенных в ветвь релиза, нам нужно собрать их вместе Разработка. В Git:

$ Разработка git checkout
# Перешел на филиал «разработка»
$ Слияние git --в-Релиз ff-1.2
# Слияние, выполненное с помощью рекурсивного.
# (Сводка изменений)

Этот шаг может привести к конфликту слияния (вероятно идти, Как только мы изменим номер версии). Если да, то, исправить и сделать Совершать.

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

$ филиал git -d релиз-1.2
# Удаленная ветвь релиз-1.2 (был ff452fe).

Ветви исправлений

– Он может ветвиться [филиал] От:
Мастер
– Необходимо объединить [Слияние] снова:
Разработка и Мастер
– Конвенция о назначении филиал:
исправление-*

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

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

Создание ветви исправлений

Тем Ветви исправлений создаются из мастер-филиал. Например, Предполагая, что версия 1.2 Запущена ли текущая версия рабочего выпуска и возникают проблемы из-за серьезной ошибки. Изменения в Разработка оставьте все еще нестабильным. Затем мы можем разветвить Ветвь исправлений и начните решать проблему:

$ git оформить заказ -Исправление b-1.2.1 Мастер
# Switched to a new branch "hotfix-1.2.1"
$ ./Шишка-Версия.Ш 1.2.1
# Файлы успешно изменены, версия увеличена до 1.2.1.
$ GIT-фиксация -в -m "Bumped version number to 1.2.1"
# [исправление-1.2.1 41e61bb] Увеличен номер версии до 1.2.1
# 1 Измененные файлы, 1 Вставки(+), 1 Удаления(-)

Не забудьте изменить номер версии после ветвления!

Затем, исправьте ошибку и сделайте Совершать исправления в одном или нескольких Совершать Отделять.

$ GIT-фиксация -m "Fixed severe production problem"
# [исправление-1.2.1 abbe5d6] Исправлена серьезная производственная проблема
# 5 Измененные файлы, 32 Вставки(+), 17 Удаления(-)

Завершение работы над ветвью исправлений

После завершения, в исправление ошибок должен быть объединен обратно в Мастер, но он также должен быть включен обратно в Разработка, для обеспечения того, чтобы исправление ошибок также включен в следующую версию. Это очень похоже на то, как это происходит. выпускных ветвей доработаны.

Первый, Обновите Мастер и пометить тегом релиз [отметить лето]:

$ мастер оформления заказа git
# Переключился на ветку 'master'
$ Слияние git --в-исправление ff-1.2.1
# Слияние, выполненное с помощью рекурсивного.
# (Сводка изменений)
$ тег git -в 1.2.1

Примечание: Можно также использовать флаги -s или -u чтобы подписать тег криптографически.

Затем, включите исправление ошибок в Разработка также:

$ Разработка git checkout
# Перешел на филиал «разработка»
$ Слияние git --в-исправление ff-1.2.1
# Слияние, выполненное с помощью рекурсивного.
# (Сводка изменений)

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

В конечном счете, Удалите значок филиал Временный:

$ филиал git -Исправление d-1.2.1
# Удаленная ветвь исправлений-1.2.1 (был abbe5d6).

Резюме

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

Качественная PDF-версия рисунка представлена в блоге оригинального поста: http://nvie.com/posts/a-successful-git-branching-model/ [или по ссылке для скачивания ниже]. Продолжайте и размещайте его на стене, чтобы получить быструю ссылку в любое время.

Git-ветвление-модель-20170825.pdf

1 архив(s) 3.89 MB

Скачать