git的版本控制流程

1、git是一款版本控制工具

例如我们常用的淘宝，每次升级，版本号就会加一。那么我们怎么控制版本号呢？ --使用git。

2、最常使用的git指令

git add . 暂存
git commit -m"***" 提交到本地
git pull 将远程仓库代码下拉到本地
git push 提交到远程仓库

不建议使用【Git Bash】中去输入指令，使用idea 中以及集成好的三个按钮更加快捷方便。

从左到右依次是【git pull】拉项目、【commit】暂提交到本地、【git push】提交到远程。

注意：使用最左侧git pull拉项目时，会有Merge和Rebase两个选项，更推荐使用Rebase。Rebase的分支管理比较清晰。

merge:将在子分支的所有提交记录成一次commit，保留在记录中。（下图的E即为该记录）

rebase:不会保留commit记录，直接将分支中的内容排到master的记录之后。

merge操作后：

rebase操作后：

git Merge 和 git Rebase比较

1. git merge 是将当前分支的提交放在merge分支的前面，而igit rebase是将当前分支的提交放到reabse分支的后面
2. git merge会在最后增加一个merge的提交记录，而git rebase不会额外增加提交记录
3. git merge合并之后提交记录是非常复杂的，而使用git rebase合并之后提交记录是线性的
4. 使用git merge合并之后就不能再回退自己的提交代码了，如果回退则会降merge的内容一同回退了，而git rebase在合并之后可以继续回退自己的提交，而从rebase合进来的代码不受影响
5. 很明显，dev开发分支适合使用git rebase，r而master主分支则非常适合git merge
6. master主分支如果使用git rebase的后果是改变了提交历史，比如多人合作时后使用rebase的必须将前面使用过rebase的代码合到自己的前面，导致跟拉出来分支的时候提交历史不一样了，从而会带来各种比较痛苦的提交体验

3、切换分支

当我们本地有文件没有commit，去切换分支的时候（弹框选择Smart Checkout），这笔改动不会因为切换分支而变化。也就是说如果在没有提交的情况下切换分支，你写的东西不会改变。但如果你已经提交了这次改动，那么切换分支后被改动的地方就会切换成新分支的内容。

4、git版本控制流程

ci/cd是大多数公司选择的一套开发流程。

首先有四个特性分支：

• dev分支，对应开发环境（属于程序员开发的，怎么折腾都没事）
• test分支，对应测试环境
• pre/release分支，对应预生产环境
• master分支，对应生产环境

• 当开发新功能时从master拉取并创建一个以feature开头的新分支，例如叫做feature_20230301，这时代码与master相同，在此基础上进行开发。
• 开发完之后将feature代码merge到dev分支，此时代码便处于开发环境。
• 如果此时代码自己测试没问题，就将feature代码再merge到测试环境下，交给测试去测。
• 测试环境通过后才能将feature代码merge到master分支。
• 再将master代码merge到release预生产，这时你的代码就到达了预生产阶段，而这样做能够使预生产部署的代码来自master分支。
• 当预生产验证没问题后就可以发布到生产了。

当开发下一个功能时再次从master拉取新分支，重复上边流程，形成一个循环。

注意：

1、所有的改动都是由feature这个小的开发分支去合并。

      为什么不由dev开发分支去合并？

      ----因为可能会出现自测不通过的分支提交到开发分支，那么这笔错误代码就会进入测试环境。

2、所有特性分支不允许push，能push只有feature这个小的开发分支。（方便代码review，merge在小组工作内是需要组长审批的）

hotfix分支

如果master分支去生产了，突然出现异常，需要紧急提一个 hotfix_xxxx 去修复这次报错。接下来按照公司需求，例如直接合并预生产，再合并到master。

总结

dev：开发环境，从feature去merge

test：测试环境，从feature去merge

pre：预生产环境，从master去merge，为了验证master代码

master：生产环境，从feature去merge

feature：开发分支----小功能，创建的时候，从master拉取

hotfix：bug修复分支，从master拉取