4
如何摆脱开发分支以简化Git流
在一个持续开发的Web项目（不是产品）中，我们目前具有以下分支策略，大致基于git flow： 开发分支：最新工作版本 主分支：要发布的版本/已发布的版本 功能分支：开发中的功能 修补程序分支：已发布版本中的紧急错误修复 Master是只读的，可以通过来自develop或hotfix分支的拉取请求进行更新。每次更新都会构建候选发布版本并将其部署到登台系统。手动批准后，候选发布版将部署到生产中。 功能分支是基于develop或已合并到master的最后一次提交创建的。构建了来自功能分支以进行开发的拉取请求，并将其部署到免费的测试系统中，在该系统中执行集成测试和验收测试（自动和手动）。成功测试和审查后，PR就会合并，因此它将成为下一个版本的一部分（即从开发到母版合并）。 我的目标 我想简化此过程，并摆脱开发分支。developer分支主要是出于历史原因，并且由于它始终是经过成功测试的版本，因此我认为不必将其与master分开。删除它还将简化发布过程，因为不再有其他合并。 我有以下限制： 版本已排定，不应完全自动化 虽然功能分支通常寿命很短，但有些分支未合并数周（例如，重新设计），但也需要进行测试（当前是针对开放拉取请求的开发） 有时，应该在常规版本之外发布单个功能，从而有效地将其转变为修补程序。使用当前策略，我可以重新建立功能分支的基础并将其直接合并到主分支中 也有发生，我们需要在对外部系统进行暂存测试失败后保留功能 我不确定转换的地方： 目前，我正在构建请求测试以合并发布的提交。我可以统一一下吗？ 当母版领先于最新版本时，如何处理修补程序。我应该直接从修补程序分支构建和部署发行版吗？ 有没有明智的方法来处理在合并功能后就应从发行版中排除的功能？在这些情况下，单独的开发部门真的是一个优势吗？大多数情况下，无论如何我最终还是要手动还原和还原提交。