（部分图片来自网络）
一、Git和Git Flow简介
Git 是一个开源的分布式版本控制系统，用于敏捷高效地处理任何或小或大的项目，是 Linus Torvalds 为了帮助管理 Linux 内核开发而开发的一个开放源码的版本控制软件。它与常用的版本控制工具 CVS, Subversion 等不同，它采用了分布式版本库的方式，不必服务器端软件支持。
Git Flow是一套基于git的工作流程，这个工作流程围绕着项目发布定义了一个严格的如何建立分支的模型。
Git Flow规定了如何建立、合并分支，如何发布，如何维护历史版本等工作流程。简单说就是每一个功能特性的开发是在分支上开发，而不是在主干开发，分支开发完毕后再合并到主干上。
二、Git及Git Tortoise安装与介绍
1.Git安装：
在官网上获取安装包：
获取最新版安装包并进行安装，完成安装。
2. Git Tortoise安装：
在官网获取
图 Git Tortoise安装
在钉钉的技术应用服务部上获取Git乌龟的安装包，并同时获取Git乌龟的中文语言包。
3.二者之间的关系：
为了方便使用Git，Git Tortoise的作用就是将Git的命令行管理变成鼠标右键的图形化管理方式。
三、Git Flow流程解析
图 Git flow图解
Master(主要分支，正式版)
分支存放所有正式发布的版本，可以作为项目历史版本记录分支，不直接提交代码。仅用于保持一个对应线上运行代码的 code base。
Hotfixes(用于修改bug)
分支基于master分支创建，对线上版本的bug进行修复，完成后直接合并到master分支和develop分支，如果当前还有新功能release分支，也同步到release分支上。同一时间只有1个，生命周期较短。
Develop(开发主线路)
分支为主开发分支，一般不直接提交代码，功能开发用。主要是合并与其他分支，比如Feature分支
Feature(各个功能开发的线路)
这个分支主要开发新功能，在开发完成之后合并回到Develop中进入下一个Release；
Release(预发布，用于测试)
在需要发布一个新的版本时，测试完成后合并到master并打上版本号，同时也合并到develop，更新最新开发分支。(一旦打了release分支之后不要从develop分支上合并新的改动到release分支)，同一时间只有1个，生命周期很短，只是为了发布。
而一般的小型项目并不用这么多，是这样的：
图 小型项目Git Flow
只需要一个主线路，一个开发主线路，一个功能开发线路这三个。
四、Git Flow常用操作
图 代码管理使用简明流程
1.代码的获取
首先在开发代码前，不仅仅是需要安装好Git使用的所有环境，而且还要从代码管理库中获取项目的代码，而获取代码的方式就是用Git Tortoise红框处进行克隆，用此方法克隆到本地的项目中。新建文件夹，右键克隆，便可以克隆项目。
获取远端项目
图 克隆项目
图 选择文件夹克隆项目
图 克隆项目
图 获取库代码
图 拉取
图 获取
而获取和拉取的区别就是，拉取过来之后会直接合并到现在的分支，获取就是在获取到之后不会合并。
2.切换，新建分支
首先切换到development分支上，这是开发分支，汇集所有创建的功能，在此分支上新建新的分支。
图 切换并创建新的分支
图 创建分支
图 切换分支
让我们来看一个简单的分支新建与分支合并的例子，实际工作中你可能会用到类似的工作流。
3.日志以及版本树查看
学会查看日志以及版本树你就可以摸清这个项目的运行情况，可以快速的切换分支等：
图 打开日志及版本分支图
图 日志浏览
图 版本树
4.添加文件
当需要从外面引入新的文件时，不能直接将文件拷贝进来，而是需要使用添加功能来添加使得文件都在Git的控制之内：
图 添加引入文件
图 添加未受控制的版本
将添加进来的文件选中添加到项目中。
5.提交和推送
在写完自己的代码后，需要使用对比差异前后文件的不同之处检测bug与原版之间的兼容情况：
图 代码对比
打开之后，双击文件打开，黄色部分就是差异处。
图 比较差异
图 比较差异
之后再提交到缓存区，进行测试，确认无误后便可以推送到库的项目了。
图 提交和推送
在提交时需要详细写出日志、时间、作者等详细信息：
5.1日志书写规范：
图 日志书写规范
5.1.1 head
(1)类型(type)：代码提交的类别，一般分为7个：
图 代码提交类型
(2)范围(scope)：说明代码修改的地方时作用于数据层，控制层，视图层等。
(3)描述(subject)：对于提交类型的简单描述，写干了什么。
5.2.2 body
是为了详细说明此次的提交对代码进行的主要行为是什么。
5.3.3 footer
为了说明此次的修改对于上个版本的影响大不大，是否存在兼容问题。如果有的话说明修改原因，迁移方式等。
6.还原
在自己的开发过程中，可能有时候因为一时疏忽，忘记修改了哪些代码或者误删了文件
图 还原文件
图 还原文件
选择自己想要恢复到的版本就可以返回了。
7.冲突处理，合并分支
像Development分支等主分支是多人共同使用的，有时候把自己的代码推送并合并到主分支后，可能别人的推送已经对该分支进行了更新，所以在你将自己的代码提交的时候就会报错，告诉你你本地仓库的主分支与远端仓库的主分支版本不一样：
图 远端主线与本地主线出现了矛盾
本来我们需要把远端的master分支合并来就行，但是拉取过来之后会与你新写的代码出现冲突导致拉取失败：
图 因为代码冲突而导致拉取失败
所以，此时我们就需要把现在刚编写好的代码进行贮藏：
图4.9 贮藏文件
并说明原因：
图 贮藏
贮藏成功后就可以成功拉取到远端仓库的master最新版本。
图 拉取成功
拉取结束后现在你的本地仓库的版本就和远端一样了，打开贮藏，将代码释放出来，此时可能会告诉你会有冲突，因为别人更新的版本可能会和你新增的代码在某同一文件的同一地方有不一样之处，会弹出有冲突的文件：
图 弹出贮藏后文件冲突
打开冲突文件，比较现在版本与自己的编辑文件之间的区别，左边为现在版本中的，右边为自己的，合适的修改文件内容：
图 修复冲突
在修改完成后，点击红框中的按钮取消掉标记位置，便可以退出之后提交了。
图 解决冲突后提交
五、仓库与流程原理
图 流程原理
1.
在最开发的时候，需要管理者在代码托管系统上创一个框架也叫做远端仓库，各个开发者使用获取方式将远端仓库克隆到自己的机器上，自己这里的就叫做本地仓库。
2.
管理者创建出develop分支作为主要的开发分支，各个开发人员都需要基于develop分支来创建自己具有具体描述的新分支来填入自己的功能，在有新的子任务时，需要基于该分支创建，创建的分支应该是具有自己详细的描述的。
3.
在你开始工作后，确保每次可能将更改并入 master 分支之前，功能分支能够保持最新状态。
4.
运行相关的测试，保证你的代码中的拼写错误和常见错误都能被发现。这一步可能包括一个拼写检查、一个语法检查（通过 Lint 进行静态语法检查）。如果你在测试驱动的环境中工作，那么一定会有额外的测试需要运行。
5.
当你完成工作的时候，上传最后一个提交，在日志中包含关键词“解决”，后跟需求或任务详述。
6.
一个需求分支的代码历史总是应该是线性的，而不是呈现珍珠链，即便是一个需求中包含多个任务。
7.
当你完成这个需求时，确保需求分支与 develop 分支保持同步，不然需要进行解决冲突步骤，然后将你的工作上传至代码托管系统。
