git reset --hard 会同时清空工作区、暂存区和 HEAD 指针，丢弃所有未包含在目标提交中的修改；误操作后应立即用 git reflog 恢复，因其完整记录所有 HEAD 变动。
Git 不是“会用 add/commit/push 就算会了”的工具，真正卡住人的从来不是命令本身，而是工作区、暂存区、本地仓库、远程仓库这四层状态的错位，以及对 reset、rebase、cherry-pick 这类重写历史操作的误判。
git reset --hard 为什么总把代码删没？
因为 --hard 同时清空工作区 + 暂存区 + HEAD 指针，它不区分“你刚写的还没 add 的代码”和“已经 commit 过的历史”，只要不在当前 HEAD 指向的提交里，就全丢。
- 误操作后第一反应不是重写，而是立刻执行
git reflog—— 它记录所有 HEAD 变动，哪怕你reset了三次，也能看到上上个位置的哈希值 -
git reset --soft HEAD~1只回退指针，保留暂存区；git reset --mixed HEAD~1（默认）回退指针+清空暂存区但保留工作区；只有--hard才动工作区文件 - 团队协作中禁用
git push --force或--force-with-lease推送reset后的分支，否则别人pull时会遇到不可合并的分叉
merge 冲突时，
冲突标记里， 和 <code>======= 之间的内容，是「你当前分支最新提交里的版本」；======= 和 >>>>>> commit-hash 之间，是「要合并进来的那个提交里的版本」。别凭感觉猜，先看 git status 确认当前在哪个分支，再看 git log --oneline -n 5 确认 HEAD 指向谁。
Conventional Git
下载
Conventional Commits v1.0.0 分支、工作树命名及提交信息规范，适用于 GitHub 与 GitLab 项目，用于创建分支和命名工作树等场景。
- 不要直接删标记行——删了 Git 就无法识别冲突已解决
- 改完后必须
git add <file>标记为已解决，再git commit，否则git status仍显示冲突 - 如果只是想放弃合并、退回合并前状态，用
git merge --abort，比手动删冲突标记快且安全
feature 分支推送到远程后，为什么别人看不到？
执行 git push 默认只推送当前分支到同名远程分支，但前提是远程已有该分支名。如果远程没有 feature/login，git push 会失败或静默忽略——除非你显式指定推送目标。
- 首次推送新分支：用
git push -u origin feature/login，-u建立上游追踪，之后直接git push就能同步 - 检查是否已设置上游：
git branch -vv，带[origin/feature/login]表示已关联 - 别依赖
git push --all，它会把所有本地分支都推上去，包括临时调试分支，污染远程分支列表
最常被忽略的其实是 .gitignore 的生效时机：它只对「未被 Git 跟踪」的文件起作用。一旦某个文件已被 add 过，后续往 .gitignore 里加规则就无效了，得先 git rm --cached <file> 把它从暂存区移出，再提交。
