git项目版本控制流程规范梳理

流程图

git版本控制

常见的分支

master：上线分支，每一个版本需要打上一个tag标签。每一个版本更新的内容可多可细，tag1.2.3，第一位数字1是系统更新的大版本，数字2是更新的大功能点，数字3是可以是优化、可以是修复、可以是小功能点。
develop：开发分支，是当前项目的可进行测试的最新代码，每一次开发人员开发的新功能、bug、优化都需要合并同步更新到develop分支；此分支也是测试同学测试功能的分支。
功能A（B/C）：功能分支，开发人员在develop拉出来进行具体功能点开发的分支。
bug_fix：修复分支，线上版本出来紧急bug，拉出来的进行修复bug的分支。修复完后需要同步更新代码到develop分支。

环境介绍

一般一个项目部署的环境至少有本地环境、dev开发环境、fat环境、线上环境，只是最最基本的几个环境。

本地环境：不用介绍了吧这个，你的电脑虚拟机环境。【可以理解为本地的git版本】
dev环境：开发自测、联调的环境【可以理解为开发对功能A（B/C）自测的环境】
fat环境：测试用例测试和验证的环境【可以理解为develop分支部署，专门做上线前，测试验证、保证产品这里的测试环境】
线上环境：给用户使用的正式环境【可以理解为master分支部署的环境】
当然，公司越大、项目越大、业务链路越复杂越长的用于开发、调试、使用的环境也就更多。可能会多一个sit环境（集成测试环境）、uat环境（预发布环境）

开发流程

我们就从新建一个项目开始和整个开发过程需要学习和熟练的版本控制内容。

正常开发

在git版本分支管理的过程中，由上图可知我们按功能来拉取不同的分支进行多人开发，假设我们线上已经有一个1.0.1的版本在运行了，在master和develop分支上代码一致，现在开发新的需求（功能1），拉取一个新的分支

git checkout develop
git checkout -b func_1 
.....陷入思考中并写好了代码
git add .
git commit -m "新功能没有bug"
git push origin func_1
git checkout develop
git merge func_1
git push origin develop

开发.png

如果你提测完后，测试反馈有些问题需要你修改，你可以这样。

开发2.png

多人开发过程中可能某些不知情的小伙伴可能会这样操作，将develop分支合到自己的分支，在这种情况下除非你的确需要功能1那某部分代码，不然搞乱的会是你自己。我们最好尽量坚持从功能分支合并到develop提测分支。

开发3.png

解决冲突

像上面那种情况，如果你合并了develop分支代码，并且手贱（可能吧）的修改了功能1的代码，哪怕是一个空格回车也好，那也会出现冲突。要知道，你辛辛苦苦写的代码，哪知道一合并代码，还有去解决这烦人的代码冲突，哪得多伤脑筋啊。

开发4.png

提测fat环境

当你各个功能（1、2、3...）合并到develop的代码在开发环境（dev环境）自测，单元测试通过的时候，你就可以选择拉出一个全新的分支作为提测fat环境分支，然后测试反馈有问题，可以直接在fat_20200221分支修改或根据功能点来拉fat_fix分支，这个因项目而异。

测试.png

不过，当你合并到develop分支的有些功能点还达不到提测要求时，例如：有bug，未自测，赶不上此次版本上线的期限内，可以将已自测完毕满足提测要求的分支合并到fat_20200221分支进行测试，赶不上此次版本上线的下个版本在上线。

测试2.png

fat环境相关的部署、配置、环境准备有测试同学去维护，开发同学协助进行修复bug。这要求开发同学的能力要强，提测给测试同学的功能要充分自测并经过单元测试才可以，要不然看似耽误的是测试同学的时间，实际上浪费的是整个团队的时间。

预生产环境验证

ok，真不容易啊，测试经过反复测试，终于到了预生产环境（sit环境，我司就是拿sit环境作为生产环境，uat为正式环境）发布环节了。说是预生产环境，那当然在环境上，配置上要同生产环境一致啦，这是上线前的最后一步，尤为重要，不可忽视。

预生产.png

发布上生产

sit验证通过后，由项目经理安排、执行发布计划，并打上标签。

发布.png

那么整个流程就差不多讲完了，中间有些小坑可能还需要你们踩下才会知道痛哈。
此教程适合刚出来实习还不太明白git版本控制的小伙伴阅读，大佬们看到有什么疑问欢迎指点下小弟，喜欢点个赞呗，感激不尽。

未完待续