常见策略：Git Flow（多分支规范）、GitHub Flow（主干开发 + PR）、Trunk-Based（主干持续集成）。没有绝对最好，适合团队节奏的就是好的。
关键是约定清晰：哪些分支保护、提交如何规范、合并走什么流程，让协作可预测。
协作原则：小步提交、清晰信息、及时同步、主分支保护。
日常高频使用的命令与场景。
创建、切换、合并、删除。
add、commit、amend。
fetch、pull、push。
merge、rebase 选择。
冲突产生与解决。
reset、revert 恢复。
让协作顺畅的落地步骤。
按团队与发布节奏选择策略，写进文档。
统一提交信息格式与颗粒度，配合 commitlint 校验。
PR + 评审 + 主分支保护，合并保持可追溯。
把常见操作与踩坑整理成文档，新人快速上手。
两种回滚方式的区别。
| 操作 | 作用 | 适用场景 |
|---|---|---|
| git revert | 新增一次反向提交 | 已推送/共享分支 |
| git reset | 移动 HEAD 回退 | 未推送/本地操作 |
| git checkout -- | 丢弃工作区改动 | 本地误改 |
| git stash | 暂存未提交改动 | 切换分支前 |
先理解冲突来源，手动合并两边改动，保留双方意图，解决后测试验证再提交。别盲目选一边。
未推送用 reset 回退，已推送用 revert 回滚，避免改写公共历史。
合并保留历史清晰、安全；变基让历史线性但会改写，共享分支慎用。团队约定统一即可。
只要提交还存在于 reflog 中，就可以通过 reflog 找回。别慌，先查日志。
