Git 常用操作与分支管理心得
Git 用了挺久，但一直停留在 add/commit/push 三板斧。最近专门花时间把分支管理和历史整理搞明白了，记录心得。
一、日常高频命令
git status # 随时看状态, 养成习惯
git add -p # 交互式分块暂存, 提交更干净
git commit -m "说明" # 提交信息写"为什么"而不是"做了什么"
git log --oneline --graph # 图形化看历史
git diff / git diff --staged二、分支模型
我的简化版分支习惯（个人项目够用）：
main：永远保持可发布状态；- 功能分支
feature/xxx：从 main 切出，做完合回； - 修 bug 用
fix/xxx，命名一眼看出用途。
git switch -c feature/login # 创建并切换分支
git switch main
git merge feature/login # 合回主干
git branch -d feature/login # 删除已合并分支三、merge 还是 rebase
这是最容易纠结的点，我的理解：
- merge：保留真实历史，会多一个合并提交，分支图呈"菱形"；
- rebase：把本地提交"搬到"最新主干之后，历史成一条直线，干净但改写了历史。
铁律：已经 push 出去的提交不要 rebase。rebase 只用于整理"还没分享的本地提交"。
个人习惯：合入主干前用 git rebase -i 把零碎的 wip 提交压成一个有意义的提交，再 merge 回 main。
四、冲突解决思路
- 冲突不是错误，是 Git 把决定权交给你；
- 打开冲突文件，找
<<<<<<<标记，看清两边各改了什么； - 改完后
git add标记已解决，再继续 merge/rebase； - 解决完一定要跑一遍程序确认没改坏。
五、后悔药
git restore file.txt # 丢弃工作区修改
git restore --staged file # 取消暂存
git commit --amend # 修补上一次提交 (未 push)
git reflog # 终极后悔药, 找回"丢失"的提交reflog 记录 HEAD 的每一次移动，几乎任何误操作都能靠它找回来，新手最该记住的命令就是它。
六、小结
Git 的核心是"提交是有意义的快照"。提交粒度合适、信息写清楚、分支命名规范，后面所有的协作和回滚都会顺。