Git - поток и мастер с несколькими параллельными ветвями разветвления

Ответ 1

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

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

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

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

Ответ 2

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

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

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

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

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

Ответ 3

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

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

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

ОБНОВЛЕНИЕ: существует новый официальный сайт The GitHub Flow ™

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

Ответ 4

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

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

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

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

Ответ 5

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

Итак, я создаю два 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 отдельные папки рядом друг с другом для каждой ветки выше. И сделайте общие изменения в мастер. затем объединить его с двумя другими версиями.

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 не будет путать.

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