Мы пытаемся принять успешную модель ветвления 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.
git flow supportне отмечен как экспериментальный.
Похоже на ментальную модель, в которой слишком много внимания уделяется веткам. Я согласен, вы можете просто пометить коммиты, которые вы выпускаете, вместо того, чтобы объединять их обратно в мастер.
Однако картина хороша. Слияние всего с мастером дает четкое представление о выпусках во временном порядке вместо того, чтобы теги версий разбросаны по всему графику.
Однако я думаю, что эта модель не работает для исправления ошибок в старых версиях. Это портит аккуратный порядок.
Чтобы ответить на ваш вопрос: я думаю, что это набор правил, которые в некоторых случаях создают простую ментальную модель. Не все правила имеют смысл с чисто технической точки зрения, но это не делает их плохими. Ментальные модели хороши для людей.
supportветки предназначены для исправления ошибок в старых выпусках, хотя по-прежнему помечены как «экспериментальные».
Я лично считаю, что упомянутый git-flow слишком сложен.
Если вы используете GitHub, попробуйте GitHub flow(как описано Скоттом Чаконом).
Это особенно полезно для совместной работы над несколькими функциями, проверки кода, и вы можете объединить его с вашим решением непрерывной интеграции с помощью Commit Status API.
ОБНОВЛЕНИЕ : появился новый официальный сайт GitHub Flow ™.
ОБНОВЛЕНИЕ 2 : есть новое официальное (и упрощенное) руководство GitHub для GitHub Flow ™: https://guides.github.com/introduction/flow/
masterаномалией хронологии произведения.
support, для чего нужны ветки. Но вы правы, это действительно аномалия, что такие выпуски не объединяются обратно master, и, как я понимаю, они должны содержать все производственные выпуски.
В моем случае у меня есть две версии одного и того же программного обеспечения, основы одинаковы, но каждая версия имеет несколько разных функций.
Итак, я создаю две, 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, но он не автоматический.
Итак, подведем итог - ключевые отличия, которые мы вводим в модель ветвления для * слияния и тегирования релизов: - тегирование релиза при создании его ветки - сохранение ветки релиза, чтобы обеспечить их поддержку в будущем
Основная ветвь ВСЕГДА должна представлять вашу производственную базу кода, поэтому вы всегда объединяете код обратно в мастер сразу после производственной версии.
Пометка используется для «запоминания» точного кода, который вошел в производственный выпуск, чтобы вы могли вернуться позже и проанализировать код, если что-то пошло не так.
При этом теоретически не имеет значения, помечаете ли вы свой код в ветке выпуска или в основной ветке после того, как вы снова слились с мастером. Я лично предпочитаю пометить код в ветке выпуска, так как это именно тот код, который вошел в сборку / выпуск (при условии, что при слиянии что-то может пойти не так).
Проблема с концепцией ветки разработки в том, что она однопоточная. Брендан в этой ветке упомянул стратегию, которую можно использовать с концепцией ветки разработки.