我有两个不同版本的分支 - 一个用于当前开发，另一个是长期支持几年。结果他们显着不同。我有一些文件存在于两个分支中，但在开发中重命名。其中一个修复最初是在开发分支中进行的，但后来发现在支持分支中也是必需的。但是，cherry-pick报告该文件在支持分支中不存在（因为它在开发中被重命名，并且支持它有不同的名称）。
这个特定文件的内容是类似的，所以看起来补丁应该应用得很好 - 如果我可以直接git它应该应用它的文件。有没有办法（最好在命令行中）手动指导git做我需要的事情？
答案 0 :(得分：11)
cherry-pick命令使用与merge命令相同的merge strategies。默认的递归合并策略能够在正常情况下检测重命名，但如果文件在这种情况下分歧过多，它可能会失败。
除了在另一个答案中概述的低级别索引黑客攻击之外，可能只需通过摆弄策略选项就可以使其工作，例如增加将类似文件视为重命名版本的阈值（默认为50％）：
git cherry-pick -Xrename-threshold=20% 0123sourcecommithash
否则你也可以手动方式，即
git format-patch 0123sourcecommithash -1
然后编辑创建的0001-Commit-message-here.patch以更改文件路径并再次应用于目标分支：
git am 0001-Commit-message-here.patch
它将保留所有原始提交消息，作者姓名，日期等，并可能作为简单的一次性解决方案。
答案 1 :(得分：3)
使用脚本你可以用一行代码来完成：
$ git merge-associate Old/Path/Original.txt :1:New/Path/Renamed.txt :3:New/Path/Renamed.txt
与git merge-file支持的:stage:filepath语法相同，而不会在Git常见问题解答中描述git show :1:New/Path/Renamed.txt > 1.txt; git show :3:New/Path/Renamed.txt > 3.txt。{/ p>