GIT:从特性分支分支而不是开发分支分支

Question

因此，通常情况下，当我们有feature1，feature2和feature3时，它们就脱离了发展。我只是意外地继续分支，而不是切换回发展，因此feature2分支从feature1和feature3分支离开了特性2。

我怎么才能解决这个问题？

编辑图片：

I would like this:
---------------
  \
    A - B - C - D - E

to become this:
---------------
  \   \     \
   A   B-C   D-E

Answer 1

因为每个分支只有一到两个提交，所以使用樱桃选择就足够了(不需要对一个或两个提交进行重基)。

首先备份本地存储库(不要信任互联网！)

写下A，B，C，D和E的散列，然后：

只要做：

# Switch to devel
git checkout devel
# Rename branches into temporary branch names
git branch -m feature1 tmp1 && git branch -m feature2 tmp2
                            && git branch -m feature3 tmp3
# Create feature1 branch and cherry-pick the required commit
git checkout -b feature1 && git cherry-pick A
# Switch to devel
git checkout devel
# Create feature2 branch and cherry-pick the required commits
git checkout -b feature2 && git cherry-pick B C
# Switch to devel
git checkout devel
# Create feature3 branch and cherry-pick the required commits
git checkout -b feature3 && git cherry-pick D E
# Switch to devel
git checkout devel
# Delete temporary branches
git branch -D tmp1 tmp2 tmp3

Answer 2

为了完整起见，下面是如何使用git rebase (带有可选的--onto)来移动这些提交。首先，让我们更新“当前”绘图以添加一些特定的标签并提交。为了便于重定位，并且具有通用性，我将假设feature1连接在devel的尖端之后，并且您希望将新的分支移动到提示(使用*标记的提交)。

如果没有额外的提交(因此*直接连接到A等)，那么这一切仍然有效。

如果有额外的提交，但是希望将feature的内容从提示中保留下来，那么在这个示例中，--onto目的地应该是devel~2。

现在：

...-o--o--*         <-- devel
     \
      A             <-- feature1
       \
        B--C        <-- feature2
            \
             D--E   <-- feature3

第1步，将feature3交互地重新定位到devel上。这将使用一堆pick命令创建一个文本文件，每个命令都将执行一个git cherry-pick。您希望选择提交D和E。告诉rebase，“上游”(不好的名称)是devel，您希望它通过执行git checkout feature3启动整个操作。

$ git rebase -i devel feature3

在这里，rebase将找到devel..feature3选择的所有提交(这是A通过包含E，但不是已经在devel上的两个额外提交中的任何一个)，并且将选择作为它的--onto目标devel。然后在编辑器中结束，在编辑器中，可以删除除最后两个提交(D和E)之外的所有提交。然后，重新基地将：

• 移动到分支devel的顶端，在一个新的未命名的分支上(分离头模式)
• 樱桃-选择提交D，将其添加到未命名的分支中
• 樱桃-选择提交E，将其添加到未命名的分支中
• 最后，使用git reset的管道等价物使feature3指向最新的提交。

现在这棵树是这样的：

            D'-E'   <-- feature3
           /
...-o--o--*         <-- devel
     \
      A             <-- feature1
       \
        B--C        <-- feature2
            \
             D--E   [abandoned, except for reflogs]

(如果将--onto devel~2添加到原始git rebase -i中，它将从提交的devel~2 (最左边的o节点)中增长D'-E'链。您仍然需要指定上游，您可以将其列表为devel或devel~2：在这种情况下，这无关紧要。)

现在你可以git rebase -i devel feature2了。这样做的方式是相同的:查看分支feature2，在devel..feature2中查找提交(这次是通过C提交)，并打开一个编辑器会话，让您修改git将运行的一组cherry-pick命令。这一次，您只需要删除一行(对于提交A)。然后，Git在commit *上启动一个新的分离头匿名分支，使用B和C的樱桃选择来生长它，然后移动feature2分支：

            D'-E'   <-- feature3
           /
...-o--o--*         <-- devel
    |      \
     \      B'-C'   <-- feature2
      |
      A             <-- feature1
       \
        B--C        [abandoned]

最后，您可以重新设置feature1的基础。在这里，您不需要担心交互，因为提交A是您唯一想要复制的，也是唯一一个git rebase会选择的。

结果与git cherry-pick相同。您需要更少的git命令，但是对于交互式的“挑选”序列需要更多的编辑。

哪条路更好？都不是真的。重命名旧分支，然后删除它们，会抛出它们的重触发器，这可能是一个特性，因为它使原始A通过E提交能够更快地得到垃圾收集，或者可能是一个缺点，以防您想再次查看它们。