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></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></file> 把它从暂存区移出，再提交。