为大型团队扩展 Git

在小团队中使用 Git 很简单。但当项目发展到拥有数百甚至数千名开发者，或者仓库变得庞大无比时，会发生什么？

本课将探讨如何在大型分布式开发团队中有效管理 Git 仓库和工作流的策略与最佳实践。

大型团队需要做出的一个关键决策，是在单体仓库（所有项目共用一个庞大仓库）和多仓库（多个较小且彼此独立的仓库）之间进行选择。

• 单体仓库：代码库集中，跨项目重构更容易。
• 多仓库：项目彼此解耦，克隆内容更少，发布周期相互独立。

在 Git 的扩展方面，两者各有挑战和优势。

大型仓库，尤其是单体仓库，可能导致性能瓶颈：

• 克隆缓慢：需要下载多年的历史记录和数 GB 的数据。
• 获取或拉取缓慢：同步更改需要时间。
• 检出缓慢：Git 需要处理大量文件。

这些问题会严重影响开发者的生产力。

对于新团队成员或 CI/CD 流水线来说，下载完整历史记录可能没有必要。浅克隆允许您指定深度，只获取最近的提交。

这会大幅减少克隆耗时和磁盘空间占用，尤其适用于非常老旧或大型的仓库。

除了浅克隆之外，Git 还提供部分克隆。您可以先克隆仓库，而不立即下载所有“文件内容对象”（文件内容）或“目录结构对象”（目录结构）。

需要时，对象会按需获取，从而让真正庞大的仓库也能实现极快的初始克隆。

在单体仓库中，您通常只会处理一小部分文件。稀疏检出允许您定义模式，只检出特定子目录或一组文件，并忽略其余内容。

这样可以保持工作目录整洁，并加快 git status 和 git checkout 等操作。

有时，您需要同时处理同一仓库中的两个不同分支，而不必来回切换。git worktree可以创建多个相互关联的工作目录。

每个工作树都是一个独立的工作区，指向不同的分支，让上下文切换变得顺畅。

对于地理位置分散的团队，连接中央 Git 服务器时产生的网络延迟可能成为主要瓶颈。一种解决方案是使用镜像仓库。

镜像仓库是主仓库的完整副本，托管在更靠近开发中心的位置。团队可以从本地镜像推送和拉取，然后再与主远程仓库同步。

开发者众多时，保持工作流一致至关重要。请为以下方面制定明确的指南：

• 分支策略：例如 Gitflow、GitHub Flow（前面的课程中介绍过）。
• 提交消息格式：标准化的消息有助于提高历史记录的可读性。
• 代码审查流程：确保质量并促进知识共享。

工具和自动化可以强制执行这些标准。

您正在处理一个巨大的单体仓库，只需要处理 src/frontend 目录。哪个 Git 功能最适合帮助您只检出仓库的这一部分，从而提升性能？

我们探讨了在大型团队和超大仓库中有效管理 Git 的几种策略：

• 使用浅克隆和部分克隆加快初始设置。
• 利用稀疏检出和git worktree管理单体仓库。
• 为分布式团队实施镜像仓库。
• 强调标准化工作流，确保协作一致。

随着项目不断发展，这些技术有助于保持生产力和性能。