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
Как я это использую
Это неправильный ответ, но вы можете обратиться к нему и использовать его в соответствии со своим проектом.
- Сначала создайте задачу на github
И в веткеdevelop
создайте ветку с названием ветки, которое соответствует номеру задачи, напримерэтойfeature/#{issue number}
- Отредактируйте исходный код в ветке
feature
Зафиксируйте изменения в веткеfeature
Обычно я пишу такое сообщение о коммите,[#{issue number}] feature : commit message
- перебазируйте ветку
develop
в веткуfeature
git pull –rebase develop feature/#{issue number}
всегда
develop
актуальна и должна перебазировать самую последнюю версию - Отправьте функциональную ветку в источник и напишите запрос на извлечение
С 3 заданием можно взять простой график
Теперь напишите отзыв на пулл-реквест, проделайте дополнительную работу и слейте его в ветку develop
.
Начало работы с контролем качества
- Сначала создайте ветку
release
из ветки разработки и поделитесь ею с командойgit checkout -b release/v1.0.0 –track develop
git push release/v1.0.0 - Если ошибка возникает во время QA, создайте проблему об ошибке и создайте ветку в выпуске.
- это то же самое, что и раньше: фиксация, отправка, запрос на слияние, слияние
фиксация:[#{issue number}] bug : Commit Message
- Когда все ошибки будут исправлены, объедините этот
release
вmaster
иdevelop
- Наконец, добавьте тег и готово.
(master) git tag 1.0.0
Проблемы, возникающие при использовании Git-flow
Я буду добавлять больше по мере возникновения новых проблем
надеюсь, что не будет добавлено
1. Когда существует несколько запросов на слияние, и один из них объединен
Если один из нескольких запросов на вытягивание объединяется,
другие запросы на вытягивание вызывают проблемы, требующие перебазирования.
В этом случае вам нужно удалить ветку функции в origin
Если вы удалите ее, запрос на слияние будет автоматически закрыт и
перебазируйте ветку develop
в ветку feature
в местном
Теперь, после повторного нажатия, создайте запрос на извлечение