git按命令中列出的hash顺序依次应用多个非连续commit，若中间某次冲突失败则暂停，需手动解决后git add再git cherry-pick --continue；跳过依赖提交易引发冲突，推荐先用git log确认独立性。
cherry-pick 多个非连续 commit 时，顺序和冲突怎么处理
直接按你想合并的 commit hash 顺序执行 git cherry-pick 即可，Git 不强制要求时间顺序，但实际应用中**越靠后的 commit 越可能依赖前面被 pick 的修改**。如果跳着 pick（比如先 pick A 再 pick C，中间跳过 B），而 C 实际改动了 B 引入的新文件或逻辑，就会触发冲突。
常见错误现象：error: could not apply abc123... fix login timeout 后跟一堆冲突标记，不是 Git 拒绝操作，而是内容层面无法自动合并。
- 推荐做法：用
git log --oneline branch-A ^branch-B先确认这些 commit 确实彼此独立（没有父子依赖） - 一次性 pick 多个：运行
git cherry-pick hash1 hash2 hash3，Git 会按命令中列出的顺序依次应用 - 如果中途出错，用
git cherry-pick --abort回退整个操作；解决冲突后用git add . && git cherry-pick --continue
如何避免 cherry-pick 后丢失原始 author 信息
默认 git cherry-pick 会把 committer 设为当前用户，author 保留原提交者——这是正确行为。但如果你用了 --no-commit 或手动 amend，就可能意外覆盖 author。
容易踩的坑：git cherry-pick -x hash 会在提交信息末尾加 (cherry picked from commit xxx)，但若后续执行 git commit --amend --author="xxx"，author 就被强行改写了。
生成周报：读取本机 Git 仓库最近一周的提交记录，按项目分类提炼总结，生成标准周报格式，通过微信推送并返回给用户。触发词：周报、weekly report、git总结、提交记录总结、工作周报。
- 检查是否保留 author：pick 完后运行
git log -1 --pretty="%an %ae | %cn %ce"，前半段是 author，后半段是 committer - 想强制统一 author（如合规要求），用
git cherry-pick --author="Name <email>" hash</email> - 不要对已 pick 的提交再
--amend，除非你明确知道要改什么
cherry-pick 到不同 base 分支时，为什么有些 patch 总是失败
根本原因不是 commit 本身有问题，而是目标分支缺少该 commit 所基于的“上下文”——比如原提交是在一个有特定目录结构、配置文件或依赖版本的分支上产生的。
典型场景：从 feature/api-v2 挑一个修复数据库字段的提交，cherry-pick 到 main，但 main 还没合入对应的 migration 文件或 model 定义。
- 先用
git show hash --stat看它改了哪些文件，再确认目标分支是否存在这些文件、是否在相同路径 - 如果只是小范围文本冲突，手工编辑后
git add+git cherry-pick --continue即可 - 如果涉及新增文件或重命名，建议先同步基础结构（比如先把 migration 补上），再 pick 功能提交
替代方案：rebase -i vs cherry-pick 多 commit 的取舍
当你要搬的是同一功能下的一串连续提交，git rebase -i 更合适；但题目明确是“非连续”，那 cherry-pick 就是唯一合理选择——rebase 只能操作连续 commit 链。
注意：别用 git format-patch + git am 来绕路，它虽然也能跨分支搬提交，但会丢失 merge 信息、不支持交互式冲突处理，且 patch 文件易受换行符/编码影响，在 Windows 和 macOS 间传递时容易出问题。
- 确认非连续性：运行
git log --oneline feature-X | grep -E "fix|refactor"手动挑出 hash，再用git merge-base feature-X main看共同祖先，确保它们真不在同一条路径上 - 批量操作前，先建临时分支备份：
git checkout -b tmp/cherry-safe main，出错也不影响工作分支 - cherry-pick 本质是 diff 应用，不是引用复制——所以哪怕源 commit 已被 reset 或 prune，只要本地 reflog 还在，hash 依然可用
