我与Git的那些破事--代码管理实践

作为一名程序猿，我相信大家都或多或少接触过git–分布式版本控制软件。

有人说，它是目前世界上最先进的分布式版本控制系统，我想说，是否最先进不知道，但确实好用，实用。

作为一款风靡全球的软件，不得不提提它的历史：

–由Linus Torvalds创作，并与2005首次发布，最初仅是为更好的管理Linux核心开发而设计，不曾想太优秀，如今已被广为使用。

作为一款分布式版本控制软件，听上去高端大气上档次，但说白了，就是一款项目代码管理工具。

既然Git如此好用，理所当然，目前全球各大公司大多采用该软件作为项目代码的管理工具。

犹记得当初刚从学校进入企业，发现原来公司的代码是这样管理的，看上去猴塞雷的样子。当然，伴随着操作小心翼翼，生怕一顿操作猛如虎，犯错回家卖红薯。。

作为一个接触多年的老手，则肆无忌惮，斧削刀砍，好不快活。讲真，那会羡慕的不要不要～～

其实，只要懂得正确操作流程，你也可以大刀阔斧，那么下面的知识，你值得拥有！！

好了，闲话就此打住，还是得来点干货。

我相信大家一定听过一句话：作为一款稳定的产品，我们一定要保证项目运行的四个九。咋听之下，一脸狐疑。其实，意为保证项目运行99.99%（至于那遁去的1，你懂的），即高可用的又一说法。

为保证项目高可用，产品上线必须严格遵守一定的流程。

这里提几个概念，可能与你所在公司说法不太一样，但我相信都是换汤不换药，领略精髓即可，大可不必咬文嚼字。

Git 分支：

部署环境：

DEV/Local环境–本地环境。一般而言，程序猿接到一个新的需求时，会在本地开发，完成后自己测试，这里称为本地环境（当然财大气粗的公司可能会专门准备一套DEV环境用于测试）。
QA环境–与产线环境配置一致（单实例）。需求本地测试通过后，部署到QA环境中，由QA进行测试。由于QA环境部署频繁，如果多实例部署会造成资源和时间上的浪费。
BTS环境–与产线环境完全一致（分布式）。在版本发布前，部署到BTS环境，该环境和产线环境完全一致。一般会在版本发布前3天部署到该环境，做UAT（用户接受测试）。
PROD环境–分布式系统。产线环境。

开发流程：

当团队接到新的需求时，一般会安排某个或某几个程序猿来开发该功能。在了解完需求和设计后，开发会拉出对应的feature分支，所有该需求的代码都将在该分支上进行开发。
当开发完成，为验证功能可行性，程序猿需要在本地进行对应测试，通过后将代码合入到dev分支。
利用Jenkins从dev分支中进行打包，然后部署到QA环境中，由团队中专职QA进行功能测试。测试不通过，上述步骤重复。测试通过，该需求结束。

这里，有些小伙伴则会问，为什么本地测试通过了，而在QA环境中却不通过呢？

通常，一个团队都会同时接多个需求，大家的代码都会并行往dev中合入，这时就有可能影响到其他的需求，或者被其他需求影响，导致bug。

Git详细流程：

开发流程：

当发布新版本时，以时间或需求结束点为节点，打对应tag（方便以后回溯）。从该tag拉出release分支，Jenkins从release分支打包。
将包部署到QA环境，由专职QA进行测试。
- 如果测试不通过，从release分支中拉出hotfix分支，在hotfix分支上进行bug修复，本地测试完毕，Jenkins从hotfix分支打包，部署到QA环境测试。
- 测试通过，下一步。
将包部署到BTS环境，由专职QA进行测试。测试不通过，判断当前分支，若为release分支，则从该分支拉出hotfix分支，在hotfix修复bug后；若为hotfix分支，则直接修改bug，本地测试完毕，Jenkins打包hotfix分支，部署到QA测试。
将包部署到PROD环境，由专职QA进行测试，测试不通过，判断当前分支，若为release分支，则从该分支拉出hotfix分支，在hotfix修复bug后；若为hotfix分支，则直接修改bug，本地测试完毕，Jenkins打包hotfix分支，部署到QA测试。

Git详细流程：

上述的内容，仅为个人多年开发经验总结，或许与标准流程有一定的出入。

如有错误之处，忘各位大佬不吝斧正。

作者：吴家二少

本文欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接

我与Git的那些破事--代码管理实践的更多相关文章