第十一章：Git 版本控制与跨平台协作
序言
功能越来越丰富，你的本地 Git 仓库里已经积累了厚厚一摞存档记录。一天，你的好朋友也打算跟你一起做。
你可能以为一个人就能搞定。实际情况是：一个人往往精力分散，而 2-3 人小团队——有人负责前端界面，有人负责后端接口，有人负责写测试——反而跑得更快。Git 协作的核心，就是让每个人专注自己的领域，同时保持代码同步。
现在，为了让朋友能拿到你的代码，老师傅告诉你，你需要把这些本地的存档同步到云端。
云端仓库与认证
他向你介绍了代码托管平台（如 GitHub 或国内的 Gitee）。协作的本质其实很简单：你已经在自己的电脑上通过 AI 养成了良好的提交习惯，现在只需要多一步操作——把本地代码同步到云端。
老师傅推荐 SSH 认证：生成一对密钥（公钥给 GitHub，私钥留给自己），这样每次推送都不用输密码，既安全又方便。
在开始之前，你需要在代码托管平台注册账号。除了 GitHub，国内用户还可以选择 Gitee 或 CNB（国内访问更快）。注册很简单，但在终端里登录往往是新手的第一道坎——当你第一次推送代码时，终端会要求你提供凭证。老师傅特意叮嘱：
- 不要输入 GitHub 登录密码：GitHub 已禁用密码登录终端
- 使用 Access Token 或 SSH：Token 是一次性设置，SSH 是长期免密
认证通过后，流程就通顺了：
- 推送：告诉 AI "推送到远程仓库"
- 拉取：告诉 AI "拉取最新代码"
这比互相发压缩包靠谱得多，Git 会精准记录每一行代码是谁在什么时候修改的。
跨平台协作
然而，当你的 Windows 电脑遇到朋友的 Mac 电脑时，你踩到了几个经典的跨平台协作大坑。
一：.gitignore 配置
.gitignore 文件在协作阶段的意义是防止污染队友的环境。如果你不小心把 node_modules 上传了，朋友拉取代码时会下载成千上万个不适配他系统的依赖包，导致项目跑不起来。
告诉 AI："为项目生成合适的 .gitignore，确保不提交 node_modules 和敏感文件"
二：文件名大小写
你的项目在朋友的 Mac 上报错"找不到文件"。你写的是 import Button from './button'，文件名叫 Button.tsx，在 Windows 上能跑，但在区分大小写的系统上就会出错。
三：换行符差异
Windows 使用 CRLF，Mac/Linux 使用 LF。这会导致"假 diff"——Git 显示整文件都改了，实际内容没变。
四：路径分隔符
Windows 用反斜杠 \，但代码中应该永远使用正斜杠 /：
// ✅ 正确
import { Button } from 'src/components/Button';
// ❌ 错误
import { Button } from 'src\\components\\Button';告诉 AI："配置 Git 自动处理换行符，统一使用 LF"
配置完这些，你和小伙伴的协作就顺畅多了。
自动化 Git 工作流
老师傅提醒你，既然你在用 AI 编程，Git 操作完全可以交给 AI：
"每次完成功能或修复 Bug 后，自动提交并推送到远程仓库"
这样你完全不需要记住具体命令。想知道"AI 到底改了什么"？告诉 AI "显示最近的修改记录" 即可。
查看历史与差异
有时候你想看看"AI 到底改了什么"或者"昨天的代码是怎么写的"，告诉 AI：
- "显示最近 5 条提交记录"
- "对比上一个版本改了什么"
- "查看某次提交的详细内容"
AI 会帮你获取并解释这些历史信息。
回滚
Git 是你的"后悔药"。三个常见场景：
场景一：改错了，还没提交 告诉 AI："撤销对 xxx 文件的所有修改"
场景二：已提交，想回到上一个版本 告诉 AI："回退到上一个能跑的版本"
场景三：已推送到云端 告诉 AI："撤销最近一次提交，但不要删除历史记录"
AI 会自动选择合适的命令（checkout、reset 或 revert），你不需要记住它们的区别。
分支
随着项目变大，你可能想尝试新功能，又怕搞坏现有代码。这时候需要分支（Branch）。
老师傅的比喻：分支就像游戏的"存档槽"。主线叫 main（有些旧仓库叫 master），你可以开一个新分支比如 feature-login 折腾新功能。折腾坏了，切回主线；折腾好了，合并到主线。
告诉 AI：
- "创建一个新分支用于开发 xxx 功能"
- "切换到主分支"
- "把功能分支合并到主线"
在协作中，每个人在自己的分支开发，完成后再合并，这样不会互相干扰。
Pull Request 代码审查
在团队协作中，直接把分支合并到主线是危险的——你可能不小心引入了 Bug，影响整个项目的稳定性。
于是，Pull Request（PR） 应运而生。开发完功能后，发起一个 PR 说："我开发了一个新功能，请检查一下代码，没问题再合并进去。"
这个流程的核心价值是代码审查（Code Review）：团队其他人查看代码，提出改进建议，发现潜在问题。研究显示，良好的 Code Review 能减少 80% 以上的错误。在 AI 编程时代，你可以在发起 PR 前让 AI 做 Self-Review，检查逻辑错误、安全漏洞、性能问题等，这样提交的 PR 质量更高。
PR 还带来两个好处：自动化检查（平台自动运行测试，不通过就不允许合并）和讨论记录（在代码行下留言，所有讨论被记录下来）。
老师傅说，虽然对于小团队或者个人项目，PR 可能显得有些繁琐。但当你开始与他人协作，尤其是参与开源项目时，PR 是必不可少的工作流程。不过一开始不用太纠结分支策略，先把主线的自动提交养成习惯，等项目复杂度上来了再引入分支管理。
冲突解决
协作中难免遇到冲突：你和队友同时修改了同一处代码，Git 无法判断该听谁的。
在 VibeCoding 时代，你不需要面对 <<<<<<< HEAD 符号手足无措。把包含冲突标记的文件内容发给 AI：
"解决这个 Git 冲突。保留我和远程最新的逻辑，如果冲突，请以我的为准。"
AI 会帮你完美合并，你只需提交即可。
Git 工作流最佳实践
日常开发：告诉 AI "提交所有修改并推送到远程，写清晰的提交描述"
最常用的命令参考（了解即可，告诉 AI 更方便）：
git add . # 暂存修改
git commit -m "描述" # 提交到本地
git push # 推送到远程
git pull # 拉取远程更新
git log --oneline -5 # 查看最近 5 条提交
git status # 查看当前状态团队协作黄金法则
跨平台协作三原则：
- 配置 .gitignore：告诉 AI "生成合适的 .gitignore，排除 node_modules 和敏感文件"
- 统一换行符：告诉 AI "配置 Git 自动处理换行符为 LF"
- 统一路径分隔符：代码中永远使用正斜杠
/，如src/components/Button
Git 安全警告
⚠️ 绝对不能提交的内容：
- ❌ API 密钥、Token、证书
- ❌ 数据库密码、连接字符串
- ❌ 私钥（
.pem、.key、id_rsa） - ❌ 环境变量文件（
.env、.env.local） - ❌ 个人敏感信息
提交前：告诉 AI "检查是否有敏感文件被提交"
如果已提交敏感信息：告诉 AI "从历史记录中彻底删除 xxx 文件"
常见协作问题速查
| 问题 | 告诉 AI |
|---|---|
| 推送失败 | "先拉取最新代码，解决冲突后再推送" |
| 拉取冲突 | "解决这个 Git 冲突，保留我和远程最新的逻辑" |
| 文件找不到 | "检查文件名大小写是否正确" |
| node_modules 污染 | "从仓库删除 node_modules 并添加到 .gitignore" |
冲突解决提示：把包含 <<<<<<< HEAD 标记的文件内容发给 AI
本章学习路径
- Git 基础与数据流向 → 理解三区模型，命令交给 AI
- 云端仓库与认证配置 → GitHub/Gitee 配置、SSH 设置
- 协作问题诊断与解决 → 跨平台问题、冲突解决
- 团队工作流最佳实践 → 分支策略、PR、Skills 共享规范
AI 编程时代的 Git：理解概念和工作流，具体命令告诉 AI 即可。