Git
Анализ типов рабочих процессов

замечания

Рабочий процесс Gitflow

Первоначально предложенный Vincent Driessen , Gitflow - это рабочий процесс разработки с использованием git и нескольких заранее определенных ветвей. Это можно рассматривать как частный случай рабочего процесса Feature Feature .

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

• master ветвь всегда является самым последним производственным кодом. Экспериментальный код здесь не принадлежит.
• develop отрасли содержит все последние разработки . Эти изменения в области развития могут быть практически любыми, но более крупные функции зарезервированы для их собственных филиалов. Код здесь всегда обрабатывается и объединяется в release до выпуска / развертывания.
• ветви hotfix для незначительных исправлений ошибок, которые не могут дождаться следующей версии. ветви hotfix отрываются от master и объединяются обратно в оба master и develop .
• release ветви используются для выпуска новой разработки от develop до master . Любые изменения в последнюю минуту, такие как набивные номера версий, выполняются в ветви релиза, а затем объединяются обратно в master и develop . При развертывании новой версии master должен быть помечен текущим номером версии (например, с использованием семантического управления версиями ) для дальнейшего использования и легкого откат.
• ветви feature зарезервированы для больших возможностей. Они специально разработаны в назначенных отраслях и интегрированы с develop когда закончены. Выделенные ветви feature помогают разделить разработку и возможность развернуть выполненные функции независимо друг от друга.

Визуальное представление этой модели:

Исходное представление этой модели:

Рабочий процесс вилки

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

Визуальное представление этого рабочего процесса выглядит следующим образом:

Централизованный рабочий процесс

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

Визуальное представление этой модели:

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

Вот почему Линус Торвальдс создал Git не как CVCS, а скорее как DVCS или систему управления распределенной версией , похожую на Mercurial. Преимущество этого нового способа работы - гибкость, продемонстрированная в других примерах на этой странице.

Функциональный блок

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

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

основанный на учебниках по Atlassian .

GitHub Flow

Популярно во многих проектах с открытым исходным кодом, но не только.

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

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

Полный поток Скотта Чакона:

• Все, что находится в главной ветке, развертывается
• Чтобы работать над чем-то новым, создайте описательно названную ветку мастера (то есть: new-oauth2-scopes)
• Фиксируйте эту ветвь локально и регулярно подталкивайте свою работу к той же именованной ветке на сервере
• Когда вам нужна обратная связь или помощь или вы считаете, что ветка готова к слиянию, откройте запрос на перенос
• После того, как кто-то еще просмотрел и подписал эту функцию, вы можете объединить ее в мастер
• После того, как он будет объединен и нажат на «master», вы можете и должны немедленно развернуть

Первоначально представлен на личном веб-сайте Скотта Чакона .

Изображение предоставлено ссылкой GitHub Flow