Git 多人协作开发

引言

⚠️ 注意

本文不提供基本的 Git 介绍与相关指令的使用教程，本文的关注重点在于规范一套分支工作流和分布式工作流，用于团队开发场景下的多人协作。
💡 Tip

Git 速查表：

英文版

中文版

统一远程仓库

约定一个统一的远程仓库，作为代码共享的基础。团队成员通过此远程仓库同步代码。

本文中，我们以GitHub 作为统一的远程仓库。

分支模型

💡 Tip

✨ Git 的分支特性使得基于分支的协作开发易如反掌。因此，我们规范如下分支模型角色：

: 只包含完全稳定的代码，始终保持可部署状态。

复制代码

> 此分支禁止直接提交，仅通过合并其他分支更新。

: 开发集成分支，通常从这个分支开始工作或测量稳定性；此分支包含下一版本的最新开发成果，团队成员从这里创建特性分支，完成后合并回来。

复制代码

> 此分支不一定总是稳定的，但只要它达到稳定状态，就可以合并到 `master / main` 中。

: 特性分支，用于开发新功能、新特性（如 feature/user-login）。

复制代码

> 特性分支是一种短期分支，从 `develop` 分支创建，完成后合并回 `develop`，随后删掉它。
> 💡 **Tip**
>
>
> ✨ Git 允许并鼓励拥有多个完全独立的本地分支，创建、合并和删除这些分支的成本非常低------仅仅只需几秒钟。
>
> 在 Git 中，每天创建、工作、合并和删除分支是司空见惯的。

✒️ 渐进式稳定性分支的 "筒仓" 视图

由以上的分支模型角色不难看出：稳定分支在提交历史中靠下，而最前沿的分支则在历史中靠上，它们呈现出一种渐进式的关系。

通常更容易将它们视为工作"筒仓"（silo），当一系列提交经过充分测试后，就会"毕业"到更稳定的筒仓中。

:
紧急修复分支，用于修复生产环境问题（如 hotfix/bug-login）。
从 master / main 分支创建，修复后同时合并到 master / main 和 develop，随后删掉它。

:
发布分支，用于版本发布前的测试和准备（如 release/v1.0）。
> 从 develop 创建，测试通过后合并到 master / main 和 develop。

项目参与者的分布式工作流

✒️ NOTE

在了解上述分支扮演的角色后，是时候尝试以此分支模型进行协作开发了。

我们的 开发模型 选择为 "共享仓库模型"。

我们以一个项目参与者（非管理员）的视角出发，以常见的开发新特性（功能）为例，为项目做出贡献。

假设项目管理员已经创建了远程仓库，目前远程仓库已有 main 和 develop 两个初始分支。

整个协作流程看起来是这样的：

1. 克隆仓库

bash 复制代码

git clone https://github.com/libgit2/libgit2.git    # 使用目标仓库的 url 链接

2. 创建特性分支

从最新的 develop 分支创建新特性分支

bash 复制代码

# 切换到本地 develop 分支（运行此命令 Git 会自动创建一个跟踪 origin/develop 的 develop 分支）
git checkout develop        # 或者使用 git switch develop
# 确保本地 develop 分支与远程同步
git pull origin develop

# 创建并切换到特性分支
git checkout -b feature/*   # 或者使用 git switch -c feature/*

💡 Tip

有关于远程跟踪分支、跟踪分支、本地分支之间的联系，可以参考 Git 分支-远程分支。

一句话概括就是：
远程跟踪分支 是远程分支的本地镜像；
跟踪分支 是关联了该镜像的本地分支；
本地分支 是未关联任何镜像的普通本地分支。

如下是一些可能常用的分支查看命令：

命令	介绍	备注
`git branch`	列出所有本地分支	- 当前分支会显示 `*` 号
`git branch -a`	列出所有分支（包括远程）	- 显示本地 + 远程分支 - 远程分支会以 `remotes/` 开头
`git branch -r`	查看远程分支	- 只列出远程跟踪分支
`git branch -v`	查看分支详情（最后提交）	- 显示每个分支的最后一次提交信息
`git branch -vv`	显示详细的分支跟踪信息	- 显示上游分支（跟踪分支）的信息

3. 本地开发与提交

开发过程中，频繁提交代码

bash 复制代码

# 查看修改
git status
git diff

# 添加修改到暂存区
git add <文件名>        # 或者使用 git add . 添加所有修改

# 提交（包含清晰的提交信息）
git commit -m "feat: 实现用户登录接口的权限绑定"

💡 Tip

小步迭代，便于回溯

提交信息需遵循规范要求，例如：
- feat: 新增 xxx 功能（新功能）
- fix: 修复 xxx bug（bug 修复）
- docs: 更新 API 文档（文档修改）

4. 同步远程更新

本地特性分支开发过程中，其他成员可能已向远程仓库的 develop 分支推送了新的提交。因此需定期同步远程更新到本地，避免冲突：

bash 复制代码

# 切换到本地 develop 分支
git checkout develop        # 或者使用 git switch develop
# 确保本地 develop 分支与远程同步
git pull origin develop

# 切换到本地特性分支
git checkout feature/*      # 或者使用 git switch feature/*
# 合并 develop 的更新（或者使用✨变基命令保持提交记录整洁）
git merge develop           # 或者使用 git rebase develop

5. 推送分支到远程

完成开发后，将本地特性分支推送到远程仓库，与团队成员共享：

bash 复制代码

git push -u origin feature/*    # -u 选项用于指定跟踪关系

6. 代码审查（PR/MR）

通过远程仓库平台创建 P ull R equest（GitHub）或 M erge R equest（GitLab），请求将 feature/* 合并到 develop：

由负责人进行代码审查，检查代码风格、逻辑正确性、测试覆盖等。
审查过程中，若需修改，直接在本地特性分支修改并推送，PR 会自动更新。

7. 合并代码并清理

审查通过后，将 feature/* 合并到 develop（可通过远程仓库平台合并，或用命令行）。

合并后，删除远程和本地特性分支（避免冗余）

bash 复制代码

# 删除远程仓库的分支
git push origin --delete feature/*  # 或者直接在远程仓库平台删除

# 切换到本地 develop 分支
git checkout develop                # 或者使用 git switch develop
# 删除跟踪分支
git branch -d feature/*
# 删除远程跟踪分支
git branch -rd origin/feature/*     # 或者使用 git fetch -p

# 同步合并后的最新代码
git pull origin develop

8. That's all

最佳实践

保护核心分支 ：在远程仓库设置分支保护规则（如 main、develop），禁止直接推送，必须通过 PR 并经审查后合并。
基于特性的工作流：为正在开发的每个新特性创建新分支，以便无缝地在它们之间来回切换，然后当该特性合并到主线时删除每个分支。
频繁同步 ：每天至少同步一次远程 develop 分支到本地，减少冲突概率。
小步提交：每个提交只包含一个逻辑修改（如一个功能点、一个 bug 修复），便于回溯和撤销。
忽略无关文件 ：通过 .gitignore 文件排除临时文件、依赖包（如 node_modules/）、IDE 配置等，避免提交冗余内容。

GitHub 在 "github/gitignore" 公共存储库中维护建议用于许多常用操作系统、环境及语言的 .gitignore 文件的正式列表。还可以使用 gitignore.io 创建 .gitignore 文件，以用于操作系统、编程语言或 IDE。有关详细信息，请参阅 github/gitignore 和 gitignore.io 站点。
使用标签版本管理 ：发布版本时，在 main 分支创建标签（如 v1.0.0），便于追溯历史版本：
bash 复制代码
```
git tag -a v1.0.0 -m "发布v1.0.0版本"
git push origin v1.0.0
```
结合 CI/CD：通过 GitHub Actions、GitLab CI 等工具，在 PR 阶段自动运行测试、代码检查，确保合并质量。
...

参考

^[1] 《Pro Git》

^[2] 拉取请求文档 - GitHub 文档