汗颜，之前的大项目团队合作都是用svn，之后在搞休闲游戏的时候虽然也用到了git，但都是单兵项目组，所以就非常矬的把git当svn用了。。。。。。
现在鉴于项目原因，不能再这么稀里糊涂下去了，git要认认真真的用起来，从gitflow走起。
先回忆一下集中式工作流
这里就不再赘述svn和git的对比评测了，如果git不完胜svn的话，我就不写这篇文章了，你说呢。
下面请出今天的主角Gitflow
如果这张图看的丝毫没有压力，请移步原文A successful Git branching model
不如我们把她旋转一下
这样是不是更好理解了？
- 相对使用仅有的一个master分支，Gitflow工作流使用2个分支来记录项目的历史。master分支存储了正式发布的历史，而develop分支作为功能的集成分支。
这样也方便master分支上的所有提交分配一个版本号。 - 每个新功能位于一个自己的分支，这样可以push到中央仓库以备份和协作。
但功能分支不是从master分支上拉出新分支，而是使用develop分支作为父分支。当新功能完成时，合并回develop分支。
新功能提交应该从不直接与master分支交互。 - 一旦develop分支上有了做一次发布（或者说快到了既定的发布日）的足够功能，就从develop分支上fork一个发布分支。
新建的分支用于开始发布循环，所以从这个时间点开始之后新的功能不能再加到这个分支上——
这个分支只应该做Bug修复、文档生成和其它面向发布任务。
一旦对外发布的工作都完成了，发布分支合并到master分支并分配一个版本号打好Tag。
另外，这些从新建发布分支以来的做的修改要合并回develop分支。
使用一个用于发布准备的专门分支，使得一个团队可以在完善当前的发布版本的同时，另一个团队可以继续开发下个版本的功能。 这也打造定义良好的开发阶段（比如，可以很轻松地说，『这周我们要做准备发布版本4.0』，并且在仓库的目录结构中可以实际看到）。 - 维护分支或说是热修复（hotfix）分支用于生成快速给产品发布版本（production releases）打补丁，这是唯一可以直接从master分支fork出来的分支。
修复完成，修改应该马上合并回master分支和develop分支（当前的发布分支），master分支应该用新的版本号打好Tag。
为Bug修复使用专门分支，让团队可以处理掉问题而不用打断其它工作或是等待下一个发布循环。
你可以把维护分支想成是一个直接在master分支上处理的临时发布。
估计现在大家已经大概明白了Gitflow的方法，那么下面给大家再看一张图，猜猜这是什么工作流？
？？？？？？？？？？？？？？？？？？？？？
上图叫Forking工作流
在github上贡献过代码的同学肯定都会知道。
Forking工作流的一个主要优势是，贡献的代码可以被集成，而不需要所有人都能push代码到仅有的中央仓库中。
开发者push到自己的服务端仓库，而只有项目维护者才能push到正式仓库。
这样项目维护者可以接受任何开发者的提交，但无需给他正式代码库的写权限。
效果就是一个分布式的工作流，能为大型、自发性的团队（包括了不受信的第三方）提供灵活的方式来安全的协作。 也让这个工作流成为开源项目的理想工作流。
提个问题
我们都知道svn里的add命令，那git为何每次commit之前都需要add一次，这背后究竟做了哪些处理？
|
|
|
|
|
|
|
好了，看图说话，add背后的秘密竟然是这个。。。
光是暂存区这个概念就可以甩svn十几条街了，暂存区带来的好处大家在日后使用中慢慢感受吧。
