git使用流程和分支管理规范
什么是git
Git 是目前最流行的开源的代码版本控制工具，用于敏捷高效地处理任何或小或大的项目。
本文主要介绍在多人合作写代码时，在知道项目URL到项目上线，git的标准使用步骤和作者见过的几种变种，以及为什么要使用，在什么场景下使用。适合刚接触git的人观看。
注：本文不涉及git命令的使用介绍。
最简单的方式：所有人写完代码都push到master分支
这也是我们写不用发布的小项目时最喜欢的方式，写代码前pull一下，写完了push一下，遇到冲突删一下，整个项目只有master分支。
存在的问题：
- master分支理论上来说每一次commit后都应该是一个可以运行的正式发布版本，然而上面这种方式master分支一定长期存在bug，或者某次commit后存在完成了一般的功能，甚至不能运行。
- 会有大量冲突，因为经常出现多个人同时改了同一部分代码。
开发与发布分离
为了解决上面的问题，每个开发周期时从master分支新建一个develop分支，大家都在develop分支上开发，这个周期开发完毕后再merge到master分支上，这样master分支的每次更新后都是一个可发布的版本。
存在的问题：
- 依然有大量冲突。
- 如果有人去修改别人写的代码的话，可能在不清楚修改代码的影响时就提交了，然后也没人察觉到。本来项目昨天还运行正常，因为队友的一次commit，你电脑上就不能正常运行了。
为此，又要增加一些分支。下面为各分支的说明。
| 分支 | 说明 |
|---|---|
| master 分支（主分支） | 为稳定版本 |
| develop 分支（开发分支） | 最新开发中版本 |
| release 分支（发布分支） | 预上线分支，提测时，会创建release分支为测试的基准版本 |
| hotfix 分支（热修复分支） | 线上出现要紧急修复的问题时，从master分支创建hotfix分支，写完代码后，合并到master分支和develop分支 |
| feature 分支（特性分支） | 每个新特性新建一条分支，日常开发的代码即commit到这条分支 |
并且在提交merge request后进行code review，防止测试无法发现的bug注入。
git其实有一套标准的分支管理规范，但是实际使用的时候各公司都会根据自身情况有一些变化。下面是作者见过的几种规范。
完整流程
（上面省略了release 分支的创建与合并）
这样每个人都在自己的分支上开发，互不影响，merge时才需要考虑冲突。
存在的问题：
- 如果有某个新特性急需提测上线，也要等到所有新特性开发完毕一起提测上线，不能单独提测上线。
feature分支直接merge到master分支
这种流程新特性可以单独提测发布，但是在第9步时可能出现冲突。
远端fork一个项目到自己名下
fork出来的项目相当于是源项目中长存的自己名下的分支。这种规范下可以避免源项目分支过多，只要管理好merge request就行了。