GIT：分支功能分支，而不是开发分支

Question

因此，通常当我们有feature1，feature2和Feature3时，它们会脱离devel。 我不小心只是继续分支而不是切换回devel，尽管如此，Feature2从Feature1分支出来，Feature3从Feature 2分支出来。

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

编辑图片：

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

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

Answer 1

由于每个分支只有一两次提交，因此使用cherry-pick就足够了（无需为一两次提交重新设置基准）。

首先备份您的本地存储库（不信任互联网！）

写下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

为了完整--onto ，这是使用git rebase （带有可选的--onto ）移动这些提交的方法。 首先，让我们更新“当前”图形以添加一些特定的标签和提交。 为了便于重新feature1并保持通用性，我将假设feature1连接在devel尖端的后面，并且您想将新分支移动到尖端（用*标记的提交）。

如果没有多余的提交（因此*直接连接到A ，等等），那么所有这些仍然有效。

如果有额外的提交，但你要保持feature从尖端的背部，在--onto目的地应为devel~2在这个例子。

现在：

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

第1步， feature3交互方式将feature3 devel 。 这样做是使用一堆pick命令创建一个文本文件，每个命令都会执行git cherry-pick 。 您要选择提交D和E 告诉rebase“上游”（名字不好）是devel ，并且您希望它通过执行git checkout feature3来启动整个操作：

$ git rebase -i devel feature3

在这里，变基会发现所有提交选定devel..feature3 （这是A通过E包容性，而不是两个额外提交已经在任devel ），并且将选择作为其--onto目标， devel 。 然后，您进入编辑器，在其中可以删除除最后两个提交（ D和E ）以外的所有提交。 重新设定基准将：

• 在新的未命名分支上移动到分支devel的尖端（分离的HEAD模式）
• 樱桃选择提交D ，将其添加到未命名分支
• cherry-pick commit 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 ，它会生长的D'-E'从提交链devel~2 ，这是最左边o节点。您仍然需要指定上游，您可以将其列为devel或devel~2 ：在这种情况下无关紧要。）

现在您可以git rebase -i devel feature2 。 这的工作方式相同：检出分支feature2 ，在devel..feature2查找提交（这次是A到C ），然后打开一个编辑器会话，让您修改git将运行的cherry-pick命令集。 这次您只需要删除一行（对于提交A ）。 然后，Git在commit *再次启动一个新的HEAD匿名分离分支，并使用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命令要少一些，但是对于交互式“选择”序列需要更多的编辑。

哪种方法更好？ 两者都不是。 重命名旧分支然后删除它们将刷新其reflog，这可能是一个功能，因为它使原始的A到E提交能够更快地被垃圾回收，或者如果您想再次查看它们，则可能是一个缺点。