Question

我有一个叫做release的分支，它是从master分支出来的。今天，我有两个分支，其中一个基于名为master的master分支，另一个基于基于release的发行版的分支。我最近进行了更改，以掌握大约10个以上的提交。我知道您可以cherry-pick来执行这些命令，但是我想找出一种方法来将这10项以上的提交重新建立到basedRelease分支上。我假设基于baseMaster的那些提交仅10+就是我想要的。我尝试了rebasing，但是它也会从其他开发人员那里获取提交，这不是我想要的。因此，然后我从basedMaster派生了另一个分支，名为basedMasterLocal，以为它只会携带我对该分支basedRelease所做的10次提交。但是，由于我不想使用cherry-pick，并且想使用rebase

解决此问题，因此一直很难弄清楚该如何做

Answer 1

让我们把它画出来。

我有一个叫做release的分支，它是从master分支出来的。

A - B - C - F - G [master]
         \
          D - E [release]

现在，我有两个分支，其中一个分支基于master，称为basedMaster，另一个分支基于版本，称为basedRelease。

我认为您已经在那些分支上添加了一些提交，否则它们是无关紧要的。

                  H - I [basedMaster]
                 /
A - B - C - F - G [master]
         \
          D - E [release]
               \
                J - K [basedRelease]

我最近对母版进行了大约10次以上的更改。

让那两个。

                  H - I [basedMaster]
                 /
A - B - C - F - G - L - M [master]
         \
          D - E [release]
               \
                J - K [basedRelease]

因此，我从basedMaster处获得了另一个分支，名为基础MasterLocal

                        [basedMasterLocal]
                  H - I [basedMaster]
                 /
A - B - C - F - G - L - M [master]
         \
          D - E [release]
               \
                J - K [basedRelease]

有了这个，我们对存储库的状态有了更好的了解。

我想找出一种方法来将这10多个提交重新建立到basedRelease分支上。

尚不清楚您是否要所有提交都在主提交中但不在basedRelease中的提交，或者只是想要您提到的那10个以上的提交。尚不清楚是要复制（cherry-pick）还是移动（rebase）。

我一直在想办法，因为我不想使用Cherry-pick，而是想使用rebase解决这个问题。

无论哪种方式，您都可以选择多次提交。这将需要一系列提交。我们可以使用..，其中x..y的意思是“从y可以到达的所有提交，从x可以到达的所有提交”。有关更多信息，请参见gitrevisions/Specifying Ranges。

假设您已basedRelease签出...如果要复制（樱桃拣选）master中而不是basedRelease中的所有提交。

# All the commits reachable from master
# excluding those reachable from HEAD (the currently checked out commit).
git cherry-pick HEAD..master

如果只是那10个以上的提交，则可以说明这10个提交。在此示例中，只有两个L和M。

git cherry-pick L M

或者您可以观察到这些是在master中但不在basedMaster中的提交。

git cherry-pick basedMaster..master

如果您想移动（变基）它们。

git rebase --onto basedRelease basedMaster..master

git-cherry-pick examples和git-rebase has an similar example in its description中也有类似的示例。

这种在长寿分支之间进行的复杂交换提交是我建议不要拥有多个长寿分支，并且绝对反对关闭分支的原因之一。使它们保持同步变得非常复杂。

相反，我建议您使用一个长期存在的分支：master。没有任何内容直接提交给master。所有工作都在短暂的要素分支上完成。他们必须先通过质量检查，然后才能合并为master。合并后，它们将被删除。这样master始终稳定并可以发布。使用标签跟踪发布。这是Feature Branch Workflow。

如何为在不同点分支的分支建立基础

1 个答案: