i007.cc

i007.cc

优先队列-降维打击

05.价值资料

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

原文地址

 

已完成100 XP

编写代码的目的是为软件提供增强功能。

引入过多处理开销的分支模型并不会有助于提高向客户获取更改的速度。

这对于开发分支模型至关重要,因为这样可提供足够的填充量,而不会产生质量较差的更改。 但同时,也不会引入太多进程来降低速度。

Internet 上全是 Git 的分支策略;虽然这些策略没有对错之分,但完美的分支策略才适用于你的团队!

你将了解到始终使用功能分支和拉取请求的组合来提供随时可发布的主分支。 还将了解,为避免回归,在将失败分支返回到主分支的修复中修复的同步 bug。

做好准备

我们来介绍一下我们建议的原则:

  • 主分支:
    • 主分支是将任何内容发布到生产的唯一方法。
    • 主分支应始终处于随时可用状态。
    • 使用分支策略保护主分支。
    • 对主分支进行的任何更改都只通过拉取请求。
    • 用 Git 标记来标记主分支中的所有发布。
  • 功能分支:
    • 将功能分支用于所有新功能和 bug 修复。
    • 使用功能标志管理长时间运行的功能分支。
    • 从功能分支到主分支的更改只通过拉请求。
    • 命名功能以反映其用途。

    分支列表:

    Cmd

    features/feature-area/feature-name
    users/username/description
    users/username/workitem
    bugfix/description
    features/feature-name
    features/feature-area/feature-name
    hotfix/description
    
    
  • 拉取请求:
    • 评审并合并带拉取请求的代码。
    • 自动执行你在拉取请求中检查和验证的内容。
    • 跟踪拉取请求完成持续时间,并设置目标以减少所花费的时间。

我们将通过使用本方法中的分支策略方法,使用在拉取请求中创建的 myWebApp 进行代码评审。 如果尚未操作,请按照该方法使用分支策略锁定主分支。 在此方法中,我们还将使用市场中的三个流行扩展:

  • Azure CLI是 Azure 的命令行接口。
  • Azure DevOps CLI:这是用于处理 Azure DevOps 和 Azure DevOps Server 的 Azure CLI 的扩展。 它旨在与 Git、CI 管道和敏捷工具无缝集成。 使用 Azure DevOps CLI,无需离开命令行即可参与项目。 CLI 在 Windows、Linux 和 Mac 上运行。
  • Git 拉取请求合并冲突:通过 Microsoft DevLabs 创建的开源扩展,你可以在 Web 上评审和解决拉取请求合并冲突。 在 Git 拉取请求完成之前,必须解决与目标分支的任何冲突。 作为拉取请求合并过程的一部分,可使用此扩展在 Web 上解决这些冲突,而不是在本地克隆中执行合并和解决冲突。

Azure DevOps CLI 支持以 JSON、JSONC、table 和 TSV 返回查询结果。 可使用“配置”命令来配置首选项。

如何实现

  1. 将主分支克隆到本地存储库后,请创建新的功能分支 myFeature-1:
    Cmd

    myWebApp> git checkout -b feature/myFeature-1
    Switched to a new branch 'feature/myFeature-1'
    
    
  2. 运行“Git 分支”命令以查看所有分支,其中显示星号的分支是“当前已签出的”分支:
    Cmd

    myWebApp> git branch * feature/myFeature-1  main
    
    
  3. 在 feature/myFeature-1 branch 中对 Program.cs 文件进行更改:
    Cmd

    myWebApp> notepad Program.cs
    
    
  4. 暂存更改并在本地提交,然后将分支发布到远程:
    Cmd

    myWebApp> git status
    
    On branch feature/myFeature-1 Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git checkout -- <file>..." to discard changes in working directory) modified: Program.cs
    
    
    Cmd

    myWebApp> git add .
    myWebApp> git commit -m "Feature 1 added to Program.cs"
    
    [feature/myFeature-1 70f67b2] feature 1 added to program.cs 1 file changed, 1 insertion(+)
    
    
    Cmd

    myWebApp> git push -u origin feature/myFeature-1
    
    Delta compression using up to 8 threads. Compressing objects: 100% (3/3), done. Writing objects: 100% (3/3), 348 bytes | 348.00 KiB/s, done. Total 3 (delta 2), reused 0 (delta 0) remote: Analyzing objects... (3/3) (10 ms) remote: Storing packfile... done (44 ms) remote: Storing index... done (62 ms) To http://dev.azure.com/Geeks/PartsUnlimited/_git/MyWebApp * [new branch] feature/myFeature-1 -> feature/myFeature-1 Branch feature/myFeature-1 set up to track remote branch feature/myFeature-1 from origin.
    
    

    远程显示更改的历史记录:

    Screenshot showing the remote history of the changes.

  5. 创建新的拉取请求(使用 Azure DevOps CLI),以评审 feature-1 分支中的更改:
    Cmd

      az repos pr create --title "Review Feature-1 before merging to main" --work-items 38 39 `
              -d "#Merge feature-1 to main" `
              -s feature/myFeature-1 -t main -r myWebApp -p
      $prj -i $i
    
    

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

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

    Screenshot showing the pull request with code changes approved and completed.

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

    Create a tag example.

  6. 开始使用功能 2。 从主分支创建远程分支,并在本地执行签出:
    Cmd

    myWebApp> git push origin origin:refs/heads/feature/myFeature-2
    
    Total 0 (delta 0), reused 0 (delta 0) To https://dev.azure.com/Geeks/PartsUnlimited/_git/MyWebApp * [new branch] origin/HEAD -> refs/heads/feature/myFeature-2
    
    
    Cmd

    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.
    
    
  7. 通过更改在 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();
    
    
    
  8. 在本地提交更改,推送到远程存储库,然后提出拉取请求,将更改从 feature/myFeature-2 合并到主分支:
    Cmd

      az repos pr create --title "Review Feature-2 before merging to main" --work-items 40 42 `
                -d "#Merge feature-2 to main" `
                -s feature/myFeature-2 -t main -r myWebApp -p
      $prj -i $1
    
    

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

    Cmd

    myWebApp> git checkout -b fof/bug-1 release_feature1
    Switched to a new branch 'fof/bug-1'
    
    
  9. 通过更改在 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();
    
    
    
  10. 在本地暂存和提交更改,然后将更改推送到远程存储库:
    Cmd

    myWebApp> git add .
    
    myWebApp> git commit -m "Adding FOF changes"
    
    myWebApp> git push -u origin fof/bug-1
    
    To https://dev.azure.com/Geeks/PartsUnlimited/_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.
    
    
  11. 在将更改推出到生产后,请立即将 fof\bug-1 分支标记为 release_bug-1 标记,然后提出拉取请求,将 fof/bug-1 中的更改合并回到主分支:
    Cmd

      az repos pr create --title "Review Bug-1 before merging to main" --work-items 100 `
                -d "#Merge Bug-1 to main" `
                -s fof/Bug-1 -t main -r myWebApp -p
      $prj -i $i
    
    

    在拉取请求过程中,将删除该分支。 但仍可以使用标记将整个历史记录引用到该点。

    修复重要 bug 后,返回到 feature-2 拉取请求的评审处。

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

    Screenshot showing the branches page. The feature myFeature 2 branch is one change ahead of the main and two changes behind the main.

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

    Screenshot showing merge conflicts from pull request.

  12. 可使用 Git 拉取请求合并冲突解决扩展解决浏览器中的合并冲突。 导航到“冲突”选项卡,然后单击“Program.cs”以解决合并冲突:

    Screenshot from the Git pull request merge conflict resolution extension.

    通过用户界面,可获取源、目标,或添加自定义更改,然后评审并提交合并。 合并更改后,拉取请求也已完成。

工作原理

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

通过拉取请求工作流,你可使用分支策略评审代码更改。

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

我们根据以前的发布标记创建了一个分支,以修复生产中的重要 bug。

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

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

发表回复