Vibe Coding 与 AI Agent 全景知识库

主题

2.2 Git 与 GitHub 入门：时光机、代码云盘、注册与代理配置 ​

多人共同修改一份文档时，文件名很容易变成“终稿”“终稿修改版”“最终确认版”。Git 用提交记录这些变化，GitHub 则提供在线托管与协作空间。学习它们，首先是为了知道改了什么、为什么改，以及如何在出问题时找到可恢复的版本。

阅读开源项目时，也可以沿着提交与讨论了解设计原因。代码展示当前实现，历史记录帮助解释它怎样变成了现在这样。

Git 是什么？下载与安装（5 分钟上手） ​

什么是 Git？（一句话 + 三大特征） ​

Git 是一个「分布式版本控制系统」。它像一个版本档案柜，保存你主动提交的内容与历史关系。尚未提交的改动不会自动成为可恢复的版本，多人修改相同内容时仍可能发生冲突。

  1. 版本存档（时光机）：每个 commit 就是一个存档点，写崩了可以一键回档；
  2. 分布式（人人都是完整仓库）：每个协作者的电脑上都有完整的历史备份，不依赖单一服务器；
  3. 分支协作（平行宇宙）：大家各自开分支干活，最后合并，互不干扰。

⚠️ 注意区分：Git 是装在本地电脑上的“版本管理软件”（离线工具）；GitHub 是全球最大的“代码托管网站”（在线平台）。两者是“引擎”和“4S 店”的关系——先装好 Git，再用 GitHub 做云端备份。

Git 下载与安装 ​

  1. 进入官网下载：打开 git-scm.com，选择对应你系统的版本（Windows / macOS / Linux）；
  2. 一键安装：下载后一路点 “Next” 默认安装即可，无需改任何配置（macOS 也可用命令行安装：brew install git）；
  3. 验证安装成功：打开终端输入 git --version，能输出版本号就说明装好了：
    bash
    git --version   # 例如输出: git version 2.47.0
  4. 设置你的“签名”（提交代码时记录你是谁，只需设置一次）：
    bash
    git config --global user.name "你的名字"
git config --global user.email "你的邮箱"

💡 完全不想碰命令行？直接跳到文末安装 GitHub Desktop 图形化客户端，全鼠标操作也能完成提交与推送。

Git 的“四层空间”说明 ​

很多新手被 git add、git commit、git push 搞得晕头转向，其实它的过程和日常网购退货打包一模一样：

概念与流程示意图

日常最常用 Git 命令速查（一学就会） ​

① 克隆与拉取更新（把代码拿到本地 / 同步最新） ​

bash
# 克隆别人的/自己的远程仓库到本地（第一次用）
git clone https://github.com/用户名/仓库名.git

# 拉取远程最新代码并自动合并（每天开工第一件事）
git pull

# 只下载远程更新但先不合并（想先看看差异再决定时用）
git fetch

git fetch 与 git pull：fetch 只把远程更新下载下来、不自动合并（先看看再说）；pull = fetch + 自动合并（一步到位）。pull 后续采用合并还是变基取决于参数与配置。同步前先检查本地状态，避免把未完成修改与远程更新混在一起。

② 日常提交四连（改完代码的固定动作） ​

bash
git status                        # 1. 查看当前哪些文件被改动了（红色 = 未暂存）
git add README.md                 # 2. 只暂存本次准备提交的文件
git commit -m "feat: 添加用户登录功能"  # 3. 存档打标（备注这次改了啥）
git push                          # 4. 推送到远程云端备份
git log --oneline                 # 额外：查看提交历史（时光机的存档列表）

③ 撤销与回退（新手最救命的三个操作） ​

bash
# 场景1：改乱了，想放弃某个文件的修改，回到上一次提交的状态
git restore README.md

# 场景2：误 add 了不想提交的文件，把它从暂存区撤出来
git restore --staged secret.py

# 场景3：想整体回退到某个历史版本（高危操作，谨慎使用）
git log --oneline              # 先找到目标版本的 commit 号
git show 3f2a9c1               # 查看目标提交；编号仅为示例

⚠️ git reset --hard 是高危命令，会永久丢弃回退点之后的改动。不确定时，优先用 git revert <commit> 生成一个“反向提交”来安全撤销。

④ 分支操作速查（平行宇宙切换） ​

bash
git branch              # 查看当前所有分支（* 号表示当前所在分支）
git switch -c feature   # 新建并切换到 feature 分支
git switch main         # 切换回 main 分支
git merge feature       # 把 feature 分支合并进当前分支

⑤ .gitignore：忽略不应纳入版本管理的文件 ​

新建 .gitignore 文件，把不想上传的内容写进去（每行一个模式）：

gitignore
# 本地密钥
.env
# 下载的依赖
node_modules/
# 运行日志
*.log
# macOS 目录记录
.DS_Store

⑥ HTTPS 与 SSH：两种连接远程仓库的方式 ​

HTTPS 可以配合凭据管理器或令牌使用，SSH 则使用公钥认证。两者都能正常协作，不需要为了学习 Git 先更换连接方式。

选择 SSH 时，按 GitHub 官方连接教程生成密钥、添加公钥并测试。公钥可以交给平台，私钥留在本机。生成新密钥前先查看是否已有同名文件，避免覆盖现有认证材料。

git config user.name 与 user.email 记录的是提交作者，不是登录凭据。作者信息正确，不代表你已经拥有远程仓库的推送权限。

核心概念与生活化实战场景 ​

1. 分支（Branch）与合并冲突（Merge Conflict） ​

    • 你和小明要共同策划一份《日本旅游攻略》。为了不互相打扰，你俩各自复印了一份草稿（拉出各自的 分支）。
    • 你在第 10 行写上了“住东京希尔顿酒店”，小明在第 10 行写上了“住新宿民宿”。
    • 当你们要把两份草稿合并（Merge）成终稿时，Git 就会亮起红灯报警：“发生冲突（Conflict）了。第 10 行你俩写的不一样，请人类自己商量决定留哪一个。”
  • Git 冲突解决说明：
    • 打开冲突文件，你会看到这样的标记：
      markdown
      <<<<<<< HEAD (你的分支)
住东京希尔顿酒店
=======
住新宿民宿
>>>>>>> xiaoming-branch (小明的分支)
    • 删除冲突标记，保留或整合正确内容，保存后重新运行检查，再提交解决结果。

2. GitHub 社交三剑客：Fork、PR 与 Issue ​

概念与流程示意图

  • Fork（复印抄底）：看到别人做了一个很酷的开源贪吃蛇游戏，点击右上角 Fork，把这套代码完整复印一份到你的个人主页里，你在里面怎么改都不会弄坏别人的原版。
  • Pull Request（PR / 合并申请）：你给这套贪吃蛇游戏增加了一个“双人对战模式”，觉得特别棒，向作者发起 PR：“嘿作者，我帮你开发了个新功能，请审查一下合并到官方版本里吧。”
  • Issue（意见与求助信箱）：在玩游戏时发现了一个 Bug，或者想要提个新功能建议，直接在项目的 Issue 专区发帖反馈。

注册与准备远程仓库 ​

从 GitHub 官网注册账户，按当前页面完成邮箱与身份验证。验证形式可能调整，无需记住某一种验证码长度。创建仓库时，确认可见范围和名称，再按页面提示克隆到本地。

如果只想阅读代码，可以直接浏览仓库；准备修改并保存时，再克隆到电脑。Fork 是在平台上建立自己的仓库副本，Clone 是把仓库下载到本地，两者并不是同一个动作。

连接失败时，先区分网络与权限 ​

浏览器能打开仓库，而终端无法克隆，可能是两者使用了不同的网络设置。连接超时、证书错误和没有仓库权限，排查方向也不同。

  1. 核对远程地址是否正确，私有仓库是否授权给当前账号。
  2. 确认使用的是 HTTPS 还是 SSH，检查对应认证方式。
  3. 如果所在网络要求代理，采用管理员或网络服务提供的实际地址，不照抄教程中的端口。
  4. 记录具体错误后再调整配置，避免同时改变认证、代理和远程地址。

偏好图形界面的读者可以使用 GitHub Desktop。它也遵循工作区、暂存与提交的版本管理思路，仍应先看修改差异再提交。

提交之前，实际检查哪些内容 ​

把一次提交看作一份有主题的修改记录。例如“修复搜索空格问题”应该包含相关实现、必要测试和说明，而不是同时混入密钥文件、下载的依赖和无关排版修改。

bash
# 查看尚未暂存的差异
git diff
# 查看已经暂存、准备写入提交的差异
git diff --cached
# 查看当前所在分支和文件状态
git status

.gitignore 只影响尚未被跟踪的文件。已经提交过的密钥，即使后来加入忽略规则，历史里仍可能存在；应先撤销或轮换密钥，再处理仓库记录。忽略规则也不能在同一行用空格附加说明，否则可能改变匹配内容。

本仓库要求：AI 只有收到明确的提交指令后才能执行提交。学习上面的命令，并不意味着每次修改后都应让智能体自动提交。

处理冲突之后为什么还要验证 ​

冲突标记消失，只说明 Git 能保存合并结果，不代表业务逻辑已经一致。一个分支把字段改名，另一个分支新增了使用旧字段的功能，即使文本自动合并成功，程序也可能报错。

处理时先理解双方修改的目的，再决定保留或组合哪些内容。保存后检查相关调用处，并运行对应功能。不要仅以“全部接受当前更改”代替判断。

恢复操作应先确认影响范围 ​

git restore 文件名 会丢弃该文件未暂存的修改；git restore --staged 文件名 只撤出暂存区，不删除工作区内容。两者名称相近，影响不同。

对于已经分享给其他人的提交，通常通过 git revert 新增反向提交来撤销；它也可能产生冲突。git reset --hard 会移动分支并重置工作区，可能丢失未保存工作，不应作为初学时的默认恢复步骤。已提交内容有时能通过引用日志找回，但不能把这一点当成备份。

相关官方平台与权威手册 ​