发展分行建议晋升标准

Question

我们在 GIT 中拥有我所知道的标准模式：Master -> Develop -> Feature

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

这样做的好处是球队将更接近均势。如果我批准的缺点是代码尚未准备好在我们的开发分支中发布。

想知道编码世界中的其他人是否遇到过这种情况以及您是如何进行的。

Answer 1

在我们的案例中，我们有另一个分支，一个 Release 分支，用于准备、审查、测试和批准计划成为 shipped/released/deployed 的代码。它是 Develop 的分支，仅用作 integration 分支，用于合并 individual 功能.

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

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

这就是 Release 分支的用武之地。我们在合并特定功能集后从 Develop 分支出来。它类似于说 "we now have a release candidate code containing these set of new features"。然后在此 Release 分支上完成最终集成测试、代码审查和批准。一旦所有检查通过，它最终会合并到 Master 并发布。

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

如果 Release 分支有问题，要么 (1) 我们从 Develop 创建一个修复分支，然后将修复分支合并到Release，或者 (2) 我们直接将修复应用到 Release 分支（如果 "small" 足够）然后将其合并回以后开发

拥有单独的 Release 分支的好处是，现在批准是在包含完整待发布代码的分支上完成的。在此分支上进行测试和执行审查可确保我们将代码作为一个整体进行检查，并将所有功能集成在一起。很明显，这个分支不应该有更多的新功能 added/removed ，类似于说 "this is the release candidate code waiting for approval".

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

发展分行建议晋升标准

Suggested promotion standard for develop branches

git

git-flow