了解用于持续交付的 Git 分支模型

3 分钟

成功的软件交付取决于平衡速度、质量和风险管理的分支策略。目标是在保持生产稳定性的同时快速交付增强功能。

战略平衡：速度与质量

有效的分支模型必须取得正确的平衡：

最大程度地减少进程开销 ，以加快上市时间。
维护质量门，以防止缺陷进入生产阶段。
为实现团队的可伸缩性，启用并行开发。
支持对关键问题进行快速修补程序部署。

虽然存在许多 Git 分支策略，但最有效的方法将经过验证的模式与团队的特定需求相结合。现代企业团队通常采用以功能分支和拉取请求为中心的 轻型基于中继的开发模型 。

核心原则：始终准备好的主分支

本单元介绍如何使用功能分支和拉取请求来实现一个为持续交付准备就绪的分支模型，以保持一个持续可部署的主分支。

企业分支策略框架

以下原则为持续交付奠定了坚实的基础：

主分支稳定性

单一事实来源：主分支是生产版本的独占路径。
生产就绪性：主分支必须始终处于可部署状态。
分支保护：实施全面的分支策略以防止直接提交。
封闭更改：所有修改都以独占方式流经拉取请求。
发布跟踪：使用语义 Git 标签标记所有生产版本。

功能分支规则

独立开发：为所有功能和 bug 修复创建专用分支。
功能标志集成：使用功能切换管理长时间运行的功能，以减少分支生存期。
战略命名：使用反映业务价值的描述性命名约定。
拉取请求工作流：只能通过评审的拉取请求以独占方式合并到主分支。

发布分支策略

专用准备：从稳定的功能集成点创建发布分支。
质量保证：对发布分支进行彻底测试并确保稳定。
生产强化：应用最终的 bug 修复和性能优化。
里程碑跟踪：标记重要的发布里程碑，以便进行可跟踪。

缩放命名约定

# Bug fixes
bugfix/[ticket-id]-description
bugfix/AUTH-123-login-timeout

# Feature development
features/[area]/[feature-name]
features/authentication/oauth-integration
features/api/rate-limiting

# Hotfixes
hotfix/[severity]-description
hotfix/critical-payment-gateway

# Personal branches
users/[username]/[description]
users/john-doe/experimental-caching

拉取请求管理

强制代码评审：不允许有直接合并到主分支的例外情况。
自动验证：为质量入口集成 CI/CD 管道。
性能指标：跟踪和优化拉取请求完成时间。
知识共享：通过评审来促进团队学习和标准执行。

先决条件和设置

适用于企业 Git 工作流的基本工具

此实际练习利用 Azure 的综合 DevOps 工具链：

Azure CLI：适用于 Azure 服务的云原生命令行接口。
Azure DevOps CLI：用于跨 Windows、Linux 和 macOS 无缝集成 Git、CI/CD 和敏捷工具的专用扩展。

Azure DevOps CLI 配置

Azure DevOps CLI 提供灵活的输出格式（JSON、YAML、表、TSV），以支持各种自动化方案。配置您的首选格式使用：

az devops configure --defaults output=table

动手实践：企业级 Git 工作流

本全面的演练演示了企业级 Git 分支，用于持续交付，包括功能开发、修补程序部署和冲突解决。

步骤 1：功能分支创建和开发

创建遵循企业命名规范的功能分支。

myWebApp

git checkout -b feature/myFeature-1

Output：切换到新的分支“feature/myFeature-1”。

验证分支上下文和工作树状态：

myWebApp

git branch

输出：✓ 功能/myFeature-1

主要*

步骤 2：功能实现和版本控制

实施你的功能更改：

myWebApp

# Edit your source files
code Program.cs  # Or your preferred editor

遵循完整的提交生命周期：

myWebApp

git status

输出：On branch feature/myFeature-1Changes not staged for commit:

修改：Program.cs*

myWebApp

git add .
git commit -m "feat: implement myFeature-1 with enhanced error handling"

输出：[feature/myFeature-1 70f67b2] 功能：实现 myFeature-1，并增强错误处理1 个文件已更改，1 次插入（+）

发布到远程存储库：

myWebApp

git push -u origin feature/myFeature-1

输出：To https://dev.azure.com/organization/teamproject/_git/MyWebApp

[new branch] feature/myFeature-1 -> feature/myFeature-1Branch feature/myFeature-1 set up to track remote branch feature/myFeature-1 from origin.

步骤 3：Azure DevOps CLI 配置和拉取请求创建

为组织和项目配置 Azure DevOps CLI。替换组织和项目名称：

az devops configure --defaults organization=https://dev.azure.com/organization project="project name"

创建新的拉取请求（使用 Azure DevOps CLI），以评审 feature-1 分支中的更改：

az repos pr create --title "Review Feature-1 before merging to main" --work-items 38 39 `
--description "#Merge feature-1 to main" `
--source-branch feature/myFeature-1 --target-branch main `
--repository myWebApp --open

在创建拉取请求后，请在提出拉取请求时，使用 --open 开关在 Web 浏览器中打开它。 --deletesource-branch该开关可用于在拉取请求完成后删除分支。此外，请考虑使用 --auto-complete，以在所有策略都通过且源分支可以合并到目标分支时自动完成。

备注

有关 az repos pr create 参数的详细信息，请参阅创建拉取请求以查看和合并代码。

团队联合评审代码更改并批准拉取请求：

屏幕截图显示代码更改的拉取请求已批准和完成。

主分支可随时进行发布。团队用发布号标记主分支：

创建标记示例的屏幕截图。

步骤 4：并行功能开发

开始使用功能 2。从主分支创建远程分支，并在本地执行签出：

myWebApp

git push origin main:refs/heads/feature/myFeature-2

输出：Total 0 (delta 0), reused 0 (delta 0) To https://dev.azure.com/**organization**/**teamproject**/\_git/MyWebApp * [new branch] origin/HEAD -> refs/heads/feature/myFeature-2。

myWebApp

git checkout feature/myFeature-2

输出：Switched to a new branch 'feature/myFeature-2' Branch feature/myFeature-2 set up to track remote branch feature/myFeature-2 from origin。

通过更改在 feature-1 中更改的代码中的同一注释行来修改 Program.cs：

```
public class Program
{
    // Editing the same line (file from feature-2 branch)
    public static void Main(string[] args)
    {
        BuildWebHost(args).Run();
    }

    public static IWebHost BuildWebHost(string[] args) =>
        WebHost.CreateDefaultBuilder(args)
            .UseStartup<Startup>()
            .Build();
```

步骤 5：功能 2 拉取请求和修补程序方案

在本地提交更改，推送到远程存储库，然后提出拉取请求，将更改从 feature/myFeature-2 合并到主分支：

az repos pr create --title "Review Feature-2 before merging to main" --work-items 40 42 `
--description "#Merge feature-2 to main" `
--source-branch feature/myFeature-2 --target-branch main `
--repository myWebApp --open

使用拉取请求时，将根据 feature-1 的发布报告生产中的重要 bug。若要调查此问题，需要根据当前在生产中部署的代码版本进行调试。若要调查此问题，请使用“release_feature1”标记创建新的 fof 分支：

myWebApp

git checkout -b fof/bug-1 release_feature1

Output：切换到新分支“fof/bug-1”。

步骤 6：紧急修补程序实现

通过更改在 feature-1 发布中更改的代码中的同一代码行来修改 Program.cs：

public class Program
{
    // Editing the same line (file from feature-FOF branch)
    public static void Main(string[] args)
    {
        BuildWebHost(args).Run();
    }

    public static IWebHost BuildWebHost(string[] args) =>
        WebHost.CreateDefaultBuilder(args)
            .UseStartup<Startup>()
            .Build();

在本地暂存和提交更改，然后将更改推送到远程存储库：

myWebApp

git add .
git commit -m "Adding FOF changes."
git push -u origin fof/bug-1

输出：To https://dev.azure.com/**organization**/**teamproject**/\_git/MyWebApp * [new branch] fof/bug-1 - fof/bug-1 Branch fof/bug-1 set up to track remote branch fof/bug-1 from origin。

步骤 7：修补程序集成和冲突解决

在将更改部署到生产环境后，请立即对 fof/bug-1 分支打上 release_bug-1 标签，然后提出拉取请求，将 fof/bug-1 中的更改合并回主分支：

az repos pr create --title "Review Bug-1 before merging to main" --work-items 100 `
--description "#Merge Bug-1 to main" `
--source-branch fof/Bug-1 --target-branch main `
--repository myWebApp --open

作为拉取请求的一部分，该分支将被删除。不过，你仍可以使用标记来引用整个历史记录。

修复重要 bug 后，让我们回顾一下 feature-2 拉取请求。

分支页表明 feature/myFeature-2 分支在主分支前做一个更改，在主分支后做两个更改：

分支页的屏幕截图。功能 myFeature 的两个分支在主分支前做一个更改，在主分支后做两个更改。

如果尝试批准拉取请求，则会看到一条错误消息，告知你合并冲突：

屏幕截图显示拉取请求中的合并冲突。

解决合并冲突

若要解决合并冲突，可以使用 Azure DevOps Web 界面，或使用 Git 命令在本地解决它们。对于本地解决，请首先使用来自主分支的最新更改更新功能分支：

```CMD
git checkout feature/myFeature-2
git fetch origin
git merge origin/main
```

解决首选编辑器中的冲突，然后完成合并：

```CMD
git add .
git commit -m "Resolve merge conflicts between feature-2 and main"
git push origin feature/myFeature-2
```

解决冲突后，拉取请求可以成功完成。

此时，可以根据在 fof/bug-1 分支中实现的关键 bug 修复来创建发布分支，并将其合并到主分支中。使用 git checkout 命令，从主分支创建专用发布分支。

git checkout -b release/v1.1 main

此命令基于主分支创建名为 release/v1.1 的新分支。

在发布过程中达到重要里程碑时，使用 Git 标记在发布分支中标记发布。标签用作标记以表示软件的特定版本。

git tag -a v1.1 -m "Release version 1.1"

此命令创建名为 v1.1 的标记，以在发布分支中标记版本 1.1。

工作原理

我们了解了 Git 分支模型如何让你灵活地通过创建每个功能的分支来并行处理功能。

拉取请求的工作流允许你使用分支策略来评审代码更改。

Git 标记是一种记录里程碑（例如已发布的代码版本）的好方法；标记可提供从标记创建分支的方法。

我们根据以前的发布标记创建了一个分支，以修复生产环境中的关键问题。

通过 Web 门户中的分支视图，可轻松在主分支前面标识分支。此外，如果任何正在进行的拉取请求在没有解决合并冲突的情况下尝试合并到主分支，则将强制发生合并冲突。

通过精简分支模型，你可创建短期分支，并更快地将质量更改推送到生产。

反馈

此页面是否有帮助？