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

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

В модели 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.

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

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

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

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

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

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

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

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

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

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

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

Итак, я создаю две, 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 не запутается.

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

Полностью согласен с @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, но он не автоматический.

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

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

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

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

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