Git Workflow для небольших команд


11

Я работаю над рабочим процессом git для реализации в небольшой команде. Основные идеи в рабочем процессе:

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

В статье подробно описываются этапы этого цикла:

https://github.com/janosgyerik/git-workflows-book/blob/small-team-workflow/chapter05.md

Имеет ли это смысл или я что-то упустил?

Ответы:


16

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

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


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

7

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

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

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

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

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


Основная ветвь может быть подключена к CI, чтобы отклонить слияния ветвей функций, если они не пройдут автоматические нерегрессионные тесты. Спасибо за подсказку, в конце я добавлю раздел «Советы» и упомяну об этом.
Янв

1
Конечно, но, как уже было сказано, это не непрерывная интеграция, а интеграция в конце функциональности, которая может быть хорошей, но не такой же
Jens Schauder

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

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

1
Для наших проектов, которые используют CI (у нас есть пара устаревших проектов, которые не могут использовать его в настоящее время), мы обязуемся ВСЁ, чтобы справиться с истинным CI, для наших устаревших проектов мы используем модель ветвления git flow. Ветви компонентов являются блокировщиком CI, если вы спросите меня, они затрудняют НЕПРЕРЫВНУЮ (не только после завершения) интеграцию. Мы продолжаем работать над функциями, и последняя задача - включить его, но код всегда в проекте.
Эллиот Блэкберн

1

Вы можете вдохновиться Gitflow или Twgit .

Gitflow обобщает свой подход как:

Расширения Git для обеспечения высокоуровневых операций репозитория для модели ветвления Винсента Дриссена.

Twgit описывает себя следующим образом:

Twgit - это бесплатный инструмент с открытым исходным кодом, помогающий управлять функциями, исправлениями и выпусками в репозиториях Git. Он предоставляет простые высокоуровневые команды для принятия модели ветвления, описанной в нашей документации. Поддерживаемые ОС: Debian / Ubuntu Linux, Mac OS X.

Оба инструмента доступны на github .

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.