版本控制 Git版本控制解读

版本控制管理工具是程开发的必备基础应用工具之一。之前写过一篇文章，重点是个人对git rebase命令(slam watch _)的理解和应用；在此基础上，这一次作者打算将git版本控制管理进行到底，然后深入描述相关流程，用来记录我学习过程中的每一点，也希望能真正帮助到正在使用git工具的小伙伴们。

一个

场景分析

Git的基本命令这里就不赘述了，主要是关于版本管理，项目真正上线后如何管理各个分支，如何有条不紊的进行版本切割，解决bug，在生产线出现问题的情况下做修补分支管理。项目启动后，每个开发都会被分配到自己的开发需求，有些是重叠的，有些是不相关的。在早期开发需求时，他们通常基于一个共同的分支，并根据自己的需求切割自己的特征分支进行开发。后期开发后，分行会合并。不相关需求的发展决定了合并过程中很少或者没有冲突。需求重叠的代码合并需要解决很多冲突。解决冲突后，可以将当前分支部署到相应的环境中进行测试。一般情况下主要有三个分支(很多公司会采用dev->:demo->；stage->Prod，这几组环境，本文暂时不考虑舞台环境)，如下:

主分支

现在的分支是主分支，有的开发团队采用这个分支，有的不采用这个分支。本文中的采用是指是从该分支中切掉在线分支，还是基于该分支发布标签。

演示分支

目前的分支是演示环境部署分支，主要作为开发阶段系统部署到生产线过程中的重要演示测试环境。一般当期上线的需求都在当前分支上。

发展分行

当前分支是开发环境分支。一般高级开发的需求合并到这个分支，用来测试开发者。

其实上面说的三个分支都体现在远程服务器上面的分支。每个互相协作的开发者可以远程推送各种名称的分支，也可以本地剪切各种分支。最终的效果是将开发人员开发的代码合并或挑选到上面的相关分支。作者经历了与版本控制管理相关的两个主要过程，即常用模式和推荐模式。

2

通用版本控制管理

1.通用版本控制管理

在这种流程模式下，不需要主分支，当前版本基于演示分支的代码提交点来切割在线分支。这里有一个问题需要强调，因为本文没有考虑舞台环境，所以演示环境是项目部署到生产线之前的最后一道防线。为了保证在线代码的稳定性，我们应该在发布前三天将这个剪切的在线分支放在演示环境中进行测试和回归测试，以避免风险并确保稳定性。具体流程见下图:

拆分过程如下:

在发展分支的基础上，切割和发展自己的地方特色发展分支；在现有基础上，开展需求研发、自测、自开发流程，解决bugs当需求开发完成时，相关的代码将被拉到开发分支，然后部署到开发环境中进行测试；

确定当前的发布需求，提交已经提交到开发分支的代码，挑选或者合并，最后将请求拉到演示分支进行演示环境部署测试；

版本稳定后，在演示分支的基础上剪出线上分支，比如rt231；一旦发现生产线问题，基于rt231分支制作一个修复程序，然后快速解决bug，裁剪出rt231.01修复程序版本紧急发布并修复生产线问题，最后将修复程序代码同步回演示分支。

三

推荐的版本控制管理

1.推荐版本控制管理

目前推荐的模式是版本控制管理，GitHub官网上很多开源项目都是用这种模式管理的。采用标签模式发布在线版本。具体流程见下图:

拆分过程如下:

开发流程指常规流程的A、B步骤；

版本稳定后，将demo分支的代码拉到master分支，然后使用gittag-a v231-m“此处备注”命令打印在线标签版本。如果出现生产线问题，基于此标签分支，修复问题后，重新打印修补程序标签版本v231.01，重新发布当前标签版本以修复生产线问题，最后将修补程序代码同步回演示分支。

附笔

上面显示的流程图在实际的版本管理过程中会有些不同，但是大的流程思路应该是一样的，或者一些详细的流程图还没有体现出来；比如已经确认在线的需求暂时不在线等。在这种情况下，可能需要根据实际的开发情况，直接隐藏需求代码条目或者直接还原当前的代码提交。在实际的代码开发过程中，根据不同的远程分支切割本地代码，并进行合并或重基础操作，最后推送远程分支做Pull请求操作。这说明了代码评审的重要性，让开发人员了解彼此的开发需求，促进彼此的进步。这个分享主要讲的是实际开发过程中的两个场景。用流程图说明版本控制的一般流程和思路，具体场景不直接用命令套现。这主要是基于前面的文章分享，不重复命令，只是总结一些思路。请批评指正描述不准确。谢谢你。