代码版本管理的流程

作者：菜鸟追梦旅行 | 2024-04-12 14:12:00

踩

代码版本管理

一、主要目标

保证环境的独立性：开发环境、测试环境、生产环境

避免过多分支切换带来的开发成本

我们的Git-flow就是为了达到上述两者的平衡

二、具体做法

（一）每个项目常备三个分支

（1）dev、origin/dev

开发分支，包含了所有开发环境下的代码。推送dev分支会触发开发环境的自动构建部署。

（2）staging、origin/staging

测试分支，包含了所有测试环境下的代码，日常开发下不要往 staging 合并，更不要往 origin/staging 推送。

staging 分支合并需要经过 merge request，进入需求开发以后，就可以发起 merge request 了；提测前会通过合并。

暂时不考虑保护 staging 分支。

（3）master、origin/master

生产分支，包含了所有生产环境下的代码。

只有通过测试的 origin/staging 分支，才可以合并到 master 分支。

master受到保护。

（二）分支模型图

（三）使用场景

（1）开发新需求

Shell
# 从 staging 分支上切换新的分支进行开发，此时可以发起 Merge request 到 staging
git fetch
git checkout -b feature/[功能名称] origin/staging

# 开发过程中注意同步 origin/staging
git fetch
git merge origin/staging

# 开发结束以后，将代码合并到 dev
# 并推送到远程仓库，它会自动触发开发环境下的构建流程，从而部署开发环境
git checkout dev
git merge feature/[功能名称]
git push

# 在开始开发时发起的 Merge request，由相关人员 review，并在提测前通过
# 将代码合并到 staging 分支，通知测试可以提测，测试环境由测试人员构建部署

（2）提交测试

发起 Merge request 到 staging，MR 通过以后，通知测试进行提测

（3）测试Bug修复

直接在 feature/[功能名称] 分支上修复，修复后合并到 staging 分支上，以供测试；测试验证通过，将 origin/staging 合并入 dev 分支（也可以将自己已经修复完毕bug的 feature/[功能名称] 合并到 dev 分支）；

（4）正式环境部署

合并 origin/staging 到 master，并推送到 origin/master

（5）正式环境bug修复

从 origin/master 切出 hotfix/[bug] 分支，修复后，再发起 merge request 到 master 分支；同时，还要合并到 staging 分支。

三、如何减少合并冲突的次数以及冲突范围

（一）日常开发中，要注意及时合并 staging，在开发新的代码前要合并远程仓库的代码

Bash
# 当前分支为特性分支，在开发新的代码前，注意合并远程 staging 中的代码
git fetch
git merge origin/staging

（二）一旦产生冲突，要找到另一方冲突人，一起协商解决冲突

不要私自覆盖他人代码！

（三）分支应与特性对应，不是与个人对应，不要一直用同一个分支开发不同功能的代码

分支不值钱，随便开。

声明：本文内容由网友自发贡献，不代表【wpsshop博客】立场，版权归原作者所有，本站不承担相应法律责任。如您发现有侵权的内容，请联系我们。转载请注明出处：https://www.wpsshop.cn/w/菜鸟追梦旅行/article/detail/411047