公司之前一直使用svn 做代码控制，最近改为git。虽然实施落地有反对的声音，以及在使用中有很多问题，但是整理来说开发更流畅，流程更合理，效率在熟悉后会也会增加不少。
个人意见：
svn操作简单，使用方便，易于理解。流程也可以设置的比较简单，但是分支不如git好用，提交代码必须先update 然后 commit 这使得团队如果比较大，那么提交前很容易冲突。

git有一定的学习成本，整体来说流程较为复杂，主要指的是分支的请求拉取，分支的合并，cherry-pick操作，各个分支的同步（复杂归复杂，但是这些步骤又是合理的），但是因为分布式的，开发可以很方便的创建分支，代码离线查看提交，整个开发流程舒适流畅。

git有多种工作流，可以自行搜索资料
下面是简化了git flow工作流，并针对实际情况提出的一种应用于 web端代码版本控制的使用流程，先看脑图：

使用gitLab 搭建git环境
始终维护三个分支
1.master分支 只有master权限的可以 push 和 merge ，所有的开发以master 分支为基础创建新分支
2.release 分支 用于发布 只有 master 可以push 和 merge
3.hotfix 分支 用于修复紧急bug ， master 和 develop 都可以push merge

大致流程描述：
1.开发根据不同的bug创建以 master为基础的分支，并做开发。开发完成，测试首先测试开发的机器，测试通过，开发创建 merge request 。
2.开发leader 根据实际和code review 结果决定是否同意merge
3.同意merge 测试人员测试master 分支
4.测试通过，等到要发新版的时候，开发leader 将master分支合并到 release 分支，然后做发布前的测试。
注：这里也可以是根据 master 拉取 release 分支，但是我采用的是固定的release 分支，因为之前写好了钩子函数，将每次代码改动都拉到测试环境，脚本指定了 release 分支。
5.发布完成，代码同步给hotfix 分支，打 tag
6.如果有紧急bug 则直接修改hotfix 分支，测试 hotfix 分支代码，测试通过直接上线。
7.bug修复完成后 再将代码同步给 master 和 release分支

下一篇： git 工作流设计分享之git-app
http://blog.csdn.net/m0sh1/article/details/70224977