所以，我一直在使用git cherry-pick，但它变得很麻烦，我想知道是否有更简单的方法（或其他方法）。
假设我有3个分支：master（稳定，生产候选人），develop（工作分支）和production。
现在，除了稳定的里程碑，production还有一些特定于生产的设置。每次我融入它时我都不想改变的事情。我不能简单地将develop合并到master然后将master合并到production，也不能develop直接合并到production，因为这会创建一个与生产设置冲突。
到目前为止，在git cherry-pick commitA^..commitB中发布production已经有效，但我不想每次都这样做。
我错过了一些明显的东西吗？是否有更简单的方法来合并只是单个分支的提交？
答案 0 :(得分：2)
听起来我应该看看Git Attributes。创建一个包含以下行的.gitattributes文件：
settingsfile merge=ours
这将阻止settingsfile被合并覆盖。而不是冲突，这将通过接受文件的当前状态来静默解析合并。
有关详细信息，请参阅this answer about how to create a custom merge driver
答案 1 :(得分：2)
cherry-pick通常是将特定提交合并到开发线中的最佳和最简单的选项。如果您必须不断cherry-pick从开发分支提交到master / release分支，而不是使用通常的merge命令，只是为了避免覆盖设置文件，您可能需要考虑在部署期间使用某种脚本生成的生产，部署版本的设置文件，和/或为开发和生产环境提供单独的设置文件，例如dev.settings和production.settings。
cherry-pick 您也可以使用rebase --onto或使用补丁来实现cherry-pick的相同效果，但如果您只是想选择一个补丁，则使用rebase --onto可能会更加麻烦单一提交，使用补丁需要更多步骤。
rebase vs cherry-pick选择一次提交作为有时rebase --onto与cherry-pick之间的繁琐develop的示例，请假设您在 develop
A <- B <- C <- D
分支上进行了以下提交：
C假设您只想将master合并到cherry-pick分支中。使用master，您只需使用此功能（在git cherry-pick C
上）
rebase --onto要选择只有git rebase --onto master B C
的提交，您需要转到
master有了上述内容，您说要使用C的当前位置作为B的新基本提交/父级，而rebase是旧基础/父节点。
cherry-pick vs B选择一系列提交尽管如此，两个命令之间的提取范围变得非常相似。例如，假设您要同时合并C和git cherry-pick A..C
git rebase --onto master A C
。然后
cherry-pick是等效的，但master需要在rebase --onto签出时完成，但master没有，因为它会为您检出{{1}}。< / p>
如果您想了解使用补丁程序还需要做多少工作，您可以在the Pro Git book中了解如何使用补丁程序。