Question

我们已经知道GIT中的标准模式：Master - ＆gt;开发 - ＆gt;特征

我们的团队通常会在推广开发之前完成一项功能，并对代码进行审核和批准。但在这种情况下，我们被要求审查和推广未完成的代码。

最重要的是团队将更接近平价。如果我的批准将是关于尚未准备好在我们的开发分支中发布的代码的缺点。

如果编码领域的其他人面临这种情况以及你是如何进行的，那就很好奇。

Answer 1

在我们的案例中，我们有另一个分支机构发布分支，用于准备，审核，测试和批准计划发送/发布/部署的代码。它是从开发分支出来的，它仅用作集成分支，用于合并各个功能。

部分基于此Atlassian Git教程中描述的Gitflow工作流程： https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow

开发中的代码通常被视为仍在进行中或尚未完成。在合并功能分支之前传递评论和测试只意味着该功能可以自行运行。但是仍然存在这种功能如何与仍然可以开发的其他功能一起使用的情况。功能本身可能已经准备好发布，但所有组合的功能（旧的和新的）可能还没有。

这就是发布分支的用武之地。在合并一组特定功能后，我们从开发分支出来。它类似于说＆＃34;我们现在有一个包含这些新功能的发布候选代码＆＃34;。然后在此发布分支上完成最终集成测试，代码审查和批准。一旦所有检查通过，它最终会合并到 Master 并释放。

Master   -------------------------------------O (product release)
                                             /
Release                                 --O---
                                       /      \
Develop  ----O--------------O---O--O-----------O---
              \            /   /  /
FeatureA ---------O--O-----   /  /
               \             /  /
FeatureB ---------O--O-------  /
                \             /
FeatureC ------------O--------

如果发布分支出现问题，或者（1）我们从开发创建修复分支，然后将修复分支合并到发布，或（2）我们将修补程序直接应用于发布分支（如果它＆＃34;小＆＃34;足够），然后将其合并回稍后开发。

拥有单独的 Release 分支的优势在于，现在可以在包含要发布的完整代码的分支上完成批准。在此分支上执行测试和执行审核可确保我们在整合代码时将所有功能集成在一起。很明显，不应该向该分支添加/删除更多新功能，类似于说＆＃34;这是等待批准的候选发布代码＆＃34;。

另一个优势是发布分支与开发分支中可能且通常正在进行的开发分开。负责批准发布的人只需要关注发布分支。

建议的发展分支机构的推广标准

1 个答案: