使用 git commit-tree 是否有风险

Question

如果我有一个提交历史记录（例如从远程存储库克隆的），如下所示：

A ---> B ---> C ---> D (master)

我想创建一个如下所示的分支：

A ---> B ---> C ---> D (master)
   \-> N ---> B' ---> C' ---> D' (branch)

也就是说，在提交 A 之后的分支上插入一个名为“N”的提交，然后将提交 B、C 和 D 复制到该分支。假设我使用以下步骤创建分支“分支”：

创建“分支”-> 提交 N -> 使用查找提交 B 的树 blob 的哈希值git cat-file -p <hash of commit B>-> 运行命令：git commit-tree <hash of tree blob of B> -p <hash of commit N>-> 移动“分支”以指向 B' -> 对提交 C 和重复重复最后两个步骤D

git commit-tree添加提交N后，使用上面的命令将提交B、C、D复制到分支是否存在风险？这样做是否会丢失 B、C 或 D 中的任何文件、更改等（特别是如果 B 和 N 之间存在冲突）？正如您所看到的，这与使用cherry-pick不同，因为cherry-pick在cherry-picking之前检查B和B'、C和C'、D和D'之间的冲突，而这种方法不检查任何冲突。

Answer 1

这取决于您的目的。N你首先为什么想要？创建后，由（和之间的）B'引入的所有更改都消失了，因为现在文件与 的文件完全相同。最后， 的文件与.NANBD'D

如果您希望历史记录中有一个快照N以便您以后可以查看，那么这样做是可以的。

如果您希望 引入的更改N存在于新分支上，则需要git cherry-pick或git rebase。如果是这样，我能想到的唯一无害的情况是A和之间的变化是和N之间变化的子集。换句话说，您希望将的更改拆分为和。正如 @torek 在评论中指出的那样，更改并没有真正消失，它们只是对后续提交快照没有影响，就好像更改已在.ABBNB'B'

在实践中，我用过git commit-tree2种情况。我们有一个历史悠久、混乱不堪的分行。git revert通过或来清理它非常困难git rebase，因此我们决定将分支重置为之前的良好提交。但我们不允许删除并重新创建或强制推送任何现有分支。因此，我们通常git commit-tree -p HEAD -m xxx ${good_commit}^{tree}将代码重置为良好提交的状态，同时保留整个混乱的历史记录。

另一种情况是我们曾经希望分支foo与分支具有相同的代码bar。很早以前就已经分化和发展了foo。bar所以我们过去常常git commit-tree -p foo -m xxx bar^{tree}在保留历史记录的同时重置代码。