我不知道在git中有什么方法可以直接做到这一点，但你可以使用git log来列出所有相关的提交，并使用一些shell脚本将它们应用到master上。
第一步是找出master和dev分支的分歧点。如果dev是基于master之上的，那么很容易（该点就是master），但如果不是，您可以使用git merge-base来找到它。
找到它之后，可以使用git log以逆序列出所有相关的提交哈希，并使用xargs将它们通过管道传输到git cherry-pick。
在master分支上运行：

git log `git merge-base master dev`..dev --reverse --format='%H' -- x.txt | xargs git cherry-pick

这里有一个替代方法，有一些缺点，所以仔细考虑它是否符合您的需求：
从“特定文件”的限制来看，我相信你只关心文件的状态，而不一定是逻辑上的变化（即此文件更改是因为错误修复#149）。也就是说，我只希望这些特定文件与dev分支中的内容匹配。
请记住，git提交不是一组更改，而是提交时文件的时间点快照。main、dev、93ab34de和7752fbe之间的所有差异输出都没有保存在提交对象中，所有这些差异都是在运行git diff命令时动态计算的。重放那些提交（挑选）并不是让文件到达同一个点，而是把历史--那些时间点和为什么做出这些更改的理由--带到主分支中。
在cherry-pick之后，关于main如何达到当前状态的叙述包括讨论bug-fix #149、feature Y和code-refactor-for-clarity的提交消息，以及在每个逻辑提交之后文件的状态。如果您需要还原main，提交消息可以帮助您快速了解这些文件被更改的原因。例如，提交7752fbe可以作为目标，因为特征Y具有性能回归。
但在这个问题中，请求似乎更关心特定文件的状态，而不是将特定的历史记录向前推进。历史是关于一组文件的。请求似乎是“我需要这个结束状态”，而不是更改（毕竟，更改可能涉及比我们命名的更多的文件）。
一个解决方案，然后：
1.从main，创建并输入一个新分支（用于卫生）;称之为surgery

1. git checkout dev -- [file1, file2, file3]
   1.测试以确保您的代码现在符合要求
   1.创建一个新的提交;这捕获了main+你从dev checkout 的那些文件的状态。
   1.返回到main并合并你的surgery提交。
   从概念上讲，surgery类似于所有那些精选提交的挤压合并。
   这种做法以及任何挤压合并的缺点是，您会丢失代码开发周围的元数据。Git不再跟踪中间更改的单个提交。这里的一个组合是将git log main..dev作为surgery提交消息的一部分。
   另一个缺点是确认更改已经完成。当提交'feature Y'时，它是git-author所做的一组逻辑更改，并且可以描述这些更改的基本原理。大概他/她/他们已经测试了变化的质量。也就是说，他们验证了在每个提交的每个时间点上一切都正常。如果file 1的改变意味着file 2的更新，那么他们的提交包括了这一点。在我们的git checkout方法中，我们可能会忽略这样的影响。因此，在进行surgery提交时，要非常小心地验证整个代码库的功能。