GitFlow说明

Git
GitFlow 协同工作流
- 由来
- GitFlow中分支角色们
常用版本说明
Composer
参考资料

Git

git 包含三种状态:

已暂存 (staged)
已修改 (modified)
已提交 (committed)

版本号 (x.y.z)

X = 主版本号 (重大升级，不同主版本的库之间是不兼容的)
Y = 次版本号 (增量升级，增加一些新的接口但保留原有接口。高版本号的库向后兼容低版本的库)
Z = 维护版本号 (仅修复 Bug) (修改错误，改进性能等，不添加新接口，也不更改接口。在主版本和次版本相同的前提下，不同维护版本之间完全兼容)

GitFlow 协同工作流

其实GitFlow并非什么技术，而是一种代码开发合并管理流程的思维模式或者是管理方法。大家一起开发的一种软约定。

由来

我们为什么需要GitFlow这种git管理流程？原因有以下几点

有一个稳定版本的代码分支，可以安心的用在线上发布。
在代码提测前或者说是代码达到预发状态时，在测试交付的过程中程序员们还可以继续进行下一个版本的开发工作。
有一个分支可以让我们及时的对线上的bug进行修复，这个过程中我们不希望将正在开发中的代码提交到线上生产中去。

由于上述开发过程中面临的需求，GitFlow协同国祚流应运而生。对应的点就是

代码共享
不同环境下代码互不干扰
管理好代码与环境的一致性

GitFlow中分支角色们

Master 分支：稳定版本代码分支，用作发布环境，上面的每次提交都是可以发布的。
Feture 分支：功能分支，用于开发功能（需求），用于开发环境
Developer 分支: 开发分支，一旦Feture分支内功能开发完成就将Feture中的代码合并到Developer分支中，合并完成后，删除该功能分支。这个分支对应的是集成测试环境。
Release 分支：预发分支，做发布前的准备工作，对应的是预发环境。这个分支可以确保们开发继续向前，不会因为要发布而被停滞住。一旦Release分支达到了可发布的状态，我们需要把Release分支同时向Master， Developer分支上合并，保持代码的一致性，然后把Release分支删除。
Hotfix 分支：线上bug修缮用的分支，每次修改线上代码的bug时都要用hotfix来维护，完成后向Developer和Master同时合并。完成后删除分支。

以上就是GitFlow中所有角色分支，从中我们可以看到以下几点：

Master和Developer需要我们长期维护，也是我们开发的主干线。
其中relesase和hotfix两个分支的操作会很零碎，操作起来会比较麻烦，在这个过程中很容易产生失误，导致代码不一致。所以我们需要一个号的工具或者脚本来完成此步骤。
这个套流程虽然麻烦，但是他可以应用到几乎所有的开发流程中：瀑布型，敏捷性（waterfall，agile）

常用版本说明

不同的软件开发中有不同的软件说明，下面列举一些常用的版本说明。

semver

全称叫semanctic version，简称为语义版本。指的是在软件开发工程中，根据semver来对产品进行划分，一般通用的划分是X.X.X，其中第一个是主版本，第二是增强版本，第三个是bug修复版本。例如发行了一款产品，代号1.0.0，在后续的开发中，如果修复了几个bug的重新版本发布，根据约定的语义，即1.0.1， 1.0.2类推，如果增加了新的功能的重新版本发布，根据约定的语义，即1.1.0, 1.2.0类推。如果产品经过了比较大的改动，和之前的产品不再兼容，产生了较大的不一致性，英文成为breaking changes，那么根据约定的语义，即2.0.0, 3.0.0类推，由此衍生出目前常用的版本管理的工具叫git。

主要版本号说明：

Canary；面向特定开发者发布的早期预览版本，不承诺API稳定性。

Beta；面向开发者公开发布的Beta版本，不承诺API稳定性。

Release；面向开发者公开发布的正式版本，承诺API稳定性。

LTS；long-term support；长期支持版本，用户支持商用。

其他常用版本号说明：

Alpha：软件或系统的内部测试版本，仅内部人员使用。一般不向外部发布，通常会有很多Bug，除非你也是测试人员，否则不建议使用，alpha 就是α，是希腊字母的第一位，表示最初级的版本。

Beta：公开测试版。β是希腊字母的第二个，顾名思义，这一版本通常是在Alpha版本后，该版本相对于Alpha版已有了很大的改进，消除了严重的错误，但还是存在着一缺陷，需要经过多次测试来进一步消除。这个阶段的版本会一直加入新的功能。

Gamma：软件或系统接近于成熟的版本，只需要做一些小的改进就能发行。是beta版做过一些修改，成为正式发布的候选版本。

RC：Release Candidate，发行候选版本。和Beta版最大的差别在于Beta阶段会一直加入新的功能，但是到了RC版本，几乎就不会加入新的功能了，而主要着重于除错。RC版本是最终发放给用户的最接近正式版的版本，发行后改正bug就是正式版了，就是正式版之前的最后一个测试版。

GA：General Available，正式发布的版本，这个版本就是正式的版本。在国外都是用GA来说明release版本的。 GA意味着General Available，也就是官方开始推荐广泛使用了。

Release：这个版本通常就是所谓的“最终版本”，在前面版本的一系列测试版之后，终归会有一个正式版本，是最终交付用户使用的一个版本，该版本有时也称为标准版。一般情况下，Release不会以单词形式出现在软件封面上，取而代之的是符号®。

Stable：稳定版。在开源软件中，都有stable版，这个就是开源软件的最终发行版，用户可以放心大胆的用了。这一版本基于Beta版，已知Bug都被修复，一般情况下，更新比较慢。

RTM：Release to Manufacture，给工厂大量生产的压片版本，与正式版内容一样。

OEM：Original Entrusted Manufacture，给计算机厂商的出场销售版本，不零售只预装

EVAL：流通在网络上的EVAL版，与“评估版”类似，功能上和零售版没有区别。

RTL：Retail，零售版是真正的正式版，正式上架零售版

GM：Gold Master，正式版前最后一个测试版，其实也就是正式版。

Chromium：开源版本，迭代速度极快，数小时就会有新版本，有很多新功能，等待验证后会移植到Chrome。

Canary：迭代速度相对于Chromium版稍慢一些，功能非常新但未经过验证，同时崩溃的概率非常高。

Dev：基于Chromium开发，每周出新功能，并且这些功能还有一定的筛选，另外还修复了一些Bug和不稳定因素。

LTS（Long Term Support）：长期支持版，Ubuntu会对这一版本的支持时间更长。目前Java也在运用这种方式。在比如说php的Laravel框架也发布了一些LTS版本等。

补充

Stable：稳定版本，也就是Chrome的正式版本，这一版本基于Beta版，已知Bug都被修复，一般情况下，更新比较慢

GA：全称叫General Availability，简称一般可用性，指的是产品经过内部比较充分的测试，释放到市场中进行公众使用的版本，如果公众可以用了，那么就可以称之为GA。

LTS：全称为Long Term Support，简称长期支持版本，在公司内部，不同的产品根据产品开发的周期，会并行多个产品线，而对已经发布的产品例如1.0.0会根据客户以及市场的反应进行适当的功能增强(衍生为1.X.0)和bug修复(衍生为1.1.X)，而这种修复只承诺一定的期限，例如Ubuntu操作系统一般承诺的是5年期限，5年过去之后，如果版本停留在1.102.188，那么就此终结，后续将不在维护，用户需要根据需要切换到更新的版本，成为依赖的升级。

（GA 、LTS 、Stable）这三个版本是不同厂家提出，Ubuntu常用LTS来描述，Chrome常用Stable来描述。

GM（Gold Master）：正式版前最后一个测试版，其实也就是正式版，谷歌Chrome浏览器常用的版本号

Chromium：开源版本，迭代速度极快，数小时就会有新版本，有很多新功能，等待验证后会移植到Chrome

Canary：迭代速度相对于Chromium版稍慢一些，功能非常新但未经过验证，同时崩溃的概率非常高

Dev：基于Chromium开发，每周出新功能，并且这些功能还有一定的筛选，另外还修复了一些Bug和不稳定因素

Beta：基于Dev版，Chrome会基于这一版本进行改进，一般按月更新，功能更加完善

Alpha：软件或系统的内部测试版本，会有很多Bug，仅内部人员使用