Итак, вы хотите, чтобы ваша команда начала использовать Git? — Часть 4. Командные рабочие процессы

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

Workflows

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

В каждом инструменте Source Control, который я использовал на протяжении многих лет, был свой подход сообщества к решению этой проблемы; неофициальный «золотой стандарт» для ветвления и слияния. Наиболее распространенным ответом сообщества Git на это является подход / рабочий процесс под названием «GitFlow».

По сути, GitFlow является стратегией ветвления, которая основана на ряде очень успешных стратегий сообществ CVS (SVN / TFS) и объединяет их вместе.

Действительно хорошее раннее описание использования  GitFlow можно найти здесь.

устои

По своей сути GitFlow использует скорость, простоту и мощь функций ветвления и слияния Git, чтобы в полной мере воспользоваться этим для улучшения работы вашей команды.

Он работает на нескольких ключевых принципах и предположениях.

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

На высоком уровне GitFlow — это использование стратегии ветвления Git для удовлетворения потребностей в исправлениях, выпусках, разработке и ветвях групповых функций.

Это переводит непосредственно в следующее:

«Мастер» филиал

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

«Развивать» филиал

Ваша ветка «разработка» — это ваша текущая интегрированная ветка «работа в процессе». Если вы внедряете отсюда готовую или готовую интеграционную кодовую базу, вы, вероятно, делаете это  правильно  🙂

Особые ветки для  всего

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

Разветвление релиза используется для предварительных настроек / интеграции

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

Поддержка работы над исправлениями в качестве первоклассного гражданина

Кто-то сообщил об ошибке sev 1 / критический / end-of-world-drop-everything, и вам просто нужно быстро что-то настроить, чтобы ее устранить. Разветвление мастера для исправления перед быстрой реинтеграцией и двойное объединение с «мастером» и «разработкой» делает это легко.

Пометка, чтобы помнить все ваши хиты лучших команд

Пометка релизов семантическими соглашениями о версиях делает откат кусочком пирога.

Вниз к делу

Независимо от того, находитесь ли вы в командной строке или используете  SourceTree GUI,  реализовать GitFlow легко. SourceTree на самом деле делает это еще проще, поддерживая GitFlow с помощью простой в использовании обертки. Хотите новую функцию? Просто используйте кнопку только для этого!

Работа над кодом вне текущей версии

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

GitFlow подходит к этому с двумя стандартными ветвями.

В ветке « master » мы сохраняем стабильную исходную кодовую базу. Наши текущие релизы.

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

Чтобы установить это в командной строке или с помощью Git Bash:

$ git checkout master
$ git checkout -b develop

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

Чтобы получить некоторые настройки в Source Tree, а также уведомить Source Tree о том, что вы хотите использовать GitFlow:

Откройте Source Source с открытым текущим репозиторием.

Нажмите на значок «GitFlow»:

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

Нажмите OK, и Source Tree создаст вам новую «развивающуюся» ветку и проверите ее.

Если вы откроете папку .git и посмотрите внимательно, вы заметите, что SourceTree также отредактировал ваш файл «.git \ config», чтобы добавить вашу конфигурацию GitFlow (** запускает новые биты **).

[core]
    repositoryformatversion = 0
    filemode = false
    bare = false
    logallrefupdates = true
    symlinks = false
    ignorecase = true
    hideDotFiles = dotGitOnly
**
[gitflow "branch"]
    master = master
    develop = develop
[gitflow "prefix"]
    feature = feature/
    release = release/
    hotfix = hotfix/
    support = support/
    versiontag = 

После этого вы готовы приступить к использованию GitFlow с SourceTree.

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

В командной строке:

$ git push origin feature/user-story-123

В Source Tree вы просто нажимаете иконку «Push» и проверяете свою новую ветку разработки.

Разделите разные части работы, которые вы и ваша команда разрабатываете

Я упоминал выше, что Git был великолепен, потому что коммиты и ветки так дешевы. Это делает работу параллельно очень простой, поскольку каждый может работать со своей веткой.

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

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

$ git checkout develop
$ git checkout -b feature / user-story-123

Protip: if you’re big into using GitFlow on the commandline, there is actually a set of bash extensions that make this more implicit. Give them a go to save yourself the keystrokes.

Если вы используете Source Tree, вы делаете это, проверяя свою ветку «разработка» (щелкните правой кнопкой мыши по ней и выберите «оформить заказ»).

Затем нажмите значок GitFlow и выберите «начать новую функцию»

Затем дайте имя своей функции, нажмите OK, и вы создали новую ветку функций и проверили ее.

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

В командной строке:

$ git push origin feature/user-story-123

В Source Tree вы делаете это так же, как в ветке разработки, нажимаете значок «Push» и выбираете новую ветку функций.

Через много коммитов вы закончили свою работу.

Вы готовы закрыть свою функцию и объединить ее с «разработкой».

Нам нужно объединить вашу ветку функций в «разработке»

В командной строке:

$ git checkout develop
$ git merge feature/user-story-123
$ git branch –d feature/user-story-123

Это объединяет «разработку» с вашей функцией, затем проверяет «разработку» и объединяет вашу функцию с разработкой, а затем удаляет разработку.

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

В исходном дереве:

Нажмите на значок GitFlow.

 

Затем нажмите «Готово».

Затем вы можете выбрать ветвь объекта, которую хотите завершить, и нажать «ОК».

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

В случае, если вы столкнулись с конфликтом слияния, потому что ваша команда внесла изменения, чтобы «развиваться», пока вы работали, вы можете следовать  этому руководству,  чтобы помочь вам преодолеть конфликт слияния с Source Tree и Git (подсказка; это довольно просто).

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

Начиная новый релиз и разделяя его, чтобы работа могла продолжаться

Еще одно важное повышение производительности команды от GitFlow — это его способность «работать над выпуском», в то время как обычная работа по разработке продолжается в «разработке» и ваших ветках функций. Он делает это, беря ветку вашей текущей ветки «Разработка» под названием «Releases / 0.1» (в соответствии с соглашениями семантического контроля версий). Это позволит вашей команде продолжить работу, пока некоторые из вашей команды или ребята из DevOps завершат ваш релиз.

Чтобы выполнить это, что мы собираемся сделать:

1. Оформить заказ
2. Ветка «развивается» в «выпуск / 0.1»
3. Сделайте некоторые изменения в последнюю минуту.
4. Объедините «release / 0.1» в master и «разверните».
5. Удалите нашу ветку релизов.

Для этого в командной строке:

$ git checkout develop
$ git checkout -b release/v0.1

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

Когда вы закончите, пора объединиться с «master» и «development» и пометить ваш релиз в командной строке.

$ git checkout develop
$ git merge release/v0.1
$ git checkout master
$ git merge release/v0.1
$ git tag -a v0.1 -m 'Our release of version v0.1'
$ git branch –d release/v0.1

Для этого в Source Tree:

Оформите свою «развивающуюся» ветку, щелкнув правой кнопкой мыши на «развернуть» и выбрав «оформить заказ».

Теперь нажмите на иконку «GitFlow».

 

Теперь нажмите кнопку «Начать новый выпуск».

Дайте вашему выпуску имя. Я назвал мой «v0.1», так как это мой первый релиз.

Теперь вы попали в новую ветку релиза.

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

Когда вы закончите с изменениями релиза, вы заканчиваете его, снова нажимая значок GitFlow.

 

Нажмите кнопку «Готово».

Введите комментарий к сообщению о завершении релиза и нажмите ОК.

И с этим вы закончили свой первый релиз!

Исправление производственных проблем без остановки музыки

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

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

Что это значит на самом деле:

1. Ваша команда обнаружила ошибку в производстве.
2. Вы создаете ветку «master» с именем «hotfix / v0.1.1» или похожую.
3. Ваша команда завершает исправление, совершая эту ветку.
4. Вы объединяете эту ветку исправлений обратно в «master» и «development» и удаляете ветку релиза.
5. Вы помечаете этот объединенный коммит для последующего отката.

Делаем это в командной строке:

$ git checkout master
$ git checkout -b hotfix/v0.1.1

Теперь сделайте любые коммиты, необходимые для завершения исправления.

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

После завершения исправления пришло время объединить его с «master», «development» и удалить его.

$ git checkout master
$ git merge hotfix/v0.1.1
$ git checkout developer
$ git merge hotfix/v0.1.1
$ git tag -a v0.1.1 -m 'Fix a cross browser compatibility issue on homepage'
$ git branch -d hotfix/v0.1.1