git - Git 分支高效工作流程
问题描述
这是我公司的发布流程。我只是想看看它是否可以优化。
- 有四个分支,
- TeamA - Team A 成员所做的所有更改都到那里。它被部署到 TeamA QA 盒子。
- TeamB - Team B 所做的所有更改都在那里。它被部署到 TeamB QA box。
- 发布 - TeamA 和 TeamB 分支的更改在这里。这被部署到 UAT 盒子。
- Main - 一旦发布分支部署到生产,它就会合并到 main。
- 这是 TeamA 开发人员的典型开发工作流程。
- 从 TeamA 创建一个 Feature/Bug 分支并推送更改。
- 它由 QA 团队在 QA 框中进行测试并签署。
- 当发布时间到来时,开发人员从发布分支创建另一个功能/错误分支并推送更改(手动)。因为 TeamA 分支会有很多其他的变化。
如您所见,开发人员在两个不同的分支上进行了两次“分支和推送”。由于是手动步骤,因此无法保证开发人员在两个步骤上都推送相同的更改。
我们如何避免开发人员重复执行相同的步骤?
解决方案
报废 TeamA 和 TeamB 分支;他们比没用更糟糕。
对每个更改进行两次测试的想法是有道理的:
- 第一次,您是单独进行测试,因此如果出现问题,您不必取消合并。
- 第二次,您正在测试将要发布的组合,以确保修复不会产生不良影响。
在您的工作流程中,TeamA 和 Release 分支都具有更改组合,但它们具有不同的组合。在 TeamA 分支上进行的任何测试都是针对永远不会发布的代码版本。此时任何测试失败都需要恢复该更改,然后重新测试不同的更改组合,这些更改也不会发布。
所以我的建议是放弃 TeamA 和 TeamB 分支,并让 QA 检查各个任务分支以进行初始测试。
推荐阅读
- powerquery - Power Query - 从嵌套列表中提取数据
- python - 尝试将 Kmeans 与 Seaborn 的 Iris 数据集一起使用时出现问题
- jquery - 在 toast ui 日历中未正确显示类别时间的计划
- css - 三列:Vuetify 中的一列是固定的,两列是反应式的
- typescript - Type alias 'Permission' circularly references itself
- c++ - std::vector 的 C++ 高效插值
- python-3.x - 如何遍历python字典
- javascript - 如何在赛普拉斯测试中模拟 JSONP 请求?
- css - 如何在最小化的同时防止背景图像移动?
- ruby-on-rails - 未在 Rails 服务器上为 ruby 创建用户