Git 多版本项目中的版本控制问题出身背景_Git_Svn_Merge_Version Control

Git 多版本项目中的版本控制问题出身背景

git svn merge version-control

Git 多版本项目中的版本控制问题出身背景,git,svn,merge,version-control,Git,Svn,Merge,Version Control,我们有一个游戏在三个不同的地区运行，所以它是三个不同版本的发行分支，从一个主分支签出，比如说branch_jp、branch_us、branch_tw（称为发行分支）和master 通常新特性在主分支上开发，并合并到发布分支中。但并不是每个发行版分支都需要所有的特性——这是由一些操作需求等决定的——因此需要一些努力才能将主分支的更改合并到它们中问题我们使用Subversion进行版本控制，最近我们决定使用Git 问题是我们在subversion中合并代码时所做的工作是从该分支所需的主机中选择

我们有一个游戏在三个不同的地区运行，所以它是三个不同版本的发行分支，从一个主分支签出，比如说branch_jp、branch_us、branch_tw（称为发行分支）和master

通常新特性在主分支上开发，并合并到发布分支中。但并不是每个发行版分支都需要所有的特性——这是由一些操作需求等决定的——因此需要一些努力才能将主分支的更改合并到它们中

问题我们使用Subversion进行版本控制，最近我们决定使用Git

问题是我们在subversion中合并代码时所做的工作是从该分支所需的主机中选择提交并合并到其中，如下所示：

委员会1
委员会2
委员会1
委员会2
委员会3

如果branch_jp需要featureB，我们要做的是挑选佣金和B，并将它们合并到branch_jp，如果branch_jp只需要featureB，我们只挑选佣金

既然我们已经迁移到Git，那么假设所有的特性都是在master的特性分支上开发的，并合并到发布分支中。问题是我们不能这样做：

master → featurebranch → master → branch_jp/tw/us

或

因为功能分支是从主功能签出的，所以以前没有合并到发布分支中的功能将以这种方式合并

我知道有一个命令“cherry pick”可能会起到同样的作用，但我想知道是否还有更多的“Git-y”方法来处理这种情况

此外，是否有更常见/更好/优雅的工作流程来处理这种“多版本代码”情况？

git cherry pick

（如您所知）是解决这种情况的正确和常见方法

由于需要为不同的发布分支选择不同的功能，因此不应使用

git merge

命令，因为

git merge

会将所有更改合并到发布分支中

对于cherry pick commit到不同的发布分支，您可以遵循所需的情况：

仅对单个功能应用更改：

您应该从feature分支中选择commit。例如，将更改从

featureA

应用到

branch\u jp，您应该从featureA`branch中选择最新的提交


对所有发布的功能应用更改：
您只需要从上次合并的提交中选择提交。例如，将功能A和B中的更改应用到branch\u us
，然后您只需在“branch\u us”上选择最新的合并提交

我在有这个问题的地方工作过。虽然这是一件很难处理的事情，但我不推荐@Marina在她的回答中提出的cherry-pick工作流。我不建议这样做的原因是，git cherry-pick
破坏了原始提交和cherry-pick提交之间的连接，因此git的历史分析将无法正常工作
IMHO您有两个更好的选择，它们都有一个优点，即它们保留提交标识，从而使源树更容易推理
1（与现状相比变化较小，但可能有点乏味）
更改分支模型。Master（如果它存在的话）不应该包含所有的特性，而应该只包含三个版本中的核心特性。如果一个特性应该只存在于一个版本中，那么只将它合并到该分支中。换句话说，您的发布过程应该是选择要包括的特性之一，而不是要删除的特性
2（更大的变化，更多的前期工作，但将使未来的发展更容易）
重新思考你的架构。与其维护三个版本的代码，不如只发布一个版本的应用程序，并将差异考虑到配置文件或插件中。如果您能做到这一点，您可能会看到代码质量的好处，而不仅仅是易于控制版本
如果可能的话，我强烈建议选择2
 嗨，玛丽娜，我刚试过樱桃酱，但还是有问题。如果我将FeatureUrea合并到master中，并基于master签出名为featureB的分支，当我选择标记featureB时，它将包含对FeatureUrea所做的更改，但我不需要，cherry选择并不仅仅是选择对分支featureB所做的更改。如果我做错了，请告诉我，谢谢。如果在将featureA
合并到master
分支后，从master
分支创建featureB分支，则表示featureA被视为以下特征分支的已发布特征。如果您不想将featureA视为已发布的功能，您可以从功能分支创建标记，或者选择功能分支到相关发布分支的最新提交。我猜您是对的，如果featureA不是所有发布分支都需要的，那么不应该将其合并到master中，或者使用开关使代码无法工作。谢谢。@B.W.Gareth我更新了我的答案，清楚地区分了这两种情况。对不起，我最近两天没有查看网站。我们决定在将特性分支合并到所有发布分支之前，不将其合并为master，这样我们就可以摆脱“cherry pick”的东西。
master → featurebranch → branch_jp/tw/us

              ↓
            master