git的版本控制流程-Toy模板网

这篇具有很好参考价值的文章主要介绍了git的版本控制流程。希望对大家有所帮助。如果存在错误或未考虑完全的地方，请大家不吝赐教，您也可以点击"举报违法"按钮提交疑问。

git的版本控制流程,git

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

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

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

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

git的版本控制流程,git

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

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

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

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

git的版本控制流程,git

merge操作后：

git的版本控制流程,git

rebase操作后：

git的版本控制流程,git

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

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

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

首先有四个特性分支：

git的版本控制流程,git

当开发新功能时从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在小组工作内是需要组长审批的）