最危险操作是直接 git add . && git commit，易提交残留冲突标记（>），导致逻辑错误或崩溃；须人工逐行检查清理、单独 git add 解决文件、用 git diff --staged 验证暂存区、git commit 不带 -m 以保留合并上下文，并推送前运行测试确保逻辑正确。
直接 git add . && git commit 是最常见也最危险的操作——它极大概率会把残留的冲突标记（ / <code>======= / >>>>>>）一起提交，导致逻辑错误或运行时崩溃。
确认所有冲突文件已手动编辑并清理标记
Git 不会自动删掉冲突分隔符，必须人工逐行检查并保留/合并逻辑。常见疏漏点：
- 只改了部分冲突块，其他块仍留着
等标记 - 误删了本该保留的代码，只留了另一方的改动
- 修改了冲突区域，但忘了删掉
=======和>>>>>>之间的“对方版本”段落
建议打开每个标红的冲突文件，在编辑器里搜索 确保零匹配；再用 <code>git diff --staged 看暂存区是否干净——如果输出为空，说明没残留标记且内容已暂存。
用 git add 单独暂存已解决的文件，别用 git add .
git add . 会把未修改但已跟踪的文件、甚至你刚删掉的临时配置也加进去，干扰合并意图。正确做法是：
- 运行
git status，只看到冲突文件状态为both modified - 对每个已编辑完的文件执行
git add <file></file>（例如git add src/utils.js） - 避免
git add -A或git add --all，它们可能引入意外变更
暂存后再次 git status，应只显示 “all conflicts resolved” 和 “to be committed” 的文件列表，没有红色未暂存项。
Github Actions Linter
下载
对 GitHub Actions 工作流 YAML 文件进行 lint 与验证，检查常见错误、安全隐患、已废弃的操作以及最佳实践。适用于要求进行代码检查、验证等场景。
提交时别加 -m，让 Git 自动生成合并提交信息
运行 git commit（不带任何参数）即可。Git 会打开默认编辑器，预填类似这样的信息：
Merge branch 'feature/login' into develop <h1>Please enter the commit message for your changes. Lines starting</h1><h1>with '#' will be ignored, and an empty message aborts the commit.</h1>
你只需保存退出（vim 中按 :wq）。强行用 -m 覆盖会导致丢失关键上下文，比如来源分支名、合并方向，后续排查时无法快速定位“谁合进了谁”。
推送前务必检查暂存区内容是否符合预期
很多人在 git commit 后就直接 git push，但 commit 成功不代表逻辑正确。容易被忽略的关键动作是：
- 执行
git diff --cached（等价于git diff --staged），确认暂存区只有你手动保留的代码，没有多余空行、调试语句或半截逻辑 - 如果项目有 pre-commit hook，确保它通过；没有的话，至少手动跑一遍本地测试（哪怕只是
npm test或简单启动） - 特别注意被冲突影响的边界条件：比如 if 分支、回调函数、配置项开关——这些地方最容易因合并错位而失效
真正麻烦的不是冲突本身，而是冲突解决后没人再看一眼那几行被改过的代码。只要有一处逻辑判断被悄悄覆盖，问题可能潜伏到上线后才爆发。
