git分支管理
使用 git 进行源代码管理，一般将某个项目的所有分支分为以下几条主线：
管理角色
每个仓库的使用者都应该对应一种角色，通常分为两种：
- 开发者
- 管理者
不同的角色使用分支的权限不同，可执行的操作也不同
长期分支
- 主分支：
master - 开发分支：
dev
master 主分支
存放的应该是随时可供在生产环境中部署的代码，当开发活动告一段落，产生了一份新的可供部署的代码时，master 分支上的代码会被更新。同时，每一次更新，都有对应的版本号标签（TAG）。
- 提交代码：不可直接更新代码提交，代码来自于
dev、test和hotfix分支的合并，供发版使用。 - 生命周期：伴随着整个项目的生命周期，项目结束时结束。
dev 开发分支
dev 分支是从最新的 master 分支派生的共有开发分支。当 dev 分支上的代码已实现了软件需求说明书中所有的功能并进行了本地调试，合并至master分支。
- 提交代码：不可直接更新代码提交，代码来自于
feature、hotfix分支的合并，供本地调试bug使用。 - 生命周期：从
master分支派生出本分支时开始，开发完成后合并至master分支时结束。
短期分支
假设一个版本可以顺利的开发，作为开发者在dev开发提交，当进行到某个提交测试通过后，将dev合并到master，打包发布，即为新版本上线。
但是实际无可避免的出现其他情况：
只上线当前版本的部分功能
若按照之前的开发方式，所有的提交都在
dev里面了，只上线其中部分功能怎么可能？所以有了功能分支：feature功能分支：
feature：- 不再在
dev上直接提交代码 - 基于线上版本
tag检出，feature分支开发完成后直接合并至dev - 只合并需要上线的
feature分支至master，暂时忽略不需要上线的feature，需要上线的时候再合并至master
当需要合并曾经开发完毕的
feature到dev时，在feature分支使用git rebase [tag]完成分支的更新，再合并至master。- 不再在
上线的版本出现了
bug和
feature分支类似，若只在dev上开发，发现线上环境有bug时，dev环境已经开发过半了，代码已经有了很大改动，若在dev修复，合并至master很有可能带上dev的代码。此时需要补丁分支：hotfix补丁分支：
hotfix：- 不在
dev上修复，基于线上版本tag检出 - 修复后合并至
master，上线修复版本 - 可视为下一版本的
feature分支，合并至dev，下版本就不再考虑需不需要合并至master
跟
feature分支的唯一区别是，修复后直接上线- 不在
需要更多环境
dev分支的代码始终是最新的，master是最稳定的，需要一个分支来供测试，上线前也需要一个预发布版本测试分支：
test，预发布分支：release：feature合并至master前，先合并至test，测试通过后，再从test合并至master- 将所有
master的分支操作前移至test，上线时再合并至master - 在
master和test之间可以有很多个环境分支供不同环境使用
记录版本号
合并至
master后打包发布，视为新版本上线，但是提交多了就会忘记哪个提交对应的哪个版本上线，这时可使用git tag v1.0.0为提交添加版本号。查看历史时即可清晰的看到对应的版本。修复
bug，也应该添加对应的版本tag
分支命名规范：
- 开发分支：
dev、develop - 测试分支：
test - 生产分支：
master、prod、production、release - 功能分支：
feature/video-20231027 - 补丁分支：
hotfix/style-20231027
其他问题
1.、两个功能分支的合并至dev、master时存在冲突
只要是合并，冲突肯定是有可能的，都是要去解决冲突，跟合并的方式无关
2、使用了feature后不能再使用dev直接合并至test或者master了吗？
一般情况下，该版本全部上线，dev直接合并至test没有任何问题
只有当所有的feature合并至dev进行测试，发现某个功能不能上线时，dev就不能直接合并至test了，但是实际可以通过revert等方式将dev恢复至上版本状态，再重新选择对应的feature合并，即可将dev直接合并至test。
revert这种方式是个人推荐的方式，因为重新合并后，可以在dev进行重新测试后再合并至其他分支，减少出错的概率，也可以应对到test合并到master时出现的类似情况