关于这一点有几个问题，但我不能找到一个明确的最小示例。假设我们想要将一个特定分支的提交应用到多个分支，而不需要补丁提交之前的遗留提交。例如
mkdir cherry_test
cd cherry_test
git init
printf "onentwonfourn" > file.txt
git add file.txt; git commit -m 'master: 1'
git branch dev
echo five >> file.txt
git add file.txt; git commit -m 'master: 2'
git checkout dev
echo FIVE >> file.txt
git add file.txt; git commit -m 'dev: 3'
echo SIX >> file.txt
git add file.txt; git commit -m 'dev: 4'
现在让我们做一个补丁来填补空白(插入'three'缺失的行):
perl -0777 -i -pe 's/twonfour/twonthreenfour/igs' file.txt
git add file.txt; git commit -m 'dev patch'
git log
commit d44425da786e161dd066b5db6db8b649b99ba575
author etc
dev patch
那么这个答案表明我们需要使用git format-patch -1 d44425da。但是如何将其与master和其他分支合并呢?我的努力似乎都导致以前的dev提交也合并了。
cherry-pick命令从一个特定的提交及其父提交创建一个补丁，并将该提交应用于当前分支。这应该对你有用:
git checkout master
git cherry-pick <commit-id>
Git用户命令很少修改未检出分支的分支指针。因此，如果一个命令修改了一个分支，假设它是签出的分支。
所以所有关于patch, apply和am的业务都是为了修补所有分支?
查看man pages，这些似乎是用于通过电子邮件发送补丁，或从"补丁"文件应用补丁。
git-format-patch -准备电子邮件提交的补丁
应用补丁
git-am -从邮箱应用一系列补丁
git-apply -对文件和/或索引
git的"手册页"通常是了解如何使用git命令的一个很好的资源。可以通过git help cherry-pick命令查看或man git cherry-pick或在网上查找
另一篇关于git入门的好文章是计算机科学家的git。它解释了git的(非常简单的)内部工作原理，一旦您理解了这些，使用git就变得非常直观了。
如果想保留提交消息，请使用-x选项。这样，您仍然可以跟踪提交的起源，并且可以避免将来的合并冲突。
git checkout <branch>
git cherry-pick -x <commit-id>
幼稚的评论，但你必须在此之后推动你的更改。
git push origin <branch>
正如nishantjr所建议的那样，你当然可以用一个精选的来做。
但是，根据您如何进行开发，我可能会期望这样的内容:
修复master:
git checkout master
perl -0777 -i -pe 's/twonfour/twonthreenfour/igs' file.txt
git add file.txt; git commit -m 'master patch'
现在，将更改从master合并到dev。我将使用git merge，但git rebase的工作原理类似:
git checkout dev
git merge master
对于你想做的，你可能不应该使用git format-patch, git apply，或git am。只有当你想要，例如，通过电子邮件将补丁文件发送给其他人时，才需要这些。但这是一个相当罕见的用例，因为从像github这样的东西中提取比应用补丁文件要容易得多。
合并master后，您将会有冲突，因为您在master分支中添加了five，而在dev分支中添加了FIVEnSIX。运行git status将提供有关如何解决冲突的基本信息。你的file.txt看起来像这样:
one
two
three
four
<<<<<<< HEAD
FIVE
SIX
=======
five
>>>>>>> master
你必须编辑这个文件来告诉git你想要修改什么。既然我们在开发分支上，让我们保持开发分支的变化。编辑文件如下所示:
one
two
three
four
FIVE
SIX
保存，然后是git add file.txt，然后是git commit。