Git/版本/分支/提测，一些常识&流程梳理。

<<写此文的缘由

下午有同学，在群里问了几个问题。突然发现，大家对开发代码完事后，执行测试前的步骤、流程及具体细节不是很清楚 。

之前招聘过程中，

也发现很多同学，确实对这块的知识有欠缺 。

特别是很多公司，由于开发同学，对测试同学的能力不太相信，让测试同学，介入的环节非常少 。什么都帮测试搞定了，测试只需在哪等着版本放到测试环境，调试通了，去执行测试即可 。

从老徐的角度，对一个测试从业者的技能要求 。以及一位测试工程师的职业发展 。了解整个研发流程 & 具体执行细节，是必备技能 。

特别是，这些与测试职业强相关的提测流程 。

<

开始之前，先了解下Git 

俗称「代码管理」，研发过程的所有代码，都会提交到Git，可以方便的管理分支、版本、打标签，且能整个团队，多人协作（如果你不知道Git ，同类的SVN你应该知道） 。

关于Git的分支、标签、版本 ，本来老徐是要画个图的 。

偷个懒，从网上找了一张 。

（图来自网络）

玩Git ，你应该知道的几个分支「Master / Hotfix / Release / Develop / Feature」

Master ：一般来说，线上的发布分支，稳定版本 。

Hotfix ：紧急修复分支 。

Feature ：功能特性分支 （一般来说，一个团队会同时存在多个功能特性分支；比如Feature/A   Feature/B   Feature/C  ... ）

注，此处简单待过，对这块感兴趣的，网上检索下文章，非常多 。

<<拉取提测分支代码

知道分支概念，接下来聊聊如何获取提测的分支代码 。

一般来说，团队内部会约定好，某个版本提测，代码在哪些仓库、哪个分支，需要在提测时，写清楚 。

测试这块，可以直接通过Jenkins，拉取对应仓库、对应分支代码，编辑、打包、部署、发布到测试环境，然后调用一些自动化手动测试，冒烟通过，就可直接进行测试 。

如果测试通过，打算发布到生产时（此文，中间省去了一些步骤；应该还有回归环境、预生产环境 等），先把代码合并到发布分支，Jenkins配置好发布脚本（一般来说，除非是新项目，否则发布脚本，不需要调整），团队内容，协商一个发布时间，Jenkins一键发布到生产即可（发布后的一些流程，此文省略）。

<<同时开发了多个Feature，如何只发布某个 ？

这里涉及到Git分支规范、版本管理 ，一般来说，独立的Feature，独立分支开发，代码别混淆，方便后续独立发布 。

而且，实际研发过程中，某些Feature，研发过程，暂停或者终止，都是很正常的事 。

注，

分支管理，很重要，团队内容，一定要约定一个规范 。

/

End 

此文，主要是帮大家梳理下思路 。对这块感兴趣的，可直接底部提问，交流 。

希望，此文对你有点用 。