Git 与 GitHub 核心概念入门笔记

Sun, 24 May 2026 00:00:00 +0000

这篇是把一份 Git 与 GitHub 的长笔记重新整理成博客版。原笔记覆盖了从安装配置、初始化仓库，到分支协作、Pull Request、Cherry-pick、Stash、Rebase 等常用操作。

如果只想记住一句话：Git 负责记录代码历史，GitHub 负责把仓库放到网上协作。前者是版本控制工具，后者是代码托管和协作平台。

Git 和 GitHub 是什么

Git 是一个版本控制工具。它解决的问题是：文件改来改去以后，怎么知道每次改了什么、谁改的、什么时候改的，以及怎么回到之前的状态。

GitHub 是基于 Git 的代码托管平台。它把本地 Git 仓库放到云端，让别人可以浏览、下载、协作、提 Issue、提交 Pull Request。

可以简单理解为：

Git：本地版本管理系统
GitHub：远程仓库和协作平台
Repository：一个项目仓库
Commit：一次历史快照
Branch：一条开发线
Pull Request：请求别人合并你的改动

Git 不依赖 GitHub 也能用，但多人协作和开源项目通常会搭配 GitHub 一起使用。

准备工作

最基础的环境一般包括：

Git
VS Code
一个 GitHub 账号
可选：Codex、Claude Code 这类 AI coding agent

安装 Git 后，可以用下面命令确认：

1

git --version

新电脑第一次使用 Git，建议先配置用户名和邮箱：

1
2


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

这两个信息会写进每次提交记录里，用来标识这次 Commit 是谁提交的。

初始化仓库

把一个普通文件夹变成 Git 仓库，可以执行：

1

git init

执行后，文件夹里会出现一个隐藏目录：

1

.git/

这个目录保存了 Git 的全部版本信息。一般不要手动改它。删除 .git/，就相当于取消这个文件夹的 Git 管理。

在 VS Code 里，也可以通过 Source Control 面板点击 Initialize Repository 完成初始化。

.gitignore 忽略文件

并不是项目里的所有文件都应该提交。

常见需要忽略的内容包括：

.env：可能保存密钥、Token、数据库密码
node_modules/：依赖包体积大，可以通过 npm install 重新安装
构建产物：例如 dist/、build/
日志和缓存文件

可以在仓库根目录创建 .gitignore：

1
2
3
4


.env
node_modules/
dist/
*.log

原则是：源码、配置模板、文档应该提交；机器生成的临时文件、依赖目录、隐私密钥不要提交。

Commit 是一次快照

Commit 可以理解为给项目拍了一张快照。

一次完整的提交流程通常是：

1
2
3


git status
git add .
git commit -m "说明这次改了什么"

其中：

git status：看当前有哪些文件被修改
git add：把改动放进暂存区
git commit：把暂存区内容保存成一次历史记录

提交信息不要写成“修改”“更新”这种空话。更好的写法是描述这次改动的意图，比如：

1
2
3


git commit -m "Add prompt guide category filter"
git commit -m "Fix homepage sidebar link"
git commit -m "Translate RenPy interpolation guide"

以后回看历史时，Commit Message 是最快的索引。

工作区、暂存区、本地仓库、远程仓库

理解 Git 最重要的是理解几个区域。

区域	含义
Working Directory	当前文件夹里正在编辑的文件
Staging Area	准备提交的改动，也就是 `git add` 后的区域
Local Repository	本地保存的 Commit 历史
Remote Repository	GitHub 上的远程仓库

常见命令对应关系：

1
2
3
4


git add # 工作区 -> 暂存区
git commit # 暂存区 -> 本地仓库
git push # 本地仓库 -> 远程仓库
git pull # 远程仓库 -> 本地仓库并合并

很多 Git 问题，本质上是在问：这个改动现在在哪个区域？

撤销操作：Discard、Reset、Revert

Git 里有好几种“后悔药”，但它们适用场景不同。

操作	作用	适合场景
Discard	丢掉工作区未提交的改动	文件改坏了，还没 commit
Reset	把分支指针退回某个历史状态	本地历史需要重写，通常适合未推送的提交
Revert	生成一个反向提交来撤销旧提交	已经推送或多人协作时更安全

新手最容易混淆 reset 和 revert。

简单规则：

自己本地还没推送的提交，可以考虑 reset
已经推送到远程、别人可能基于它继续开发的提交，优先用 revert

revert 不会删除历史，而是新增一条“抵消旧改动”的提交，所以更适合团队协作。

Branch 分支

分支是另一条开发线。

常见用法是：主分支保持稳定，新功能放到单独分支开发。

1

git switch -c feature/login

开发完成后，再合并回主分支：

1
2


git switch main
git merge feature/login

分支的价值在于隔离风险。你可以在 feature 分支上尝试新功能，不影响 main 的稳定状态。

如果使用 VS Code 或 GitHub Desktop，也可以通过界面创建、切换和删除分支。

HEAD 是什么

HEAD 表示当前仓库指向哪一次提交。

通常情况下：

在 main 分支上，HEAD 指向 main 的最新提交
在 feature 分支上，HEAD 指向 feature 的最新提交
如果 checkout 到某个历史提交，可能进入 detached HEAD 状态

Detached HEAD 可以用来看历史代码，但不适合直接长期开发。需要继续改的话，最好从这个状态创建一个新分支。

Worktree 工作树

Worktree 可以让一个仓库同时拥有多个工作目录。

它适合这种场景：

常用命令：

1

git worktree add ../project-feature feature-name

AI coding agent 很适合搭配 worktree：每个任务一个独立工作树，互相不干扰，完成后再合并。

Merge Conflict 合并冲突

当两个分支修改了同一个文件的同一部分，Git 不知道该保留谁，就会产生冲突。

解决冲突不是“哪个按钮更高级”，而是人工判断最终文件应该长什么样。

一般流程：

打开冲突文件
找到冲突标记
保留正确内容
删除冲突标记
git add
git commit

冲突标记大概长这样：

1
2
3
4
5


<<<<<<< HEAD
当前分支内容
=======
另一个分支内容
>>>>>>> feature

在 VS Code 中可以选择保留当前、保留传入、两者都保留，但最终还是要确认合并后的代码是否合理。

Clone、Push、Pull

远程仓库最常用的三个动作是：

1
2
3


git clone <url>
git push
git pull

含义分别是：

clone：把 GitHub 上的仓库复制到本地
push：把本地提交推送到 GitHub
pull：把 GitHub 上的新提交拉到本地

如果你先在 GitHub 创建仓库，再复制到本地，一般用 clone。

如果你先在本地写了项目，再想传到 GitHub，就先 git init、commit，再添加远程仓库并 push。

GitHub 页面常用功能

GitHub 不只是放代码的网盘，它还有很多协作功能。

常用区域包括：

Code：查看代码、下载 zip、复制 clone 地址
Commit：查看提交历史
README：项目介绍，一般是仓库首页最重要的说明
Releases：发布版本和下载构建产物
Issues：提 bug、需求、讨论
Pull Requests：代码合并请求
Actions：自动化构建、测试和部署
Fork：把别人的项目复制一份到自己账号下
Star：收藏项目，也能反映项目热度

快捷键也很实用：

/：搜索仓库内容
t：快速找文件
.：在浏览器打开网页版 VS Code
?：查看 GitHub 快捷键

Fork 和 Pull Request

开源协作通常不是直接改别人的仓库，而是：

Fork：把仓库复制到自己账号
Clone：把自己的 fork 克隆到本地
Branch：创建新分支修改
Commit：提交改动
Push：推送到自己的远程仓库
Pull Request：请求原项目合并

Pull Request 不是单纯的“上传代码”，它也是讨论区。维护者可以 review 代码、提出修改意见，直到确认没问题再合并。

如果你是项目协作者，仓库管理员也可以直接把你加成 collaborator。这样你可以直接 push 到仓库，但更推荐仍然通过分支和 PR 保持审查流程。

Cherry-pick 精选提交

cherry-pick 用来把某几个 Commit 单独拿到当前分支。

例如 feature 分支有三次提交：

1
2
3


A 修按钮
B 改文案
C 加功能

你只想把 A 合到 main，不想要 B 和 C，就可以 cherry-pick A 的 Commit ID。

1

git cherry-pick <commit-id>

它适合“只挑某个改动”的场景，不适合替代正常合并流程。

Stash 临时存储

如果你正在改代码，突然需要切到另一个分支处理急事，但当前改动还不适合提交，可以用：

1

git stash

它会把当前未提交改动临时收起来，让工作区恢复干净。

回来以后再恢复：

1

git stash pop

Stash 适合临时切换任务，不应该长期当作保存代码的地方。真正有价值的进度还是应该 commit。

Rebase 变基

rebase 可以把一个分支的提交“挪到”另一个分支最新提交之后，让历史更线性。

例如：

1
2


git switch feature
git rebase main

效果是：feature 分支像是基于最新 main 重新开发出来的一样。

注意：rebase 会改写提交历史。
如果这个分支已经推送并且别人也在用，随便 rebase 再强推会影响别人。所以它更适合个人分支、尚未公开协作的分支。

简单规则：

自己一个人用的功能分支，可以 rebase
多人共用的公共分支，谨慎 rebase
主分支不要乱 rebase

AI 时代更要懂 Git

现在很多代码可以交给 AI agent 写，但 Git 反而更重要。

因为 AI 改代码很快，也可能一次改很多文件。如果没有 Git，你很难回答这些问题：

AI 到底改了哪些文件？
哪次改动引入了问题？
能不能只保留其中一部分？
能不能回到 AI 修改前的状态？
多个 AI 任务能不能并行？

所以 AI coding 的基础动作应该是：

1

一个任务 -> 一个分支或 worktree -> 小步 commit -> 审查 diff -> 再合并

不要让 AI 在一个长期混乱的工作区里连续改很多轮。每完成一个明确的小功能，就 commit 一次。这样即使后面改坏了，也能清楚地回退。

总结

Git 的核心不是背命令，而是理解版本流动：

1

工作区 -> 暂存区 -> 本地仓库 -> 远程仓库

GitHub 的核心也不是“上传代码”，而是围绕仓库建立协作流程：

1

Fork -> Branch -> Commit -> Push -> Pull Request -> Review -> Merge

掌握这些概念后，命令只是操作方式。无论是在 VS Code 里点按钮，还是让 AI agent 执行命令，本质都是在移动文件状态、提交历史和分支指针。

对新手来说，最值得先熟练的不是所有高级命令，而是这几件事：

会看 git status
会做小步 commit
会写清楚提交信息
会用分支隔离任务
会区分 discard、reset、revert
会把本地改动 push 到 GitHub
会通过 Pull Request 协作

这些掌握了，Git 和 GitHub 就不再是黑盒，而是你和 AI、队友、未来的自己协作时最可靠的底座。

Git on September的个人空间