匿名职言 代码管理流程你们是怎么做的

匿名 · October 14, 2020 · Last by 匿名 replied at October 14, 2020 · 1130 hits

1、目前遇到的情况:

  • 由于测试资源不足,导致提测多个需求积压,比如有A,B,C,D四个每个需求,都是基于master新建对应的A,B,C,D分支
  • 中途可能会插入一个紧急的E,F需求,并且优先上线的,这样master就会往前推了,并且可能和ABCD分支修改了同一个地方的代码
  • E,F需求上线之后,也就是E,F分支合并到了master。
  • 现在A也测试完成了,测试时是在A分支构建测试的,测试通过后,目前做法把A分支合并到master,假设A分支和F分支修改了同一个地方的代码,就会产生冲突。

2、手工解决冲突带来了不确定性

  • 因为合并冲突了,导致git无法自动合并,需要开发手工合并代码,这时开发就要选择A分支或者F分支的修改了,如果迭代时间比较长,并且冲突多,很容易出现合并错误。
  • 那么为了保证质量,把合并了A分支的master分支重新构建,再测试一遍,这相当于重新测试了一遍,很浪费时间。
  • 目前我能想到的方法就是不要把A分支合并到master,而是把master先合并到A分支。这样的好处就是就算合并出现错了,影响的只有A分支,master不会向前推进提交记录。但始终还是会存在合并不全的风险

3、想问问大家是怎么处理开发合并了冲突代码这种情况

共收到 12 条回复 时间 点赞

还有一个问题想请教一下,合并代码的时候是用rebase还是merge呢?
我平时维护自动化框架时,是先在dev分支上rebase master,然后再切换到master,把dev分支merge过来。
用rebase的话,整个提交就是一条记录,不会出现各种分叉,强迫症患者的福音。但是有个坏处就是会改变原本git提交的记录,不过代码还是一样的。

定版发车,单拉分支,版本+1,发车日期过了,自动顺延,不怕插入新需求

没有develop分支吗

gitflow工作流程,了解下

匿名 回复

没有,每个需求都是从master拉一个新的分支,做完测试通过合并回master

版本控制流程你们需要重新梳理好。A,E代码会冲突,说明是同一个功能,E应该是修复一个紧急bug,这种仅测试功能+自动化跑主流程,A再正常测试就好了,同一个迭代周期发多个版本,就会出现这样的问题。归根到底还是流程问题,要么固定版本,要么合并需求,否则只能重复测试。

匿名 回复

自动顺延这个我们这里不太现实,领导一句话,明天这个需求必须上,怎么加班也得肝出来。

等于说代码合并还要测试去操心了,左移的有点远了吧。

改进流程才是正确的。我们之前版本也是这样 说上就要上版本频发,开发也难受,测试也经常加班,再怎么测试还是多多少少会出现一些问题,老板总以为测试不到位。目前我们改进就是学习gitflow工作流程,并且控制版本 一周一个小迭代,一个月一个大迭代。

A,E代码会冲突,说明是同一个功能的不同的改动,如果E先合并master了(尤其是已经上线了),再回来测A时,需要先把master再合到A分支,测试diff的时候,检查一下是否有奇怪的删除行。。我一般就是这么做的。如果是要同时上线,那我觉得你们这种只有一个master,没有dev分支的开发测试流程,可能是有问题的。。。。这是我个人的愚见😂

匿名 回复

可能是我个人操心的有点多,我平时还会review开发的代码,并且有问题会启动远程调试。
因为我这个测试是没有界面的,从代码层面去测试才能够更加深入理解业务

匿名 回复

只有一个master,需求就起一个feature分支,按照楼上各位童鞋推荐的gitflow,至少应该还要有一个develop分支才行

需要 Sign In 后方可回复, 如果你还没有账号请点击这里 Sign Up