Git-flow начал распространяться в блоге Винсента Драйсена около 10 лет назад, когда Git только что был активирован, и теперь является почти стандартной методологией для его разработки.

Git-flow — это не функция, это взаимные обязательства

Краткий обзор стратегии Git-flow

Большинство проектов имеют пять типов ветвей,
2 ветки, которые остаются не удаленными (main, develop) И
есть три второстепенные ветки (feature, release, hotfix), которые существуют только в течение определенного периода времени.

  • master: ветвь, которую можно выпускать как продукты.
  • develop : Филиал, разрабатывающий следующую версию выпуска.
  • функция :функции разработки филиалов
  • выпуск : ветка, которая готовится к этой версии.
  • исправление: ветка, исправляющая ошибки в выпущенных версиях.

Я объясню процесс разработки этой картинкой
во-первых, есть master, develop конечно, develop начинается с master
В ветке разработки всегда добавляются коммиты с исправлениями ошибок.

Когда есть работа по добавлению новых функций, мы создаем ветку feature в ветке develop и
если работа по добавлению функций завершена, ветка feature объединяется с веткой develop (запрос на извлечение)

Наконец, из ветки develop создается ветка develop для QA
В ветке release исправляются ошибки, которые возникали во время QA. Если вы успешно прошли контроль качества, объедините ветку release с веткой master и
develop. Добавьте тег версии из последней выпущенной ветки master

Как я это использую

Это неправильный ответ, но вы можете обратиться к нему и использовать его в соответствии со своим проектом.

  1. Сначала создайте задачу на github
    И в ветке develop создайте ветку с названием ветки, которое соответствует номеру задачи, напримерэтой feature/#{issue number}
  2. Отредактируйте исходный код в ветке feature
    Зафиксируйте изменения в ветке feature
    Обычно я пишу такое сообщение о коммите,
    [#{issue number}] feature : commit message
  3. перебазируйте ветку develop в ветку feature
    git pull –rebase develop feature/#{issue number}
    всегда develop актуальна и должна перебазировать самую последнюю версию
  4. Отправьте функциональную ветку в источник и напишите запрос на извлечение

С 3 заданием можно взять простой график

Теперь напишите отзыв на пулл-реквест, проделайте дополнительную работу и слейте его в ветку develop.

Начало работы с контролем качества

  1. Сначала создайте ветку release из ветки разработки и поделитесь ею с командой
    git checkout -b release/v1.0.0 –track develop
    git push release/v1.0.0
  2. Если ошибка возникает во время QA, создайте проблему об ошибке и создайте ветку в выпуске.
  3. это то же самое, что и раньше: фиксация, отправка, запрос на слияние, слияние
    фиксация: [#{issue number}] bug : Commit Message
  4. Когда все ошибки будут исправлены, объедините этот release в master и develop
  5. Наконец, добавьте тег и готово.
    (master) git tag 1.0.0

Проблемы, возникающие при использовании Git-flow

Я буду добавлять больше по мере возникновения новых проблем
надеюсь, что не будет добавлено

1. Когда существует несколько запросов на слияние, и один из них объединен

Если один из нескольких запросов на вытягивание объединяется,
другие запросы на вытягивание вызывают проблемы, требующие перебазирования.

В этом случае вам нужно удалить ветку функции в origin
Если вы удалите ее, запрос на слияние будет автоматически закрыт и
перебазируйте ветку develop в ветку feature в местном

Теперь, после повторного нажатия, создайте запрос на извлечение