我试图将my_branch拆分为多个分支，因为对于单个PR而言，将其other_branch太大了。但是在拆分时，我要保留指定目录（及其子目录）下文件的my_branch的历史记录，同时保留所有其他目录（及其子目录）的other_branch的历史记录。
多个团队成员对my_branch进行的大型提交过多，以至于无法cherry-pick提交与指定目录下文件有关的提交。
答案 0 :(得分：2)
如果我理解的正确，那么cherry-pick的问题不是cherry-pick本身，而是尝试手动进行操作时会遇到的所有麻烦。
我建议您将git rev-list与reverse 和--一起使用，以获取按时间顺序修改了特定路径的所有提交，并提交给用户xargs为您应用cherry-pick。在您的祖先分支中，您可以执行以下操作：
$ git checkout -b <branch_feature_1>
$ git rev-list --reverse <ancestor of my_branch and other_branch>..<my_branch> -- <directory_feature1> | xargs -n 1 git cherry-pick
答案 1 :(得分：1)
...拆分时，我想保留指定目录（及其子目录）下文件的
my_branch的历史记录，同时保留所有其他目录（及其子目录）的other_branch的历史记录。
Git没有文件历史记录。 Git具有提交，其中（a）包含文件和（b）是历史记录。因此，此请求没有任何意义：例如，您从提交c123...开始，这是当前my_branch的技巧。提交c123...有一个父提交，例如c122...，或者有两个父提交，例如c122...和d345...，如果c123是合并提交。
这就是提交c123...的历史：它的父级是c122...，或者它的两个父级是c122...和d345...。同时，提交c123...包含文件dir1/file_a，dir1/file_b，dir2/file_x等（某些特定版本）。父提交c122...包含相似的文件-可能部分或大部分其中的内容与c123...相同，也许不一样。
历史记录是一系列提交，在每次提交到其父级（或同时合并到其所有父级）之后。任何提交的 content 是该提交附加的文件集，再加上元数据（作者，提交者，时间戳，日志消息和父提交哈希）。这就是全部：Git可以向您显示的所有其他内容都是通过比较两个提交的内容而产生的。 1
简而言之，您无法获得想要的东西：Git没有这种归因。没有观念认为它应该在dir1/file_a之后回到父＃1，而在dir2/file_x之后回到父＃2。 （但是请注意，如果例如，父＃1没有<{>} dir2/file_x，那么从从孩子到父母＃1，然后从孩子到父母＃2成功。这是否有帮助，如果有帮助，还取决于很多其他因素。）
来自多个团队成员的大量提交...
更多的是过程问题，必须在Git本身之外解决。
other answer here（我赞成）有一个您可能要使用的过程，一次可以一次选择（某种）提交，从而将一个较大的提交有效地分成许多较小的提交。它们是否在分支上并不重要：像往常一样，每次提交都是其所有文件的完整快照。
1 对于合并提交，当被问及Git时，它将把一个提交（子进程）与多个先前的提交（都是父母的所有提交）进行比较。 Git称这些为 combined diffs （组合差异），它们是还原论者。 Git首先像往常一样进行成对比较。通过这个，我的意思是它比较子代与父代＃1，然后比较子代与父代＃2，依此类推。 （无论如何，大多数合并只有两个父对象。）但是，默认情况下，Git从该差异集中抛出，而子文件版本与 any匹配的任何文件一个这样可以将文件集减少为以下文件集，即dir2/file_x和dir1/file_a的合并提交副本与每个父副本的 不同那两个文件。然后，默认情况下，Git对于合并的差异，将每个父项到（单个）孩子的差异进行比较，找到合并时发生合并冲突的地方，并向您显示（合并）差异，以便您可以弄清楚有人如何进行合并。