都2024了还不知道如何去管理团队的 Git 分支吗?

一种好的分支策略,是可以允许多个团队在同一个存储库上工作,并可以通过分支命名明确的知道这个分支是干什么的。

首先来说一下核心原则

核心原则

  1. master 这是每个开发的起点,主分支受到保护的。你的新代码必须从这里开始,你可以确定那里的一切已经经过100%的测试并已经上线。由于该分支受到保护,人员不允许手动合并任何内容,也不允许通过PR进行合并,因此不会有任何意外。
  2. 分支使用前缀 使用前缀有助于更轻松地查找分支并理解其目的。不必逐个审查分支时,清理GIT也更容易。
  3. 使用描述性的分支名称 前缀是一回事。描述性的名称对于帮助理解我们正在查看的内容至关重要。使其对人友好且易读。
  4. 正确的版本控制 版本控制会影响发布分支的名称,因此更容易找到并推送它们而不影响其他团队的工作流程。
  5. 尽可能自动化 分支创建、版本控制、合并。这需要一些工作,但与任何其他发布自动化流程相比,并没有什么不寻常或更复杂的事情需要做。

关于前缀的命名

  1. master/main --- 始终代表当前上线的内容。

  2. wip/name --- 这些分支主要用于实验性工作、POC和其他非基于任务的任务。 "WIP"表示它无法独立上线,可能是一个重要功能或工作流的一部分。它还可能是一个临时的集成分支。可以将这些分支推送到开发服务器进行测试。

  3. feature/#####-name --- 这些分支将用于开发和测试新功能/任务/错误修复。在提交到发布之前,可以将它们推送到服务器进行测试。如果有助于将代码与任务连接起来,使用#####来表示任务编号。

  4. release/X.XX --- 发布分支是由构建过程自动创建的,所有代码都将合并到这里以进行上线。分支名称是使用主要和次要版本号的版本。永远不要为"更新"创建分支。

  5. integration/name --- 有时我们会遇到一些作为更大功能的任务,它们必须一起测试并上线。这些通常被视为长期存在的分支,并允许持续开发和PR来创建最终的功能/项目。

  6. hotfix/#####-name --- 从我们想要应用修复的特定发布创建的分支。

    注意:我们决定永远不删除发布分支,每当我们需要查看历史记录、在特定时间检查代码或审查更新时,分支都是可用且易于找到的。

优点:

  • 它在许多方面介于 GitFlow 和 GitHub Flow 之间,但澄清并简化了一些无法解释的领域。
  • 它非常适合由于额外的手动步骤、审批流程或时间问题而无法实施完整 CD 的情况。
  • 非常适合单一存储库,其中多个应用程序构建在共享核心上,并由具有不同交付时间表和优先级的各个团队开发。
  • 将能够轻松地单独创建一个版本,对其进行测试、部署,只有在 100% 正常后,才将其合并回 Master。这意味着如果代码因尚未测试而失败,没有人会感到恼火。
  • 多个团队可以从同一存储库为不同的应用程序创建版本并部署它们,而不会相互阻塞。
  • 轻松同时管理多个版本并在实时推送代码之前同步它们。
  • 无需开发分支。忘掉它。
  • 由于版本控制是由构建过程和管道控制的,因此发布分支命名不会发生冲突。
  • master/main分支始终可以安全地用于新版本。可以相信,没有未经测试的代码或令人讨厌的意外。
  • 无需依赖哈希值或标签,使所有内容都易于阅读,但每当发布版本被推送并合并回主版本时,留下标签仍然是一个好习惯。
  • 功能(在发布分支上)只要准备好并经过测试就可以上线。
  • 由于每个版本都是一个单独的分支,因此可以直接回滚或在此特定分支上进行更新并发布任何应用程序。
  • 不会因未完成的代码或等待依赖项或其他团队而导致发布周期锁定。
  • 鼓励合并前进行测试。
  • 为开发人员创造更少的认知开销,因为分支由发布管道维护(假设有适当的自动化)。
  • 如果出于任何原因不再需要某个版本,则很容易放弃该版本。
  • 将CI 和自动部署的流程扩展到开发环境有很大的潜力。

缺点:

  • 每个版本的发布分支名称都会改变,因此可能需要编写更智能的管道,因为不会从一个分支(通常是主分支)发布。
  • 持续交付的自动化更加困难,但并非不可能。
  • 开发人员需要跟踪正在进行的版本。
  • 在合并到发布分支之前,需要确保正在处理来自主分支的最新代码(将其合并)。
  • 如果团队正在开发一项重要功能并且需要对其进行测试,那么可能(不必)在将其全部推送到发布之前最终使用集成分支。
  • 由于在开发过程中 master 中的情况可能会发生变化,因此必须稍后将其合并,并且可能会产生一些需要解决的额外冲突
  • 当所有团队成员都以某种隔离方式工作时,在发布分支中相遇时,会遇到冲突。
  • 如果不考虑适当的版本控制和管道自动化,这一切可能都毫无意义。

发布流程很重要!

管道控制如何创建每个版本的分支、版本控制以及使用相关更改正确更新以避免错误。最重要的是,负责安全地推送代码并将所有内容合并回 master。

举个栗子

1. 简单

两个开发人员正在准备两个功能并一起发布它们。

2. 典型

一些功能、一个发布分支和一个后期合并。

3. 常规特征和一个很长的特征。两个版本。

一个功能需要很长时间的流程。基本上,在合并到发布之前,再次合并到 master 中以保持 100% 最新。

4. 放弃发布。

当一个版本开始时,另一个版本随后创建,但在第一个版本之前上线(可能是快速修复)。可以通过在管道中采取一些额外的保护措施来防止这种情况,从而避免一次创建多个"正在进行中"的版本。此外,可以使用修补程序来代替小更新。

5. 发布后进行修改。

如果对现有实时代码有简单的错误修复,则可以使用修补程序。这将帮助你避免陷入上述情况。修补程序用于通过一个小但重要的补丁来更新现有版本。

6. 还有更多事情发生。

请注意,不同的人和团队可能会处理这样的示例。它可能看起来很复杂,但如果你遵循两个简单的规则,它就会很顺利。

  • 始终确保你已将 master 合并到发布分支并且版本正确。
  • 与团队发布计划和正在进行的分支进行沟通(通常,团队会共同创建一个版本并将其推出)。

可能每个团队的流程都不一样,但是我想应该都是大同小异。

点赞收藏支持、手留余香、与有荣焉,动动你发财的小手哟,感谢各位大佬能留下您的足迹。

往期热门精彩推荐

解锁 JSON.stringify() 5 个鲜为人知的功能

解锁 JSON.stringify() 7 个鲜为人知的坑

如何去实现浏览器多窗口互动

面试相关热门推荐

前端万字面经------基础篇

前端万字面积------进阶篇

简述 pt、rpx、px、em、rem、%、vh、vw的区别

实战开发相关推荐

前端常用的几种加密方法

探索Web Worker在Web开发中的应用

不懂 seo 优化?一篇文章帮你了解如何去做 seo 优化

【实战篇】微信小程序开发指南和优化实践

前端性能优化实战

聊聊让人头疼的正则表达式

获取文件blob流地址实现下载功能

Vue 虚拟 DOM 搞不懂?这篇文章帮你彻底搞定虚拟 DOM

移动端相关推荐

移动端横竖屏适配与刘海适配

移动端常见问题汇总

聊一聊移动端适配

Git 相关推荐

通俗易懂的 Git 入门

git 实现自动推送

更多精彩详见:个人主页

相关推荐
EricWang135820 分钟前
[OS] 项目三-2-proc.c: exit(int status)
服务器·c语言·前端
September_ning20 分钟前
React.lazy() 懒加载
前端·react.js·前端框架
web行路人30 分钟前
React中类组件和函数组件的理解和区别
前端·javascript·react.js·前端框架
王解37 分钟前
Jest项目实战(4):将工具库顺利迁移到GitHub的完整指南
单元测试·github
油泼辣子多加38 分钟前
2024年11月4日Github流行趋势
github
假装我不帅1 小时前
asp.net framework从webform开始创建mvc项目
后端·asp.net·mvc
超雄代码狂1 小时前
ajax关于axios库的运用小案例
前端·javascript·ajax
神仙别闹1 小时前
基于ASP.NET+SQL Server实现简单小说网站(包括PC版本和移动版本)
后端·asp.net
长弓三石1 小时前
鸿蒙网络编程系列44-仓颉版HttpRequest上传文件示例
前端·网络·华为·harmonyos·鸿蒙
小马哥编程1 小时前
【前端基础】CSS基础
前端·css