从入行第一天起，我就被Git折腾得够呛。那时我以为会git add、git commit、git push三连就够了，结果第一次参与团队协作就闹了个大笑话：直接把本地所有文件推到公共分支，覆盖了同事半天的改动。那次之后我才意识到，对一个Java开发来说，Git不是"能用就行"的工具，而是日常开发的底层操作系统——你有多懂它，写代码就有多顺手。
这篇内容就是想把我在实际项目里反复用的Git操作整理出来。不是网上那种命令大全，而是结合Java开发场景，讲清楚每个操作在什么情况下用、为什么这么用、踩过什么坑。无论你是刚毕业的初级开发，还是已经写了两三年CRUD却对Git半懂不懂的同学，这篇应该都能帮你少走几趟弯路。
1. 先搞清楚每天高频执行的提交流程：add、commit、push的细节
1.1 为什么很多Java开发写着写着，提交还是无脑git add .
我见过不少同事，每天的工作流就是：改完代码直接git add .，然后git commit -m "update"，再git push。在一个人单干的项目里这么玩问题不大，可一旦进入团队协作，这就是定时炸弹。
先说git add .的问题。它把所有改动、新增、删除全部塞进暂存区，包括你调了一下午还没调完的测试类、临时生成的日志文件、IDE的配置文件、甚至不小心下载的jar包。等你commit的时候，一条提交里混进了十几个无关紧要的改动，后续git bisect排查问题、git revert回滚单个功能，都会因为这个"脏提交"变得极其痛苦。
我现在的习惯是：先git status看一眼全貌，再逐个git add 具体文件添加我要提交的改动。如果确实改了多个文件且它们属于同一件事，我也会把git add一次性加进来，但前提是我心里清楚这里面每一处改动都是为什么。推荐一个更优雅的做法：git add -p，它会一个hunk一个hunk地问你是否加入暂存区，适合需要精细控制提交粒度的场景。
1.2 我推荐的一条标准提交流水线
拿我自己来说，每天提交代码的完整流程是这样走的：
# 1. 先看当前工作区状态 git status # 2. 查看具体改了什么，确认没有意外改动 git diff # 3. 分文件或分块加入暂存区 git add src/main/java/com/example/service/UserService.java git add src/main/java/com/example/dto/UserDTO.java # 4. 再次确认暂存区内容 git diff --cached # 5. 提交并写清楚提交信息 git commit -m "feat: 用户模块新增查询接口" # 6. 推送前先拉取远端最新代码（这点很重要，后面细说） git pull --rebase origin main # 7. 推送 git push origin main有人会觉得第6步麻烦，说"我还没写完呢，拉什么拉"。但实际项目里，你写代码的时间越长，远程分支被其他人推进新提交的概率就越大。等你真想push的时候，大概率会遇到"非快进"错误。与其到时候手忙脚乱解冲突，不如每次推送前都养成同步的习惯。
注意：
git pull --rebase和git pull是两回事。默认的git pull等价于fetch加merge，会在本地形成一个分叉的合并节点，历史很难看。而git pull --rebase会把你在本地未推送的提交"摘下来"，接到远端最新提交的后面，历史是一条干净的直线。关于rebase的具体原理，我在后面分支合并那块会展开。
1.3 提交信息怎么写得让队友不再骂人
提交信息这件事，Java开发之间差异巨大。有人写update，有人写fix bug，有人干脆把注释里的中文复制一遍。这些信息过两周再看，基本等于没写。
我的模板很简单，参考主流社区的提交规范：
feat: 用户列表新增分页查询接口 fix: 修复订单金额计算溢出问题 refactor: 重构登录鉴权逻辑，提取公共拦截器 docs: 补充接口文档 test: 增加单元测试覆盖每个提交只做一件事，只写一件事。配合上面说的"精细add"，一条提交就是一次逻辑完整的变更。这样在看git log的时候，你扫一眼就能定位到某次提交，而不是在一堆 "update" "fix" 里猜。
2. 工作区、暂存区、版本库这三个概念搞不明白，迟早要出事故
2.1 用"草稿纸、购物车、档案柜"来理解三个区
很多Java开发记不住命令是因为不理解底层的三个区域。其实一点都不玄。执行一个Java程序时你会有内存模型的理解，Git的三区同理：
- 工作区：就是你IDE里打开的那一坨文件，改完代码没执行任何Git操作时，改动就在工作区。
- 暂存区：你可以把它理解成超市购物车。
git add就是把你看中的商品放进了购物车，这时候你还能随时不要，把商品拿出去。 - 版本库：是收银台结完账的购物袋。
git commit就是把购物车里的东西正式打成一个包裹，永久存在Git历史里。
这个类比能直接解释一类高频问题："我改完代码、想撤销，到底用git checkout还是git reset？"答案取决于你的改动在哪个区：
# 改动在工作区，还没 add，直接放弃修改 git restore src/main/java/com/example/controller/UserController.java # 也可以等价地使用老写法 git checkout -- src/main/java/com/example/controller/UserController.java# 已经 add 进暂存区，想撤销暂存、保留工作区改动 git reset HEAD src/main/java/com/example/controller/UserController.java注意区分这两者的行为：前者是把你工作区里改错的内容恢复成上次提交的版本，改动直接没了；后者只是把文件从暂存区"踢"出来，工作区里你改过的代码还在，随时可以重新编辑再add。
2.2 三个区对应要会看的"状态查询三兄弟"
配合三区模型，我把日常开发里最高频的三条查询命令捋一下：
git status # 看哪些文件改了、哪些文件已暂存 git diff # 看工作区里还没暂存的改动 git diff --cached # 看暂存区里已准备的改动，等价于 git diff --staged git log --oneline # 看版本库里已提交的历史有次一个同事说"我代码明明改了，commit里怎么没有"，我让他跑一下git diff，结果改了十几个文件，但git add只添加了一个。这就是典型的不看状态瞎提交。工作区、暂存区、版本库各管一摊，你得先确认东西放对了位置，再往下走。
2.3 .gitignore：Java项目里必须从第一天就配置好的防线
这个问题老生常谈，但每次都有人栽。我一个同事曾经把整个target/目录提交进了Git仓库，那次提交直接让仓库体积暴涨几百MB，后面所有同事git clone都慢得要死。后来清理仓库也是折腾了一下午。
Java项目里必须配置的.gitignore至少包括以下几类：
# 编译输出 target/ *.class # IDE 配置 .idea/ *.iml .vscode/ .settings/ .classpath .project # 日志 *.log logs/ # 系统文件 .DS_Store Thumbs.db # 本地环境配置 / 敏感信息 application-local.yml *.sql很多人容易忽略application-local.yml这种东西。你自己本地的数据库密码、第三方密钥都在里面，一旦提交到公开仓库，后面就是安全事故级别的问题了。.gitignore的规则也别写得太复杂，我一般是按"编译产物、IDE配置、本地配置、日志"四类维护，清晰好查。
提示：
.gitignore只对未跟踪文件生效。如果一个文件已经被git add跟踪过了，再写进.gitignore也没用，需要先执行git rm --cached把它移出版本控制，再补上忽略规则。
3. 分支与合并：团队协作里的核心战场
3.1 创建、切换、推送、删除分支的完整姿势
单人开发不开分支也罢，但团队协作里没有分支管理就是灾难。我们团队目前是按"主干开发 + 功能分支"的模式在走：主干永远是稳定可发布的，新增功能一律新建分支。
创建并切换分支：
git checkout -b feature/order-export # 等价于两条命令 git branch feature/order-export git checkout feature/order-export从某个历史节点拉出分支，可以指定基点：
git checkout -b feature/hotfix origin/main推送分支到远程并建立关联：
git push -u origin feature/order-export-u参数设置了上游跟踪，下次在这个分支上直接git push或git pull就不用再写远程分支名了，个人觉得这是最容易忽略但又最实用的小参数。
删除分支分别有两条命令：
git branch -d feature/order-export # 本地删除，安全模式 git push origin --delete feature/order-export # 删除远程分支用了-d时如果分支上有未合并的内容，Git会拒绝删除，这是很好的保护机制。想强制删除才用-D，但除非你非常确定这个分支没用了，否则不建议这么干。
3.2 merge 和 rebase：不是二选一，而是分场景
这个是Git里最让Java开发头疼的问题之一，我在不同团队看过截然相反的规矩：有的团队一律merge，有的团队一律rebase，还经常有人因为这吵起来。我的观点是用场景说话。
merge的场景：把主干合进自己的功能分支、或者把功能分支合回主干，需要保留"分支从哪里来、合到哪里去"的完整拓扑信息时，用merge最直观。它会生成一个合并提交，历史里能看到清晰的分岔和汇合。
rebase的场景：想把自己在本地做的分散提交整理成一条干净的线，或者想直接基于远程最新代码重放自己的修改时，用rebase。它适合那些"还没推到远端、或者推了远端但不涉及协作"的分支。
具体到我日常的操作，通常是这么安排的：
# 功能分支上干活 git checkout feature/order-export git pull --rebase origin main # 把主干最新提交拉到基线之下 # 处理完冲突后 git push --force-with-lease origin feature/order-export这里有个关键坑：一旦你的分支已经推到了远程并且有同事在上面协作，别轻易rebase。因为rebase会重写提交哈希，别人拉取时会出现历史混乱，处理起来极其费劲。所以我自己定的规矩是：非共享分支随意rebase，共享分支只做merge。
3.3 冲突解决：别怕，看清楚再动手
冲突几乎是每个Java开发每周都要面对的事。最常见的场景：你和同事同时改了一个实体类，你加了age字段，他加了email字段，合并时就出现冲突了。
Git处理冲突会在文件里插入这样的标记：
public class User { <<<<<<< HEAD private Integer age; ======= private String email; >>>>>>> feature/order-export }我看很多人遇到这个问题第一反应是紧张，其实处理流程非常固定：
- 打开冲突文件，搜索
<<<<<<<定位所有冲突位置。 - 逐处判断：是保留当前分支的、保留对方分支的、还是两处都要。
- 删除
<<<<<<<、=======、>>>>>>>这三行标记。 - 保存文件后执行
git add，表示该文件冲突已解决。 - 继续合并流程（merge或rebase），直到Git提示完成。
如果冲突文件太多、改得晕头转向，有个省心办法：用IDE提供的可视化合并工具。主流Java IDE都内置了冲突对比界面，可以左边看自己的改动、右边看别人的改动、中间直接编辑合并结果，比手动盯这些标记高效很多。
提醒：rebase过程中遇到冲突和merge过程中遇到冲突，后续命令不一样。rebase是
git rebase --continue，merge是git merge --continue或者直接git commit。这一步我见过无数人卡住，必须记住当前是在哪个操作里。
4. 历史查看与代码回滚：别让一次错误提交毁掉半天工作量
4.1 把 git log 用出花来
git log是最容易被低估的命令之一。Java开发平常查历史，最常用的几条我给列全了：
# 经典的一行带图历史 git log --oneline --graph --all --decorate # 只看最近N条 git log -n 10 # 查看某次提交改了哪些文件、每个文件改了多少行 git log --stat # 查看某次提交的完整diff git log -p <commit-hash> # 按提交信息关键词搜索 git log --grep="登录" # 查看指定文件的演进历史 git log --oneline -- src/main/java/com/example/service/OrderService.java在排查"这段业务逻辑是谁在什么时候改的"这类问题上，git log -S某种字符串或者git log -L 起始行,结束行:文件路径也极其好用。后一个命令可以直接看某个文件里连续几行的历史变更，我在追溯旧代码逻辑时经常用它。
4.2 回滚到底是 reset 还是 revert：一个动时间线，一个不动时间线
这是一个值得说清楚的问题，也是很多初级开发特别容易搞混的。归纳下来：
git reset是让当前分支的指针往回移动，看起来就像那些提交从未发生过，会改变历史。git revert是生成一个全新的提交，用反向改动去抵消旧的提交，历史保持完整。
最典型的场景：代码已经push到了团队共用的远程分支，结果发现上次提交有严重bug。这时候千万别用reset，因为你一reset，本地分支和远程分支就分叉了，下次push会被拒，强制push又会把同事的提交搞乱。正确做法是用git revert：
git revert <commit-hash>这个操作会创建一个"与之前相反"的新提交。比如旧提交是新增了一行，revert就产生一个删掉这行的提交。要撤销某个合并提交的话，需要加-m 1参数指定保留哪条主线，这属于较高级场景，遇到时再查细节也不迟。
而git reset更适合操作还没push到远端的提交，它有三种模式：
git reset --soft <hash> # 仅移动指针，暂存区和工作区都保留改动 git reset --mixed <hash> # 默认模式，暂存区被重置，工作区保留改动 git reset --hard <hash> # 指针、暂存区、工作区全部回到指定状态，工作区改动直接丢失三个模式怎么选？想修改上次提交的信息、补文件，用--soft或--mixed；想彻底放弃本地改动回到某个历史版本，才用--hard。--hard是危险操作，我在团队里一直强调：不确认清楚就一定别硬来。
4.3 git reflog：所有后悔药的入口
很多人不知道Git还有个本地操作日志，叫reflog。它记录了你每一次指针移动的历史，包括reset、rebase、checkout等。这意味着即使你git reset --hard丢掉了提交，只要这个提交在本地存在过一段时间，git reflog就能帮你找回来。
实战场景：某天上午我不小心在功能分支上git reset --hard了一个没push的提交，里面是重构到一半的代码，当时心都凉了。后来想起来用 reflog ：
git reflog输出里能看到一堆形如HEAD@{2}: reset: moving to 9a3f5b2的记录，每条前面都有一个提交哈希。我把分支重新切到丢失提交的哈希上：
git checkout <丢失提交的哈希>丢失的代码就回来了。之后再从那个临时状态重新拉一个分支，继续之前的工作。这个经验真的救过我很多次，每次给团队讲Git技巧我都第一个说它。
5. 实战项目里那些让我印象深刻的Git事故与补救
5.1 提交信息写错了、文件漏提交了：用 amend 优雅补救
有次我提交完代码正要推送，结果发现commit信息少写了个功能点，而且有个新加的工具类文件忘记git add了。这时提交还没有push到远程，完全可以用git commit --amend补救：
git add src/main/java/com/example/util/DateUtil.java git commit --amend -m "feat: 新增用户导出功能，补充日期工具类"--amend会把最后一次提交"重做"，它不会新增一条提交，而是直接替换原来的提交。这个操作同样只适用于还没推到远程的分支。如果已经push了，再amend然后强推，就又会殃及协作的同事。
5.2 一不小心提交了大文件，仓库越来越臃肿
处理过一回大型项目里的经典事故：团队里有人把几十MB的二进制资源包提交了，之后仓库体积膨胀，所有人clone都要多等很久。推上去再删文件其实是治标不治本，Git会把大文件的记录保存在历史里。
如果提交还没推送，可以尝试用git reset --soft把影响范围控制在本地，再重新提交干净的文件，同时把大文件加入.gitignore。
如果推送过了，事情就比较棘手。正经的解决方案是用git filter-branch或git filter-repo这类工具重写历史，把指定大文件从所有历史提交中抹掉。这类操作的危险性很高，属于仓库级维护操作，会改写所有协作者的提交哈希，必须选在团队空闲时间做，做完后全员要重新clone。在我经历过的那次事故里，因为仓库体积实在太大，最后是约定好时间、备份全量代码、在测试环境验证通过后才执行的，整个过程不敢有任何马虎。
5.3 本地分支和远程分支状态错乱：一个快速自查流程
还有种很常见的"错乱"是：本地有自己的提交，远程也被别人推了新提交，直接git push被拒绝。这时与其瞎试一通，不如按流程走：
# 1. 先拉取远程状态，但不自动合并 git fetch # 2. 查看本地分支和远程分支的关系 git status git log --oneline --graph --all -n 20 # 3. 基于远程最新状态重放本地提交 git pull --rebase origin main # 4. 处理完潜在冲突后推送 git push origin main这套流程我实践了无数次，几乎没有失手过。关键是第3步的--rebase，它保证本地提交会在远程提交之后按顺序重放，不会产生节点合并的分叉痕迹。如果这一步报冲突，就进入前面说的冲突处理流程，解决完git add后继续git rebase --continue。
5.4 正在写着代码，临时要切分支：先 stash
Java开发经常会碰到这种场景：正在开发A功能，代码写了一半，测试环境突然报了个线上的急bug要立刻修。这时候手上的改动既不能提交也不能直接扔掉，怎么办？git stash就是为此设计的：
git stash # 把当前工作区改动压入栈 git stash list # 查看保存了哪些现场 git checkout -b fix/urgent # 切到热修复分支 # 修复完成提交后，切回原分支 git checkout feature/order-export git stash pop # 恢复之前的现场我用stash之前有个好习惯：先git status确认改动内容，再git stash。恢复的时候如果出现冲突，说明恢复时当前分支状态已经和你保存现场时的基线不一致了，这时候逐个解决冲突即可，不用慌。
5.5 强制推送的两种参数：force 与 force-with-lease
强推是团队协作中最敏感的操作，因为一旦远程分支被覆盖，同事的提交就"消失"了。其实这个场景有一种更安全的推法：
git push --force-with-lease origin feature/order-export--force-with-lease跟--force的差别在于：后者是闭着眼睛强推，覆盖一切；前者在推送前会检查远程分支在你上一次fetch之后有没有变化，如果别人推了新提交，强推会被拒绝，需要你重新fetch再处理。这个参数讲究的是"允许我覆盖自己基于的旧状态，但绝不允许覆盖别人新推的东西"。日常如果非要用强推，我都建议先上--force-with-lease，把它当成默认，能帮你挡住很多隐形的事故。
我在实际项目里使用Git这么多年，最大的感受是：Git本身不难，难的是理解它背后的模型——三区、提交、分支、引用这些概念一旦在心里扎稳了，绝大多数操作都是"模型推演"的结果，根本不需要背命令。希望这篇内容能帮你把日常开发里的Git操作理顺，少踩几个我已经替你踩过的坑。最后再分享一个我坚持了很久的小习惯：每次准备push前，先花三十秒看一眼git status和git log --oneline -n 5，大部分低级事故，都是在这一眼之间被拦下来的。
