通常，我们的项目在进行多人开发的时候，会创建多个分支。
master分支(主分支)：
作为主分支，通常该分支上的代码是最稳定的，与服务器上的代码保持一致，服务器发布线上代码，每次拉取master分支。
dev分支(开发、测试分支)：
dev分支可以作为一个开发分支，有需要上线的代码，在本地开发好后，提交到dev分支进行测试，测试通过后，可以 把dev分支的代码合并到master分支，执行上线操作。
feature分支(功能分支)：
feature分支分为功能分支，可以不推送到远程，在本地开发一个临时的功能，功能开发完程，把该分支的代码合并到dev分支测试，测试通过，合并到master分支。
feature分支功能上线后，该分支就不再用到，可以在本地将该分支删除。
通常feature以要开发的功能命名，如feature_login、feature_register等等…

以上几个分支是最简单也是最常用的分支创建策略。
在实际的项目中，可能还会存在：
release分支：这个分支的内容与master保持一致，通常用来模拟线上环境，用作代码预发布的一个版本，也可以理解为线上环境的一个仿真环境。
hotfix分支：这个分支作为线上环境的临时bug修复分支，通常用于修复线上问题的紧急bug，当修复完成后，直接合并到master分支，发布上线。

上面的分支创建策略是最简单也是最常用的分支策略模型。
我们再来看另一种分支策略：
master分支：主分支，用于线上分布代码的分支。
dev分支：开发分支，这个分支包含了所有功能的代码，每个人开发的代码都可以合并到dev分支，在dev分支上进行测试
feature分支：功能分支

分支合并流程：
feature_login分支：用于编写用户登录的分支
feature_register分支：用于编写用户测试的分支
feature_xxxx:其它功能分支

feature_xxx_yyy_zzz这些功能分支可以随时合并到dev进行测试，测试通过后，确定该功能可以发布到线上，如feature_login分支。

此时，将feature_login分支直接全并到master分支发布。

第二种分支策略的好处是，可以随时决定哪个分支的代码可以发布到线上。
第一种分支的缺点是，需要开发人员确定没有达到上线标准的代码，就不要提交到dev分支，因为发布代码的时候，会将dev分支合并到master上，但这种分支合并策略比较简单，也更容易理解。
具体采用哪一种分支策略，还是需要根据项目的实际情况来决定。