（Git）Git的工作流

上一篇：习Git（分布式版本控制工具）的第四天

前言

日期：2020/05/01
心情：😄😄😄
Description：学习到这里的朋友们，基本上Git的基本运用已经都讲到了，剩下的就是大家，还有我自己不断磨合（实战）开始累积经验了（就是打怪升级了哈哈）😂😂😂。接下来我们来了解一个Git的工作流概念，那么为什么不一开始就说呢，是因为如果对不了解Git的操作，和Git的使用可能会听不懂吧。

---

---

9. Git的工作流

9.1 工作流的概念

在项目开发过程中使用Git进行版本控制的具体方式.

9.2 分类

9.2.1 集中式工作流

类似SVN,集中式工作流以中央仓库为项目所有修改的单点实体.所有修改都提交到Master分支上.这种方式几乎和SVN一样,主要的区别在于开发人员有本地库.Git的很多特性没有被使用到

9.2.2 GitFlow工作流

GitFlow工作流通过为功能开发,发布准备和维护升级都设计了独立的分支,让整个项目各个阶段的迭代过程更为流畅,严格的分支模型也为大型项目提供一些必要的结构.

9.2.3 Forking工作流

Forking工作流是在GitFlow基础上,使用Git的Fork和Pull Request的功能,以达到代码审核的目的.更适合安全可靠的管理大型团队的开发者,并且可以接受团队外的开发人员提供的代码

9.3 GitFlow工作流详解

9.3.1 分支种类

• 主干分支 master
  负责管理运行生产环境的代码.永远保持与正在运行的生产环境一致.

• 开发分支 develop
  负责管理正在开发过程中的代码,一般情况下应该是最新的代码

• Bug修复分支 hotfix
  负责生产环境下的紧急修复代码.从主干分支分出,修复完毕并测试后,再并回主干分支

• 准生产分支release
  较大的版本变更上线之前,从开发分支上分出一个准生产分支,进行最后阶段的集中测试.测试通过后,会合并到主干分支完成上线.主干分支运行新版本一段时间后发现稳定,可以考虑删除准生产分支

• 功能分支 feature
  负责独立功能开发代码的管理.开发完成一般会合并到开发分支上.

9.3.2 GitFlow具体操作演示

• Git-Project02(例子)操作步骤:
  1.通过clone 或者 pull执行使用远程库的最新版本,初始化项目和本地库.
  2.使用master分支创建一个新的分支
  
  
  3.在新创建的分支上,编写或者修改代码后,添加到暂存区,在提交到本地区后.是不会对其他分支的代码造成影响的
  
  4.功能发开完成后,将新分支的内容push到远程库中（略）.

---

• Git-Project01（例子）的操作步骤:
  1.通过pull指令获取远程库中master分支的最新版本
  2.在获取develop分支的最新版本
  
  
  3.查看新分支中的代码,如果检查通过.切换回master分支,在本地完成分支合并
  
  
  4.将合并后的内容通过push指令推送至远程库（略）.

---

---

---

总结：
请牢记，当你做这么多操作的时候，这些分支全部都存于本地。 当你新建和合并分支的时候，所有这一切都只发生在你本地的 Git 版本库中 —— 没有与服务器发生交互。
好了，这篇文章加上前面4篇文章就是Git的所有内容了。剩下的就是在使用期间遇到的问题，如果有，也可以跟我分享分享，我会尽我最大努力来帮助你的！！！
大家多多关注我啊！！带你学习，一步步走上用编程恰饭的道路！！！加油！奥利给！😄😄😄