git常用分支管理

常用分支建议

前面简单讲了下代码提交流程，但是版本控制并不是简单代码提交就完事了，这里分享一些常用的分支开发，但并不是任何项目都一定按照这种分支结构来定义，按你的需求来确定需要哪些。比如你一个人开发一个小型项目，那么就不用搞的那么复杂，如果是多人协同开发版本迭代较快，那么下面的分支内容会让你开发节奏更清晰合理！

生产分支（master）‌

master分支是仓库的主分支，也有人叫production分支，这个分支包含最近发布到生产环境的代码，最近发布的release， 这个分支只能从其他分支合并，不能在这个分支直接修改‌

master 分支一般由release、develop以及hotfix分支合并，任何时间都不能直接修改代码

开发分支（develop）‌

这个分支是我们的主开发分支，始终保持最新完成以及bug修复后的代码.

包含所有要发布到下一个release的代码，这个主要合并与其他分支，比如feature分支‌

一般开发的新功能时，feature分支都是基于develop分支下创建的

补丁分支（hotfix）‌

当我们在生产环境发现新的Bug时候，我们需要基于master分支创建一个hotfix分支，然后在hotfix分支上修复bug

完成hotfix后，我们要把hotfix分支合并回master和develop分支‌，所以hotfix的改动会进入下一个release

发布分支（release)‌

当你需要发布一个新功能的时候，要基于develop分支创建一个release分支

在release分支做为基准进行测试并修复bug，完成release后，把release合并到master和develop分支‌

release 分支为预上线分支，发布提测阶段，会release分支代码为基准提测

功能分支（feature）‌

feature分支主要是用来开发一个新的功能，一旦开发完成，我们合并回develop分支，然后提交合并请求到 release 分支进行提测。

分支命名: feature/ 开头的为特性分支， 命名规则: feature/user_module、 feature/cart_module

Git工作流

上面那么多种分支类型，而且不同的分支又是基于其他分支，每次看完之后都记得，但是结合起来发现仅仅停留在有印象，是的，我们不好从单纯的文字上理清分支之间的关系和合并方式。

没关系，小许用个图把之间的关系梳理清楚：

其实核心是要弄明白主干和各个开发分支的关系，以及你的开发分支该和谁去合并。

不过还是那句话根据自己的项目和业务团队去指定Git工作，不能为了更风去创建并不适合团队的分支，不然会导致开发在无聊的敲命令，花费时间在各种分支的合并上，反而降低了效率。

适合别人的未必适合大家，互相交流，选择合适自己的！

更多方位的流程，大家可以看看这篇文章【字节研发设施下的 Git 工作流】