一般来讲，系统代码需要经过研发、测试、生产三种环境。那么在Git上如何管理分支，才不会乱？在线上生产环境有问题时有条不紊的解决。

经过发展，有一个Git Flow原理可帮助解决。设置以下几种分支。

• master——production生产环境。最为稳定功能最为完整的随时可发布的代码；这个分支存放最近发布到生产环境的代码，最近发布的Release， 这个分支只能从其他分支合并，不能在这个分支直接修改。

• hotfix——修复线上代码的 bug；

• develop——永远是功能最新最全的分支；这个分支是我们是我们的主开发分支，包含所有要发布到下一个 Release 的代码，这个主要合并与其他分支，比如 Feature 分支。

• feature——某个功能点正在开发阶段；这个分支主要是用来开发一个新的功能，一旦开发完成，我们合并回 Develop 分支进入下一个
  Release。

• release——发布定期要上线的功能。当你需要一个发布一个新 Release 的时候，我们基于 Develop 分支创建一个 Release 分支，完成 Release 后，我们合并到 Master 和 Develop 分支。

「master」和「develop」是「主要分支」，其他的分支是基于它们派生出来的。
主要分支每种类型只能有一个，派生分支每个类型可以同时存在多个。各类型分支之间的关系用一张图来体现就是：

Git使用规范提醒

• 使用Git过程中，必须通过创建分支进行开发，坚决禁止在主干分支上直接开发。review的同事有责任检查其他同事是否遵循分支规范。

• 在Git中，默认是不会提交空目录的，如果想提交某个空目录到版本库中，需要在该目录下新建一个 .gitignore 的空白文件，就可以提交了

• 把外部文件纳入到自己的 Git 分支来的时候一定要记得是先比对，确认所有修改都是自己修改的，然后再纳入。不然，容易出现代码回溯

• 多人协作时，不要各自在自己的 Git分支开发，然后发文件合并。正确的方法应该是开一个远程分支，然后一起在远程分支里协作。不然，容易出现代码回溯（即别人的代码被覆盖的情况）

• 每个人提交代码是一定要 git diff 看提交的东西是不是都是自己修改的。如果有不是自己修改的内容，很可能就是代码回溯 review

• 代码的时候如果看到有被删除掉的代码，一定要确实是否是写代码的同事自己删除的。如果不是，很可能就是代码回溯

www.cnblogs.com/kevin-ying/p/14329768.html
https://segmentfault.com/a/1190000004992316
https://ourai.ws/posts/working-with-git-in-team/