GitPython 自动化拉取合并需绕过默认不处理冲突的缺陷；pull() 可能不更新本地分支因 refspec 未显式指定；合并冲突须捕获 GitCommandError 并用 unmerged_blobs() 解析冲突文件。
GitPython 能完成拉取与合并的自动化，但必须绕开它默认不处理冲突的缺陷；直接调用 repo.git.merge() 在有冲突时会抛出异常，而不是返回状态码。
为什么 repo.git.pull() 有时不更新本地分支
常见现象是执行 repo.git.pull('origin', 'main') 后，repo.head.commit.hexsha 没变，但远程已有新提交。这是因为 GitPython 的 pull 方法底层调用的是 git pull <remote> <refspec>，而 refspec 若未显式指定（如 main:main），Git 可能跳过 fast-forward 合并，尤其当本地分支已设置上游但配置不一致时。
- 确保远程分支已正确关联：运行
repo.create_remote('origin', url)后，再执行origin.fetch()，然后手动repo.heads.main.set_tracking_branch(origin.refs.main) - 改用更可控的组合：先
origin.pull()（无参数，依赖 upstream 配置），再检查repo.git.rev_parse('origin/main')是否 ≠repo.git.rev_parse('main') - 避免传字符串分支名给
pull()；它不等价于命令行的git pull origin main，后者实际是git fetch origin main && git merge FETCH_HEAD
合并操作必须捕获 GithubCommandError 并手动解析冲突文件
调用 repo.git.merge('feature/login') 时，只要发生冲突，GitPython 就会抛出 GitCommandError，且异常信息里不会列出具体冲突文件——它只是把 Git 命令的 stderr 原样包裹返回。
- 合并前先
repo.git.status('--porcelain')，确认工作区干净；否则merge直接失败 - 捕获异常后，用
repo.index.unmerged_blobs()获取冲突文件列表，该方法返回 dict，key 是路径，value 是三元组(stage_1, stage_2, stage_3)，对应 base、ours、theirs - 不要依赖
repo.is_dirty()判断是否冲突：它返回True即使只是 untracked 文件存在，无法区分真实冲突
企业环境中批量拉取多分支需绕过 git pull --all 的陷阱
git pull --all 不等于“拉取所有远程分支”，它只对当前已存在的本地跟踪分支执行 pull，而不会自动创建缺失的本地分支。企业 CI/CD 中常需同步 main、develop、release/* 等全部分支，此时必须分两步。
立即学习“Python免费学习笔记（深入）”；
- 先
origin.fetch('--prune')清理过期远程引用，再遍历origin.refs过滤出refs/remotes/origin/*分支 - 对每个远程分支
r，用repo.create_head(r.remote_head, r.commit)创建本地同名分支（若不存在），再r.checkout()+repo.git.reset('--hard', r.commit)强制对齐 - 禁止使用
repo.git.pull('--all')：它在 GitPython 中行为不稳定，某些版本会忽略--all参数，仅作用于当前分支
真正难的不是写几行 repo.git.pull()，而是当 merge 报错时，你得从 repo.index.unmerged_blobs() 里捞出冲突路径，再决定是 abort、手动 resolve 还是跳过——这些逻辑没有现成封装，全得自己兜底。
