Git-flow и master с несколькими параллельными ветками выпуска


86

Мы пытаемся принять успешную модель ветвления Git, реализованную с помощью git-flow. Сейчас мы работаем как минимум над двумя ветвями выпуска, одна для последней стабильной версии, а вторая - для следующей («превью») версии. Я не понимаю, почему все выпуски кажутся «линеаризованными» по отношению к мастеру и помечены там. Почему бы не пометить выпуски в их ветках выпуска? Зачем вообще мастер ? Или почему развивать отрасль , а не использовать мастер для этого?

Ответы:


77

В модели git-flow ваша «последняя выпущенная» версия фактически сопоставляется с версией master, а ваша «предварительная версия» сопоставляется с releaseветкой git-flow . Он разветвляется developи, наконец, объединяется, masterкогда происходит фактический выпуск. Тогда это станет вашим «последним выпуском», и вы обычно будете исправлять ошибки только для этого выпуска, используя hotfixветки git-flow . Таким образом, вы masterвсегда представляете наиболее стабильное состояние вашей последней выпущенной версии.

Если вы хотите исправить ошибки в более старых выпусках или заняться какой-либо другой разработкой в ​​них, вы создадите supportветку из соответствующего коммита master(у вас будут все версии, когда-либо созданные там). supportветки все еще являются экспериментальными ( согласно документации ) и плохо документированы. Но как видно из справки командной строки:

usage: git flow support [list] [-v]
       git flow support start [-F] <version> <base>

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


17
Это не касается медленного конвейера от тестирования до контроля качества и производства. Может быть две (или даже больше, но пока давайте просто скажем две) открытых ветки выпуска, каждая из которых находится на разных этапах этого конвейера, и каждая необходима для исправления ошибок, обнаруженных в тесте. В этом случае ветвь разработки будет местом, где накапливаются функции для выпуска, ветвь которого еще не создана. В такой ситуации исправление для выпуска n-2 в конечном итоге будет объединено для разработки, но пропустит выпуск n-1, по крайней мере, в соответствии со стандартным потоком git. Это приведет к регрессу на n-1, что в конечном итоге будет исправлено в выпуске n
Брендан

Почему бы не сохранить ветки выпуска, а после создания новой ветки выпуска старые превратятся в ветвь «поддержки»?
lkanab

1
Почему ветви выпуска «разветвляются» от разработки, а не просто «ответвляются» от разработки?
Sandra K

gitflow-avh выглядит как поддерживаемая (т. е. не мертвая) вилка исходного gitflow. git flow supportне отмечен как экспериментальный.
Тимо Верховен

9

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

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

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

  1. Допустим, мы выпустили версию 1.0.1 и более поздние, добавили функции и выпустили 1.1.0.
  2. Мы обнаружили ошибку в 1.0.1 и хотим исправить ее в обеих версиях.
  3. Мы должны добавить 1.0.2 после 1.1.0 в master, а затем напрямую (или раньше) также 1.1.1.

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


1
supportветки предназначены для исправления ошибок в старых выпусках, хотя по-прежнему помечены как «экспериментальные».
mstrap

2

Я лично считаю, что упомянутый git-flow слишком сложен.

Если вы используете GitHub, попробуйте GitHub flow(как описано Скоттом Чаконом).

Это особенно полезно для совместной работы над несколькими функциями, проверки кода, и вы можете объединить его с вашим решением непрерывной интеграции с помощью Commit Status API.

ОБНОВЛЕНИЕ : появился новый официальный сайт GitHub Flow ™.

ОБНОВЛЕНИЕ 2 : есть новое официальное (и упрощенное) руководство GitHub для GitHub Flow ™: https://guides.github.com/introduction/flow/


10
Поток GitHub подходит только для контекста, не ориентированного на выпуск: процесс git-flow разработан в основном вокруг «выпуска». На самом деле у нас нет «релизов», потому что мы развертываем в производственной среде каждый день - часто несколько раз в день.
Remi Mélisson

10
Я бы также добавил, что git-flow действительно не так хорошо работает в контексте, ориентированном на выпуск, который имеет выпуски обслуживания. Например, что происходит, когда выпуск 1.2.1 происходит после выпуска 1.3.0? По-видимому, это не может быть объединено с masterаномалией хронологии произведения.
Кен Уильямс,

@KenWilliams, как описано в ответе mstrap , это то support, для чего нужны ветки. Но вы правы, это действительно аномалия, что такие выпуски не объединяются обратно master, и, как я понимаю, они должны содержать все производственные выпуски.
beatngu13

2

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

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

$git worktree add -b version-silver ..\version-silver master
$git worktree add -b version-gold ..\version-gold master

Тогда у меня есть:

$git branch
master  # base stuff here
version-silver # some normal features
version-gold # some better features

Есть один репозиторий, но у меня есть 3 отдельные папки рядом друг с другом для каждой ветки выше. И внести общие изменения в master. затем объедините его с обеими другими версиями.

cd master
vim basic.cpp
git add .
git commit -m "my common edit on basic.cpp"
cd ..\version-silver
vim silver.cpp
git add .
git commit -m "my specific edit on silver.cpp"
git merge master # here i get the basic.cpp latest changes for silver project
cd ..\version-gold
git merge master # here i get the basic.cpp latest changes for gold project

Конкретные изменения каждой версии также будут помещены в соответствующую папку, и работа над каждым проектом изолирована, и IDE не запутается.

Надеюсь, это поможет.


2

Полностью согласен с @Mot.

Приятно слышать одни и те же вопросы.

Наша команда также искала более универсальную модель ветвления, чем успешную . Т.е., как упомянул @Mot выше, основная идея состоит в том, чтобы избежать введения дополнительных репозиториев для поддержки веток release- * в отдельном репозитории * .git, как это, например, делается kernel.org для стабильных выпусков. Но kernel.org делает это, я думаю, для минимизации загружаемых размеров.

Мне кажется, что лучше иметь master в качестве основного направления разработки .

Также есть некоторые конфликты в модели слияния релиза *, которую нужно освоить, а затем пометить ее идеей для

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

причина завершения (слияние и маркировка) не является атомарной транзакцией:

$ git checkout master
Switched to branch 'master'
$ git merge --no-ff release-1.2
Merge made by recursive.
(Summary of changes)
$ git tag -a 1.2

и если git hook запускает сборку с поддержкой автоматического управления версиями:

$git describe --tags --long >.ver

тогда ошибочная версия может быть построена для:

$ git merge --no-ff release-1.2

Я знаю, что управление версиями в Successfull one вводит некоторый процесс bump-version, но он не автоматический.

Итак, подведем итог - ключевые отличия, которые мы вводим в модель ветвления для * слияния и тегирования релизов: - тегирование релиза при создании его ветки - сохранение ветки релиза, чтобы обеспечить их поддержку в будущем


-2

Основная ветвь ВСЕГДА должна представлять вашу производственную базу кода, поэтому вы всегда объединяете код обратно в мастер сразу после производственной версии.

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

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

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


4
Что такое «производственная кодовая база», если вы поддерживаете несколько выпусков, например v1.0, v1.1, v1.5 параллельно?
Thomas S.

База производственного кода - это то, что сейчас находится в производстве, например, v1.0. Ветви содержат изменения для выпусков, которые будут развернуты в производственной среде в будущем, например, V1.0.1, v1.1 и v2.0. После того, как «будущий» выпуск развертывается в производственной среде, он снова объединяется с основной версией, так что основная версия отражает то, что находится в производстве. Он также объединен (например, с v1.0.1 на 1.1 и v2.0), поэтому изменения v1.0.1 не теряются при выпуске v1.1 в производство.
Берни Ленц

4
Я говорю о поддержке нескольких выпущенных версий, а не о будущих версиях.
Thomas S.

4
Похоже, вы меня не понимаете. Разве вы не представляете, что в некоторых компаниях поддерживается несколько версий релизов? Microsoft, например, также поддерживает обновления для Windows 7, 8, 8.1 и 10, так почему бы не другим компаниям?
Thomas S.

1
Это правильно, Томас. Эта модель ориентирована на продукты, для которых в данный момент времени выпускается единственный производственный выпуск, например, на веб-сайты. Я также использовал эту модель для мобильных сборок, например для Android и iPhone, где сборка параметризована для создания сборки Android или iPhone (или обеих) с использованием одного и того же номера версии. Мне любопытно узнать ваше мнение о том, как структурировать модель сборки для продукта, который имеет несколько действующих версий в любой заданный момент времени, возможно, с некоторыми общими компонентами и разными компонентами. Пожалуйста, дайте нам знать ...
Берни Ленц
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.