正确做法是为每种语言或每位译者建独立分支，如feat/translate-zh_CN，并禁止直接向main推送PO文件；合并前须用msgfmt -c校验语法，避免因msgmerge行号差异导致冲突。
git分支怎么管理多语言PO文件不冲突
直接在main分支上改zh_CN.po或fr.po，很快就会和别人提交的翻译撞车——尤其当多个译者同时处理同一份模板git-cola.pot时，msgmerge生成的上下文行号稍有差异，git merge就报冲突，且全是msgid/msgstr块里的“看似一样实则不同”的行。
正确做法是为每种语言或每位译者建独立分支：
- 按语言建分支：比如
feat/translate-zh_CN、feat/translate-es，所有该语言的PO文件修改只在这个分支里提交 - 按任务建分支：比如
fix/po-update-2026Q3，用于同步上游git-cola.pot后批量更新所有PO文件 - 禁止直接向
main推送PO文件；合并前必须用msgfmt -c zh_CN.po校验语法，否则CI会失败
如何用git cherry-pick把某次翻译提交迁移到其他分支
有时你只想把某个译者修复的msgstr错译（比如把“Commit”误翻成“承诺”）单独拎出来，补到stable分支上，而不是整个合并分支——这时cherry-pick比merge更干净。
操作要点：
- 先
git log --oneline zh_CN.po找到目标提交的SHA（例如a1b2c3d） - 切到目标分支：
git checkout stable - 执行
git cherry-pick a1b2c3d；如果PO文件结构差异大，可能提示冲突，需手动解决msgstr部分 - 解决后
git add zh_CN.po && git cherry-pick --continue，别忘了再跑一次msgfmt -c
git diff对比两个分支的PO文件翻译差异
git diff main..i18n-fr branch1..branch2 zh_CN.po这种写法容易漏掉关键信息：PO文件里大量空行和注释行，diff默认输出会淹没真正改动的msgstr。
推荐加参数聚焦语义变更：
-
git diff -U0 --ignore-all-space main..feat/translate-fr zh_FR.po | grep "^+msgstr"—— 只看新增/修改的翻译值 -
git diff --no-index --color-words=.<code>msgstr/dev/null zh_CN.po —— 高亮显示msgstr字段内字符级变化（需Git 2.30+） - 避免用
git difftool直接开GUI对比PO文件——多数工具把msgid和msgstr当成普通文本，无法识别翻译单元边界
为什么不能用git-lfs管理PO文件
有人想把几百个PO文件扔进git-lfs来“加速克隆”，结果发现git status不显示修改、git diff全变二进制、CI里msgfmt校验直接失败——PO文件本质是纯文本，LFS反而破坏了Git对文本变更的精准追踪能力。
真正该用LFS的，是项目里那些和国际化无关的大文件：
- 翻译记忆库TMX文件（如果体积超10MB）
- 模型微调用的双语语料压缩包
- UI截图等验证用图片
- PO文件必须留在Git原生索引下，否则
git blame zh_TW.po查不到谁在哪天改了“暂存区”这个词的译法
多语言文件的版本控制难点不在体积，而在语义一致性——每次msgmerge重排条目顺序、增删空白行，都会触发Git认为“整块内容变了”。盯住msgstr本身是否变，比盯住文件是否变更重要。
