git的版本控制流程，特性分支之间怎么切换

在开发中，有四个特性分支dev、test、pre/release、master

dev：开发环境，从feature去merge
test：测试环境，从feature去merge
pre：预生产环境，从master去merge,为了验证master代码
master：生产环境，从feature去merge
feature：开发分支——小功能创建的时候，从master拉取
hostfix：bug修复分支，从master拉取

• 开发新功能要在原来的代码基础上进行修改，所以从master拉取并创建一个分支（feature_20230301），此时master和分支feature_20230301的代码是一样的。

• 接着开发新功能，在分支feature_20230301上进行开发，此时分支feature_20230301与master的代码不再相同。

• 开发完新功能后，将分支feature_20230301去merge到dev分支，此时的代码就到达了开发环境。进行自测，若是没问题，就可以让test测试环境进行测试。

• 分支feature_20230301去merge到test分支，若是测试环境进行测试后也通过，那么将分支feature_20230301去merge到master。

• master去merge到pre分支，进行预生产，这样master就可以在pre分支进行验证（这样为了保证 ：我的master分支是测试过的），验证没问题后提交到生产。

• 在生产时，当master出现问题，拉取并创建一个分支hotfix进行修复 ，修复后直接合到pre分支，pre分支再合到master。（不属于需求）

开发环境——>测试环境——>预生产环境——>灰度测试（生产环境小部分人可以体验)）——>生产环境

---

一些要注意的git小知识

1. git merge 和 git rebase，强制要求使用git rebase，这样分支管理比较清晰。

2. Commit的时候，只提交要给别人看到的，要检查改动是否正确。

3. 没有commit文件就切换分支，改动会被带过去;

若是commit了文件，那么切换分支，改动不会被带过去。

4. 所有的特性分支，不允许push。

可以push的分支只有feature分支，方便代码review；

merge需要审批，方便代码review。

---