Git工具使用详解
Git 工具使用详解
本章位置：第三阶段 Java 企业项目 + AI 助手
对应课程：Git 工具使用
前置知识：命令行基础、Maven、SpringBoot 项目开发
后续衔接：Redis、若依脚手架、企业项目协作
学习目标：从零掌握 Git 的工作区、暂存区、本地仓库、分支、合并、冲突、远程仓库、撤销恢复、stash、rebase、tag、团队协作，以及 IDEA / Cursor 中的常用 Git 操作。
一、Git 是什么
Git 是：
分布式版本控制系统
它主要解决：
代码版本管理
多人协作
历史追踪
分支开发
错误恢复
二、为什么开发必须学 Git
假设你开发一个 SpringBoot 项目。
第一天：
登录功能完成
第二天：
权限功能完成
第三天你改坏了：
登录也不能用了
如果没有 Git：
只能手工找旧代码
有 Git：
可以回到昨天的版本
三、Git 不是“代码网盘”
很多初学者以为：
Git = GitHub
这是错误的。
Git：
版本控制工具
GitHub / Gitee：
远程代码托管平台
四、Git 和 GitHub 的关系
Git
本地版本管理
GitHub
远程代码托管
你完全可以：
只使用 Git
不使用 GitHub
五、Git 最核心的三个区域
必须记住：
工作区
Working Tree
暂存区
Staging Area / Index
本地仓库
Repository
六、工作区
工作区就是：
你当前项目目录中的文件
例如：
src
pom.xml
application.yml
你编辑文件：
就是修改工作区
七、暂存区
暂存区可以理解：
准备提交的文件清单
执行：
git add .
就是把修改：
加入暂存区
八、本地仓库
执行：
git commit
会把暂存区内容：
保存为一个版本
这个版本存在：
本地 Git 仓库
九、最核心流程
修改代码
↓
Working Tree
↓
git add
↓
Staging Area
↓
git commit
↓
Local Repository
十、远程仓库再多一层
Working Tree
↓
git add
↓
Staging Area
↓
git commit
↓
Local Repository
↓
git push
↓
Remote Repository
十一、安装 Git 后先检查
Windows PowerShell：
git --version
如果输出：
git version ...
说明：
安装成功
十二、配置用户名
第一次使用：
git config --global user.name "YourName"
十三、配置邮箱
git config --global user.email "you@example.com"
十四、为什么要配置用户名和邮箱
每次 Commit：
都要记录作者
十五、查看配置
git config --global --list
十六、global 是什么意思
当前 Windows 用户全局配置
对：
多个项目生效
十七、项目级配置
进入项目后：
git config user.name "ProjectName"
不加：
--global
表示：
只对当前仓库生效
十八、初始化 Git 仓库
进入项目目录：
git init
执行后：
生成 .git
十九、.git 是什么
.git：
Git 仓库真正的数据目录
包含：
提交历史
分支
配置
对象
引用
二十、不要随便删除 .git
删除：
.git
意味着：
当前项目 Git 历史全部消失
源码：
可能还在
但版本历史：
没了
二十一、查看状态
最常用：
git status
二十二、git status 能看到什么
例如：
未跟踪文件
已修改文件
已暂存文件
当前分支
二十三、Untracked
表示：
Git 还没开始跟踪这个文件
例如新建：
UserController.java
Git：
知道文件存在
但还没纳入版本控制
二十四、Modified
表示：
文件以前已经跟踪
现在被修改
二十五、Staged
表示：
已经 git add
准备 commit
二十六、添加单个文件
git add src/main/java/UserController.java
二十七、添加所有修改
git add .
二十八、git add . 到底干什么
它不是：
提交代码
只是：
把当前修改放入暂存区
二十九、提交
git commit -m "feat: add user login"
三十、Commit 是什么
Commit：
一个版本快照
每次 Commit 有：
Commit ID
作者
时间
提交信息
父提交
三十一、查看提交历史
git log
三十二、简洁日志
git log --oneline
三十三、图形日志
git log --oneline --graph --decorate --all
非常推荐。
三十四、Commit ID
例如：
a1b2c3d
Git 内部真正是：
更长的哈希
平时：
前几位足够唯一
即可使用。
三十五、提交信息为什么重要
错误：
update
修改
改一下
123
以后看历史：
完全不知道改了什么
三十六、推荐提交信息
例如：
feat: add login api
fix: resolve token expiration bug
refactor: extract user service
docs: update README
test: add user service tests
三十七、常见 Commit 类型
feat
新增功能
fix
修复 Bug
docs
文档
style
格式
refactor
重构
test
测试
chore
构建/工具/杂项
三十八、一次 Commit 应该多大
推荐：
一个相对完整的小功能
不要：
一天所有东西一次提交
也不要：
每改一行就提交
三十九、好的 Commit
例如：
feat: add role permission assignment
里面包含：
Controller
Service
Mapper
DTO
必要测试
围绕：
一个功能
四十、.gitignore
作用：
告诉 Git 哪些文件不要跟踪
四十一、Java 项目常见忽略
target/
.idea/
*.iml
*.log
四十二、Vue 项目常见忽略
node_modules/
dist/
四十三、环境文件
如果：
.env
包含：
Token
密码
Secret
应该：
忽略
四十四、但配置模板可以提交
例如：
application-example.yml
.env.example
里面：
只写示例值
四十五、Git 已经跟踪的文件，后来写进 .gitignore 有用吗
不会自动停止跟踪。
例如：
application.yml
已经 commit 过。
后来：
application.yml
Git 仍可能：
继续跟踪
四十六、停止跟踪但保留本地文件
git rm --cached application.yml
然后：
git commit
四十七、为什么不能直接 git rm
git rm file
会：
删除工作区文件
+
暂存删除
四十八、git rm --cached
只：
从 Git 索引中移除
本地文件：
保留
四十九、查看修改
git diff
默认比较：
工作区
vs
暂存区
五十、查看已暂存修改
git diff --staged
也可：
git diff --cached
五十一、为什么 commit 前应该 diff
防止：
误提交密码
误提交 debug 代码
误删文件
五十二、推荐提交前流程
git status
git diff
git diff --staged
git commit -m "..."
五十三、分支是什么
Branch：
一条独立开发线
五十四、为什么需要分支
例如：
main
当前稳定版本
你要开发：
Redis 缓存
不应该直接：
在 main 上边写边改
可以：
feature/redis-cache
五十五、分支图
A---B---C main
\
D---E feature
五十六、查看分支
git branch
五十七、创建分支
git branch feature/login
五十八、切换分支
现代 Git 推荐：
git switch feature/login
五十九、创建并切换
git switch -c feature/login
六十、旧写法 checkout
旧教程常见：
git checkout -b feature/login
仍然能用。
但现代 Git 把很多职责拆成：
git switch
切分支
git restore
恢复文件
语义更清楚。
六十一、切回 main
git switch main
六十二、删除分支
安全删除：
git branch -d feature/login
六十三、强制删除
git branch -D feature/login
危险：
可能删除未合并提交
六十四、分支只是指针
Git 分支本质：
指向某个 Commit 的引用
不是：
完整复制一份项目
所以：
创建分支非常快
六十五、HEAD
HEAD：
当前你所在的位置
通常：
指向当前分支
六十六、查看 HEAD
git log --oneline --decorate
会看到：
HEAD -> main
六十七、合并分支
例如：
feature/login
开发完成。
先：
git switch main
再：
git merge feature/login
六十八、Fast-forward
如果 main 没有新提交：
A---B main
\
C---D feature
merge 后：
A---B---C---D main
这叫：
Fast-forward
六十九、真正 Merge Commit
如果两边都继续开发：
C---D feature
/
A---B
\
E---F main
merge 后：
C---D
/ \
A---B M
\ /
E---F
M：
Merge Commit
七十、合并冲突
如果两个分支：
修改同一个文件同一位置
Git 无法判断：
应该保留哪一个
就产生：
Conflict
七十一、冲突标记
文件可能出现：
<<<<<<< HEAD
当前分支代码
=======
另一个分支代码
>>>>>>> feature/login
七十二、冲突怎么解决
不是：
随便删一个
而是：
理解两边业务
决定最终正确代码
删掉冲突标记
保留正确结果
七十三、解决冲突后
git add 冲突文件
再：
git commit
七十四、查看冲突文件
git status
会提示：
both modified
七十五、取消当前 merge
如果发现：
合错了
还没有完成 Merge Commit：
git merge --abort
恢复：
merge 前状态
七十六、团队冲突减少方法
小步提交
经常同步 main
一个文件避免多人长期大改
功能模块边界清晰
七十七、远程仓库
查看：
git remote -v
七十八、添加远程
git remote add origin <remote-url>
七十九、origin 是什么
只是：
远程仓库别名
不是特殊关键字。
习惯上：
第一个远程仓库叫 origin
八十、查看远程详细信息
git remote show origin
八十一、clone
已有远程项目：
git clone <remote-url>
Git 会：
下载源码
+
下载版本历史
+
配置 origin
八十二、第一次 push
例如：
git push -u origin main
八十三、-u 是什么
建立：
upstream tracking
以后：
git push
即可。
八十四、push 是什么
本地 Commit
↓
推送到远程仓库
注意：
必须先 commit
未提交工作区修改：
push 不会自动上传
八十五、fetch 是什么
git fetch
表示：
把远程最新提交下载到本地
但：
不会自动合并到当前分支
八十六、pull 是什么
通常可以理解：
fetch
+
merge/rebase
八十七、为什么初学要区分 fetch 和 pull
fetch：
更安全地“先看看远程有什么”
pull：
直接把远程变化整合到当前分支
八十八、查看远程分支
git branch -r
八十九、查看全部分支
git branch -a
九十、创建本地分支跟踪远程
git switch -c feature/login --track origin/feature/login
某些情况下：
git switch feature/login
Git 也能自动猜测远程同名分支。
九十一、远程分支
例如：
origin/main
它是：
远程跟踪分支
表示：
本地记录的 origin/main 状态
九十二、origin/main 不一定实时最新
只有执行：
git fetch
之后：
才更新
九十三、团队开发开始一天建议
进入项目：
git switch main
git pull
然后：
git switch feature/xxx
必要时同步：
main 最新代码
九十四、不要在 main 上长期写功能
推荐：
main
稳定
feature/xxx
功能
fix/xxx
Bug 修复
九十五、常见分支命名
feature/login
feature/redis-cache
fix/token-expired
refactor/user-service
release/1.0.0
九十六、企业常见开发流
main
稳定生产
develop
日常集成
feature/*
功能开发
release/*
发布准备
hotfix/*
线上紧急修复
九十七、是不是所有项目都要 Git Flow
不是。
小团队可以：
main
+
feature/*
就够。
九十八、分支越多不代表越专业
正确目标：
适合团队协作
而不是：
制造流程复杂度
九十九、stash 是什么
场景：
你正在开发 Redis
代码还没写完。
突然：
线上有 Bug
需要马上切分支。
但当前工作区：
有未提交修改
一百、git stash
git stash
把当前未完成修改：
暂时藏起来
工作区：
恢复干净
一百零一、查看 stash
git stash list
一百零二、恢复最近 stash
git stash pop
恢复并：
从 stash 列表删除
一百零三、apply
git stash apply
恢复：
但保留 stash 记录
一百零四、带说明 stash
git stash push -m "wip: redis cache"
一百零五、stash 某些未跟踪文件
默认行为要根据 Git 版本和参数理解。
如果需要连未跟踪文件也保存：
git stash -u
一百零六、stash 不是长期存档
不要：
stash 放几个月
真正重要的阶段结果：
应该 Commit
一百零七、WIP Commit
有时比 stash 更稳：
git add .
git commit -m "wip: unfinished redis cache"
后续：
再整理历史
一百零八、restore
恢复工作区文件：
git restore file
表示：
丢弃当前未暂存修改
危险。
一百零九、恢复所有未暂存修改
git restore .
这会：
直接丢掉工作区改动
一百一十、取消暂存
git restore --staged file
把文件从：
暂存区
退回：
工作区修改
文件内容：
不丢
一百一十一、这是非常常用的
误执行：
git add .
发现：
application.yml 不该提交
可以：
git restore --staged application.yml
一百一十二、reset 是什么
reset 用于：
移动当前分支指针
并根据模式：
影响暂存区和工作区
一百一十三、三种主要 reset
--soft
--mixed
--hard
一百一十四、git reset --soft
例如：
git reset --soft HEAD~1
效果：
撤销最近 Commit
代码仍在
修改仍在暂存区
一百一十五、适合场景
刚 Commit：
提交信息写错
或者：
漏了一个文件
一百一十六、git reset --mixed
默认模式：
git reset HEAD~1
效果：
撤销 Commit
代码保留
暂存区取消
修改回到：
工作区
一百一十七、git reset --hard
git reset --hard HEAD~1
效果：
Commit 回退
暂存区回退
工作区也回退
修改：
可能直接丢失
一百一十八、hard 为什么危险
因为它：
真的改工作区文件
所以不要：
看到“撤销”就复制 hard
一百一十九、reset 最重要原则
如果 Commit：
还没有 push
reset 相对容易使用。
如果 Commit：
已经推到公共远程分支
不要随便 reset + force push。
一百二十、revert 是什么
git revert <commit-id>
不是删除旧 Commit。
而是：
创建一个新的 Commit
把旧 Commit 的修改：
反向撤销
一百二十一、为什么公共分支更推荐 revert
历史：
不被改写
团队成员：
更安全
一百二十二、reset vs revert
reset
移动历史指针
可能改写历史
revert
新增一个反向提交
保留历史
一百二十三、记忆
本地未共享历史
可以考虑 reset
公共已 push 历史
优先 revert
一百二十四、reflog
Git 的救命工具之一：
git reflog
它记录：
HEAD 近期移动记录
一百二十五、什么时候用 reflog
例如你：
git reset --hard HEAD~3
结果发现：
回多了
可以：
git reflog
找到：
原来的 Commit
一百二十六、恢复误 reset
例如 reflog 找到：
abc1234
可以：
git reset --hard abc1234
前提：
对象还没被 Git 清理
一百二十七、reflog 为什么重要
很多“提交看似丢了”的情况：
其实 Commit 还在
只是：
没有分支指向它
一百二十八、cherry-pick
git cherry-pick <commit-id>
作用：
把某一个 Commit
应用到当前分支
一百二十九、适合场景
例如：
feature 分支有一个 Bug 修复 Commit
你只想把：
这个 Commit
拿到：
release 分支
可以：
cherry-pick
一百三十、不要用 cherry-pick 替代正常 merge
如果整个 feature：
都应该合入
就：
merge / rebase
cherry-pick 适合：
挑某个提交
一百三十一、rebase 是什么
Rebase：
变基
用于：
把一组提交
重新放到另一个基点之后
一百三十二、例子
原来：
A---B---C main
\
D---E feature
main 又有：
C
feature 基于 B。
执行：
git rebase main
结果类似：
A---B---C---D'---E'
一百三十三、为什么 D/E 变成 D’/E’
因为 rebase：
重新创建提交
Commit ID：
会改变
一百三十四、rebase 优点
历史：
更线性
看起来：
更整洁
一百三十五、rebase 风险
它会：
改写提交历史
所以：
不要随便 rebase 已经被多人使用的公共分支
一百三十六、黄金规则
不要 rebase 已经公开共享的提交
一百三十七、自己的 feature 分支
如果只有你自己用：
rebase main
通常比较安全。
一百三十八、rebase 冲突
处理：
解决冲突
然后：
git add .
git rebase --continue
一百三十九、跳过当前 Commit
git rebase --skip
谨慎使用。
一百四十、取消 rebase
git rebase --abort
一百四十一、merge vs rebase
Merge：
保留真实分叉历史
Rebase：
重写为更线性历史
一百四十二、哪个更好
没有绝对。
团队需要：
统一规则
一百四十三、初学建议
先熟练：
branch
merge
conflict
再学：
rebase
一百四十四、交互式 rebase
git rebase -i HEAD~3
可以：
合并 Commit
改提交信息
删除 Commit
调整顺序
一百四十五、squash
把多个小 Commit：
合并为一个
例如：
fix typo
fix typo again
fix test
最终整理成：
feat: add user management
一百四十六、不要在公共分支随便 interactive rebase
因为：
历史会改
一百四十七、修改最近 Commit 信息
git commit --amend
一百四十八、漏提交一个文件
先：
git add missing-file
再：
git commit --amend
一百四十九、amend 也会改变 Commit ID
所以：
已 push 的公共 Commit
不要随便 amend。
一百五十、Tag 是什么
Tag：
给某个 Commit 打标签
常用于：
版本发布
一百五十一、查看 Tag
git tag
一百五十二、创建 Tag
git tag v1.0.0
一百五十三、推荐 Annotated Tag
git tag -a v1.0.0 -m "release 1.0.0"
一百五十四、推送 Tag
git push origin v1.0.0
一百五十五、推送所有 Tag
git push origin --tags
一百五十六、Tag 和 Branch 区别
Branch：
会随着新 Commit 移动
Tag：
通常固定指向某个版本
一百五十七、版本发布
例如：
v1.0.0
v1.1.0
v2.0.0
和 Maven：
版本号
可以保持一致。
一百五十八、查看某个 Commit
git show <commit-id>
一百五十九、查看某个文件历史
git log -- path/to/file
一百六十、查看每一行是谁改的
git blame path/to/file
一百六十一、blame 不是“甩锅工具”
主要用于：
追溯上下文
看看：
为什么当时这么写
一百六十二、删除文件
git rm file
一百六十三、移动/重命名
git mv old.java new.java
Git 最终主要根据：
内容相似度
判断重命名。
一百六十四、远程删除分支
git push origin --delete feature/login
一百六十五、远程已删，本地还显示 origin/xxx
执行：
git fetch --prune
清理：
失效远程跟踪引用
一百六十六、prune
也可以：
git remote prune origin
一百六十七、强制 push
git push --force
危险。
一百六十八、什么时候才可能需要 force
例如：
自己 feature 分支
做了：
rebase
远程历史和本地不同。
一百六十九、更安全
git push --force-with-lease
比：
--force
更安全。
一百七十、为什么 force-with-lease 更安全
它会检查：
远程分支是否还是你预期的状态
减少：
覆盖别人新提交
一百七十一、不要对 main 强推
除非：
团队非常明确知道在做什么
通常：
禁止
一百七十二、Pull Request / Merge Request
GitHub：
Pull Request
GitLab / Gitee 常见：
Merge Request / Pull Request
用途：
代码评审
一百七十三、团队推荐流程
main
↓
创建 feature 分支
↓
开发
↓
commit
↓
push feature
↓
PR
↓
Code Review
↓
CI
↓
Merge
一百七十四、为什么不直接 push main
因为：
缺少评审
容易把 Bug 直接推入稳定分支
一百七十五、Code Review 看什么
业务正确性
异常处理
安全问题
SQL
事务
命名
重复代码
测试
一百七十六、AI 生成代码也必须 Review
Cursor / AI 生成：
不能直接 commit
先检查：
是否真能运行
是否引入旧 API
是否破坏权限
是否泄露 Secret
一百七十七、Git 在 AI 开发中的价值
AI 修改前：
git status
确认：
工作区干净
一百七十八、先 Commit 再让 AI 大改
例如：
git add .
git commit -m "chore: checkpoint before ai refactor"
然后让 AI：
重构
如果改坏：
容易恢复
一百七十九、这是 Cursor 开发非常推荐的习惯
AI 一次可能：
改很多文件
Git 就是你的：
安全网
一百八十、AI 改完第一步
git diff
看：
AI 到底改了什么
一百八十一、不要只看“项目能启动”
AI 可能：
顺便删权限校验
硬编码密码
改 API
必须：
看 diff
一百八十二、GitHub/Gitee HTTPS
远程地址可能：
HTTPS
认证通常：
密码已逐渐被 Token / Credential 方式替代
一百八十三、SSH
也可以：
SSH Key
访问远程仓库。
一百八十四、生成 SSH Key
常见：
ssh-keygen -t ed25519 -C "you@example.com"
一百八十五、公钥
通常：
~/.ssh/id_ed25519.pub
把：
公钥
添加到：
GitHub/Gitee
一百八十六、私钥
id_ed25519
绝对不要：
上传
发给别人
提交 Git
一百八十七、SSH 测试
平台不同命令不同。
GitHub 常见：
ssh -T git@github.com
一百八十八、Windows Credential Manager
HTTPS 认证可能：
由 Git Credential Manager
缓存凭据。
一百八十九、凭据错误
如果：
一直用旧账号
可以检查：
Windows 凭据管理器
一百九十、Git LFS
大文件：
模型
视频
大型二进制
普通 Git：
不适合频繁存大文件
Git LFS：
Large File Storage
可处理大文件版本。
一百九十一、但不要把数据库备份随便放 Git
例如：
10GB SQL
不适合。
一百九十二、敏感文件泄露
如果你把：
数据库密码
API Key
Secret
Commit 了。
即使后来：
删除文件
历史 Commit：
仍然可能包含
一百九十三、第一件事
立即：
更换泄露的 Secret
不是只：
删 Git 历史
一百九十四、为什么
一旦推到远程：
应该视为已经泄露
一百九十五、清历史属于后续操作
可以用：
git filter-repo
等专门工具。
但核心：
先轮换密钥
一百九十六、Git Hooks
Git 可以：
在 commit/push 等事件自动执行脚本
例如：
pre-commit
pre-push
一百九十七、pre-commit
可以：
代码格式检查
Secret 扫描
Lint
一百九十八、pre-push
可以：
运行测试
一百九十九、学习阶段先了解
企业团队可能通过：
Husky
CI
做自动检查。
二百、Git 与 CI/CD
git push
↓
CI
↓
mvn test
↓
npm build
↓
Docker build
↓
deploy
Git 通常是：
整个自动化流程入口
二百零一、Git 子模块 Submodule
用于：
一个仓库引用另一个 Git 仓库
命令：
git submodule
但：
管理复杂
初学：
知道即可
二百零二、Monorepo
多个项目：
放一个仓库
例如：
backend
frontend
docs
二百零三、Multi Repo
不同服务：
不同 Git 仓库
例如：
user-service
order-service
gateway
二百零四、企业如何选择
根据：
团队规模
发布边界
权限
依赖关系
决定。
二百零五、IDEA 中 Git
IDEA 2024.3 可以直接：
VCS / Git
操作。
二百零六、IDEA 开启 Git
如果项目还没启用：
VCS
→ Enable Version Control Integration
→ Git
二百零七、IDEA Commit
可以：
左侧 Commit 工具窗口
选择文件：
填写 Commit Message
然后：
Commit
二百零八、IDEA Push
菜单：
Git
→ Push
常见快捷键：
Ctrl + Shift + K
Windows/IDEA Keymap 可能有差异。
二百零九、IDEA Update Project
常见：
Ctrl + T
对应：
同步远程更新
具体行为取决于：
Update Method
二百一十、IDEA Branch
右下角：
当前分支名
点击即可：
New Branch
Checkout
Merge
Compare
二百一十一、IDEA 解决冲突
冲突时：
Merge
会出现三栏：
Yours
Result
Theirs
二百一十二、冲突界面不要盲点 Accept Yours
要理解：
当前分支
对方分支
最终结果
二百一十三、IDEA Local Changes
可以查看：
哪些文件改了
并逐个查看：
Diff
二百一十四、IDEA Rollback
相当危险。
可能：
丢掉未提交修改
使用前：
确认真的不要这些改动
二百一十五、Cursor 中 Git
Cursor 基于 VS Code 体系，
左侧：
Source Control
可以：
Stage
Commit
Push
Pull
Branch
二百一十六、Cursor + AI 最重要习惯
AI 修改前：
Commit 一个 checkpoint
AI 修改后：
逐文件看 Diff
二百一十七、不要让 AI 直接执行危险 Git 操作
尤其：
reset --hard
clean -fd
push --force
rebase
如果你还没理解：
不要让 AI 自动执行
二百一十八、git clean
删除：
未跟踪文件
预览：
git clean -n
二百一十九、真正删除
git clean -fd
危险。
二百二十、为什么先 -n
让 Git：
先告诉你会删什么
二百二十一、git clean 不一定能 reflog 恢复
因为未跟踪文件：
从未 Commit
Git 可能根本：
没有对象
所以：
比 reset 更危险
二百二十二、误删未跟踪文件
如果：
从没 add/commit/stash
Git：
通常帮不了你
需要：
IDEA Local History
系统备份
二百二十三、IDEA Local History
即使没 Git Commit，
IDEA 有时可以：
Local History
找回近期修改。
右键：
Local History
→ Show History
二百二十四、但不能依赖 Local History
真正重要代码：
及时 Commit
二百二十五、常见错误 1：git add 后以为已经上传
没有。
还需要：
commit
再：
push
二百二十六、常见错误 2：commit 后 GitHub 没变化
因为只：
本地 Commit
还需要：
git push
二百二十七、常见错误 3：push rejected
例如：
remote contains work that you do not have
说明：
远程有你本地没有的提交
二百二十八、正确思路
先：
git fetch
看看：
远程变化
再：
merge / rebase
之后：
push
二百二十九、不要看到 rejected 就 force push
这可能：
覆盖别人代码
二百三十、常见错误 4：切分支失败
提示：
Your local changes would be overwritten
说明：
当前有未提交修改
选择：
Commit
Stash
或放弃修改
二百三十一、常见错误 5：merge conflict
不是 Git 坏了。
这是：
Git 不知道应该选哪边
需要：
人工解决
二百三十二、常见错误 6：detached HEAD
你可能：
git checkout <commit-id>
然后处在：
detached HEAD
二百三十三、detached HEAD 是什么
HEAD：
直接指向 Commit
而不是：
某个 Branch
二百三十四、在 detached HEAD 上写代码
Commit 后：
可能没有正常分支长期指向
容易迷失。
二百三十五、如果想保留
创建分支：
git switch -c rescue-work
二百三十六、常见错误 7：误 commit 到 main
如果还没 push：
可以创建新分支保留 Commit
例如：
git branch feature/login
然后把 main：
reset 回去
具体操作前：
先看 log
二百三十七、常见错误 8：commit 信息写错
未 push：
git commit --amend
二百三十八、常见错误 9：漏文件
git add missing-file
git commit --amend
二百三十九、常见错误 10：误 add 敏感配置
还没 commit：
git restore --staged application.yml
然后：
加入 .gitignore
二百四十、常见错误 11：误 commit Secret
如果已 push：
先立刻轮换 Secret
然后：
再处理 Git 历史
二百四十一、常见错误 12：误 reset --hard
第一时间：
git reflog
看看：
原 Commit
二百四十二、常见错误 13：误删未跟踪文件
Git：
可能无法恢复
尝试：
IDEA Local History
二百四十三、常见错误 14：rebase 后 push 被拒绝
因为：
Commit ID 改了
自己的私有 feature 分支：
可以考虑
git push --force-with-lease
公共分支：
不要随便强推
二百四十四、常见错误 15：本地分支太多
已合并分支：
git branch -d xxx
远程失效引用：
git fetch --prune
二百四十五、常见错误 16：改了 .gitignore 仍然跟踪
因为文件：
之前已经被 Git 跟踪
用：
git rm --cached file
二百四十六、常见错误 17：两个分支都有同名不同功能
说明：
分支生命周期过长
应该：
更频繁集成
二百四十七、常见错误 18：一次 Commit 100 个不相关文件
Code Review：
非常痛苦
应：
按功能拆 Commit
二百四十八、常见错误 19：只依赖 IDE 按钮不会命令
IDE 图形界面：
只是 Git 命令的包装
真正排错：
必须会基本命令
二百四十九、必须掌握命令 1
git status
二百五十、必须掌握命令 2
git add .
二百五十一、必须掌握命令 3
git commit -m "..."
二百五十二、必须掌握命令 4
git log --oneline --graph --all
二百五十三、必须掌握命令 5
git switch -c feature/xxx
二百五十四、必须掌握命令 6
git merge branch
二百五十五、必须掌握命令 7
git fetch
二百五十六、必须掌握命令 8
git pull
二百五十七、必须掌握命令 9
git push
二百五十八、必须掌握命令 10
git stash
git stash pop
二百五十九、必须掌握命令 11
git restore
二百六十、必须掌握命令 12
git reset
二百六十一、必须掌握命令 13
git revert
二百六十二、必须掌握命令 14
git reflog
二百六十三、必须掌握命令 15
git rebase
至少：
理解原理
二百六十四、必须掌握命令 16
git cherry-pick
二百六十五、必须掌握命令 17
git tag
二百六十六、日常开发标准流程
早上：
git switch main
git pull
创建功能分支：
git switch -c feature/user-role
开发。
检查：
git status
git diff
提交：
git add .
git commit -m "feat: add user role assignment"
推送：
git push -u origin feature/user-role
然后：
创建 PR
二百六十七、继续开发同一个分支
git add .
git commit -m "fix: validate role assignment"
git push
二百六十八、main 更新了怎么办
先：
git fetch origin
选择：
merge origin/main
或者：
rebase origin/main
具体：
按团队规则
二百六十九、合并完成
PR：
Merge
然后本地：
git switch main
git pull
git branch -d feature/user-role
二百七十、个人毕业设计推荐流程
即使一个人：
也建议 Git
二百七十一、毕设分支可以简单
main
feature/login
feature/user
feature/ai
feature/workflow
二百七十二、每做完一个核心模块就 Commit
例如：
feat: complete login module
feat: complete user management
feat: integrate activiti approval
feat: add workflow diagram
二百七十三、AI 大改前打 checkpoint
git add .
git commit -m "chore: checkpoint before ai ui refactor"
二百七十四、为什么特别适合 Cursor
Cursor 可能一次：
改几十处
如果：
效果不好
可以快速：
比较/恢复
二百七十五、Git 不能替代备份
Git 非常强，
但仍建议重要项目：
远程 push
因为如果电脑硬盘坏：
只有本地 Git 也没用
二百七十六、所以真正安全
本地 Git
+
远程仓库
二百七十七、私有仓库
毕设、商业项目：
可以创建 Private Repository
避免：
源码公开
二百七十八、README
建议项目根目录：
README.md
包含：
项目介绍
技术栈
环境要求
启动方式
数据库初始化
默认账号
二百七十九、不要在 README 写真实生产密码
可以写：
请配置环境变量
二百八十、Git 项目应该提交什么
提交：
源码
pom.xml
package.json
数据库结构脚本
必要配置模板
README
二百八十一、不应该提交什么
target
node_modules
dist
IDE 临时文件
日志
Secret
私钥
二百八十二、数据库 SQL 是否提交
推荐提交：
schema.sql
migration scripts
用于：
团队同步数据库结构
二百八十三、不要只发一份最新 db.sql
企业项目更好：
版本化 migration
例如：
V1__init.sql
V2__add_role.sql
后面可以了解：
Flyway
Liquibase
二百八十四、Git 与 Maven
Git 保存：
pom.xml
不保存：
本地 .m2 repository
二百八十五、Git 与 npm
Git 保存：
package.json
package-lock.json
不保存：
node_modules
二百八十六、Git 与 Docker
Git 保存：
Dockerfile
docker-compose.yml
但：
镜像本身不放 Git
二百八十七、Git 与 Redis
后面 Redis 项目：
配置代码
提交 Git。
Redis 实际数据：
不提交 Git
二百八十八、练习 1：初始化仓库
创建空目录：
git-practice
执行：
git init
二百八十九、练习 2：第一次提交
创建：
README.md
执行：
git add README.md
git commit -m "docs: add readme"
二百九十、练习 3：观察三区
修改 README。
执行：
git status
然后：
git add README.md
再次：
git status
理解：
Working Tree → Staging Area
二百九十一、练习 4：查看 diff
git diff
和：
git diff --staged
二百九十二、练习 5：创建分支
git switch -c feature/login
创建：
login.txt
提交。
二百九十三、练习 6：merge
切回：
git switch main
合并：
git merge feature/login
二百九十四、练习 7：制造冲突
main：
修改 README 第一行
feature：
也修改第一行
分别 Commit。
然后 merge。
自己解决：
Conflict
二百九十五、练习 8：stash
修改：
两个文件
不 Commit。
执行：
git stash push -m "test stash"
观察工作区。
再：
git stash pop
二百九十六、练习 9：restore
修改一个文件。
先：
git diff
再：
git restore file
观察：
修改被丢弃
二百九十七、练习 10：取消暂存
git add file
再：
git restore --staged file
二百九十八、练习 11：reset --soft
提交一个 Commit。
执行：
git reset --soft HEAD~1
观察：
Commit 消失
修改仍 staged
二百九十九、练习 12：reset mixed
再提交。
执行：
git reset HEAD~1
观察：
修改回 Working Tree
三百、练习 13：revert
提交一个错误版本。
执行：
git revert <commit-id>
观察：
新增一个反向 Commit
三百零一、练习 14：reflog
记录当前 log。
执行一次：
reset
再：
git reflog
找原 Commit。
三百零二、练习 15：cherry-pick
在 feature：
做一个 fix Commit
切 main。
执行：
git cherry-pick <commit-id>
三百零三、练习 16：rebase
创建：
feature/demo
main 和 feature：
分别提交
feature 上：
git rebase main
观察：
历史变线性
三百零四、练习 17：remote
创建：
GitHub / Gitee 私有仓库
添加：
git remote add origin ...
三百零五、练习 18：push
git push -u origin main
三百零六、练习 19：clone
另建目录：
git clone ...
观察：
代码 + 历史
三百零七、练习 20：tag
git tag -a v1.0.0 -m "first release"
git push origin v1.0.0
三百零八、面试题 1：Git 三个区域
答：
Working Tree 是当前实际文件。
Staging Area 保存下一次准备提交的修改。
Repository 保存已经 Commit 的历史版本。
常见流程是：
工作区 → git add → 暂存区 → git commit → 本地仓库。
三百零九、面试题 2：git add 做什么
答：
git add 不是真正提交代码。
它把工作区中的修改加入暂存区，
决定哪些内容会进入下一次 Commit。
三百一十、面试题 3：fetch 和 pull 区别
答：
git fetch 只把远程最新提交和引用下载到本地，
不会自动改变当前分支。
git pull 通常相当于 fetch 后
再把远程变化合并或 rebase 到当前分支。
三百一十一、面试题 4：merge 和 rebase 区别
答：
merge 通常保留原来的分支分叉历史，
必要时生成 Merge Commit。
rebase 会把当前分支提交重新应用到新的基点，
形成更线性的历史，
但会改变提交 ID。
因此不要随便 rebase 已共享的公共历史。
三百一十二、面试题 5：reset 和 revert 区别
答：
reset 通过移动分支指针回退历史，
可能改变工作区和暂存区，
也可能改写提交历史。
revert 不删除旧提交，
而是创建一个新的反向 Commit 撤销旧修改。
公共分支通常优先使用 revert。
三百一十三、面试题 6：stash 是什么
答：
stash 用于临时保存当前未完成的工作区修改，
让工作区恢复干净，
方便临时切换分支处理其他事情。
之后可以通过 stash pop/apply 恢复。
三百一十四、面试题 7：reflog 有什么用
答：
reflog 记录 HEAD 和分支引用近期移动历史。
误 reset、误 rebase 等操作后，
很多看似丢失的 Commit
仍然可以通过 reflog 找到并恢复。
三百一十五、面试题 8：为什么 git reset --hard 危险
答：
因为它不仅移动 Commit 指针，
还会同步重置暂存区和工作区。
没有保存的本地修改可能直接丢失。
三百一十六、面试题 9：为什么公共分支不建议 force push
答：
强制 Push 会重写远程分支历史，
可能把其他成员已经 Push 的提交覆盖掉。
如果个人分支 rebase 后确实需要强推，
也更推荐 force-with-lease。
三百一十七、面试题 10：.gitignore 为什么有时不生效
答：
.gitignore 主要影响尚未被 Git 跟踪的文件。
如果文件之前已经 Commit 并被 Git 跟踪，
后来再加入 .gitignore，
Git 仍会继续跟踪。
可以使用 git rm --cached
停止跟踪并保留本地文件。
三百一十八、面试题 11：branch 本质是什么
答：
Git 分支本质是一个轻量级引用，
指向某个 Commit。
新建分支并不会复制整个项目，
所以创建和切换分支都非常快。
三百一十九、面试题 12：HEAD 是什么
答：
HEAD 表示当前工作位置。
正常情况下它指向当前分支，
而当前分支再指向一个具体 Commit。
detached HEAD 时，
HEAD 会直接指向某个 Commit。
三百二十、面试题 13：Commit 和 Push 区别
答：
Commit 只是在本地 Git 仓库创建一个版本。
Push 才会把本地 Commit
同步到远程仓库。
因此 Commit 后 GitHub 没变化，
通常只是还没有 Push。
三百二十一、面试题 14：Cherry-pick 是什么
答：
Cherry-pick 可以把另一个分支中的某一个指定 Commit
复制应用到当前分支。
适合只需要某个独立 Bug Fix 的场景，
不适合替代完整分支合并。
三百二十二、面试题 15：为什么 AI 开发更需要 Git
答：
AI 工具可能一次修改大量文件。
在 AI 大改之前创建 Git Checkpoint，
改完后通过 git diff 检查，
可以快速知道 AI 修改范围并在出错时恢复。
因此 Git 是 AI 编程非常重要的安全网。
三百二十三、Git 知识树
Git
│
├─ Basic
│ ├─ init
│ ├─ status
│ ├─ add
│ ├─ commit
│ ├─ log
│ └─ diff
│
├─ Branch
│ ├─ branch
│ ├─ switch
│ ├─ merge
│ ├─ conflict
│ └─ HEAD
│
├─ Remote
│ ├─ clone
│ ├─ remote
│ ├─ fetch
│ ├─ pull
│ └─ push
│
├─ Recovery
│ ├─ restore
│ ├─ reset
│ ├─ revert
│ ├─ reflog
│ └─ stash
│
├─ Advanced
│ ├─ rebase
│ ├─ cherry-pick
│ ├─ tag
│ └─ clean
│
├─ Team
│ ├─ PR
│ ├─ Code Review
│ ├─ Feature Branch
│ └─ CI/CD
│
└─ Tools
├─ IDEA
├─ Cursor
├─ GitHub
└─ Gitee
三百二十四、最重要的日常命令表
git status
git add .
git commit -m "message"
git log --oneline --graph --all
git switch -c feature/xxx
git switch main
git merge feature/xxx
git fetch
git pull
git push
git stash
git stash pop
git restore file
git restore --staged file
git reset --soft HEAD~1
git revert <commit>
git reflog
git cherry-pick <commit>
git rebase main
git tag -a v1.0.0 -m "release"
三百二十五、最重要的安全原则
1. reset --hard 前先确认
2. clean -fd 前先 clean -n
3. force push 前先确认分支
4. 公共分支优先 revert
5. AI 大改前先 Commit
6. Commit 前看 git diff
7. Secret 不要提交
8. 已泄露 Secret 先轮换
9. 重要代码要 Push 远程
10. 不要删除 .git
三百二十六、本章总结
Git 最重要的不是：
背几十条命令
而是理解：
状态如何流转
核心三区：
Working Tree
↓
Staging Area
↓
Repository
核心远程：
Local Repository
↓
Push
↓
Remote Repository
核心分支：
Branch
Merge
Conflict
核心恢复：
Restore
Reset
Revert
Reflog
Stash
核心高级：
Rebase
Cherry-pick
Tag
核心团队协作：
Feature Branch
↓
Push
↓
Pull Request
↓
Code Review
↓
Merge
对你使用 Cursor / AI 开发而言，最重要的习惯：
AI 修改前
先 Commit
AI 修改后
先 git diff
确认无误
再 Commit
到这里，第三阶段中的：
Git 工具使用
已经完成。
按照课程表，下一篇进入：
Redis 详解
会继续学习：
Redis 是什么
String / Hash / List / Set / ZSet
Key 设计
TTL
缓存
缓存穿透
缓存击穿
缓存雪崩
双写一致性
分布式锁
SpringBoot RedisTemplate
StringRedisTemplate
序列化
登录 Token
验证码
排行榜
高并发缓存