最近也算是把Git相关的知识看了不少了，虽然对于Git的有些命令还是没怎么熟记，对一些更加高级的命令也是没有实践过，但慢慢理解了Git的相关的flow之后，不自然就和以前用过的SVN进行了一些对比，发现Git相对于SVN来说的确有些优势。

在之前的公司里，项目组一直是用SVN来做相关的版本管理的，当然，我这种底层的开发小兵也不需要用到SVN的版本控制层面的功能的。我所能使用的，也就是提交代码，查看提交日志等一些一线开发人员常用的功能而已。当初记得，项目组的SE经常提出新的需求，同时，测试也在不停提出bug修改要求，所以总是把代码一份一份的拷贝到不同的文件夹中，然后对于不同文件夹的代码进行不同的代码功能修复或者开发，最后合并到最初的SVN源码文件夹中。不得不说，这是一种非常原始的方式，但是这是我当时能够最有效的代码控制的方式了，因为经过自己的实践证明，这种方式可以合理规避掉各种的代码覆盖冲突等问题。至今还对于用BeyondCompare一行行比对代码的事记忆犹新啊。

然而，随着了解Git的相关的一些知识后，蓦然发现，原来我使用过的那种原始代码控制方式，已经在Git中完美的实现了(唯一可能不满意就是Git中diff工具没有BeyondCompare那么强大吧，当年一直对于代码冲突导致的文件内容混乱非常反感)。看了不少的关于Git分支管理的布道文章后，加上自己的那套原始的代码控制方式，从而也对使用Git有效管理控制代码有了些自己的见解。

在我看来，我们clone完项目组的代码之后，此时的分支为master，那么我们应该一直保持此分支的干净整洁，不要在master分支上直接进行开发。我们应该在开始一项新的主功能的开发时，从master分支分离出一直develop分支，日常的开发应该在此分支之上。同时，根据的以后的附加功能的需要，我们应该考虑是从master分支分离分支开发还是从develop分支分离分支开发，对于bug的修复同样需要如此考虑。当我们开发完成该项主功能后，应该清理干净从develop分支上分离的各个分支，然后保证develop分支干净后，将其合入最新的master分支，最后将最新的master分支push到远程仓库中。另外，在整个开发过程中，对于master分支我们时常保持其最新程度，要时常更新master分支上的代码，这样可以便于我们同其他开发者的同步，也减小了覆盖别人代码的几率。