背景

从一开始的svn到后来接触到git，到目前已经和git打交道比较多了，突然觉得可以把项目中所用到一些分支的管理方式分享出来，希望帮助到大家。

分支介绍

现在使用git一般很少是单个分支来使用，通常是多个分支来进行，接下来我以我最新的项目中所用到的分支，来做一些介绍。

master：

• master分支代码只能被release分支分支合并，且合并动作只能由特定管理员进行此操作。
• master分支是保护分支，开发人员不可直接push到远程仓库的master分支

release：

• 命名规则：release/*，“*”一般是标识项目、第几期、日期等
• 该分支是保护分支，开发人员不可直接push，一般选定某个人进行整体的把控和push
• 该分支是生产投产分支
• 该分支每次基于master分支拉取

dev

• 这个是作为开发分支，大家都可以基于此分支进行开发
• 这个分支的代码要求是本地启动没问题，不影响其他人的代码

hotfix

• 这个分支一般是作为紧急修复分支，当前release发布后发现问题后需要该分支
• 该分支一般从当前release分支拉取
• 该分支开发完后需要合并到release分支以及dev分支

feat

• 该分支一般是一个长期的功能需要持续开发或调整使用
• 该分支基于release创建或者基于稳定的dev创建也可以
• 一般开发完后需要合并到dev分支

分支使用

以上是简单介绍了几个分支，接下来我针对以上分支，梳理一些场景，方便大家理解。

首先从master创建一个release分支作为本次投产的分支，然后再从master拉取一个dev分支方便大家开发，dev分支我命名为:dev/soe,然后我就在这个分支上进行开发，其他人也是这样。

然后当我开发完某个任务后，又有一个任务，但是呢，这个任务需要做，只是是否要上这次的投产待定，所以为了不影响到大家的开发，我就不能在dev分支进行开发了，此时我基于目前已经稳定了的dev分支创建了一个feat分支，叫做：feat/sonar,主要是用来修复一些扫描的问题，在此期间，如果我又接到了开发的任务，仍然可以切换到dev来开发，并不影响。

当开发工作完成后，并且也基于dev分支进行了测试，感觉没问题之后，我就会把dev分支的代码合并到release上。

当release投产之后，如果业务验证过也没有问题，那么就可以由专人把release合并到master了，如果发现了问题，那么此时就需要基于release创建一个hotfix分支，开发人员在此分支进行问题的修复，修复完成并测试后，合并到release分支和sit分支。然后再使用release分支进行投产。

总结

以上就是我在项目中，对分支的使用，我觉得关于分支使用看团队以及项目的需要，不必要定死去如何如何，如果有的项目不规定必须要release投产，那么hotfix就不必使用，直接release修改完合并也未尝不可，所以大家在项目中是如何使用的呢？可以评论区一起讨论分享。

致谢

感谢你的耐心阅读，如果我的分享对你有所启发或帮助，就给个赞呗，很开心能帮到别人。