代码版本管理的流程

一、主要目标

  1. 保证环境的独立性:开发环境、测试环境、生产环境
  1. 避免过多分支切换带来的开发成本

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

二、具体做法

(一)每个项目常备三个分支

1devorigin/dev

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

2stagingorigin/staging

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

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

暂时不考虑保护 staging 分支。

3masterorigin/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

(二)一旦产生冲突,要找到另一方冲突人,一起协商解决冲突

不要私自覆盖他人代码!

不要私自覆盖他人代码!

不要私自覆盖他人代码!

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

分支不值钱,随便开。

  • 24
    点赞
  • 20
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
### 回答1: App版本管理流程规范是指在开发和发布App时,对于版本进行统一管理和规范化的一系列流程。 首先,开发团队需要建立一个版本管理系统,用于记录和跟踪App的版本号和变更内容。版本号一般遵循主版本.次版本.修订版本的命名规则,例如1.0.1。同时,版本管理系统还可以记录每个版本的发布日期、负责人等信息。 其次,在每个版本的开发过程中,开发团队需要建立版本控制机制,确保代码的稳定性和一致性。每次开发完成后,需要对代码进行版本控制,即将代码提交到版本管理系统中,并标记对应的版本号和变更内容。 然后,在开发团队确认一个稳定的版本后,可以进行内部测试。在测试过程中,需要对该版本进行全面的功能测试、性能测试、稳定性测试等,确保版本的质量和稳定性。 接下来,开发团队可以将测试通过的版本交付给产品经理或项目经理,并根据需求和计划对版本进行优化和修改。在此过程中,版本管理系统可以发挥作用,团队可以根据变更内容追溯和管理每个版本。 最后,当开发团队确认版本达到发布标准后,可以进行正式发布。在发布之前,需要制定发布计划和发布流程,包括版本的打包、上传至应用商店或公司的私有平台、灰度发布等。 总的来说,App版本管理流程规范包括版本记录、版本控制、内部测试、优化修改和正式发布等环节,通过统一的流程管理和控制App的版本,确保版本的质量和稳定性,提高团队的协作效率和开发效率。 ### 回答2: app版本管理流程规范是指在开发和发布app的过程中,按照一定的规范和流程进行版本管理,确保app的开发、测试和发布的有序进行。 首先,版本管理应该建立在一个版本控制系统的基础上,例如Git。开发团队成员需要在该系统中创建自己的个人分支,或者在主分支上创建自己的特性分支,用于进行开发工作。 其次,开发团队需要根据需求对app进行功能设计和开发。相关的代码、资源文件等需要按照一定的文件夹结构进行组织,并定期进行代码提交。每次提交都需要附带相应的注释,以便后续的版本追踪和代码维护。 接下来是测试阶段。测试人员需要从版本控制系统中获取最新的代码进行测试。在测试过程中,需要编写详细的测试用例和测试报告,记录测试结果和问题。如果发现问题,需要及时在版本控制系统中创建对应的issue,并指派给开发人员进行修复。 一旦测试阶段完成,可以进入发布阶段。在发布前,需要对代码进行审核和打包。审核是为了确保代码质量,打包则是将所有的代码、资源文件和相关文档整合成最终的发布包。发布包需要进行命名、版本号的确认,并结合发布说明文档进行归档和存储。 最后是正式发布。发布人员需要按照预定的发布计划,将发布包上传到指定的发布渠道,例如应用商店或企业内部的分发平台。同时,发布人员还需要更新版本号和发布说明,并在发生问题时及时回滚到之前的版本。 综上所述,app版本管理流程规范的关键是建立版本控制系统、制定开发、测试和发布的规范,并保证团队成员的遵守和执行。这样可以提高开发效率、确保代码质量,并及时响应问题和需求变更。 ### 回答3: App版本管理流程规范不仅可以确保开发团队的高效协作,还能够提高App的质量和稳定性。下面是一个常见的App版本管理流程规范: 1.版本规划:在开始开发新版本之前,团队应该进行版本规划。包括确定新功能和改进的范围,制定开发计划,并确定发布日期。 2.版本控制:使用版本控制系统管理代码库,如Git或SVN。确保每个开发人员都能够从仓库中拉取最新的代码,避免代码冲突。 3.分支管理:在进行开发之前,团队应该基于主线分支创建一个开发分支。在开发分支上进行具体的开发工作,确保主线分支的稳定性。 4.代码审查:开发人员在完成自己的任务之后,应该进行代码审查。通过对代码的检查,可以发现潜在的问题和改进的机会。 5.测试和集成:在开发完成后,应进行单元测试和集成测试,以验证功能的正确性和稳定性。任何发现的问题都应该被记录下来并及时修复。 6.发布准备:在发布版本之前,团队应该进行最后一次的检查和准备工作。包括更新版本号,更新版本说明文档,并准备好发布所需的材料。 7.发布和回滚:发布版本时应该记录发布的具体时间和内容。在发布后的一段时间内,团队应密切监控用户反馈和错误报告,并根据需要及时进行回滚或修复。 8.版本记录:团队应该建立一个版本记录的系统,记录每个版本的信息,包括发布日期、功能、改进和修复等。这有助于团队回顾和评估每个版本的表现。 以上是一个简要的App版本管理流程规范,可以根据实际情况进行调整和补充。通过严格执行这一规范,可以提高团队的开发效率和交付质量。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值