<< 写此文的缘由
下午有同学，在群里问了几个问题。突然发现，大家对开发代码完事后，执行测试前的步骤、流程及具体细节不是很清楚 。
之前招聘过程中，
也发现很多同学，确实对这块的知识有欠缺 。
特别是很多公司，由于开发同学，对测试同学的能力不太相信，让测试同学，介入的环节非常少 。什么都帮测试搞定了，测试只需在哪等着版本放到测试环境，调试通了，去执行测试即可 。
从老徐的角度，对一个测试从业者的技能要求 。以及一位测试工程师的职业发展 。了解整个研发流程 & 具体执行细节，是必备技能 。
特别是，这些与测试职业强相关的提测流程 。
<< 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
此文，主要是帮大家梳理下思路 。对这块感兴趣的，可直接底部提问，交流 。
希望，此文对你有点用 。
2018年，IDO老徐，除了更新「测试技术 & 测试职场」文，还会利用碎片化时间，每日分享一些职场经验 。
