分支类型
| master | 主分支:通常是 master 或 main 分支，用于存放稳定的、可部署的代码。主分支应该是非常稳定和可靠的，只包含已经经过测试和验证的代码。 |
|---|---|
| release | 发布分支:用于准备发布新版本的分支。从开发分支创建发布分支，进行版本准备、测试和修复 bug，最终将发布分支合并回主分支和开发分支。 |
| develop | 开发分支：用于整个团队的开发工作。开发分支是各个开发者合作的主要分支，包含最新的功能和修复。 |
| feature | 功能分支：用于开发特定功能或实现特定需求的分支。当需要开发新功能时，从开发分支创建特性分支，完成开发后再合并回开发分支 |
| hotfix | 修复分支：用于紧急修复生产环境中的 bug。从主分支创建修复分支，进行修复后将其合并回主分支和开发分支。 |
Vincent Driessen是Git Flow分支模型的创造者。
Vincent Driessen在2010年提出了Git Flow，这是一种构建在Git之上的软件开发模型。它通过利用Git创建和管理分支的能力，为每个分支设定了明确的生命周期和作用，以适应不同的开发阶段和需求。Git Flow模型包括以下几个关键分支：
- master分支：对应生产环境的线上代码，所有开发代码最终都会合并到master分支并发布。
- develop分支：作为功能开发的主线，新功能开发都在这个分支上进行，准备合并到master分支的预发布代码所在的地方。
- feature分支：从develop分支拉出，用于开发单一功能的分支。
- release分支：当develop分支达到一个稳定状态，可以为其发布新版本时，就会创建一个release分支。
- hotfix分支：用于快速修复master分支上的问题，直接基于master分支创建。
然而，随着软件开发实践的演进，特别是持续集成和持续交付（CI/CD）的普及，Vincent Driessen自己也指出，Git Flow可能不再适用于当前的软件开发模式。他推荐更简单的模型，如Github Flow，这种模型更适合快速迭代和频繁发布的项目。
总的来说，Vincent Driessen的贡献在于为软件版本控制提供了一个清晰、结构化的框架，尽管随着时间的推移和开发模式的变化，他所提出的模型也在不断地被重新评估和更新。
开发环境
- 本地开发环境
- 测试环境 （内测）
- 预发布环境 （外测）
- 生产环境
版本合并流程
两大主分支、三个辅助分支的生命周期
Git Flow常用的分支
- Production 分支
也就是我们经常使用的Master分支，这个分支最近发布到生产环境的代码，最近发布的Release， 这个分支只能从其他分支合并，不能在这个分支直接修改
- Develop 分支
这个分支是我们是我们的主开发分支，包含所有要发布到下一个Release的代码，这个主要合并与其他分支，比如Feature分支
- Feature 分支
这个分支主要是用来开发一个新的功能，一旦开发完成，我们合并回Develop分支进入下一个Release
- Release分支
当你需要一个发布一个新Release的时候，我们基于Develop分支创建一个Release分支，完成Release后，我们合并到Master和Develop分支
- Hotfix分支
当我们在Production发现新的Bug时候，我们需要创建一个Hotfix, 完成Hotfix后，我们合并回Master和Develop分支，所以Hotfix的改动会进入下一个Release
Git Flow如何工作
初始分支
所有在Master分支上的Commit应该Tag ；当一个项目达到一个稳定的发布状态时，通常会在此时创建一个tag来标记这个时间点的代码状态。这有助于后续的版本控制和回溯。
Feature 分支
分支名 feature/*
Feature分支做完后，必须合并回Develop分支, 合并完分支后一般会删掉这个Feature分支，但是我们也可以保留
Release分支
分支名 release/*
Release分支基于Develop分支创建，打完Release分之后，我们可以在这个Release分支上测试，修改Bug等。同时，其它开发人员可以基于开发新的Feature (记住：一旦打了Release分支之后不要从Develop分支上合并新的改动到Release分支)
发布Release分支时，合并Release到Master和Develop， 同时在Master分支上打个Tag记住Release版本号，然后可以删除Release分支了。
维护分支 Hotfix
分支名 hotfix/*
hotfix分支基于Master分支创建，开发完后需要合并回Master和Develop分支，同时在Master上打一个tag
Git Flow代码示例
a. 创建develop分支
git branch develop
git push -u origin develop
b. 开始新Feature开发
git checkout -b some-feature develop
git push -u origin some-feature
git status git add some-filegit commit
c. 完成Feature
> git pull origin develop
> git checkout develop
> git merge --no-ff some-featuregit push origin develop
> git branch -d some-feature>
> push origin --delete some-feature
d. 开始Relase
> git checkout -b release-0.1.0 develop
e. 完成Release
> git checkout master
> git merge --no-ff release-0.1.0
> git push
> git checkout develop
> git merge --no-ff release-0.1.0
> git push
> git branch -d release-0.1.0>
> git push origin --delete release-0.1.0
> git tag -a v0.1.0 master
> git push --tags
f. 开始Hotfix
> git checkout -b
> hotfix-0.1.1 master
``
g. 完成Hotfix
```js
> git checkout master
> git merge --no-ff hotfix-0.1.1
> git push
> git checkout develop
> git merge --no-ff hotfix-0.1.1
> git push git branch -d hotfix-0.1.1
> git tag -a v0.1.1 master
> git push --tags
Git flow工具
使用
-
初始化: git flow init
-
开始新Feature: git flow feature start MYFEATURE
-
Publish一个Feature(也就是push到远程): git flow feature publish MYFEATURE
-
获取Publish的Feature: git flow feature pull origin MYFEATURE
-
完成一个Feature: git flow feature finish MYFEATURE
-
开始一个Release: git flow release start RELEASE [BASE]
-
Publish一个Release: git flow release publish RELEASE
-
发布Release: git flow release finish RELEASE
别忘了git push --tags
-
开始一个Hotfix: git flow hotfix start VERSION [BASENAME]
-
发布一个Hotfix: git flow hotfix finish VERSION
Git Flow GUI
GUI 工具
SourceTree
当你用Git-flow初始化后，基本上你只需要点击git flow菜单选择start feature, release或者hotfix, 做完后再次选择git flow菜单，点击Done Action. 我勒个去，我实在想不到还有比这更简单的了。
目前SourceTree支持Mac, Windows, Linux.
3.分支/tag命名
3.0 主干分支
master-v{版本号}-{日期}
- 主版本号（Major）：没有具体限制，可以增长到很大的数值。
- 次版本号（Minor）：没有具体限制，可以增长到很大的数值。
- 修订号（Patch）：建议数值增长到 999。
3.1.功能分支
m-{JIRA-NUM}-{功能}，示例: m-KaigejavaCRM-1014-Hystrix m-{功能}，示例：d-Hystrix
JIRA-NUM通常指的是在JIRA项目管理工具中分配给每个问题或任务的唯一编号。
JIRA是一款由Atlassian开发的项目管理和缺陷跟踪工具，它广泛应用于软件开发和其他类型的项目管理。JIRA的功能强大，包括项目计划、任务分配、需求管理、错误跟踪等，并且支持敏捷开发流程。它的灵活性和全面性使得全球超过19,000家客户选择使用JIRA作为他们的项目管理工具。
在JIRA中，每个任务或问题都会被分配一个唯一的编号，即JIRA-NUM。这个编号用于追踪和管理问题，确保团队成员可以快速定位和沟通相关的工作项。用户可以通过这个编号来查找问题的状态、历史记录、相关评论以及与之关联的所有文档和附件。
总的来说，JIRA-NUM是JIRA系统中一个重要的组成部分，它帮助团队有效地管理和跟踪项目中的各项工作。
3.2.开发分支
m-{JIRA-NUM}-{功能}-{developer}，示例: m-KaigejavaCRM-1014-Hystrix-wangning m-{禅道项目ID}-{功能}-{developer}，示例: m-KaigejavaCRM-1014-Hystrix-wangning
3.3.修改线上bug分支
m-{JIRA-NUM}-{问题} ，示例: m-KaigejavaCRM-1014-hystrix-npe
3.4.tag版本号
v{版本号}-{日期} ，版本号使用十进制。示例: v1.2.9-20190401
软件版本号一般由四部分组成，格式如：主版本号.子版本号.修订版本号.日期版本号+希腊字母版本号。
举个例子：1.2.3.20230128_beta
说明：
第一位(1): 主版本号。当功能模块有较大的变动，API 的兼容性发生变化时，比如增加多个模块或者整体架构发生变化。此版本号由项目决定是否修改，且只能递增。
第二位(2): 子版本号。当功能有一定的增加或变化，但是不影响 API 的兼容性，比如增加了对权限控制、增加自定义视图等功能。此版本号由项目决定是否修改，且只能递增。
第三位(3): 修订版本号。一般是 Bug 修复或是一些小的变动，不影响 API 的兼容性，要经常发布修订版，时间间隔不限，修复一个严重的 Bug 即可发布一个修订版。此版本号由项目经理决定是否修改，且只能递增。
日期版本号(20230128): 用于记录修改项目的当前日期，每天对项目的修改都需要更改日期版本号。此版本号由开发人员决定是否修改。
希腊字母版本号(beta): 也叫里程碑版本号，此版本号用于标注当前版本的软件处于哪个开发阶段，当软件进入到另一个阶段时需要修改此版本号。此版本号由项目决定是否修改。
希腊字母版本号共有5种，分别为：Base、Alpha、Beta、RC、Release。
Base 版: 此版本表示该软件仅仅是一个基础框架，通常包括主要功能和结构，但是都没有做完整的实现，只是作为程序设计的一个基础架构。
Alpha 版: 此版本表示该软件在此阶段主要是以实现软件功能为主，通常只在软件开发者内部交流，一般不向外部发布，是内部测试版，该版本软件的 Bug 较多，需要继续修改。
Beta 版: 该版本相对于 Alpha 版已有了很大的改进，消除了严重的错误，但还是存在着一些缺陷，是公开测试版，需要经过多次测试来进一步消除，这个阶段的版本会一直加入新的功能。
RC 版: (Release Candidate)最终测试版本，该版本已经相当成熟了，基本上不存在导致错误的 BUG，与即将发行的正式版相差无几。
Release 版: 该版本意味“最终版本”，在前面版本的一系列测试版之后，终归会有一个正式版本，是最终交付用户使用的一个版本。该版本有时也称为标准版。一般情况下，Release 不会以单词形式出现在软件封面上，取而代之的是符号(Ｒ)。
