如何更改Git中的分支点？

假设我的git回购中有以下结构：

          C'---D'---E'---F'    (dev)
        / 
A---B---C---D---E---F       (master)

---

我想将

C'

拉入主分支，并将分支点更改为

C'

，也就是说，我想将上述内容转换为

              D'---E'---F'     (dev)
             / 
A---B---C---C'---D---E---F  (master)

我认为我应该结合使用樱桃采摘和重定基调，但我不知道如何准确地做到这一点。我应该执行哪些操作序列

---

建议在注释之后，以获得更清晰的模式（因为原来的相同字母提交实际上是不必要的）

与相关的预期结果：

              H---I---J    (dev)
             / 
A---B---C---G---D---E---F  (master)

              H'--I'--J'    (master)
             / 
A---B---C---D---E---F---G   (dev)

---

您需要执行以下操作：

不要考虑这些提交的散列引用：

C

，

C'

，

D

，

E

，

F

。然后：

git签出主机

git重置——硬C

git cherry pick C'

git签出开发人员

git-rebase-i master

（交互式rebase以摆脱C'）

git签出主机

git cherry pick D

git cherry pick E

git cherry pick F

用

--强制

完成两个分支

如果您对

git

不满意，我不建议您这样做，但如果绝对需要这样做，我会这样做

你可以走这条路

                           D'---E'---F'     (dev)
                          / 
A---B---C---D---E---F---C'  (master)

---

然后根据

master

重新设置

dev

分支的基础。这将是最简单的解决办法

您只需将

master

重设为

G

：

git checkout master
git rebase <id-of-G>

git签出主机
吉特重基

---

这将重写

G

上

G

中未找到的

master

中的所有提交。没有必要采摘樱桃。您的

dev

分支将保持不变。

对于您的新图表，简短的回答是，您可以使用以下内容重新设置

G

的基础：

git checkout master
git rebase <commit_id_G>

与相关的预期结果：

              H---I---J    (dev)
             / 
A---B---C---G---D---E---F  (master)

              H'--I'--J'    (master)
             / 
A---B---C---D---E---F---G   (dev)

---

希望在这里更容易看到，我们只需要重新设置

master

的基础，而不是

C

，

D

这个新的

D
相同的字母提交之间的关系是什么？（即
C
和
C'
）这些是相同版本的重定基版本还是还原版本？还是别的什么？（此外，您的预期结果是不可能的，因为无论发生什么情况，
D
都将始终为其父级提供
C
）@romavaileri
C
是
C'
的父级（也是
D
的父级）。您关于
D
的观点总是需要将
C
作为其父项才有意义。因此，也许我需要在图中用一些
D'
替换
D
，这与
D
相同，只是它有
C'
作为其父级？您没有回答我的问题。当然
C
是
C'
的父级，您的模式已经告诉我们了。我将重新措辞：如果您的所有提交都只是提交，为什么不用不同的字母命名它们。我们经常使用
A'
来表示
A
的重基版本或
A
@romavaileri的反转。对不起，我误解了你的问题。
D
和
D'
、
E
和
E'
等之间没有任何关系（只有
C
是
C'
的父项。）我的提交标签令人困惑，我不知道关于重新设置基础提交的约定。无意冒犯，这只是为了帮助你避免对应答者做出错误的假设。如果您愿意，我建议重命名您的模式。这应该是
git-rebase-hash-of-d
（而不是G的hash），否则这是正确的（并且经过了投票）。请注意，原始的
H-I-J
链仍保留在存储库中（通过
ORIG_HEAD
临时查找，默认情况下通过
主文件的reflog至少保留30天）。我喜欢用名称
H'-I'-J'
来绘制新的提交，以表示尽管我们使用它们就像它们是原始的
H-I-J
链一样，但它们实际上是具有新的、不同的哈希ID的新提交。@torek我在第二个OP图中指的是G。这有点让人困惑。我会按照你的建议用素数重做我的第二张图表。谢谢！看来我对rebase的理解是完全错误的。有人能介绍一个关于git的好教程吗？（我主要是在一个分支上使用git进行版本控制，有点像svn的替代品，但我知道你可以用git做更多的事情，你会感兴趣去学习它们。）这是一种复杂的方法，它会毫无理由地在
dev
上重写历史。@CalumHalpin来自原始帖子，他想改写这两个分支的历史。他想从<代码> DEV/<代码>中取出一些东西，把它放在<代码> Muth[4]的代码中间，然后将代码“>代码> DEV/<代码>从提交到主< <代码>中提交。他的图表显示了<>代码> DEV的完全相同的历史。它在不同的点分支出
master
，但这是因为
master
已更改。“我想将
C'
拉入
master
分支，并将分支点更改为
C'
”。他的原始图表清楚地表明了这一点。不知道为什么每个人都忽略了原来的问题。正如我所说，我个人不会这么做，但我相信他一定有这样做的理由，“分支点”正是这两个分支历史的分歧点。将
master
单独重定到
C'
/
G
上会更改它，因为现在master也包含该提交。无论哪种方式，
dev
的历史记录都将是
A->B->C->G->H->I->J
，无需重新设置/重写这些提交的基础。这就是为什么我们“忽略”原始问题的这一部分。