你是不是在用 GitHub，却根本不知道自己在干嘛？
闭眼瞎点，迟早会出事。
GitHub 上只有三个绿色按钮。
按下它们之前，你只需要看一个地方。
这篇文章会用红框标出 GitHub 页面上所有需要看、需要点的地方。
连接、提交、检查 diff、合并、撤销。
我们会用 10 张真实截图，带你走完这个完整流程。
打字交给 AI。
你只负责看和点。
遇到难懂的词，我会当场用大白话解释清楚。
※ 本文中的 GitHub 界面和功能说明基于 2026 年 10 月的版本验证。界面后续可能会有变动。
第 1 章：连接 GitHub | 创建仓库并上传本地记录
GitHub 的界面是英文的。
但需要点的位置是固定的。
画面上的红框就是你要看、要点的地方。
在这一章里，你只需要按一个绿色按钮。
首先，创建一个仓库（repository）。
仓库就像一个储物柜，用来在网上存放你的 Git 记录。
关于储物柜里装了什么，以及四个核心术语，我在上一篇文章里讲过。
【图解】给初中生讲明白的 Git
https://x.com/dan_pro_man/status/2107224533099069671?s=20
就算没看过那篇，只看这一篇也能跑通整个流程。
登录 GitHub，点击右上角的 "+" 图标，选择 "New repository"。
直接打开 https://github.com/new 也会进入同一个页面。
你唯一需要填的就是名字。
在 "Repository name" 里输入一个由字母和数字组成的名称。
比如填 "git-practice" 就行。
在 "Choose visibility" 下面选择 "Private"。
意思是不公开。
"Add README" 开关先保持关闭。
如果你本地已经有记录，建一个空仓库再连接会更省事。
点击底部的绿色按钮 "Create repository"。
点完之后跳出的页面，是本章最关键的部分。
靠下的位置有一个标题："…or push an existing repository from the command line"。
它下面的三行命令，就是我们今天要用的。
上面的七行是给本地还没有记录的人准备的，你可以直接跳过。
这三行的意思是：
第 1 行：告诉本地记录，这个储物柜的地址在哪。
第 2 行：把主分支的名字统一改成 "main"。
第 3 行：把 main 分支存进储物柜。
从这个页面复制地址（红框处），用一行话发给 AI。
1把这个文件夹里的记录上传到 https://github.com/account-name/git-practice
Claude Code 会自己敲出这三行命令。
Claude Code 是一个能根据指令在你电脑上干活的 AI。
在我的操作手册里，我要求它在 push 之前必须先确认。
Push 就是把本地记录存进储物柜的操作。
所以它会在这里停一下。
回答 "Yes"，然后刷新浏览器页面。
原来显示三条命令的地方，现在变成了你本地的文件列表。旁边是 commit message（提交信息）。
这就是你已经"连上了"的标志。
这里有一点希望你注意。
文件列表上方的 "main" 字样。
它表示你现在正在看储物柜里的哪个书签。
书签就是分支（branch）。
它标记了你正在往哪一列堆放记录。
接下来不要直接去动这个 "main"。
一开始我也没太在意这个。
结果直接在 main 上干活，最后浪费了大量时间去找该回退到哪里。
连接失败的时候，通常是地址出了问题。
比如漏掉了末尾的 ".git"。
或者账号名拼错了。
如果看到 "not found"，就回到图②重新复制一次地址。
到这里，你的本地记录就已经连上 GitHub 了。接下来是通过 Pull Request 合并的日常流程。
**
第 2 章：通过 Pull Request 合并 | 提交 AI 的工作、检查 diff、然后点按钮
从这里开始，就是日常循环了。
Pull Request 就是一份申请，意思是"请把这个合并进去"。
在这一章里，你需要按三个绿色按钮。
打字交给 AI。
你只负责看和点。
首先，给 AI 发一句话。
1创建一个新分支，在 README 里加 3 行用法说明，commit 后上传到 GitHub
README 是你写仓库说明的第一个文件。
Claude Code 会创建分支。
修改文件，然后 commit。
最后，它会在 push 之前停下来问你。
回答 "Yes"，然后在浏览器里打开那个储物柜。
顶部会出现一条黄色横幅。
它在提醒你："我刚把这个分支存进去了"。
点击右边的绿色按钮 "Compare & pull request"。
这就是"提交"。
就像把草稿本递给老师看一样。
光是提交，并不会把内容抄进正式版本里。
要等检查完才会抄过去。
提交页面有三个地方要看。
第一处：最顶部的箭头。
"base: main" 和 "compare: work-branch"
这表示从哪合并到哪。
只要确认左边是 main 就行。
第二处："Add a title" 里的标题。
如果是 AI 生成的，通常会包含改动摘要。
如果是手动提交，会自动填入 commit message。
手动提交时，用一句话写清楚"做了什么"。
第三处：绿色的 "Create pull request" 按钮。
点下去，提交就生效了。
提交之后，就需要人来操作了。
页面顶部会出现四个标签页。
只看最右边那个 "Files changed"。
意思是"被改动的文件"。
绿色的是新增的行。
红色的是删除的行。
这就是 diff。
如果你让它加的 3 行是绿色的，那就没问题。
示例图中还加了标题和空行，所以一共是 6 行绿色。
如果出现了你没要求过的红色行，就不要合并。
示例图里有 1 行红色。
"Items placed" 里少了一行备忘。
如果你没让它删，就在这里停下。
问 AI："你为什么删掉这行红色的？"
这是把工作交给 AI 时最关键的 30 秒。
以前光是看到 review 通知我就心里发慌，经常看都不看就直接点了。
现在，我会先数红色的行数。
哪怕多出一行没要求过的红色，我都会停下来。
如果 diff 没问题，就回到 "Conversation" 标签页。
靠下的位置有一个绿色的 "Merge pull request" 按钮。
如果上面显示 "No conflicts with base branch"，就可以直接合并。
点一下，按钮会变成 "Confirm merge"。
再点一次。
这样，工作分支的记录就合并进 main 了。
颜色变成紫色，显示 "Merged"。
下方会出现一个提示框："Pull request successfully merged and closed"。
右边是 "Delete branch"。
放心点就行。
消失的只是储物柜里工作分支的那个"书签"。
记录已经合并进 main 了，什么都不会丢。
最后，更新一下本地环境。
对 AI 说："切换到 main，从 GitHub 拉取最新代码"。
这样一个循环就跑完了。
下一个任务要从新分支开始。
不要在 main 上直接干活。
到这里，提交、检查 diff、合并的流程就走完了。接下来讲讲 Revert，也就是合并后用来反悔的按钮。
**
第 3 章：Revert | 合并后发现错了，一键撤销
有时候合并完才发现搞错了。
在 Git 里，"撤销"并不是删掉记录，而是把它抵消掉。
GitHub 页面上就有专门的按钮。
叫 "Revert"。
重新打开你刚刚合并的那个 Pull Request。
里面有一行写着 "merged commit … into main"。
这行的最右边就是 "Revert"。
点下去会发生什么？
记录不会被删除。
而是会新建一个 Pull Request，里面的改动刚好相反。
按照官方文档的说法，当你合并这个新的 Pull Request 时，撤销才算完成。
所以，Revert 走的也是第 2 章那套流程。
检查 diff，点绿色按钮。
不是删掉，而是追加一条"已撤销"的记录。
如果要让 AI 来做，就说："撤销我刚刚合并的那个 Pull Request"。
Claude Code 会用 git revert 做同样的事。
还有一个你可能会碰到的页面。
"This branch has conflicts that must be resolved"。
这就是冲突（conflict）。
当 main 和工作分支对同一行做了不同修改时，就会出现。
绿色按钮会变灰，点不了。
别在页面上硬改，给 AI 发一句话。
1拉取 main，把冲突部分的两个版本都展示给我看
保留哪一个，由你来定。
等 AI 改好重新上传后，绿色按钮就会恢复。
冲突不是失败。
它只是在告诉你：同一行被改了两次。
最后，说一个页面上看不见的东西。
密钥（Keys）。
包含密码或 API key 的文件，绝对不能上传到 GitHub。
就算用了 Revert，密钥一旦传上去就等于泄露了，必须重新生成。
上传前记得跟 AI 说："把 .env 从记录中排除"。
在我自己的工作环境里，我会把 AWS 配置写在文本文件中，走的也是这套流程。
没检查 diff 就合并的配置，会直接跑到生产环境里。
所以，按下按钮前那关键的 30 秒，我绝不交给 AI。
页面上的所有按钮，都由人来点。
不管我把多少工作交给 AI，这条规矩都不会变。
到这里，连接、提交、合并、撤销的完整流程就全部讲完了。
最后，我准备了可以直接用的资料。
我把在 GitHub 页面上跑完一个循环的步骤整理出来了。
文章里用到的页面说明和 prompt，我都打包成了现成的格式。
- GitHub 页面对照海报（9 个页面，69 个术语）
- AI 搞砸时的修复地图（6 种场景）
- 跑完一个循环的 7 条 prompt
- 合并前检查清单（8 项）
合在一起做成了一本 15 页的 PDF 小册子。
光靠这些，你今天就能开始跑循环。
领取方式很简单，加入下面的 Open Chat 即可。
加入后按提示发送"提交"，就会自动发给你。
https://line.me/ti/g2/pEpZQdEyn1BM5Zi2wqLBT2rZYpC0ZaOncIWTag
总结：今天只跑完一个循环就好
不要把 AI 的产出直接塞进 main。
从工作分支提交，检查 diff，然后点绿色按钮。
一个循环里一共要按三个绿色按钮。
我第一次亲手按下 Revert 的那天，才明白记录是不会被删掉的。
从那以后，我就不怕动手了。
不用一口气全学会。
今天只做一件事。
打开第 1 章创建的仓库，给 AI 发一句话。
创建一个新分支，在 README 里加 1 行内容，然后上传到 GitHub
黄色横幅出现后，点绿色按钮，打开 "Files changed"。
如果只有一行绿色，就没问题。
合并之前，用自己的眼睛看一眼那一行。
这就是扩大 AI 可接管范围的第一步。
对 30 岁以上的工程师来说，胜负不在于工作量，而在于设计。
与其每次工具更新都重学一遍，不如先把"哪里该停下来"定义清楚，这样更快。
AWS 和 AI 的迭代速度太快了。
去看别人在真实工作中踩坑的日志，比自己一个人死磕快得多。
在我的 AI × 工程实践中，我不只留下成功的记录，那些搞砸的、被排除的也都会留下来。
欢迎关注我，不错过后续的干货！@dan_pro_man
