Куда идут исправления в модели git-flow?

В обычно называемых исправлениях модели Git-flow идут в своей конкретной hotfix-*ветке, а небольшие исправления интеграции прямо перед выпуском выпускаются в release-*ветке. Общие исправления из предыдущей версии, похоже, не имеют места.

Где они должны появиться? Должны ли они быть в своей собственной bug-*ветви разветвлений прочь develop(так же , как featureветвь)?

git gitflow

— башмак
источник

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

— Барт ван Инген Шенау

@BartvanIngenSchenau Вы рекомендуете их быть feature-*филиалами? Может ли исправление ошибочного поведения рассматриваться как особенность?

— Чистка

@ Думаю, Барт означает, что вы должны относиться к ним как к функциям, не обязательно используя тот же префикс ветви .

— Darkhogg

@Shoe: в GIT-потоке, любой отрасли , за исключением master, develop, release-*или hotfix-*это особенность ветви, так что вы можете использовать любой префикс , как и использовать другой префикс для ошибок. Кроме того, в чем разница между ошибочным поведением, которое работает как указано, и ошибочным поведением, которое отличается от спецификации? В обоих случаях это ошибочное поведение, но только последний является ошибкой.

— Барт ван Инген Шенау

Краткий ответ: Да, ветки для исправлений ошибок, которые входят в запланированный выпуск, должны быть в функциональных ветках. То, как вы называете ветви функций или эти ветви для исправления ошибок, зависит от вас и стандартов вашей команды, но к ним следует относиться одинаково, если вы следуете Gitflow.

Комментарий Барта ван Ингена Шенау поднимает хороший вопрос.

Gitflow имеет пять филиалов: master, develop, исправление ветвь (с префиксом hotfix-), ветвь высвобождения (с префиксом release-, и особенность ветви. masterИ developветвь затянувшиеся ветвей , и вы не совершали непосредственно в них В. release-Ветвях сделаны , чтобы нарисовать линию для определенного выпуска, а затем поддерживают исправления ошибок между идентификацией следующей версии и выпуском. hotfix-Ветви предназначены специально для критических выпусков вне цикла производства. feature-Ветки предназначены для разработки отдельных функций для некоторых будущих выпусков.

Исходя из условий , где реципиентов используются и в стороне от отдельного разработчика , совершающего в эту ветку, ничто не должно быть совершено непосредственно в master, developили ветви выпуска. Это гарантирует, что каждое изменение проверяется кодом, а также обеспечивает надлежащее покрытие тестами и прохождение тестов в среде CI до того, как изменения вступят в силу. Я был бы против любых коммитов непосредственно в одну из этих ветвей, хотя кажется, что Gitflow сам по себе не ' У вас не возникнет проблем с фиксацией исправлений или изменений до релиза непосредственно в ветке релиза, а затем в ветке разработки, а затем в ветвях функций.

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

Если ваше исправление не критично, ветка исправлений тоже не подходит. Цель ветви исправлений - позволить кому-то очень быстро вносить критические изменения в производственную среду, не вмешиваясь в текущую разработку. Их использование должно быть скорее исключением, чем нормой для команды разработчиков. Как правило, критические исправления должны быть исключительным случаем.

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

— Томас Оуэнс
источник

Мы согласны с тем, что не должно быть прямых обязательств по освоению, разработке или выпуску веток. Но каким должен быть PR-поток, когда вы обнаружите ошибку в ветке релиза, и она должна быть исправлена как в ветке релиза, так и в разработке. Это имеет свои проблемы, если вся ваша ветка релиза еще не готова для объединения в разработке, но исправление ошибки должно быть сделано в обоих местах. Если вы хотите, я могу опубликовать новый вопрос для этого.

— Sap

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

— Томас Оуэнс

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

Также есть комментарий от автора git-flow, в котором говорится, что именно вы спрашиваете: пропущены ветки исправлений # 24

— дебютантка
источник

Спасибо, эта ссылка, которой вы поделились, прояснила это для меня.

— arcseldon