Статьи

Реализация «потока Git»

Март 22, 2019

Git можно использовать по-разному, что здорово. Но, тем не менее, работая в команде, хорошо иметь консенсус в отношении общего, совместного подхода, чтобы избежать конфликтов. В этой статье быстро объясняется, как мы реализовали шаблон «git flow» в одном из наших проектов.

Git-поток …

… Это популярная стратегия, которая работает вокруг основной ветви, но менее «агрессивно» (чем, например, схема потока GitHub ). У вас есть две основные ветви:

  • Основная ветвь содержит самый последний производственный код, который был развернут, и имеет версии с соответствующими тегами для каждого выпуска.
  • ветвь разработки, которая разветвляется от мастера и содержит последний код для следующей разрабатываемой функции. Для каждой новой функции может быть много ветвей функций (всегда ветвь от ветви «разработки»).
    Помимо основных ветвей есть так называемые опорные ветви:

Помимо них есть вспомогательные ветви:

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

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

Такая ориентированная на производство стратегия ветвления имеет

  • основная ветвь, которая содержит фактический код разработки (соответствует ветви «разработка» в модели git-flow)
  • Производственная ветка содержит развернутый код.

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

  • ветви функций, которые содержат разработку специфических функций, разветвляются от мастера и объединяются в мастер
  • ветви исправлений (работает как в стандартной модели git-flow)
  • ветвь релиза (работает как в стандартной модели git-flow)
Изменения потока, ориентированные на производственную отрасль

Изменения потока, ориентированные на производственную отрасль

использование

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

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

1
2
$ git init
$ git remote add origin git@.....

Кроме того, я бы предложил также добавить файл .gitignore . Вы можете начать с существующего в зависимости от типа вашего проекта: Github .gitignore репозиторий .

«Подтолкнуть» все до вашего удаленного репо.

1
$ git push --set-upstream origin master

Создать новую функцию

От master

1
2
$ git pull
$ git checkout -b userstory/login

Сделайте некоторые коммиты, а затем опубликуйте функцию на удаленном репо (если не на крошечном за пару часов)

1
$ git push origin userstory/login

Обновить функцию от мастера

Часто обновляйтесь с origin / master, чтобы получать последние изменения, которые были отправлены в репо вашими коллегами.

1
2
$ git fetch origin master
$ git rebase origin/master

В качестве альтернативы проверьте вашу главную ветку и выполните

1
2
3
$ git pull master
$ git checkout <yourfeaturebranch>
$ git rebase master

Обратите внимание, что когда вы перебазируете с master, ваша ветка может быть нелегко обновить с помощью своего удаленного аналога (если вы синхронизировали его с центральным репо). В таком случае вы можете использовать флаг --force .

Внимание! Сообщите себе в документации Git о потенциально опасных побочных эффектах при использовании флага --force !

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

1
$ git push --force origin <yourfeaturebranch>

Завершить функцию

Слей его обратно в мастера

1
2
3
$ git checkout master
$ git pull
$ git merge --no-ff userstory/login

--no-ff означает отсутствие быстрой перемотки вперед для отслеживания того, откуда произошли определенные изменения.

Чтобы не забыть флаг --no-ff вы можете настроить его как поведение по умолчанию при слиянии с мастером, выполнив следующую команду: git config branch.master.mergeoptions "--no-ff"

В случае конфликтов разрешите их, а затем нажмите мастер

1
$ git push

и удалите историю пользователя (локально и удаленно)

1
2
$ git branch -d userstory/login
$ git push origin :userstory/login

Подготовить релиз

1
$ git checkout -b release/0.1.0

Публикация продукции

1
2
3
4
5
$ git checkout production
$ git pull
$ git merge --no-ff release/0.1.0
$ git tag v0.1.0
$ git push --tags origin production

Удалите ветку release/xxx .

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

1
2
$ git checkout production
$ git checkout -b hotfix/login-does-not-work

После тестирования вернитесь в производство

1
2
3
4
$ git checkout production
$ git merge --no-ff hotfix/login-does-not-work
$ git tag v0.1.1
$ git push --tags

Очевидно, также объединить эти изменения с мастером

1
2
$ git checkout master
$ git merge --no-ff hotfix/login-does-not-work

А затем удалите ветку исправлений

1
$ git branch -d hotfix/login-does-not-work

Хорошо, я джедай, дай мне несколько инструментов

Инструмент Git Flow CLI

Git Flow — это расширение командной строки git, облегчающее использование шаблона «git flow».

Итак, если вы освоили использование шаблона git flow вручную, вы готовы пойти на это.

Git Псевдонимы Haacked

Фил Хаак (бывший сотрудник Microsoft, а ныне работающий над GitHub для Windows @ GitHub) опубликовал интересный набор из 13 псевдонимов git для повышения вашей производительности. Возможно, вы захотите взглянуть на них:

http://haacked.com/archive/2014/07/28/github-flow-aliases/

Чтобы установить их, просто скопируйте и вставьте псевдонимы в ваш файл .gitconfig . Вы должны найти его в каталоге своего профиля пользователя ( ~ в системах Unix; C:\users\<yourname>\ в Windows).

Конфигурирование Jenkins

Пожалуйста, обратитесь к моему недавнему сообщению в блоге «Поток Git с Jenkins и GitLab» для получения дополнительной информации о том, как настроить вашу среду сборки.

Как мы это используем — наш трубопровод

Мы приняли шаблон потока git в одном из наших проектов, когда команда впервые связалась с git (раньше они использовали TFS). Я познакомил их с основами Git, а затем они начали прямо перед собой, и на удивление переключение было действительно легким. Используя поток git, мы минимизировали конфликтующие слияния и, следовательно, потенциальные проблемы в процессе разработки.

Так как мы это использовали? Команда применила какой-то Scrum (мы новичок в этом, то есть «своего рода»). У нас есть две недели итераций с начальной фазой планирования (обычно утром в четверг), и у нас есть тестер в команде (ууу!).

  1. В начале цикла спринта наши разработчики берут свои пользовательские истории (в Trello) и создают соответствующие ветви функций, имеющие шаблон userstory/<trello-card-#>-userstory-title для userstories, task/<trello-card-#>-title для задач и bug/<trello-card-#>-title для ошибок.
  2. Разрабатывайте ветки функций и часто обновляйте их с помощью master (см. Использование потока git выше). Если реализация story / task / bug занимает больше времени, чем сутки или два, ветка отправляется на удаленный сервер GitLab (по причинам резервного копирования). Каждый из этих шагов автоматически собирается и тестируется нашими Jenkins .
  3. Закончив реализацию, разработчик либо объединяет ее с master либо создает в GitLab запрос на слияние, назначенный другому разработчику для проверки кода. Когда master отправляется в GitLab, Дженкинс автоматически берет его и публикует на нашем экземпляре сервера разработки .
  4. Каждую ночь ветвь master автоматически публикуется на нашем экземпляре тестового сервера, и тестировщик в нашей команде может продолжать тестировать внедренные истории и либо пометить их как выполненные, либо отклонить их в нашем весеннем цикле. Кроме того, выполняется серия автоматических тестов jMeter, которые проверяют правильность работы нашего REST API, а также производительность наших конечных точек.
  5. После двухнедельного цикла один из наших разработчиков готовит релиз (см. Вид команд для выполнения в разделе «Использование потока git» выше), объединяя master production . Это автоматически обнаруживается Jenkins, который — снова — публикует на нашем экземпляре сервера подготовки производства, который также доступен для нашего клиента.

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

Это поток, который мы создали после нескольких итераций и обсуждений в команде и с нашим тестером. Какой у тебя подход ?? Мне было бы интересно услышать в комментариях.

Эта статья была повторно опубликована на следующих партнерских сайтах:

Ссылка: Внедрение «потока Git» от нашего партнера по JCG Юри Струмпфлохнера в блоге Юри Струмпфлохнера на TechBlog .
54
Share: