Git 协作

掌握 Git 的本地操作是版本控制的基础，但在实际开发中，团队协作才是 Git 真正发挥价值的地方。现代软件开发通常是多人协作的结果，需要高效的版本控制和代码管理机制。

本部分我们将介绍 Git 协作的核心概念和实践方法。你将学习两种角色：作为贡献者，如何规范地提交代码变更；作为维护者，如何高效地管理项目并整合来自社区的贡献。

协作模式

传统的集中式版本控制系统（如 SVN）采用客户端-服务器架构，所有开发者都直接与中央服务器交互。这种模式管理集中，但在高并发场景下容易出现性能瓶颈和单点故障。

Git 的分布式架构则提供了更大的灵活性。每个开发者都拥有完整的仓库副本，可以独立工作，也可以与任意远程仓库交互。这种设计支持多种协作模式，适用于不同规模和类型的项目。

集中式工作流（Centralized Workflow）

集中式工作流是最接近传统版本控制的模式，适合小型团队或刚接触 Git 的团队。

在这种模式下，团队共享一个中央远程仓库。所有开发者都从这个仓库克隆代码（git clone），在本地完成开发后，将更改推送回中央仓库（git push）。

当多个开发者同时修改同一文件时，可能会出现冲突。例如，开发者 A 和 B 都从中央仓库拉取了代码，各自进行修改。如果 A 先完成并推送了更改，B 在推送时会被 Git 拒绝，提示需要先拉取最新的更改（git fetch 和 git merge），解决可能的冲突后再推送。

这种模式简单直观，适合习惯了集中式管理的小型团队。

Fork 工作流（Forking Workflow）

Fork 工作流是目前最流行的协作模式，也是 GitHub、GitLab 等平台推荐的方式。这种模式特别适合开源项目，允许任何人对项目做出贡献，同时保护主仓库的稳定性。

工作流程如下：

这种模式的优势在于权责分离：维护者可以控制代码质量，贡献者可以在自己的空间自由开发，互不干扰。

分层式工作流（Hierarchical Workflow）

分层式工作流适用于大型项目，如 Linux 内核、Git 本身等拥有大量贡献者的项目。

这种模式采用层级管理结构：

• 项目维护者（Benevolent Dictator）：拥有最终决策权，负责项目的整体方向和最终整合
• 模块维护者（Lieutenants）：负责特定模块或子系统，审查和整合该领域的贡献
• 贡献者（Contributors）：提交代码到对应的模块维护者

工作流程如下：

这种层级化的管理模式能够有效分担审查工作，让项目维护者专注于整体架构和关键决策，同时高效整合来自全球的大量代码贡献。

代码贡献最佳实践

理解了不同的协作模式后，我们来讨论如何规范地贡献代码，让你的提交清晰、专业、易于审查。

提交规范

每次提交（commit）应该是一次逻辑完整的修改。将相关的更改组织在一起，将不相关的修改分开提交，这样有助于代码审查和问题追踪。

例如，如果你在周末同时修复了五个不同的 bug，不要将它们打包成一个巨大的提交。应该利用暂存区（Staging Area），将工作拆分成多个独立的提交，每个提交对应一个问题，并配以清晰的提交信息。

高质量的提交信息通常遵循以下格式：

• 标题行：用 50 个字符以内的文字，以祈使句（动词开头）简明扼要地概括修改内容。例如，写“修复用户登录 bug”，而不是“我修复了用户登录 bug”。
• 空一行：这至关重要，很多工具会依赖这个空行来区分标题和正文。
• 正文（可选）：如果需要，用更详细的文字解释你为什么要做这个修改，以及你的实现思路是怎样的。

清晰的提交历史有助于团队成员理解项目的演进过程，也便于问题定位和版本回退。

协作模式选择

根据团队规模和项目性质，选择合适的协作模式：

• 小型团队：建议使用集中式工作流或简单的分支策略。每个开发者在自己的分支上工作，完成后检查主分支的更新，解决冲突后推送更改。
• 中型团队：采用功能分支工作流。各自负责不同功能的开发，完成后通知整合者。整合者将各个功能合并到开发分支，测试通过后更新到主分支。
• 公共开源项目：使用 Fork 工作流。贡献者需要 Fork 项目，在自己的分支上开发新功能。完成后，通过 Pull Request 提交，根据审查意见进行调整，直到代码被合并。

项目维护与管理

主题分支

当收到一份贡献（无论是通过 Pull Request 还是邮件补丁）时，最佳实践是不要直接在主分支（如 master 或 main）上应用更改。应该创建一个临时的主题分支（Topic Branch）来评估和测试这份贡献。

例如，一位名为 zhangsan 的贡献者提交了一个优化搜索功能的补丁，你可以这样做：

|
git checkout -b zhangsan/search-optimization master

在这个独立的分支上，你可以安全地评估、测试甚至修改这份贡献，而不会影响主分支的稳定性。如果测试不通过，可以暂时搁置；如果一切顺利，再考虑将其合并到主分支。

合并、变基与拣选

当一份贡献在主题分支上验证通过后，你有几种方式将其整合到主分支：

• 合并 (Merge)：使用 git merge zhangsan/search-optimization 可以在主分支上创建一个新的合并提交，保留完整的历史记录。这种方式适合需要保留分支历史的场景。
• 变基 (Rebase)：使用 git rebase master zhangsan/search-optimization 可以将贡献者的修改在主分支的最新版本上重放，形成线性的历史记录。这种方式能保持提交历史的整洁，但会改写历史。
• 拣选 (Cherry-pick)：使用 git cherry-pick <commit-id> 可以选择性地将某个提交整合到你的分支中。这种方式适合只需要部分更改的场景。

选择哪种方式取决于团队的需求和项目策略。追求完整历史记录使用 merge；追求整洁的线性历史使用 rebase。

版本管理与发布

当项目达到重要的里程碑时，使用 Git 的标签功能为当前版本打上标记：

|
git tag -a v1.0 -m "第一个正式版本"

标签有助于版本管理，让团队成员和用户能够轻松识别和回溯到特定的版本。

此外，git archive 命令可以将当前版本的代码打包成 zip 或 tar.gz 格式的压缩包：

|
git archive --format=zip --output=release-v1.0.zip v1.0

这对于不使用 Git 的用户来说，提供了一种便捷的方式来获取项目的特定版本。

git shortlog 工具能够自动生成更新日志，详细列出每个版本的变更和贡献者：

|
git shortlog v0.9..v1.0

这对于发布公告和记录项目进展非常有用，帮助团队和用户了解项目的演变过程。