如何解决如何将大型PR分成多个小型PR?基本上可以在延时模式下回退视频胶卷
我在一个分支中提出了45个测试案例(我们正在使用Java Cucumber BDD),从而提高了git的知名度。假设这45个故事属于3个类别,例如“用户”,“设备”,“引导负载”等,同样,每个类别都实现了15个故事。每个测试案例的实现都以3个文件的形式进行
- 功能文件
- BDD步骤文件,
- BDD步骤实施文件。 每个测试用例类别都将在上面单独命名为3个实现文件。
我们的经理希望将单个分支中包含45个故事的大型PR分成理想的45个PR,或者我的想法是至少提高15个PR,每个PR包含每个3层的实现。
因此,考虑到这一点,现在我从原始的“ master”分支开始,开始一个新的分支CA1(意味着CategoryA,分支1的开发分支)。
然后在同一行中,我将拥有
-
分支-CA2,CA3,CA4,CA5 FOR类别A, p>
-
分支-CB1,CB2,CB3,CB4,CB5 FOR类别B,
-
支行CC1,CC2,CC3,CC4,CB5 FOR类别C
每个分支将从原始的“ master”分支的拉拔开始, CA1,CA2,CA3,CA4,CA5将会更改(在一个故事实现之后追加 )与上述相同的3个实现文件。
类似地,CB1,CB2,CB3,CB4,CB5也会更改(与另一个故事实现相继追加)上述相同的3个实现文件(与类别B对应的名称)。 / p>
类似地,CC1,CC2,CC3,CC4,CC5也会更改(追加一个故事实现)另一个与上述相同的3个实现文件(与C类相对应的名称)。 / p>
现在在筹集15个较小的PR(每个3个故事)而不是1个PR(45个故事)的大块之后会出现问题。我怎么认为??
当类别A的第一个PR具有前三个故事实现时...直到类别C的第15个PR具有最后43,44,45个测试故事实现。
当这些PR尝试按顺序合并后,在经过一些评论和对每个PR的补救措施后,,最终的PR合并最终会如何?他们有无数吗?冲突,因为每个PR都建立在原始主分支的基础上,即使每个故事实现都是原子地并且分别地依次更改3个实现文件?
有更好的方法吗?这是由于我们的PR审稿人之所以赢得胜利,是因为他们无法像一天一样长时间地一次审阅一大堆45个故事,而不是花很少的时间(不到3个故事)进行小型PR(审阅3个故事)。>
版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。