Question

我使用Git进行版本控制，我正在尝试完成一些我不确定可能轻松实现的内容。我有一个功能分支feature1.1，其中有一些提交。我还有一个分支看似最后一次提交该功能feature1.2。这是因为feature1.2取决于feature1.1，但不一定需要在同一分支上。

目前，当我重新定位feature1.1时，我最终不得不挑选feature1.2进入我重新定位feature1.1之后创建的新分支。

有更好的方法吗？

基本上，我想要这个

                F feature1.2
               /
      C---D---E feature1.1
     /
A---B---G---H---I---J---K master

成为这个

                                      F' feature1.2
                                     /
                          C'---D'---E' feature1.1
                         /
A---B---G---H---I---J---K master

Answer 1

分支机构不拥有根。

嗯，这有点夸大其词。 feature1.1的根是提交A。因此，更准确地说分支没有有用的根。

分支是，是指向一个特定提交的指针：feature1.1指向您标记为E的提交，其哈希值取决于其内容及其历史记录一路回到根。这意味着您有两个不同的提交，这两个提交都标记为E：其父链为D，C，B， ......以及D，C，K，......

git rebase对复制的提交做了什么，提交给具有不同父哈希ID的新提交（通常还有不同的基础源树）。新的提交很像旧的提交，但不一样。因此，您需要为其指定新名称，例如C'-D'-E'。

旧提交会在您的存储库中保留一段时间（默认情况下至少保留30天）。将C-D-E复制到新链时，这不会影响原始F。

现在您需要将F复制到F'。如果您使用git checkout feature1.2; git rebase feature1.1天真地执行此操作可能会出现问题：Git不知道不应该复制C-D-E。它可以在新C'-D'-E'上看到feature1.1，但它并不真正知道这些来自C-D-E。如果提交的气味足够相似，¹，rebase会注意到它已经拥有它们，并跳过复制它们。但是如果他们在第一次rebase期间改变得足够多，它会再次复制。

要阻止Git在原始C-D-E链上进行查看，您需要git rebase --onto。或者，您可以使用交互式rebase：这里Git为您提供了一个文件，其中包含要复制的建议提交集，您可以手动删除已经复制的提交。

请记住，拥有原始提交副本（与原始提交的哈希ID相同）的任何人都将保留其副本。他们也必须安排开始使用 new 副本代替旧副本。如果您是唯一拥有这些功能分支的人，或者如果您的所有合作者都准备好处理这些功能，那么您就可以开始了。如果没有，你可能会产生比他们可以处理更多的痛苦。

¹实际上，这意味着“如果它们具有相同的git patch-id”。

重新启动后，将分支的根目录更改为另一个分支

1 个答案: