敏捷项目版本管理方案Git
公司项目的版本管理方式
常用分支
-
主分支（master）
仓库的主分支，包含最近发布到生产环节的代码，最近发布的release，这个分支只能从其他分支合并，不能直接修改 -
修复分支（hotfix_xxx_20220414）
线上出现的紧急bug，需要新建hotfix分支进行修复，修复完成后，将代码提交到master（MR），release（MR）和develop -
发布分支（release）
当需要发布新版本时，对应release环境，将所有需要上线的feature分支合并到release分支（Merge Request方式，需要进行Code Review）；在release分支进行回归测试并修复bug，完成后，将release分支合并到master（Merge Request方式）和develop上 -
开发分支（develop）
主开发分支，对应测试环境，主要用来合并其他feature分支，测试同学基于该分支进行功能测试 -
功能分支（feature/bug_xxx_20220414）
主要用来开发一个新的功能，一旦开发完成，合并到develop分支进行测试，功能上线之后，需要删除
git flow的具体使用细节
当我们新建git仓库之后，默认会创建一个主分支也就是master分支，由于master分支是用于发布生产环境，所有必须保证master上代码的稳定性，所以我们不能直接在master分支上修改提交。我们要基于master分支创建release分支和develop分支，其中release分支用来保存开发完成并且测试通过的即将上线的多个功能，有两个作用，一是基于该分支做回归测试，二是进行代码review；develop分支用于保存开发好的相对稳定的多个功能，主要进行功能测试。
1. 当新的开发任务来了之后，就要编写代码了，我们尽量不要在develop分支上写代码，要保证develop分支的相对稳定，所以这时我要就要基于master分支创建一个临时的开发分支，然后在开发分支上编写代码，等功能开发完之后我们再把开发分支合并到develop上，测试人员基于develop 分支进行测试，如有bug，各开发人员在原有分支进行改动，改完后合并到develop分支继续进行测试
2. 新功能测试完成后，我们想把新功能发布到生产环境，首先需要整理此次发布需要上线的功能点，明确每个功能的负责人以及所属分支，各功能负责人将分支通过Merge Request的方式提交到release分支，并通知相关人员进行Code Review。所有功能合并完成后，测试同学基于release分支进行回归测试；回归测试完成之后，将release分别合并到master分支和develop分支，并基于master进行打包发版：
说明：需要将各功能分支合并到release，而不是直接基于develop，目的是为了防止在发版时develop分支还存在未完成测试的功能，导致功能延期。
3. release/hotfix分支合并到master分支之后，需要在在master分支上打上版本标签