我们有一个在三个不同区域运行的游戏，因此从一个主分支检出的是三种不同版本的发行分支，分别是branch_jp，branch_us，branch_tw（称为发行分支）和母版本。
通常，新功能是在master分支上开发的，并合并到release分支中。但是并不是每个发行分支都需要所有功能-这是由某些操作需求等决定的-因此需要花费一些精力将主分支的更改合并到其中。
我们使用Subversion进行版本控制，最近我们决定移至Git。
问题是合并代码时我们在Subversion中所做的就是从master提取该分支需要的提交并合并到其中，如下所示：
如果branch_jp需要featureA，我们要做的就是挑选commitA＆B，然后将它们合并到branch_jp，如果branch_us仅需要featureB，我们就选择commitB。
自从我们移至Git以来，假设所有功能都是从master的功能分支开发的，并合并到发行分支中。问题是我们不能像这样：
master → featurebranch → master → branch_jp/tw/us
或
master → featurebranch → branch_jp/tw/us
↓
master
因为功能分支是从母版中签出的，所以未合并到发行分支中的先前功能将通过这种方式进行合并。
我知道有一个命令'cherry-pick'可能起到同样的作用，但是我想知道是否还有更多的'Git-y'方法来处理这种情况？
此外，是否有更通用/更精细/更优雅的工作流程来处理这种“多发行版本代码”情况？
答案 0 :(得分：1)
git cherry-pick（如您所知）是这种情况的正确且常见的方法。
由于您需要为不同的发行分支选择不同的功能，因此不应使用git merge命令，因为git merge会将所有更改合并到发行分支中。
对于将樱桃选择提交到不同的发行分支，您可以按照需要的情况进行操作：
仅对单个功能应用更改：
您应该从功能分支中选择提交。例如将从featureA到branch_jp, you should cherry-pick the latest commit from featureA`分支的更改应用。
对所有已发布功能应用更改：
您只需要从上次合并的提交中挑选出提交即可。例如将功能A和功能B的更改应用到branch_us，那么您只需要在branch_us上选择最新的合并提交即可。