Git是一个分布式版本控制工具。在现代的项目开发中常用于管理软件或者其他开发相关资料的的版本变更。历史上有很多个版本控制软件，但是截至今日对于开发者较为常见使用的就是Git、SVN这些（还有一些商业使用的例如Mercurial，由于笔者不怎么涉及这个所以在此略过）。对于软件工程师涉及的代码编写都是通过Git进行管理，但是对于一些开发的相关文档资料例如设计的UI UE图片、设计文档等这些都是通过SVN进行管理。对于使用SVN好过git的原因主要可以总结以下几点 1.涉及大量图片频繁变更的场景。这种场景下SVN库的体积远比Git小，这里主要涉及底层对于差异文件的处理，感兴趣可以自行搜索 2.SVN可以通过工具快速操作，相比较Git使用场景更加快捷。程序员使用场景中大部分都是通过开发工具本身进行Git操作，SVN场景的管理场景都是通过SVN命令行工具一键同步。此外相比较Git，SVN使用时候大部分都是单个人提交多人拉取更新，Git则是多个人提交，多个人拉取更新。这种场景下Git大部分的命令实际上都是没有使用到的。 3.权限管理上，SVN可以针对目录进行权限管理，这就可以天然的解决多个资源目录分配不同权限的场景，但是Git目前还不支持目录级的权限管理。虽然可以通过Repo等工具达到类似目录权限管理的效果，但是不如直接使用SVN方便。 上面简单讨论了Git和SVN的差异，主要目的只是想阐述虽然本文讨论的是Git，但是SVN在一些场景下使用起来会更好，大家在学习或者使用某项技术同时也应该从更高层面思考一下工具存在的必要性。
1.Git代码分支需求
Git代码分支也是随着项目开发团队以及实际项目复杂度变化而变化，场景主要有以下几个场景
1.1个人学习开发
如果说只是一个人用于学习开发，那么实际上Git分支没有太多存在的必要性。直接本地每次添加修改然后通过master推送到远程仓库同步就行了。不仅可以记录自己每次提交的文件修改还可以通过远程仓库实现文件备份。这种场景不涉及多人开发以及产品测试、部署、交付以及客户现场紧急更新的场景，Git高级一点的技巧都是可以不用关注。这种场景较少，常见于一些个人开发者，以及用于递增文本类相关项目开发（例如统计其他开源项目的）
1.2小团队项目
如果是小团队的开发项目，且功能开发都是处于线性开发模式，那么日常只需要在代码仓库维护develop分支和master分支即可。develop分支用于开发、测试以及预部署。master用于制作正式部署或者发布的软件。这里提到的develop和master分支只是用于简称开发分支和发布分支（或者称为稳定分支），实际可以用任何你们喜欢的名字。对于一些项目可能存在需要紧急处理的线上反馈问题，这种场景下还会有hotfix分支存在，目的就是基于特定的master分支创建hotfix分支，在hotfix分支上完成问题修复和问题验证，并在后续将hotfix修复同步到develop和master分支，并给予master分支创建新的软件提供给客户或者线上部署。 首先想先聊一下为什么会有develop分支和master分支，从实际代码开发角度，master就是一个当前集成了所有稳定功能可以用于发布部署的软件版本，develop就是一个开发分支用于承载当前最新代码。日常开发代码都是应该直接在develop上进行开发，只有当develop分支代码完成所有测试以及功能问题修复验证后才能允许将develop合入到主分支。master分支一方面是用于合入稳定功能开发，另外一方面是用于发布部署。也就是说所有的开发部署都应该基于master分支进行。 这里就有一个疑问，能不能不用develop分支，直接在master分支上进行开发呢？先说结论，从规范上不建议，从功能实现上可以这么做。代码直接提交到master进行开发提测，测试通过后经过评估可以发布的软件直接在代码库上打上相应的软件版本tag，后续可以基于软件版本tag进行发布部署即可。这种操作模式主要有两个缺点，第一个是master分支的定义变得模糊，因为日常软件开发和软件发布部署都是在这个分支，无法完整的定义该分支到底是用于开发还是发布。第二个是对于打tag需要进行严格限制，只能将tag操作用于发布部署，不能够随意的打tag记录开发进度或者进行其他标记操作。
1.3中大型项目管理
上面提到的小团队项目管理有一个预先定义的约束，就是项目开发是一个线性开发模式，即开发人员开发完一个功能之后，再开发下一个功能，这种开发模式在团队中很常见，但是对于大型项目来说，这种开发模式并不适合，因为中大型项目开发过程中，一方面多个功能开发会并行而不是串行，此外不同的分支需要更加细粒度的权限控制。比如一些同事只允许使用特定分支进行开发而不允许参与合并代码，并且不同的特定分支需要隔离不同的开发人员。这种场景下，原先的master+develop的分支开发就不太合适了，不太合适主要是在以下几个方面，第一个是多个团队会同时在develop上开发，会导致带来很多的冲突提交并导致develop软件迟迟无法用于构建软件，每天需要花费大量的精力在开发之外的工作，效率会变低。第二个就是develop分支会因为多个项目并发导致迟迟不能提供一个稳定测试的版本用于合入master，试想你只是改了其中一个配置项，但是由于其他项目的并行开发导致需要等待其他项目开发完成稳定后才能一并合入到master分支。从软件开发的扩展性角度来看扩展性较差，不能及时的响应需求变更。 针对这类场景，也是需要今天我们提到的更近一步的主流代码分支管理思路，主要是Git flow、GitHub flow、GitLab flow。可以参考下一篇内容
