git企业级版本管理

一、介绍

git大家都知道，是一个开源的分布式版本控制系统，用于敏捷高效地处理任何或小或大的项目。它和SVN最大的不同，在与git分支的遍历。

但往往企业在使用git时，也仅仅把git当做SVN来使用，并没有很好的利用起git的分支，每个人都提交一堆commit，建立一堆杂乱无章的分支，导致项目的管理混乱。

所以需要企业根据实际的开发需要，定义一个git版本规范，是很有必要的。

二、分支命名

• 分支线

  • master：主分支，始终与线上发布的版本保持一致，只做合并，不做提交
  • test：测试分支，对应测试环境的分支
  • dev：开发分支，对应开发环境的分支
  • hotfix：火速修复分支，当线上代码出现bug，基于master分支创建出一个新的分支，进行修复bug

• 命名规则：[分支线]_[年月日 ]_信息

  • 如开发权限代码：dev_20211128_auth
  • 如线上支付出现bug：hotfix_20211128_pay

三、开发发布流程

3.1）正常版本需求开发

1. 当开发人员需要开发新需求，开发人员需要基于master创建出一个新分支，注意分支名称要规范，例如dev_20211128_auth

2. 开发人员需要将分支拉取到本地开发，只拉取刚刚创建的dev_20211128_auth

   1. 如果是组内共同开发的同个功能，同样拉取一样的分支

3. 开发人员完成开发后，上传代码远程分支至远程分支

   1. 根据自己业务开发需要，决定自己提交至远程的代码，例如一天一次提交等
   2. 全部完成后，远程分支dev_20211128_auth拥有了你们所有功能代码，此时合并至dev分支
   3. 然后将dev分支打包构建只开发环境

4. 当自测通过，将dev_20211128_auth合并至test分支

   1. 不能将dev合到test分支，因为dev上可能有其他小组还在联调的代码

5. 测试通过时，可以上线的情况下，将dev_20211128_auth合并至master分支，然后进行打包构建发布

3.2）线上问题紧急修复

1. 线上有bug，需要修复时，基于master创建出一个hotfix分支，例如hotfix_20211128_pay

2. 开发人员拉取分支进行修复

3. 开发修复完成后，将hotfix_20211128_pay合并至dev进行联调或者自测

4. 当自测通过，将hotfix_20211128_pay合并至test分支

5. 测试通过时，可以上线的情况下，将hotfix_20211128_pay合并至master分支，然后进行打包构建发布

3.3）dev、test分支测试有bug反馈

1. 当dev、test分支有bug反馈，需要在本地进行修复bug时

2. 不能直接修改dev、test分支，应当从自己开发功能的分支上进行修改bug

3. 修改完成后，再将自己的开发功能分支合并到dev、test分支上，重新进行测试

四、分支清理

• 当每个版本上线后，自己的功能开发分支都将删除

• 每隔一段时间，dev、test分支都将删除，重新基于master创建

  • 主要是避免代码污染，某些人没有按照规范，直接提交到dev、test分支了
  • 最好在没有功能需求的空窗期进行

五、结语

上述就是git代码的管理，以前确实很乱，有了规范分支也清楚。

每个企业，开发的资源环境不同，比如有些没有统一的开发服务器，比如有的还有预发布环境。可以根据企业自身，进行适当的修改，但规范一定是要有的，本文仅供参考。

git大全

git命令小游戏