Git 高效工作流实践指南

要解决什么问题

提交历史一团乱、rebase 和 merge 分不清、误删分支后觉得代码永远找不回来、团队分支策略迟迟定不下来。这个技能的核心判断是：Git 里几乎没有真正丢失的提交，恐惧来自不理解。所有操作都是在工作区、暂存区、本地库、远端四个区间之间搬运代码，每个“可怕”的命令只是决定了动哪个区、动到哪里；配合本地操作日志 reflog，你就有了无限后悔药。

技能如何工作

日常提效：用交互式暂存的 patch 模式把一坨改动拆成语义化提交；stash push -m "描述" 带说明储藏临时切换；git switch - 快速回到上一个分支；commit --amend 修补未推送的提交；blame 定位改动来源、bisect 二分定位引入 bug 的提交。

历史整形：守住黄金安全线——只整形未推送到共享分支的提交。rebase -i 把零碎提交 squash 成主提交；提交信息说清“为什么”比“改了什么”重要；一个提交只做一件事。决策原则：私有历史可整形，公共历史只追加——同步主干用 rebase，共享分支合流用 merge。

冲突解决：冲突不是错误，是 Git 不敢替你决定。先读双方提交说明理解意图再改代码；rebase --abort / merge --abort 可随时无损退出；预防优于解决——小步提交、频繁同步主干。

灾难恢复：reflog 默认保留 90 天，丢失的提交和误删的分支都能从中找到哈希；未 add 过的改动最难救，这就是频繁 add 的意义；误 push 的密钥立即吊销；合错分支已推送用 revert -m 生成反向提交，不要 reset。

团队策略：小团队用主干开发加短命功能分支（≤2 天）；多人并行用功能分支加 PR；固定发版周期加 release 分支。规范四条：主干保护、提交前缀统一、分支命名规范、合入即删。

适用边界

reset --hard、push --force 等破坏性命令执行前先确认影响范围，共享分支上使用需团队共识；各平台的保护分支与 PR 能力有差异，以官方文档为准。