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

时间 2020-01-09

标签 git 那些代码管理栏目 Git 繁體版

原文原文链接

1. Git是什么？

做为一名程序猿，我相信你们都或多或少接触过git--分布式版本控制软件。git

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

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

--由Linus Torvalds创做，并与2005首次发布，最初仅是为更好的管理Linux核心开发而设计，未曾想太优秀，现在已被广为使用。测试

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

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

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

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

其实，只要懂得正确操做流程，你也能够大刀阔斧，那么下面的知识，你值得拥有！！项目管理

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

我相信你们必定听过一句话：做为一款稳定的产品，咱们必定要保证项目运行的四个九。咋听之下，一脸狐疑。其实，意为保证项目运行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详细流程：

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

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

做者：吴家二少

本文欢迎转载，但未经做者赞成必须保留此段声明，且在文章页面明显位置给出原文链接