Git 基础

• 检查环境： 打开你的终端，输入以下命令，确保 Git 已经安装。

git --version

基础生存技能

登陆

在开始游戏前，你需要创建自己的角色。

• 如果看到版本号，说明已就绪。如果没有，macOS 用户可以通过 brew install git 安装。
• 游戏玩家创建： 让游戏世界知道你是谁。

# 设置你的玩家 ID (请使用你自己的名字)
git config --global user.name "wangenius"
# 设置你的联系邮箱 (通常是你 GitHub 的邮箱)
git config --global user.email "[email protected]"

• 这个身份会记录在你未来的每一次“存档”上。

开启游戏

每个伟大的冒险都需要一个起点。

# 1. 在你的“文稿”里，为冒险创建一个专属地点cd ~/Documents
mkdir my-legendary-quest

# 2. 进入这个新创建的世界
cd my-legendary-quest

# 3. 施放咒语，为这个世界开启“存档功能”
git init

git init 命令会在当前文件夹里生成一个隐藏的 .git 目录。这就是你的 ​“存档芯片”​，所有游戏进度、历史、分支都将保存在这里。

核心循环：从探索到存档

这是你在 Git 世界里最常做的一套连招。

在工作区探索

echo "第一章：一个神秘的开始" > story.txt

这就像你在游戏地图上打了个小怪，或者捡到了一株草药。这个 story.txt 文件就在你的 ​工作区 (Working Directory)​，也就是你当前能看到、能编辑的区域。

​启动雷达，查看状态 (​​​git status​)

git status 是你的“游戏雷达”，随时告诉你周围发生了什么。

git status

Git 会提示你：Untracked files: story.txt。意思是，雷达发现了一个新物品 story.txt，但你还没决定要不要它。

​将战利品放入背包 (​​​git add​)

决定将这个新发现的物品保留下来，放入我们准备存档的“临时背包”——​暂存区 (​​Staging​​​ Area)​。

git add story.txt

现在再用 git status 查看，提示会变为 Changes to be committed: new file: story.txt。这表示 story.txt 已经在背包里，准备好被存档了。

​在存档点创建存档 (​​​git commit​)

当你觉得一个阶段的任务已完成，就可以走到“存档点”（比如篝火或神像），正式记录你的进度。

bash

git commit -m "故事开篇：撰写了第一章的标题"

-m 后面的文字是本次存档的描述，​务必清晰明了​，方便未来的你回忆。这一次 commit，就创建了一个永久的“存档点”，保存在你的“存档芯片”.git 里。

​回顾冒险日志 (​​​git log​)

想看看你都创建过哪些存档吗？

git log

它会像游戏里的任务日志一样，列出你所有的存档记录：存档ID、作者、时间和描述。

即时修正术 (The "Oops!" Moments)

​丢弃刚捡的垃圾装备 (​​​git restore​)

问题： 你改了 story.txt，但还没 add。你突然觉得改得很糟糕，想让它变回 上一次存档时 的样子。

# 让我们给故事加点糟糕的情节
echo "主角出门就踩到了香蕉皮，摔了一跤。" >> story.txt

# 糟糕，这不是我想要的传奇故事！施放“复原”咒语！
git restore story.txt

现在 story.txt 里的糟糕情节就消失了，完美回到了你上次 commit 时的状态。

​从背包里扔掉物品 (​​​git restore --staged​)

问题： 你不小心把一个还未完成的文件 git add 进了背包（暂存区），现在想在存档前把它拿出来。

# 创造一个新计划，并错误地将它放入背包
echo "作战计划：明天再说" > plan.txt
git add plan.txt

# 等等，这个计划太烂了！把它从背包里拿出来！
git restore --staged plan.txt

plan.txt 仍然在你的工作区，但已经从“待存档”的暂存区里移除了。你可以从容地修改它，或者之后再 add。

​重写存档描述 (​​​git commit --amend​)

问题： 你刚刚 commit，但发现存档描述有错别字，或者漏掉了一个小文件。

# 假设你提交时手滑了
git commit -m "故shi开篇" 
# 糟糕，有错别字
# 施放“修正”咒语，直接修正上一次提交
git commit --amend -m "故事开篇：撰写了第一章的标题"

这个命令不会创建新的存档，而是会 覆盖 你上一次的提交。就像你存完档后，立刻选择“覆盖存档”来改个名字一样。

开启平行时空

什么是分支？

想象一下，你的主线任务是“拯救公主”，它发生在 main 这条故事线上。但你突然想去探索一个传说中的“黑暗森林”，这个支线任务可能有风险，可能会失败，也可能会让你获得神器。

你当然不希望在探索时，把主线任务搞得一团糟。​分支​，就是让你开启一条独立的、全新的故事线，去完成这个支线任务。

​开启并进入支线 (​​​git checkout -b​)

让我们开启“探索黑暗森林”的支线任务。

# 创建并立即切换到一条名为 explore-dark-forest 的新故事线
git branch explore-dark-forest
git switch explore-dark-forest

现在，你所做的一切修改，都将发生在这个“平行时空”里。

​在支线上冒险 (​​​add​, ​​​commit​)

你在黑暗森林里奋战，并最终找到了一把传说中的圣剑！你需要把这个伟大的成果“存档”在这条支线上。

# 1. 在故事中记录你的新发现
echo "在黑暗森林的深处，我找到了一把传说中的圣剑！" >> story.txt

# 2. 将这个成果放入背包
git add story.txt

# 3. 在支线上创建存档点
git commit -m "支线任务：获得圣剑"

现在，这个“获得圣剑”的存档点，只存在于 explore-dark-forest 分支上，你的 main 主线对此一无所知，仍然保持着原样。

​满载而归，融合成果 (​​checkout​​ & ​​​merge​)

你带着圣剑，决定回归主线，继续“拯救公主”的伟业。

# 1. 首先，传送回你的主线故事
git checkout main

# 2. 施放“融合”咒语，将支线上的所有成果带回主线
git merge explore-dark-forest

当 git merge 成功后，你在 explore-dark-forest 分支上所做的所有提交（包括那把圣剑），都会被智能地合并到 main 分支上。现在，你的主线故事里也拥有了这把传说中的神器！

高级时空魔法

​安全地“修正”历史 (​​​git revert​)

问题： 你发现几天前的一个存档点（比如 commit "第三章：学习了错误的火球术"）是完全错误的，它给你的项目带来了 Bug。你需要撤销它的影响，但又不想粗暴地删除历史记录（尤其是在团队协作中，删除历史是大忌）。

咒语：git revert <那个错误提交的ID>

效果：revert 不会删除历史。它会创造一个 ​全新的提交​，这个新提交的内容刚好与那个错误提交 ​完全相反​，从而在结果上“抵消”了那次错误的操作。

类比： 你是历史的史官。你不能撕掉或涂改史书上“国王今天下令加税”这一页。正确的做法是，在新的一页郑重地写上：“国王今天颁布新法令，撤销了之前的加税令”。历史被完整保留，但结果被完美修正了。这是团队协作中唯一推荐的“后悔药”。

​毁灭性的时光倒流 (​​​git reset --hard​)

问题： 你在 单人游戏 中，确定最近的几次提交完全是垃圾，你想让这些提交和它们附带的所有修改从世界上彻底消失，就好像它们从未发生过一样。

咒语：git reset --hard <你想回到的那个存档ID>

效果： 你的项目文件夹、暂存区和历史记录，会瞬间回到你指定的那个旧的存档点。所有在那个存档点之后的提交记录和文件改动，都会被 ​永久、彻底地删除​。

类比： 你坐上时光机，回到三天前的某个时刻，然后亲手摧毁了时光机。你不仅回到了过去，还抹除了未来所有的可能性。

⚠️ 终极警告：reset --hard 是 毁灭性 的。它会真正地丢失数据。绝对不要 对已经分享给别人的历史（比如已经 push 到 GitHub 的历史）使用它！它只属于你一个人的“删档重练”大招。

模块四总结： 恭喜你，大法师！你现在掌握了 Git 中最高级的时空魔法，既懂得如何以外科手术般精准、安全的方式修正历史 (revert)，也了解了威力巨大但极其危险的终极咒语 (reset)。

进入多人在线世界 (MMORPG)

本章目标： 掌握与他人协作的秘诀。你将学习如何将你的本地游戏连接到“世界服务器”（如 GitHub），并与队友们同步进度，共同创造伟大的作品。

​加入一场正在进行的冒险 (​​​git clone​)

通常，你加入一个团队时，项目已经存在于一个“世界服务器”上了。你的第一步不是 git init，而是将整个项目复制（或“克隆”）到你的电脑上。

类比： 这就像下载一款已经开服很久的网游。你不需要从零开始创造世界，而是直接下载完整的游戏客户端，包含了所有的地图、任务和历史记录。

如何操作：

1. 在 GitHub、GitLab 或其他代码托管平台上，找到项目的主页。
2. 点击一个绿色的 "Code" 按钮，复制项目的 URL (通常以 .git 结尾)。
3. 在你的终端里，进入你想存放项目的文件夹，然后施放“克隆”咒语：

# 将 <URL> 替换为你复制的链接
git clone <项目的URL>

Git 会将整个项目，包括所有的分支和完整的历史记录，下载到你的电脑上。

​连接世界服务器 (​​​git remote​)

你的本地仓库如何知道要把存档上传到哪里？它通过一个叫做 “远程仓库” (Remote) 的路标来指引。

当你使用 git clone 下载一个项目时，Git 会非常智能地为你自动设置好一个路标，默认名字叫 origin，它指向你下载项目的那个服务器地址。

你可以用以下命令查看你所有的路标：

git remote -v

它会显示出 origin 指向的地址，告诉你“上传”(push) 和“下载”(fetch) 的目标服务器是同一个。

​分享你的冒险成果 (​​​git push​)

你在本地通过 git commit 创建的所有存档点，都只存在于你自己的电脑上。你的队友对此一无所知。当你完成了一个阶段的任务，准备分享给团队时，你需要把这些存档“推送”到世界服务器。

类比：git push 就是“上传云存档”的过程。

假设你在 explore-dark-forest 分支上完成了任务，想让队友看到：

# 语法: git push <远程仓库名> <分支名>
git push origin explore-dark-forest

执行后，你的 explore-dark-forest 分支和其上的所有新提交，都会被上传到 GitHub 上。现在，你的队友也能看到你找到的“圣剑”了！

​同步队友的最新进度 (​​​git pull​)

你在奋战的同时，你的队友可能也在世界的另一端完成了他们的任务，并把他们的存档 push 到了服务器。为了避免你们的进度不一致（比如他建了一座桥，而你的地图上还没有），你需要定期从服务器“拉取”最新的世界状态。

类比：git pull 就是“下载云存档”，更新你的本地游戏到最新版本。

在你开始一天的工作前，或者准备合并分支前，先同步一下主线 main 的最新进度是一个非常好的习惯。

# 语法: git pull <远程仓库名> <分支名>
git pull origin main

这个命令会从服务器下载 main 分支的最新提交，并自动与你的本地 main 分支进行合并。这样，你就总能基于团队的最新成果来展开工作。

团队协作的黄金流程 (The ​​​Pull Request​)

在专业的团队里，通常不会直接向 main 分支 push 或 merge。更安全、更规范的方式是：发起一个​合并请求​​​ (​​Pull Request​​ 或 ​​​PR​​)​。

1. 你在自己的支线（如 my-new-feature）上完成开发，并 push 到服务器。
2. bash

git push origin my-new-feature

1. 然后，你打开 GitHub 网站，会看到一个提示，邀请你为刚刚推送的分支创建一个 ​Pull Request​。
2. 在 PR 里，你会详细描述你做了什么、解决了什么问题。
3. 你的队友们会看到这个 PR，他们可以检查你的代码（Code Review），提出修改意见，甚至进行自动化测试。
4. 所有人都确认无误后，由一位项目负责人点击“Merge Pull Request”按钮，将你的分支安全地合并到 main 分支中。

Pull Request 是 Git 协作的灵魂。它不是一个 Git 命令，而是一个基于 Git 的、标准化的团队协作流程。

冒险者，你已掌握诸多神力，并在 Git 的世界里游刃有余。现在，是时候将所有知识系统化，并为你奉上一份终极的 “技能大全与游戏秘籍” 了。

这份《Git·无限手套》将赋予你掌控时间与空间的力量。它分为两部分：

• 第一部分：技能大全 (Skills Compendium) - 系统化地整理你学过的所有核心技能，如同你的角色技能树。
• 第二部分：游戏秘籍 (Cheat Sheet) - 针对具体场景的快速咒语，方便你随时查阅，解决燃眉之急。

神兵技能大全

​git stash​：你的“次元口袋”

• 场景： 你正在一个分支上开发一个复杂功能，代码改了一半，乱七八糟。突然，老板让你立刻去 main 分支修复一个紧急的线上 Bug！此时你的工作区是“脏”的，无法切换分支。
• ​咒语：​​git stash
• 效果： 这个命令会像一个“次元口袋”，把你当前工作区和暂存区里所有的修改一股脑地塞进去，然后让你的工作区瞬间恢复到上次提交时的干净状态。
• 后续： 现在你可以安心地切换分支去修复 Bug。等 Bug 修完，再切回原来的分支，使用 git stash pop，就能把你之前塞进口袋里的所有修改瞬间释放出来，继续你未完成的工作。

.gitignore​​ 文件：你的“结界”

• 场景： 你的项目在运行时，会自动生成一些日志文件 (.log)、编译文件 (.o, .class) 或包含密码的配置文件 (.env)。你绝对不希望把这些自动生成或敏感的文件提交到版本库里。
• 解决方案： 在你的项目根目录下创建一个名为 .gitignore 的文件。
• 效果： 把它想象成一个“结界”。你在这个文件里写下的所有文件名或匹配规则（比如 *.log 或 node_modules/），Git 就会自动忽略它们，无论你怎么 git add .，它们都不会被加入到版本库中。这是所有正规项目必备的文件。

​git tag​：设置“里程碑”

• 场景： 你的项目终于完成了 v1.0 版本！你想给这个历史性的 commit 打上一个永久的、有意义的标记，而不是那一长串难记的 commit ID。
• ​咒语：​​git tag -a v1.0 -m "版本 1.0 发布"
• 效果： 这就像在你的冒险地图上插上一面旗帜，上面写着“v1.0 - 里程碑”。它让版本发布点一目了然，方便你和团队随时回到这个光辉的时刻。

美化你的 ​​git log

• 场景： 默认的 git log 信息太长太乱。
• 推荐咒语：

git log --graph --oneline --decorate --all

• 效果： 这个咒语会以一种非常紧凑的、带有关联图线的形式，展示所有分支的提交历史。强烈建议你为它设置一个别名（alias），比如 git lg，这样每次输入 git lg 就能看到清晰漂亮的历史线。

游戏秘籍与心法

这些是更偏向“心法”和“理念”的高级技巧，能让你和你的团队协作如丝般顺滑。

解决“合并冲突” (Merge Conflict)

• 场景： 你和你的队友，碰巧修改了同一个文件的同一行代码。当你们试图合并彼此的工作时，Git 懵了，它不知道该听谁的。这就是“合并冲突”。
• 类比： 两个史官，在史书的同一页上，对同一件事写下了不同的记载。国王现在需要亲自决定，到底采用哪个版本，或者结合两者，写出一个新的版本。
• 如何解决： 当 git merge 或 git pull 提示冲突时，你需要：
  • 打开那个冲突的文件。
  • Git 会用 <<<<<<<，=======，>>>>>>> 这样的标记，把两个人的不同修改都展示给你看。
  • 你需要手动编辑文件，决定最终保留哪些内容。
  • 删除那些特殊标记符号。
  • 最后，使用 git add 和 git commit 来提交你解决冲突后的最终版本。
  • 解决冲突是每个开发者的必经之路，第一次会很紧张，但习惯了就好。

​git rebase​：让历史线“更整洁”

• 这是什么：rebase (变基) 是 merge 的另一种选择。merge 会产生一个“合并提交”，保留两条分支交汇的痕迹。而 rebase 会拿起你的分支，找到两条分支的共同祖先，然后把你的分支上的所有修改，在对方分支的最新点上“重放”一遍。
• 效果： 它能创造出一条非常干净、笔直的线性历史，看起来就像你是一个天才，从一开始就预知了所有变化，一气呵成。
• 使用原则： 黄金法则是——永远不要对已经分享给别人的公共分支（如 ​​​main​）使用 ​​​rebase​。它会修改历史，对别人造成困扰。它只适合用在你自己的、还未分享的个人分支上，用来整理你自己的提交记录。

优秀的提交信息 (Commit Message)

• 理念： 你的 commit message 是写给未来的你和你队友看的。一个好的 message 远比一行代码注释更重要。
• 业界标准（如 Conventional Commits）：
  • feat: 添加用户登录功能 (feat = feature, 新功能)
  • fix: 修复无法发送邮件的 bug (fix = bug a修复)
  • docs: 更新项目 README 文档 (docs = 文档)
  • style: 调整代码格式，不影响功能 (style = 格式)
  • refactor: 重构部分代码以提升性能 (refactor = 重构)
  • chore: 更新依赖包或构建脚本 (chore = 杂务)
  • 采用这种规范，能让你的提交历史一目了然，甚至能自动生成项目更新日志。

游戏设置

在 Git 的世界里，git config 命令和 .gitconfig 文件就是你的“设置菜单”。通过它，你可以定制 Git 的方方面面，让这个强大的工具完全符合你的个人习惯，极大地提升效率。这就像给你的角色调整键位、界面和画面效果一样。

​Git 设置的三个层面 (​​​作用域​)

首先，你要知道，Git 的设置分为三个等级，就像游戏里的“默认设置”、“玩家档案设置”和“当前角色设置”，优先级从低到高：

1. --system​​ (系统级):
   1. 作用范围： 这台电脑上的所有用户。
   2. 配置文件位置： 通常在 /etc/gitconfig (macOS)。
   3. 类比： 游戏安装时的默认设置。通常我们很少动它。
2. --global​​ (全局级):
   1. 作用范围： 当前电脑用户的所有 Git 项目。
   2. 配置文件位置： 在你的用户主目录下，一个叫 ~/.gitconfig 的文件。
   3. 类比： 你的“玩家档案”设置。这是我们 最常使用 的设置级别，适用于你所有的冒险。
3. --local​​ (本地级):
   1. 作用范围： 仅对当前这一个项目有效。
   2. 配置文件位置： 当前项目文件夹下的 .git/config 文件。
   3. 类比： 你为一个特定游戏角色（项目）做的专门设置。

当你执行 git config 命令时，不加任何级别参数，默认就是 --local。我们之前设置 user.name 时用了 --global，就是为了让它对你所有的项目生效。

必调设置：优化你的基础体验

这些是强烈建议你配置的基础选项，能让你的游戏体验立刻提升。

我们已经做过了，但它太重要了，必须再提一次。这是你的身份标识。

git config --global user.name "Your Name"
git config --global user.email "[email protected]"

过去，Git 的主分支默认叫 master。现在，社区和 GitHub 都推荐使用 main 作为新的默认主分支名，更具包容性。

# 让未来所有 git init 创建的仓库，默认主分支都叫 main
git config --global init.defaultBranch main

1. ​选择你的魔法卷轴编辑器 (​​​core.editor​)

当你执行 git commit (不带 -m) 或 git merge (有冲突时) 等命令时，Git 会弹出一个文本编辑器让你输入信息。默认通常是 Vim，对新手可能不太友好。你可以将它设置为你更熟悉的编辑器，比如 VS Code。

# 将默认编辑器设置为 VS Code# (需要确保你已经在 VS Code 中安装了 'code' shell command)
git config --global core.editor "code --wait"

现在，写 commit message 就像在 VS Code里写代码一样舒服。

高手进阶：自定义你的神级操作

这是最激动人心的部分！通过别名 (Alias)，你可以把那些长长的、复杂的命令，变成简短的、个性化的“自定义咒语”。

​alias​：创造你的自定义咒语

别名设置都位于 [alias] 区块。

# 咒语1：状态查询 (st)# 将 'git status' 简化为 'git st'
git config --global alias.st status

# 咒语2：分支切换 (co, br)# 'git checkout' -> 'git co'# 'git branch' -> 'git br'
git config --global alias.co checkout
git config --global alias.br branch

# 咒语3：添加所有 (aa)# 'git add .' -> 'git aa' (add all)
git config --global alias.aa "add ."# 终极咒语：美化日志 (lg)# 这是最经典、最强大的别名之一，能显示出非常漂亮的分支图
git config --global alias.lg "log --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit"

设置完这些别名后，你的操作将行云流水：

• 想看状态？输入 git st
• 想切换到 main 分支？输入 git co main
• 想看那令人惊艳的历史日志？输入 git lg

​color.ui​：让你的游戏界面活起来

默认情况下，Git 会在很多地方自动加上颜色。但你可以强制开启它，确保在任何终端环境下，你的 Git 输出都是彩色的。

git config --global color.ui true

​pull.rebase​：设定你的默认合并策略

这是一个偏向个人工作流的设置。执行 git pull 时，默认是 merge 策略。但很多喜欢干净历史线的开发者，更倾向于使用 rebase。

• 类比： 当你和队友的剧情需要合并时，你是希望产生一个“他们俩在这里相遇了”的交汇点 (merge)，还是希望你的剧情线看起来像是“无缝衔接”在队友的剧情之后 (rebase)？

# 设置 git pull 默认使用 rebase 策略# 这能避免很多不必要的 merge commit，让历史更整洁# 如果你不确定，可以暂时不设置此项
git config --global pull.rebase true

如何查看和直接编辑？

• 查看所有配置：

git config --list

• 直接编辑配置文件：
• 所有 --global 的设置都保存在 ~/.gitconfig 这个文本文件里。你可以直接用编辑器打开它来修改或查看。

# 使用你设置的默认编辑器打开全局配置文件
git config --global --edit

• 打开后，它看起来会是这样：

[user]name = Your Name
    email = [email protected]
[init]defaultBranch = main
[core]editor = code --wait
[alias]st = status
    co = checkout
    br = branch
    aa = add .
    lg = log --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit
[color]ui = true[pull]rebase = true

Git 的代理配置主要分为两大场景，取决于你访问远程仓库时使用的 URL 协议： HTTPS 和 ​SSH​。

网络配置

HTTPS

这是最常见的情况。如果你的远程仓库 URL 是以 https:// 开头的（例如 https://github.com/owner/repo.git），就使用这种方法。

这种方式是直接在 Git 的“游戏设置” (git config) 里完成的。

# 为 http 和 https 流量设置同一个代理
git config --global http.proxy http://proxy.example.com:8080
git config --global https.proxy http://proxy.example.com:8080

如果你的代理需要用户名和密码：

git config --global http.proxy http://your_username:[email protected]:8080
git config --global https.proxy http://your_username:[email protected]:8080

# 假设本地 HTTP 代理端口是 7890
git config --global http.proxy http://127.0.0.1:7890
git config --global https.proxy http://127.0.0.1:7890

当你的网络环境变化，不再需要代理时，可以用 --unset 咒语来移除设置：

git config --global --unset http.proxy
git config --global --unset https.proxy

SSH

如果你更喜欢使用 SSH 方式克隆仓库（URL 以 git@ 开头，例如 [email protected]​:owner/repo.git），情况会有些不同。SSH 协议不理会 Git 的 ​​http.proxy​​​ 设置​。

你需要配置 SSH 自身的“传送规则”。

类比： 这不是直接告诉 Git 怎么走，而是告诉你的 SSH “传送师”，当他要去 “GitHub 大陆” 时，必须通过一个你指定的“本地魔法传送阵”（你的代理客户端）。

如何设置

这种方法需要修改 SSH 的客户端配置文件 ~/.ssh/config。

1. 打开或创建配置文件 在终端输入 open ~/.ssh/config。如果文件不存在，就创建一个。
2. 添加代理规则 在文件中添加以下内容。这里我们假设你本地有一个 SOCKS5 代理正在运行，地址是 127.0.0.1，端口是 1080 (这是很多 SOCKS5 代理的默认端口)。

# 对所有 GitHub 的 SSH 连接生效
Host github.com
  HostName github.com
  User git
  # 核心命令：通过 netcat(nc) 工具，使用 SOCKS5 代理连接# -X 5 表示 SOCKS5 协议# -x 后面是你的 本地代理地址:端口
  ProxyCommand nc -X 5 -x 127.0.0.1:1080 %h %p

1. ProxyCommand nc ... 是这里的核心咒语。它告诉 SSH，在连接 github.com 时，不要直接去，而是执行 nc (netcat) 命令，让 nc 通过指定的代理去连接目标主机(%h)和端口(%p)。

• 你的本地代理软件可能会提供 SOCKS5 端口（如 1080），也可能提供 HTTP 端口（如 7890）。请根据你的代理软件设置来修改 ProxyCommand：
  • 如果是 SOCKS5 代理：ProxyCommand nc -X 5 -x 127.0.0.1:1080 %h %p
  • 如果是 HTTP 代理：ProxyCommand nc -X connect -x 127.0.0.1:7890 %h %p

1. 保存文件 保存 ~/.ssh/config 文件后，所有后续通过 SSH 对 github.com 的 git 操作都会自动通过你设置的代理进行。

如何取消代理

直接编辑 ~/.ssh/config 文件，将你添加的那几行配置删除或用 # 注释掉即可。