跳到正文
一AllOne
关注

上手教程

Git 和 GitHub 最少要会的那些

一个人做项目，用不到 Git 的全部功能，但有十来个命令和几个概念是绕不开的。这篇只讲最少必要的部分：三种状态、提交、分支、推送拉取、忽略文件、撤销，以及密钥不小心提交了怎么办。

发布于 2026-10-22 · 最后核实：2026-10-22 · 文中价格与额度以各官网为准

Git 的命令有上百个，完整学下来是一本书的分量。但一个人做网站、做小产品，日常真正用到的，不过十来个命令。尤其是现在用 AI 写代码，Git 不再是「程序员才需要的东西」——它是你的存档系统和后悔药。

结论先说：记住「改 → 暂存 → 提交 → 推送」这条主线，学会开分支和撤销，再管好 .gitignore 和密钥，就够你用很久了。

先分清 Git 和 GitHub

  • Git 是装在你电脑上的版本管理工具，负责记录项目的每一次「存档」。不联网也能用。
  • GitHub 是一个托管 Git 仓库的网站。它让你的存档有一份云端备份，也是 Vercel、Netlify、Cloudflare Pages 这类部署平台读取代码的地方。

类似的托管网站还有 GitLab、Gitee 等，本文的 Git 命令对它们同样适用。

三个概念：工作区、暂存区、提交

Pro Git 一书把文件在 Git 里的状态归纳为三种：

  1. 已修改（modified）：你改了文件，但还没告诉 Git 要保存它。
  2. 已暂存（staged）：你标记了「这些改动要放进下一次存档」。
  3. 已提交（committed）：改动已经安全地存进了 Git 的历史记录。

可以把它想成寄快递：工作区是你的桌面，暂存区是打包好的箱子，提交就是把箱子交给快递员并拿到单号。之所以多一个「暂存」步骤，是为了让你可以挑选：桌上改了五个文件，这次只寄其中三个。

Git 记录的是项目在每次提交时的完整快照。Pro Git 里有一句话很值得记住：一旦提交，改动就很难丢失；没提交的改动才是真正容易丢的。所以，勤提交。

第一次使用：配置和建仓库

安装 Git 后，先告诉它你是谁（这会写进每一次提交记录）：

git config --global user.name "你的名字"
git config --global user.email "你的邮箱"

如果不想公开个人邮箱，GitHub 在账号设置里提供了一个专用的匿名邮箱地址，可以用它代替。

在项目文件夹里初始化仓库：

git init

或者从 GitHub 上把已有的仓库拉到本地：

git clone 仓库地址

日常主线：改 → 暂存 → 提交 → 推送

git status                 # 看看现在有哪些改动（最常用，随时敲）
git diff                   # 看具体改了什么
git add 文件名              # 把某个文件放进暂存区
git add -A                 # 把所有改动都放进暂存区
git commit -m "说明这次改了什么"   # 提交
git push                   # 推送到 GitHub
git pull                   # 把 GitHub 上的新改动拉到本地
git log --oneline          # 查看提交历史，一行一条

第一次推送新仓库时，需要先关联远程仓库（GitHub 新建仓库后的页面上会给出完整命令，照着复制即可）。

连接 GitHub 的认证方式：通过 HTTPS 推送时，GitHub 不接受账号密码，需要用个人访问令牌（token）；也可以配置 SSH 密钥，或者用 GitHub 官方的命令行工具 / 桌面客户端登录，让它替你处理认证。选一种你觉得最顺手的即可。

提交信息怎么写

一句话，说清楚这次改动做了什么：

  • ✅ 「修复手机端导航菜单无法关闭」
  • ✅ 「新增文章：DNS 入门」
  • ❌ 「update」「改了点东西」「123」

GitHub 的工作流文档建议，每次提交只包含一个独立、完整的改动，这样以后想撤销某一项时不会牵连其他。如果想要更规范的格式，可以参考「约定式提交」（Conventional Commits），用 feat:、fix: 之类的前缀标明类型，但一个人的项目不强求。

分支：放心做实验的地方

分支就是一条独立的开发线。在分支上怎么改都不影响主分支（通常叫 main），满意了再合并回去。

git switch -c 新分支名       # 创建并切换到新分支
git switch main             # 切回主分支
git merge 新分支名           # 在 main 上执行，把分支合并进来
git branch -d 新分支名       # 合并完删除分支

什么时候开分支？任何你不确定会不会保留的改动：试一个新设计、让 AI 做一次大重构、升级一个大的依赖。

对一个人的项目来说，GitHub 的 Pull Request（PR）也很有用：把分支推送到 GitHub 后开一个 PR，你可以在网页上逐行检查改动；很多部署平台还会为 PR 自动生成预览网址。确认没问题再点合并。这就是 GitHub 官方推荐的「GitHub flow」：开分支 → 提交 → 开 PR → 审查 → 合并 → 部署。

.gitignore：哪些东西不该进仓库

在项目根目录放一个 .gitignore 文件，列出 Git 应该忽略的文件。一个网站项目通常至少包括：

node_modules/
dist/
.next/
.env
.env.local
.DS_Store
  • 依赖目录（node_modules）体积大，而且可以随时重新安装；
  • 构建产物（dist、.next）可以随时重新生成；
  • 环境变量文件（.env）里有密钥，绝对不能提交；
  • 系统生成的垃圾文件（macOS 的 .DS_Store）。

GitHub 维护着一个官方的 .gitignore 模板仓库（github/gitignore），覆盖了大部分语言和框架，新项目可以直接参考。

注意：.gitignore 只对还没被跟踪的文件有效。如果一个文件已经提交过，再写进 .gitignore 也不会让 Git 忘掉它，需要先用 git rm --cached 文件名 取消跟踪。

后悔药：撤销操作

想做的事 命令
放弃某个文件还没暂存的改动 git restore 文件名
把文件从暂存区拿出来（改动保留） git restore --staged 文件名
刚提交完发现漏了文件或写错了提交信息 补上改动后 git commit --amend（只用于还没推送的提交）
撤销一个已经推送的提交 git revert 提交号（生成一个反向提交，不改写历史）
临时把手头的改动收起来 git stash，之后用 git stash pop 取回

一条原则：已经推送到 GitHub 的历史，尽量不要改写。用 revert 新增一个提交来抵消，而不是用 reset 或 --force 把历史抹掉。Pro Git 对 --amend 的提醒也是同样的道理：它本质上是用一个新提交替换旧提交，所以只适用于还在本地的提交。

密钥不小心提交了怎么办

这是新手最常见、也最危险的事故。GitHub 文档给出的处理顺序非常明确：

  1. 第一步，立刻到对应服务的后台作废（撤销）或更换这个密钥。 这是唯一真正有效的补救。只要密钥还有效，就要假设它已经泄露。
  2. 然后再考虑是否清理 Git 历史。仅仅在新提交里删掉文件是不够的，旧的提交里还留着它；彻底清除需要用 git-filter-repo 等工具改写历史，过程复杂且有副作用（所有提交号都会变，其他人的克隆也要处理）。GitHub 文档专门有一篇讲这件事，需要时照着做。

预防胜于补救：

  • .env 一开始就写进 .gitignore；
  • 公开仓库可以开启 GitHub 的密钥扫描（secret scanning）功能，它会扫描仓库的完整历史，检测常见类型的密钥；
  • 让 AI 写代码时，在项目说明文件里写明「不读取、不提交 .env」。

和 AI 编程工具一起用

现在的 AI 编程工具（Claude Code、Codex、Cursor 等）都很擅长 Git，可以帮你写提交信息、查历史、定位是哪次提交引入了 Bug。但有两件事建议你亲自把关：

  • 提交前自己看一眼 git diff，确认它改的是你想改的；
  • 推送和任何改写历史的操作，保留人工确认。

把 Git 当作每个 AI 任务前的存档点：先提交，再让 AI 动手；改坏了，一条 git restore . 就能回到原点。

常见的坑

  1. 一周不提交一次。出了问题回不到中间状态。
  2. 把 node_modules 提交进去。仓库瞬间变得巨大。
  3. 在 GitHub 网页上改了文件，本地没先 pull 就继续改。推送时会冲突。养成开工前先 git pull 的习惯。
  4. 遇到冲突就慌。冲突只是 Git 在问你「这两处改动保留哪个」。打开冲突文件，留下想要的内容，删掉 <<<<<<<、=======、>>>>>>> 标记，然后 add、commit 即可。
  5. 用 --force 推送解决问题。几乎总有更安全的办法。
  6. 提交信息全是「update」。三个月后你自己都看不懂。

最少命令清单

status · diff · add · commit · push · pull · log · switch · merge · restore · revert · stash

把这十二个命令用熟，一个人的项目就够用了。剩下的，等真的遇到需要时再查。

参考资料

← 返回教程列表