Правила ветвления git

У нас есть большой корпоративный проект, и у нас есть несколько этапов разработки. Мы используем гит. Ветвление выглядит так:

РАЗРАБОТКА -> СИДЕТЬ -> ПРОД

Ветка DEV является веткой разработки как есть. Когда разработка завершена, она передается в ветку SIT, а исходный код SIT используется QA для этапа тестирования. Для выпуска используется PROD.

Итак, вопрос: если DEV завершен, а SIT-тестирование начато и обнаружена ошибка, каков правильный поток?

1:

  • создать ветку для исправления ошибок из ветки SIT и отправить ее прямо из ветки в SIT
  • повторное тестирование
  • в случае, если ошибка исправлена, необходимо создать ветку от DEV и отправить ее в DEV с исправлением этого исправления.

2:

  • Создайте ветку из DEV и отправьте исправление в DEV.

  • Отправка изменений из DEV в SIT

Какой поток правильный 1 или 2?

Я хочу знать лучшую практику


2
930
4

Ответы:

Обе стратегии можно использовать.

Опция 1

плюсы:

  1. Вы можете быстрее протестировать свое исправление, так как вы минуете ветку DEV.
  2. Вы можете увидеть, какая ветвь исправления ошибок (если их несколько) является лучшим подходом, и использовать ее для добавления в DEV, а затем в PROD.
  3. SIT отделен от DEV, поэтому вы можете продолжать работу над DEV, не беспокоясь о том, что SIT должен тестировать.

минусы:

  1. Между DEV и SIT может быть много взаимодействий, если исправление не сохраняется в долгосрочной перспективе, и вам нужно повторно применить исправление к DEV несколько раз.
  2. Если вы не будете осторожны, DEV может быть объединен с PROD или SIT с PROD, но тогда другая ветвь может пропустить эти изменения.
  3. Рабочий процесс нет представляет собой прямую линию: DEV -> SIT -> PROD, а это означает, что может возникнуть путаница, какие изменения куда идут.

Вариант 2

плюсы:

  1. Рабочий процесс прост и легок в использовании. Здесь нет путаницы.
  2. Вы можете легко отслеживать изменения на всех уровнях разработки, не задумываясь о том, что SIT должен тестировать, или DEV слишком далеко впереди, если PROD/SIT, или наоборот.
  3. Вы пишете весь свой код в DEV, вместо этого часть его в DEV, а часть в SIT. Таким образом, вы не будете иметь дело с большим количеством конфликтов.

минусы:

  1. Вы можете быть немного медленнее, предоставляя ветке SIT необходимые изменения/исправления для тестирования, так как они должны пройти через DEV.
  2. DEV может оказаться перегруженным ветвями, если им не управлять должным образом.
  3. Будет больше работы, если вы хотите протестировать разные функции для разных клиентов, если весь ваш код исходит от DEV, так как вам нужно больше обслуживания git, чтобы выбрать конкретную версию, которую вы будете тестировать.

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


На этот вопрос нет «ИСТИННОГО» ответа, но как разработчик вы не должны изобретать велосипед. Уже существуют общепринятые стратегии ветвления, не зависящие от проекта:

Я бы порекомендовал прочитать их и решить вместе с вашей командой. И только применять эти потоки. Есть также инструменты для форсирования каждой стратегии.


Решено

Создайте ветку исправлений от SIT, исправьте там проблему. Если тест пройден, объедините его с SIT, а затем перебазируйте DEV из SIT.

SIT -> create branch fix/issue

QA PASS -> merge fix/issue into SIT -> rebase dev from SIT

Потоки Git сильно зависят от вашей среды разработки и стека. Github, Bitbucket и GitLab имеют свои рекомендации и лучшие практики.

Рекомендую прочитать все: поток GitHub, Рекомендации Bitbucket, GitLab потоки.

Как по мне, оба ваших варианта исправления не оптимальны и усложняют процесс. Создание дополнительной бесполезной ветки для бутфикса, чем создание нового слияния с SIT или DEV. Во всех этих операциях нет смысла. Что, если вы обнаружите новую ошибку в своей DEV-функции? Новые ветки|слияния?

Я рекомендую использовать поток Стабильное ветвление основной линии.

feature -> pull --rebase PROD & push -f -> remote/feature -> QA testing -> PROD
   |                                                            |
  FIX    <---                    <---                     <--- bug

Шаг за шагом:

  1. Создайте feature ветку из prod.
  2. Реализовать в feature функционал/исправления.
  3. После feature завершите перезагрузку на последнюю prod и принудительно нажмите.
  4. Делайте тесты на ветке remote/feature.
  5. Если вы нашли ошибку в remote/feature, повторите шаги 2-4.
  6. Быстрое слияние remote/feature в prod.