使用短分支实时策略制作功能切换长寿命功能

Question

嗨搜索如何使用功能切换长寿命功能和短分支生存策略。建议使用短期分支（使用 PR 并每天在 master 上合并），但是当你的功能长期存在时如何做到这一点。如何在 git 历史中有意义的多个分支中拆分您的功能。

我建议像这样在分支名称中使用版本控制：

创建 feature-A-v1 分支（在生产中关闭）
PR
合并
删除 feature-A-v1 分支
创建 feature-A-v2 分支（在生产中打开）
PR
合并
删除功能-A-v2 分支

但是在互联网上我找不到这样的示例，而且我不明白制作它的好习惯是什么。

Answer 1

功能分支通常用于开发新功能或修复错误。所以对于不同的features/bugs你应该使用不同的特性分支并且将一个特性分支合并到主分支直到它完成.

正如您展示的 feature-A-V1 和 feature-A-V2 的过程，如果这两个功能分支是为不同的功能开发的，您应该按照您展示的方式进行操作（它们作为短期分支工作）。但是为同一个功能（feature-A）开发的两个分支，你应该合并直到feature-A完成。在某种程度上，我们称之为长期存在的功能分支。

使用长期存在的分支，通常遵循以下步骤：

1.Assume feature-A 分支已从 production 签出，您正在处理 feature-A 分支。

A---B---C  production
         \           
          D feature-A

2.During 在 feature-A 分支上开发，其他开发者更新 production 分支，结构如下：

A---B---C---G---H  production
         \           
          D---E---F feature-A

3.After 你完成开发 feature-A 分支，在推送和创建 PR 之前，你可以 rebase feature-A 分支以确保它基于 [=18= 的最新版本] 分支。您可以使用命令：

git checkout feature-A
git pull origin production --rebase

结构如下：

A---B---C---G---H  production
                 \           
                  D'---E'---F' feature-A

现在您可以将 feature-A 推送到远程并创建一个 PR 以将其合并到 production 分支。

还有a successful branching module，可以参考

更新

由于您需要合并和部署 feature-A-v1，并修复其他错误但不想为这种情况创建新的功能分支。您可以检出到 feature-A-v1 分支，并通过将 production 合并到 feature-A-v1 来快进它（feature-A-v1 也将指向下图中的提交 O ）。

A---B---C---M---O  production
         \     /        
          D---N    feature-A-v1


A---B---C---M---O  production, feature-A-v1
         \     /        
          D---N

使用短分支实时策略制作功能切换长寿命功能

Make feature-toggle long live feature with short branching live strategy

git

azure-devops

continuous-deployment

continuous-delivery