git checkout --ours 用当前分支版本覆盖冲突文件，git checkout --theirs 用被合并分支版本覆盖；merge 时 ours=HEAD 分支、theirs=待合并分支，rebase 时含义反转，需特别注意。
git checkout --ours 和 git checkout --theirs 怎么用
这两个命令是 Git 冲突解决中最直接的“版本取舍”工具，适用于你明确知道该保留哪一方修改的场景。它们不编辑冲突块内部，而是整份文件覆盖——git checkout --ours 用当前分支（HEAD）的完整内容替换工作区文件；git checkout --theirs 则用待合并分支（比如 origin/main 或 feature/login）的完整内容覆盖。
常见错误现象：在冲突状态下误运行 git checkout --ours 却没加文件名，Git 会静默失败且不报错；或者在 rebase 过程中混淆了 “ours/theirs” 的含义（rebase 时 --ours 实际指 *rebase 目标分支*，--theirs 指 *当前被重放的提交*，和 merge 场景相反）。
使用场景包括：
- 你确认同事改的某个配置文件完全正确，自己本地的临时调试代码可以全删，就用
git checkout --theirs config/database.yml - 你在 feature 分支上重构了整个工具类，而 main 分支只修了一个无关紧要的注释，想无条件保留自己的版本，就用
git checkout --ours src/utils/StringUtils.java - 批量处理多个文件时，可配合
git status --porcelain | awk '/^UU/{print $2}' | xargs -r git checkout --ours（注意：仅限确定全部保留当前分支时使用）
为什么 git checkout --theirs 在 rebase 中行为反直觉
rebase 不是 merge，它的“三方基础”不同。merge 以共同祖先为 BASE，HEAD 为 ours，MERGE_HEAD 为 theirs；而 rebase 把目标分支（如 main）当作新的 BASE，正在重放的提交才是“外来变更”。所以当你执行 git rebase main 遇到冲突时：
git checkout --ours → 实际取的是 main 分支的内容（即“基底”版本）
git checkout --theirs → 实际取的是你当前这个被暂停的 feature 提交的内容
容易踩的坑：
- 看到提示 “CONFLICT in src/api.js” 就习惯性敲
git checkout --theirs src/api.js，结果却丢掉了自己刚写的逻辑（因为此时 yours = main，theirs = 你的提交） - 没意识到
git status输出里的 “both modified” 文件，在 rebase 下不能靠颜色或上下文判断谁是谁 - 想快速跳过冲突但又不确定语义，应优先用
git rebase --skip（仅限该提交确实无需应用）而非盲目覆盖
用 git restore 替代 checkout 更安全吗
Git 2.23+ 引入的 git restore 是更语义清晰的替代方案，尤其适合保留指定版本的场景。它把“恢复工作区”和“恢复暂存区”拆开，避免 git checkout 一身多职带来的歧义。
Git post-commit 钩子 + SQLite 提交索引工具。自动将每次提交的元数据（哈希值、作者、分支、仓库、主题）记录到本地 SQLite 数据库中，随后提供一个命令行接口（CLI），支持查询、列表展示、统计、删除和更新记录。 触发场景：管理 Git 钩子、跨仓库查询提交历史、定位某次提交所属的仓库、查看提交统计信息、将提交记录写入本地索引。 当用户提及“提交日志记录”、“提交索引”、“跨仓库查找提交”、“Git 钩子管理”，或希望以结构化方式查询其提交历史时（即使未明确指出该工具），请使
等价操作：
-
git checkout --ours file.txt≈git restore --source=HEAD --staged --worktree file.txt -
git checkout --theirs file.txt≈git restore --source=MERGE_HEAD --staged --worktree file.txt（merge 时）或--source=REBASE_HEAD（rebase 时）
优势在于：
- 命令名
restore直观表达“恢复某来源”，比checkout更贴合用途 - 必须显式指定
--staged和--worktree，不会意外只恢复暂存区或只恢复工作区 - 支持
--source=commit-hash，可从任意历史提交恢复，不只是 ours/theirs
但要注意：老项目或 CI 环境可能仍用旧版 Git，git restore 不可用，此时还是得回退到 checkout。
冲突标记里
是的，但仅限于 git merge 场景。这个标记是 Git 自动生成的，HEAD 指向当前检出分支，也就是 merge 命令发起时的分支（例如你在 main 上运行 git merge feature，则 HEAD 就是 main，即 ours）。
真正容易被忽略的点是：这个标记只是“快照位置”，不代表逻辑正确性。比如你刚 git pull origin main，但本地有未提交的修改，Git 会先尝试自动合并远程变更到你的工作区 —— 此时 HEAD 虽然是 main，但冲突块里的 “ours” 实际混入了你未提交的脏修改，和真正的 main 分支 HEAD 并不一致。
所以，当看到冲突标记时，别只盯 HEAD 和 theirs 标签，先用 git show HEAD:file.txt 和 git show MERGE_HEAD:file.txt 分别看两个纯净版本，再决定怎么融合。手动删标记不是目的，理解两方变更意图才是关键。
