作为一个“年老的”的技术人员，总是习惯于拥抱着过去的，熟悉的技术不断应用，也许能够应用得炉火纯青，但是时代总是进步的，技术总是前进的。所以在必要的时候，也必须去学习一些新的技术。比如现在我正在学习的Git，这就是不同于SVN的一个“新鲜”名词。也许“新鲜”这次词只是针对现在的自己。
在此文开始之前，我想我必须得先感谢两个博客，它们在我学习的过程中，给了我很大的帮助。它们分别是：
本文是对Git中常用的知识点的整理和归纳，并非是全面介绍Git如何安装及使用的文章，如果有兴趣了解更多关于Git的知识，可以阅读上面两个博客以及Git官方帮助手册。
1. Git是什么?
简单的说，Git是一个分布式版本控制系统，个人感觉对于SVN，Git最大的优势在于分支的创建和管理，以及基于分支的工作流。
至于Git号称的分布式管理，由于本人工作和实验的环境限制，对其体会尚浅，就不去描述了。
2. Git常用命令
git init：
在当前目录创建版本库。
git add [filename]，<filename2>：
添加指定文件到版本库。filename和filename2为希望被添加的文件名，可以一次性添加多个文件。
git commit <-m “message”>:
提交文件到版本库。-m 表示后面为本次提交的说明。
git status：
查看版本库状态。
git diff [filename]：
查看文件具体修改的地方。
git log:
查看日志记录。
git reset <–mixed | –soft | –hard> [id]：
版本回退，id为希望回退到的版本的ID，根据不同的参数，回退的方式也不一样，默认为–mixed。
git revert：
撤销提交。
git rm：
从版本库移除文件。
git branch：
命令后面添加以下参数，可以实现不同的分支逻辑，如果什么参数都不加，则会列出所有分支。
-v：查看每一个分支最后一次提交。
[branchname]：创建一个分支
-d [branchname]：删除指定分支。
git checkout：
切换到一个分支。
git merge：
将指定分支合并到当前分支。
git fetch：
从远程仓库获取代码到本地。但并不对本地代码做任何更改。
git pull：
从远程仓库获取代码到本地，并和本地代码合并，相当于 fetch + merge。
git push：
将更改推送到远程仓库。
git clone：
更具URL获取一个远程仓库的副本到本地。
3. Git工作流分类
Git工作流分为以下几种：
集中式工作流：类似SVN，以中央仓库为核心，修改前先获取中央仓库代码，修改后提交代码到中央仓库。
功能分支工作流：基于集中式工作流，但是在该流程中按照功能创建分支。最后通过Pull Request再将分支合并到中央仓库。
Gitflow工作流：在功能分支工作流的基础上，对围绕项目发布建造了严格的分支模型。更加适合用于实际项目的管理。
Forking工作流：分布式工作流，可以有多个远程仓库副本，通过Pull Request合并代码。是Git的精髓，但学习曲线比较陡峭。
4. Gitflow工作流
基于我的体会，这里着重介绍一下Gitflow工作流，本人认为这是一个无论项目大小都可以广泛运用的工作流程，适合不同规模的开发团队。
Gitflow工作流如上图所示，其中Master和Develop为必要分支，这里先说说各分支代表的含义。
Master： 主分支，项目的基础，首先一个项目必须有一个Master分支，项目的发版都应该出自Master分支。
Develop：开发分支，由Master分离出来，并最终合并回Master分支去。此分支承担测试，bug修复，文档生成和其他面向发布的任务。
Feature：功能分支，由Develop分离出来，并最终合并回Develop分支去，此分支承担开发和单元测试的任务，如新特性的开发和维护开发等。
Release：发布分支，由Develop分离出来，承担发版前的测试任务和Bug修复任务，如集成测试，回归测试等，当测试和修复任务完成后，此分支需要合并到Master分支，同时合并回Develop分支，以支持下一次的迭代开发。
Hotfix：热补丁分支，一个短暂的临时分支，由Master分离出来，并最终合并回Develop和Master分支去，用于修复紧急或重大的bug。
说完分支含义后，以实例分阶段描述一下从立项到迭代的过程。
1） 立项：在项目开始之初，有项目经理或其他相关角色建立Master分支，此时Master分支应该是一个干净的初始的状态。同时从Master分支分离出Develop分支，以备开发使用。
2）开发：一般是按功能对需求进行拆分，每一个功能对应一个Feature分支，每一个分支都是基于Develop分离处理，如果前后Feature存在依赖关系，那么Feature分支从Develop分离出来的时间将有所不同。如果User Management的Feature分支依赖于Sign In 的Feature分支，那么User Managerment分支应该在Sign In分支合并回Develop分支之后，再进行创建。每一个功能完成后，将对应Feature分支合并回Develop分支。
3）测试：针对每一个发版计划，建立不同的Release分支，一个Release分支代表一个版本，在某一个版本的开发计划完成后，基于Develop分离创建出Release分支，并在此基础上进行测试和Bug修复，完成后，发布Pull Request，请求将合并回Master分支，由Master分支的代码完成编译和版本发布。同时也需要发布Pull Request，请求将合并回Develop分支，以便进行下一次迭代开发。在Release分支完成并合并回Master和Develop分支后，删除该分支。
4）-1 热补丁：当发布出去的版本遇到致命问题或者需要紧急修复的问题时，为了不打断当前开发进度，应当建立Hotfix分支，用于进行问题修复，问题修复完成后，将此分支合并回Master分支和Develop分支。在问题修复并将代码合并回Master和Develop分支后，删除该分支。
4）-2迭代开发：当完成版本发布后，由Develop分支分离出新的Feature分支，进行迭代开发。
