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

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

Опция 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. Вы также можете проверить эти рабочие процессы, чтобы получить некоторые другие идеи.

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

• Git-поток
• поток GitHub

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

Создайте ветку исправлений от 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.