Управление версиями GIT: модель Git Flow

задняя часть Git модульный тест HotFix

1 Введение в Git Flow

Все мы знаем, что функция ветвления в git действительно намного удобнее, чем svn.而且也非常推荐使用分支来做开发Мой подход заключается в том, чтобы иметь 2 ветки для каждого проекта, осваивать и разрабатывать.master 分支是主分支, 保证程序有一个 稳定版本, develop 则是开发用的分支, 几乎所有的功能开发, bug 修复都在这个分支上, 完成后再合并回 master.

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

То есть ветка git очень мощная,但是没有一套模型告诉我们应该怎样在开发的时候善用这些分支. Модель Git Flow должна рассказать нам, как лучше использовать ветки Git.

Проще говоря,git-flow 就是在 git branch git tag基础上封装出来的代码分支管理模型, смоделируйте фактическую разработку в нескольких сценариях поддержки исправлений выпуска основной функции разработки,其中 master 对应发布上线，develop 对应开发，其他几个在不同的情况下出现. Благодаря инкапсуляции,git-flow 屏蔽了 git branch 等相对来说比较复杂生硬的命令(git branch 还是比较复杂的，尤其是在多分支情况下)，简单而且规范的解决了代码分支管理问题.

Проще говоря, Git Flow разбивает ветку на 2 основные и 3 временные вспомогательные ветки:

Основная отрасль

мастер: всегда в **即将发布(production-ready)状态**;

develop: 最新的开发状态;

вспомогательная ветвь

feature: 开发新功能的分支, 基于 develop, после завершенияmerge 回 develop;

release: 准备要发布版本的分支, 用来修复 bug. 基于 develop, после завершенияmerge 回 develop 和 master;

hotfix: 修复 master 上的问题, не могу дождаться, когда релизная версия появится в сети немедленно.基于 master, после завершенияmerge 回 master 和 develop;

2 Использование Git Flow

2.1 Установка и сборка Git Flow

Установите git-поток:

➜ brew install git-flow

Автор также предоставляет командный инструмент git-flow для построения модели git-flow в новом каталоге:

➜ git flow init

Затем он задаст вам ряд вопросов, Данг Дин! Просто попробуйте использовать его значение по умолчанию:

No branches exist yet. Base branches must be created now.
Branch name for production releases: [master]
Branch name for "next release" development: [develop]
How to name your supporting branch prefixes?
Feature branches? [feature/]
Release branches? [release/]
Hotfix branches? [hotfix/]
Support branches? [support/]
Version tag prefix? []

Или создайте существующий репозиторий:

➜ git flow init
Which branch should be used for bringing forth production releases?
   - master
Branch name for production releases: [master]
Branch name for "next release" development: [develop]

How to name your supporting branch prefixes?
Feature branches? [feature/]
Release branches? [release/]
Hotfix branches? [hotfix/]
Support branches? [support/]
Version tag prefix? []

Такая модель ветви git-flow инициализируется.

2.2 Сценарий 1: Разработка новой функции, кодовое имя f1

  1. На основе разработки, открытия новой функциональной ветки

    После завершения предыдущей операции сборки текущая ветка становится develop.Любая разработка должна начинаться с develop:

    ➜ git flow feature start f1

    git-flow 从 develop 分支创建了一个新的分支 feature/f1，并自动切换到这个分支下面. Затем вы можете разработать функции f1, и вы можете зафиксировать несколько раз в середине.

    Отправьте ветку f1 на удаленный сервер для совместной работы с другими разработчиками:

    ➜ git flow feature publish f1

或者

➜ git push origin feature/f1

  2. Завершить разработку функции, завершить новую ветвь функции и удалить:

    ➜ git flow feature finish f1

    feature/f1 分支的代码会被合并到 develop 里面，然后删除该分支，切换回 developНа этом сцена разработки новой функции завершена. При разработке функции f1, если f1 не завершена, одновременно можно запустить функцию f2.

2.3 Сценарий 2: Выпуск онлайн, кодовое имя 0.1

  1. На основе разработки разработайте ветку релиза

    ➜ git flow release start 0.1
Switched to a new branch 'release/0.1'

Summary of actions:
- A new branch 'release/0.1' was created, based on 'develop'
- You are now on branch 'release/0.1'

Follow-up actions:
- Bump the version number now!
- Start committing last-minute fixes in preparing your release
- When done, run:

git flow release finish '0.1'

  2. git-flow создает новую ветку релиз/0.1 из ветки разработки и переключается на эту ветку Следующее, что нужно сделать, это изменить номер версии и другие операции выпуска. после завершения:

    ➜ git flow release finish 0.1
Switched to branch 'master'
Merge made by the 'recursive' strategy.
 f1      |    1 +
 version |    1 +
 2 files changed, 2 insertions(+)
 create mode 100644 f1
 create mode 100644 version
Switched to branch 'develop'
Merge made by the 'recursive' strategy.
 version |    1 +
 1 file changed, 1 insertion(+)
 create mode 100644 version
Deleted branch release/0.1 (was d77df80).

Summary of actions:
- Latest objects have been fetched from 'origin'
- Release branch has been merged into 'master'
- The release was tagged '0.1'
- Release branch has been back-merged into 'develop'
- Release branch 'release/0.1' has been deleted

  3. git-flow переключится на основную разработку, в свою очередь, чтобы объединить изменения в выпуске / 0.1, а затем использовать тег git, чтобы пометить текущий выпуск с помощью тега 0.1.Вы можете просмотреть все теги через тег git:

    ➜ git:(master) git tag
0.1
0.2

2.3 Сценарий 3: Срочное исправление ошибки, кодовое имя bug1

  1. На основе мастера откройте ветку исправления

    ➜ git flow hotfix start bug1
Switched to a new branch 'hotfix/bug1'

Summary of actions:
- A new branch 'hotfix/bug1' was created, based on 'master'
- You are now on branch 'hotfix/bug1'

Follow-up actions:
- Bump the version number now!
- Start committing your hot fixes
- When done, run:

git flow hotfix finish 'bug1'

  2. git-flow создает новую ветку hotfix/bug1 из основной ветки и переключается на нее. Следующее, что нужно сделать, это исправить ошибку, и когда это будет сделано:

    ➜ git flow hotfix finish bug1
Switched to branch 'master'
Merge made by the 'recursive' strategy.
 f1 |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
Switched to branch 'develop'
Merge made by the 'recursive' strategy.
 f1 |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
Deleted branch hotfix/bug1 (was aa3ca2e).

Summary of actions:
- Latest objects have been fetched from 'origin'
- Hotfix branch has been merged into 'master'
- The hotfix was tagged 'bug1'
- Hotfix branch has been back-merged into 'develop'
- Hotfix branch 'hotfix/bug1' has been deleted

    git-flow переключится на основную ветку разработки, чтобы объединить исправление/ошибку1, а затем удалит исправление/ошибку1. На этом исправление завершено.

    git-flow 的 feature release 都是从 develop 分支创建，hotfix support 都是从 master 分支创建。

3 Классическая спецификация управления филиалами

Как показано на фиг.1:

  1. 最稳定的代码放在 master 分支上（相当于 SVN 的 trunk 分支）, мы не фиксируем код непосредственно в ветке master, в этой ветке можно выполнять только операции слияния кода, например слияние кода других веток в ветку master.

  2. мы日常开发中的代码需要从 master 分支拉一条 develop 分支出来, ветка доступна всем, но в целом,我们也不会直接在该分支上提交代码，代码同样是从其它分支合并到 develop 分支上去.

  3. Когда нам нужно разработать функцию,需要从 develop 分支拉出一条 feature 分支, такие как функция-1 и функция-2, параллельно разрабатывают определенные функции на этих ветвях.

  4. Когда разработка функции завершена, мы решаем, что нам нужно выпустить определенную версию,此时需要从 develop 分支上拉出一条 release 分支, например выпуск-1.0.0,并将需要发布的特性从相关 feature 分支一同合并到 release 分支上, а затем тестовая среда будет развернута для ветки релиза, инженеры-тестировщики будут проводить функциональное тестирование в этой ветке, а инженеры-разработчики будут исправлять ошибки в этой ветке.

  5. Когда инженер-испытатель не может найти никаких ошибок,我们可将该 release 分支部署到预发环境，再次验证以后，均无任何 bug，此时可将 release 分支部署到生产环境.

  6. После того, как онлайн будет завершен,将 release 分支上的代码同时合并到 develop 分支与 master 分支，并在 master 分支上打一个 tag, например v1.0.0.

  7. Когда в производстве обнаруживаются ошибки, мы需要从对应的 tag 上（例如 v1.0.0）拉出一条 hotfix 分支（例如 hotfix-1.0.1），并在该分支上做 bug 修复. После того, как ошибка будет полностью исправлена,需将 hotfix 分支上的代码同时合并到 develop 分支与 master 分支.

У нас также есть требования к номерам версий,格式为：x.y.z，其中，x 用于有重大重构时才会升级，y 用于有新的特性发布时才会升级，z 用于修改了某个 bug 后才会升级. Для каждого микросервиса нам нужно строго следовать указанному выше режиму разработки.

Отличия от управления ветвями модели Git Flow:

  1. feature分支开发完成后，暂时不合并至develop, но откройте релизную ветку на основе разработки, объедините функциональную ветку с релизной веткой для тестирования;

  2. release分支测试通过后，部署到生产环境，将release分支代码合并到develop分支与master分支，并在master分支打一个tag;

Категории