为什么使用Git
“svn用了这么多年都好好的，为啥折腾搞Git？”
“Git一点都不好用，提交个代码都提交不上去！”
“Git这么复杂，命令多到记不住，而且完全用不到。哪有svn简单好用？”
推销任何一种新事物，无论新事物本身是否先进，最能打动客户的一点就是，能否解决客户的痛点，能否给客户带来价值。
拿软件开发过程来说，项目团队关注项目版本的可控性，包括对多个版本的开发、构建、测试、发布、特性等管理；关注持续集成的效率等；开发团队关注代码管理、回溯、合并的可控性；关注开发协同等；
在svn（目前在用的版本管理工具）的上述痛点，Git都能很大的解决或改善。推广Git，背后的目的就是提高项目产品的质量和团队开发的效率。当然，任何收益都有代价，在支持如此多的特性的同时，Git的使用复杂度也势必增加。
本文侧重讨论Git在团队的推广，所以首先回答一下，相较于svn，Git给开发中个人和开发团队带来的价值：
- 对于开发者，可以随时提交修改到本地仓库，方便代码修改查看，回滚，终结svn时代开发阶段无代码管理工具、代码管理混乱的窘境，提高个人代码管理效率。
- 如果一个功能需要尝试多种方案进行对比，开发者可以通过本地分支对多个方案代码进行修改、对比、查看等管理，终结svn时代手动备份代码的远古习惯，提高个人代码管理效率。
- 如果一个功能需要多人协同开发，可以通过Git分支协同开发，驱散自己搭svn服务器、建svn仓库、代码手动同步的苦闷，提升团队协同开发效率。
- 如果这些都没有打动你，那还有最后一点：全世界都在用Git，作为基本技能的Git你都不会的话，以后找工作都困难哦。
团队级Git分支模型
Git本身并没有推荐的最佳实践，但有很多非官方的最佳实践总结，比如这篇《一个成功的Git分支模型》，这个分支模型贯穿整个产品的生命周期，为整个产品项目服务。这个模型过于复杂，特别是对于特性团队级的Git来说，有点重了。
团队的Git分支策略由使用场景、任务特点、开发周期等决定，在团队2年多的Git使用实践中，主要用到了如下三种分支模型：
- remote/master
- remote/master, remote/dev
- remote/master, local dev
分支详情展示：
[email protected]:~/healthcheck$ git br -a * master remotes/origin/master
这个分支模型只有master分支。适用于在新团队中起步推广Git，避免使用复杂的分支模型，引起程序员心理不适。而且对于不需要协同开发的任务，这个分支模型也够用了。
[email protected]:~/sc/robot_framework$ git br -a develop * master remotes/origin/develop remotes/origin/master
这个分支模型有master和dev分支，master分支是稳定版本分支，用于每日自动化测试的持续集成，要保证功能稳定。dev分支是开发分支，用于新特性开发和协同开发需要。
[email protected]:~/sc/ci$ git br -a * alex_dev master remotes/origin/master
这个分支模型除了一个master分支外，还有一个未推送的本地dev分支。这种分支模型适用于如下场景：想验证对比多个实现方案，对已有实现采用多种策略进行重构尝试；只想从主分支同步某些合入，避免不相关的同步破坏自己正在开发的功能。
团队级Git工作流程
Git之所以强大，主要来自其复杂的分支模型和分布式策略，这也是其复杂的原因。
Git命令是操作的是Git对象和对象间的关系。所以要掌握Git，理解Git的工作机制，首先要理解Git中的基本对象，比如远程仓库、本地仓库、远程分支、本地分支，暂存区（stage）、工作区（workspace），以及数据是如何在这些对象中流动的。在这基础上，才有可能真正掌握Git。
上图是前面介绍的几种分支模型下的Git工作流及相关命令的总结梳理。
详细的命令讲解这里不再赘述，请读者咨询Google。这里只对几个易混淆的操作命令的区别总结如下：
- fetch只更新local repo，不修改local branch；
- pull更新local branch，pull等价于fetch+merge，pull -r等价于fetch+rebase；
- merge、rebase同时更新local branch、stage和workspace，只是合并策略不同；
- reset更新local branch和stage，不更新workspace；
- checkout更新stage和workspace，不修改local branch
Git推广注意事项
- Git推广中的最大的问题往往是最简单的问题，比如软件安装、兼容。所以最好能提供工具来统一环境，包括操作系统、基础软件、Git版本、Git配置等;
- 提前准备好各系统的安装包、安装说明，方便所有人访问查阅;
- 制定Git使用规范，通过工具，在环境配置、分支管理、提交日志、提交策略做好统一约束;
- 采用适合任务特点和团队的Git模型，不要盲目仿照。
-EOF-