版本管理的阶段
版本管理工具， 首先是一个内容管理工具， 可以将项目的内容信息存放在版本管理服务器上
方便项目组人员进行访问和查询修改。
https://blog.csdn.net/liurong1028/article/details/80307038
原理：
https://cloud.tencent.com/developer/article/1843580
常用命令：
https://blog.csdn.net/kenan6545456/article/details/139885605
版本管理具有里程碑意义的主要有三个阶段
CVS 阶段----->SVN 阶段---->Git 阶段
版本管理的好处及种类
CVS 阶段
项目搭建开发过程中， 每次提交项目都会将整个项目提交到服务器进行保存，服务
器存储着项目的 N 个备份， 开发过程中的协作效率较低，同时也出现了各种传输的
问题，所以慢慢淡出了行业。
SVN 阶段
考虑到 CVS 的缺陷，开发人员根据项目的实际情况，研发出专门针对项目版本控
制的软件 Subversion（简称 SVN） ，SVN 同样也是搭建服务器，让项目组成员将
数据存储在服务器上， 但是每次改动并提交的时候， SVN 服务器并不重新保存整个
项目的完整信息，而是和原来的项目进行对比，只保存改动的信息。这样就在很大
的程度上对于项目版本服务器、项目协作效率有了显著的提升。所以至今为止，有
很多公司依然选用 SVN 作为公司内部项目协作的版本控制软件。
Git 阶段
前面的 CVS 和SVN 都是基于一个服务器的，如果脱离服务器，项目的版本保存就
没有了任何意义，Git 恰恰处理了这样的问题，Git 是一个分布式的版本控制系
统，在 Git 中即使用户离线，也能进行项目的提交和更新操作，等到下次连线服
务器时进行整体的同步操作。
Git 工作流程
一般工作流程如下：
1、克隆 Git 资源作为工作目录。
2、在克隆的资源上添加或修改文件。
3、如果其他人修改了，你可以更新资源。
4、在提交前查看修改。
5、提交修改。
6、在修改完成后，如果发现错误，可以撤回提交并再次修改并提交。
Git 工作区、暂存区和版本库
基本概念
工作区：就是你在电脑里能看到的目录。
暂存区：英文叫stage, 或index。一般存放在 ".git目录下" 下的index文件（.git/index）中，所以我们把暂存区有时也叫作索引（index）。
版本库：工作区有一个隐藏目录.git，这个不算工作区，而是Git的版本库。
工作区、版本库中的暂存区和版本库之间的关系图：
图中左侧为工作区，右侧为版本库。在版本库中标记为 "index" 的区域是暂存区（stage, index），标记为 "master" 的是 master 分支所代表的目录树。
图中我们可以看出此时 "HEAD" 实际是指向 master 分支的一个"游标"。所以图示的命令中出现 HEAD 的地方可以用 master 来替换。
图中的 objects 标识的区域为 Git 的对象库，实际位于 ".git/objects" 目录下，里面包含了创建的各种对象及内容。
当对工作区修改（或新增）的文件执行 "git add" 命令时，暂存区的目录树被更新，同时工作区修改（或新增）的文件内容被写入到对象库中的一个新的对象中，而该对象的ID被记录在暂存区的文件索引中。
当执行提交操作（git commit）时，暂存区的目录树写到版本库（对象库）中，master 分支会做相应的更新。即 master 指向的目录树就是提交时暂存区的目录树。
当执行 "git reset HEAD" 命令时，暂存区的目录树会被重写，被 master 分支指向的目录树所替换，但是工作区不受影响。
当执行 "git rm --cached <file>" 命令时，会直接从暂存区删除文件，工作区则不做出改变。
当执行 "git checkout ." 或者 "git checkout -- <file>" 命令时，会用暂存区全部或指定的文件替换工作区的文件。这个操作很危险，会清除工作区中未添加到暂存区的改动。
当执行 "git checkout HEAD ." 或者 "git checkout HEAD <file>" 命令时，会用 HEAD 指向的 master 分支中的全部或者部分文件替换暂存区和以及工作区中的文件。这个命令也是极具危险性的，因为不但会清除工作区中未提交的改动，也会清除暂存区中未提交的改动。
git flow
http://www.ruanyifeng.com/blog/2015/12/git-workflow.html
http://www.ruanyifeng.com/blog/2012/07/git.html
Git分支管理策略
分支Master
首先，代码库应该有一个、且仅有一个主分支。所有提供给用户使用的正式版本，都在这个主分支上发布。
Git主分支的名字，默认叫做Master。它是自动建立的，版本库初始化以后，默认就是在主分支在进行开发。
开发分支Develop
主分支只用来分布重大版本，日常开发应该在另一条分支上完成。我们把开发用的分支，叫做Develop。
这个分支可以用来生成代码的最新隔夜版本（nightly）。如果想正式对外发布，就在Master分支上，对Develop分支进行"合并"（merge）。
Git创建Develop分支的命令：
git checkout -b develop master将Develop分支发布到Master分支的命令：
# 切换到Master分支
git checkout master
# 对Develop分支进行合并
git merge --no-ff develop这里稍微解释一下，上一条命令的--no-ff参数是什么意思。默认情况下，Git执行"快进式合并"（fast-farward merge），会直接将Master分支指向Develop分支。
使用--no-ff参数后，会执行正常合并，在Master分支上生成一个新节点。为了保证版本演进的清晰，我们希望采用这种做法。关于合并的更多解释，请参考Benjamin Sandofsky的《Understanding the Git Workflow》。
临时性分支
前面讲到版本库的两条主要分支：Master和Develop。前者用于正式发布，后者用于日常开发。其实，常设分支只需要这两条就够了，不需要其他了。
但是，除了常设分支以外，还有一些临时性分支，用于应对一些特定目的的版本开发。临时性分支主要有三种：
* 功能（feature）分支
* 预发布（release）分支
* 修补bug（fixbug）分支
这三种分支都属于临时性需要，使用完以后，应该删除，使得代码库的常设分支始终只有Master和Develop。
功能分支
接下来，一个个来看这三种"临时性分支"。
第一种是功能分支，它是为了开发某种特定功能，从Develop分支上面分出来的。开发完成后，要再并入Develop。
功能分支的名字，可以采用feature-*的形式命名。
创建一个功能分支：
git checkout -b feature-x develop
开发完成后，将功能分支合并到develop分支：
git checkout develop
git merge --no-ff feature-x
删除feature分支：
git branch -d feature-x
预发布分支
第二种是预发布分支，它是指发布正式版本之前（即合并到Master分支之前），我们可能需要有一个预发布的版本进行测试。
预发布分支是从Develop分支上面分出来的，预发布结束以后，必须合并进Develop和Master分支。它的命名，可以采用release-*的形式。
创建一个预发布分支：
git checkout -b release-1.2 develop
确认没有问题后，合并到master分支：
git checkout master
git merge --no-ff release-1.2
# 对合并生成的新节点，做一个标签
git tag -a 1.2
再合并到develop分支：
git checkout develop
git merge --no-ff release-1.2
最后，删除预发布分支：
git branch -d release-1.2
修补bug分支
最后一种是修补bug分支。软件正式发布以后，难免会出现bug。这时就需要创建一个分支，进行bug修补。
修补bug分支是从Master分支上面分出来的。修补结束以后，再合并进Master和Develop分支。它的命名，可以采用fixbug-*的形式。
创建一个修补bug分支：
git checkout -b fixbug-0.1 master
修补结束后，合并到master分支：
git checkout master
git merge --no-ff fixbug-0.1
git tag -a 0.1.1
再合并到develop分支：
git checkout develop
git merge --no-ff fixbug-0.1
最后，删除"修补bug分支"：
git branch -d fixbug-0.1