назначение ветки git hotfix - PullRequest
Новая
       155

назначение ветки git hotfix

2 голосов
/ 03 августа 2020

gitflow

CMIIW, известный рабочий процесс git -flow, описанный выше, предлагает следующий шаг для выполнения исправления: стабильная ветка: рабочая ветка 'master': 'develop'

  1. ответвление «исправления» от «мастера»
  2. исправление и фиксация до «исправления»
  3. слияние «исправления» с «мастером»
  4. слияние «исправления» с Develop '
  5. del' hotfix '

Мой вопрос: зачем нам создавать ветку' hotfix '? Каким будет [вред / недостаток / отсутствие гибкости], если мы сделаем это

  1. checkout 'master'
  2. исправим и зафиксируем 'master' и вызовем фиксацию как «DEBUG : some fix "
  3. объединить 'master' в 'develop'

Я предполагаю, что ветка 'hotfix' пытается следовать той же парадигме, что и 'feature branch', где мы не обязуйтесь напрямую «развиваться» и «управлять». Но ветка 'hotfix' в моем случае обычно требует лишь небольших изменений кода (например, избавления от лишней запятой, вызывающей ошибку SQL), что лично я не считаю хуже усилий по созданию новой ветки *. 1030 *

Если оба способа подходят, как мне определить, когда что использовать? На основании количества исправлений?

Если предложенный мной способ не подходит, не могли бы вы указать, какие проблемы он потенциально может вызвать или какие гибкости он не предоставляет по сравнению со стандартным способом?

1 Ответ

1 голос
/ 03 августа 2020

master / ( или теперь main) должно отражать то, что выполняется в производственной среде в любое время.

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

1009 * Цель также, чтобы избежать слияний из master/main. Вы сливаетесь с ним, а не с ним, чтобы ограничить любой возможный конфликт слияния. Кроме того, слияние выполняется с помощью --no-ff (без перемотки вперед), как обсуждалось в petervanderdoes/gitflow-avh issue 257 : цель состоит в том, чтобы четко увидеть, из какой ветви hotfix создается коммит разработки, созданный слиянием. исходит от (а не просто от "master / main"). Опять же, не все исправления ошибок publi sh to master в любом случае полностью применимы к develop.
...