简单的说，git的管理策略目前有两大流派。平时和同事聊天或和别的公司的朋友交流时也能够感觉的到，即Git One Track和Git-flow。
一个轨道
One Track简单的说，就是整个团队在开发项目时都在同一个分支上进行。这也就意味着开发阶段的所有工作都集中在同一个分支，例如新功能开发、bug的修复。当然，One Track策略并不意味着只有一个分支，而是只有一个开发分支。当达到团队设定的里程碑时，可以开一个新的分支用来维护这个基本稳定的版本，这个维护分支只进行维护的工作，而不进行开发的工作。同时，开发分支继续进行最新的开发工作。
使用这种策略的最大特点就是大家都在同一个分支上工作，因此每次提交代码都有可能会有冲突。为了减少冲突，团队也常常会提高提交的频率，同时每次提交的颗粒度都比较小。同时，管理成本比较低，整个团队的学习成本也比较低。
在我之前的项目中，参与过一个刚从svn切换到git的团队，我们使用过一段时间One Track的工作方式，可以看到这种策略对整个团队接触和适应git还是很有好处的。
但是我相信更多的人还是更推崇另外一种策略，即Git-Flow策略。
gitflow
首先我相信很多人一定在哪里会见过下面这张图：
这张图已经能很好的说明了gitflow了。即任何变更都是一个分支。
可以看到，这张图中的分支虽然很多，但是大体上可以分为两类。即主要分支和辅助分支。
主要分支
主要分支即git默认的mater分支以及一个主开发分支develop。
master分支是git默认的主分支，平时团队不在该分支上进行开发。而主开发分支develop则管理着开发人员提交的代码，当代码稳定时或固定一个周期，将develop分支上的代码合并到主分支。
辅助部门
辅助分支是团队每个开发人员都能接触到的，常见的辅助分支包括：
• 功能科
• 出版公司
• 修理分公司
这三类分支都有其对应的使用场景。
开发新的功能时，需要从主开发分支上创建一个新的功能分支，待该分支上的功能开发完毕之后，再合并会主功能分支。
发布分支则是在版本发布时创建的分支， 按照产品里程碑的需求包括应该完成的功能。
修复分支则是当出现bug时，为了不影响开发分支，因此创建出一个新的分支来修改bug，之后再合并回开发分支。
因此我们可以看到，GitFlow的策略无论是开发功能还是修复bug都是以分支的方式来进行。这样做的好处当然是管理上十分干净。但是由于功能开发时间相对要长、代码提交的粒度相对较大，因此在分支合并的时候有可能会出现冲突的问题，另外一个问题是对整个团队的要求要比One Track策略大。
不过，并没有最完美的方案，有的也仅仅是更适合团队的方案。例如很多团队包括我现在都更喜欢将两种方式混合使用，例如针对One Track都在同一个分支上开发，可能不够干净，我们就可以适当的开一个新的分支也用来开发。针对GitFlow提交合并时代码粒度大、冲突多，我们就每天都同步一次代码而不必等整个功能都完成再合并到主开发分支。
