终于进入 Git 的核心玩法啦！分布式不是玄学，而是让多个开发者像搭积木一样高效协作的神器 🧩。想象一下：你在公司写代码，同事在家改功能，远程队友补 bug，最后所有修改能完美融合——这就是分布式 Git 的魔力！
本章我们会从「协作流程」「贡献代码」「维护项目」三个维度，用最接地气的例子 + 实操代码，让初学者也能轻松拿捏分布式协作～
集成管理者 workflow
独裁者与副手 workflow
1. 集中式工作流程 – 最像 SVN 的入门款 🚪
如果你的团队刚从 SVN 迁移到 Git，不想改变习惯？集中式 workflow 就是最佳过渡方案！
核心逻辑 ：所有人共享一个「中央仓库」，代码只能推送到这个仓库，谁先推谁优先，后推的人必须先合并别人的修改。
# 1. John 克隆仓库并提交修改
git clone john@githost:simplegit.git
cd simplegit
vim lib/simplegit.rb # 修改代码
git commit -am “ 修复默认值错误 ”# 2. Jessica 同时克隆并提交
git clone jessica@githost:simplegit.git
cd simplegit
vim TODO # 添加任务
git commit -am “ 新增重置任务 ”
# 3. Jessica 先推送成功
git push origin master
# 4. John 推送失败（需要先合并 Jessica 的修改）
git push origin master # 报错：non-fast forward
git fetch origin # 拉取 Jessica 的修改
git merge origin/master # 本地合并
git push origin master # 合并后推送成功
2. 集成管理者工作流程 – GitHub 最常用 🐙
开源项目、跨团队协作首选！核心是「fork+PR」，每个开发者都有自己的仓库副本。
流程拆解 ：
- 项目维护者把代码推到「官方仓库」（比如 GitHub 上的主仓库）
- 你 fork 官方仓库，得到自己的「副本仓库」（可写权限）
- 在自己的副本仓库里改代码、提交、推送
- 给官方仓库发「Pull Request」（PR），请求维护者拉取你的修改
- 维护者审核后，合并到官方仓库
git clone https://github.com/ 你的用户名 / 项目名.git
cd 项目名# 2. 创建功能分支（避免直接改 master）
git checkout -b feature- 新增功能
# 3. 写代码、提交
vim 文件名
git commit -am “ 实现 XXX 功能 ”
# 4. 推送到自己的仓库
git push origin feature- 新增功能
# 5. 去 GitHub 上给官方仓库发 PR（网页操作）
3. 独裁者与副手工作流程 – 大型项目专属 🦸♂️
像 Linux 内核这样有上千名贡献者的超级项目，就靠这种流程管理！
层级结构 ：
- 「独裁者」：项目总负责人（比如 Linus），只有他能合并代码到最终主分支
- 「副手」：分管某个模块（比如网络、文件系统），审核该模块的贡献
- 「普通开发者」：向对应模块的副手提交代码
流程类比 ：就像公司里的审批流程——员工→部门经理→CEO，层层把关，保证代码质量。
冲突解决
补丁提交
1. 提交信息的黄金法则 – 别人能看懂才是好提交 📝
新手最容易犯的错：提交信息写「修复 bug」「更新代码」——这种信息等于没写！
规范格式 ：
修复登录时用户名大小写敏感的问题# 空一行后：详细说明（72 字换行）
– 问题描述：用户输入大写用户名时无法登录，小写正常
– 解决方案：在验证用户名时统一转为小写比较
– 影响范围：仅登录接口，不影响其他功能
为什么要这样写？ 当项目有上千次提交时，`git log` 能快速筛选有用信息，维护者不用点开代码就知道你改了啥。
2. 避免 ” 大爆炸 ” 提交 – 一次只改一件事 ⚡
新手常犯的另一个错：周末写了 5 个功能，周一打包成一个超大提交——维护者审核时会崩溃！
正确做法 ：一个功能 / 一个 bug 对应一个提交，用分支拆分工作。
git checkout -b feature- 搜索功能 # 新建搜索功能分支
# 写搜索功能代码
git commit -am “ 实现搜索功能：支持关键词模糊匹配 ”
git checkout master
git checkout -b feature- 分页功能 # 新建分页功能分支
# 写分页功能代码
git commit -am “ 实现分页功能：每页显示 10 条数据 ”
好处 ：维护者可以分别审核，就算其中一个功能有问题，另一个也能正常合并。
3. 冲突解决 – 协作中不可避免的 ” 小摩擦 ” 🤜🤛
当两个人同时改同一个文件的同一行代码，就会产生冲突——别慌，Git 会帮你标记冲突位置！
冲突场景模拟 ：
- 你拉取了最新代码，开始修改文件 A 的第 10 行
- 同事同时修改了文件 A 的第 10 行，并先推送到仓库
- 你推送时失败，需要先拉取并合并
git fetch origin
# 合并（此时会提示冲突）
git merge origin/master# 打开冲突文件，会看到这样的标记：
# <<<<<<< HEAD（你的修改）# 你的代码内容 # ======= # 同事的代码内容 # >>>>>>> origin/master（同事的修改）
# 编辑文件，保留正确的代码，删除冲突标记
vim 冲突文件
# 标记为已解决，提交合并结果
git add 冲突文件
git commit -m “ 合并同事修改，解决文件 A 的冲突 ”
# 推送
git push origin master
4. 给老项目发补丁 – 没有仓库权限怎么办？📩
有些老项目不支持 GitHub 的 PR，只接受邮件补丁——Git 也能搞定！
git checkout -b patch- 修复问题 origin/master# 2. 修复问题并提交
git commit -am “ 修复 XXX 问题 ”
# 3. 生成补丁文件（格式：0001- 提交信息.patch）
git format-patch -M origin/master # -M 检测文件重命名
# 4. 用邮件发送补丁（可以用 git send-email）
git send-email –to 项目邮箱 0001-*.patch
补丁文件会包含你的提交信息、代码修改内容，维护者收到后可以直接应用到项目中。
补丁应用
版本发布
1. 用主题分支测试贡献 – 安全第一 🛡️
作为维护者，不能直接把别人的代码合并到主分支——万一有 bug 呢？
正确操作 ：为每个贡献创建「主题分支」，测试通过后再合并。
git checkout -b contributor-feature 贡献者用户名 / 分支名# 2. 测试代码（运行单元测试、手动验证功能）
./run_tests.sh # 假设项目有测试脚本
# 3. 测试通过，合并到主分支
git checkout master
git merge contributor-feature
git push origin master
# 4. 删除临时主题分支
git branch -d contributor-feature
2. 应用补丁 – 处理邮件提交的贡献 📥
如果有人给你发了.patch 格式的补丁文件，用 `git am` 命令快速应用：
git apply –check 0001- 修复问题.patch# 2. 应用补丁（会自动创建提交）
git am 0001- 修复问题.patch
# 如果补丁有冲突，解决后继续
# 编辑文件解决冲突
git add 冲突文件
git am –resolved
对比 `git apply`：`git am` 会保留贡献者的姓名、邮箱和提交信息，而 `git apply` 只应用代码修改，需要自己手动提交。
3. 版本发布 – 给你的项目打标签 🏷️
当项目达到稳定状态（比如 v1.0），需要打标签标记这个版本，方便用户下载。
git tag -s v1.0 -m “ 正式发布 v1.0 版本 ”# 2. 推送标签到远程仓库（标签不会随 git push 自动推送）
git push origin v1.0
# 3. 生成发布包（给不使用 Git 的用户）
git archive master –prefix=” 项目名 -v1.0/” –format=zip > 项目名 -v1.0.zip
签名标签的作用 ：用你的 PGP 密钥签名，别人可以验证这个版本确实是你发布的，没有被篡改。
4. 复杂项目的分支策略 – 长期分支管理 📊
大型项目通常会维护多个长期分支：
- master：稳定版本分支，只有发布时才更新
- develop：开发分支，所有功能合并到这里，测试稳定后再合并到 master
- maint：维护分支，用于给旧版本打补丁（比如 v1.0 出了 bug，从 v1.0 标签创建 maint 分支修复）
5. 神器 rerere – 重复冲突自动解决 🤖
如果同一个分支经常和主分支冲突，每次都手动解决太麻烦？开启 rerere 功能！
git config –global rerere.enabled true
原理 ：Git 会记录你上次解决冲突的方式，下次遇到完全相同的冲突时，自动套用上次的解决方案——不用再手动编辑文件！
比如你维护的 feature 分支，每次合并 master 都要解决同一个文件的冲突，开启 rerere 后，第一次手动解决，之后 Git 会自动处理～
场景 1：多人协作同一个功能 🤝
比如你和同事一起开发「支付模块」，可以创建一个共享分支：
git checkout -b feature- 支付模块
git push origin feature- 支付模块# 2. 同事拉取这个分支
git fetch origin
git checkout feature- 支付模块
# 3. 同事修改后推送
git commit -am “ 添加微信支付 ”
git push origin feature- 支付模块
# 4. 你拉取同事的修改
git pull origin feature- 支付模块
注意 ：每天开始工作前先 pull，避免本地代码过时导致大量冲突！
场景 2：提交错分支了怎么办？😱
比如你想提交到 feature 分支，却不小心提交到了 master——用 cherry-pick 转移提交！
git log master # 假设提交 ID 是 abc123# 2. 切换到正确的 feature 分支
git checkout feature- 目标分支
# 3. 把错误提交转移过来
git cherry-pick abc123
# 4. 删除 master 上的错误提交（如果还没推送）
git checkout master
git reset –hard HEAD~1 # 撤销最后一次提交
场景 3：贡献被维护者要求修改 📝
你的 PR 被维护者说 ” 这里要改一下 ”——不用重新发 PR，直接在原分支修改并推送！
git checkout feature- 你的功能# 2. 修改代码（根据维护者的意见）
vim 文件名
# 3. 提交修改（如果之前的提交需要调整，用 –amend）
git commit –amend # 修改最后一次提交
# 或者新建提交
git commit -am “ 根据审核意见修改 XXX”
# 4. 强制推送（因为修改了历史提交）
git push -f origin feature- 你的功能
PR 会自动更新，维护者能看到你的修改——不用重新创建 PR！
- 选择适合团队规模的工作流程：小团队用集中式，开源项目用集成管理者，超大型项目用独裁者与副手
- 提交代码要遵循规范：一次一事、信息清晰、格式正确
- 冲突不可怕，本地合并 + 沟通是关键
- 维护项目要注重安全：用主题分支测试、打签名标签、合理管理长期分支
要不要我帮你整理一份 Git 分布式协作速查表 ？包含常用命令、冲突解决步骤、PR 提交模板，打印出来就能直接用～