4

master我决定从我的(个人项目)存储库中删除一些分支,这些分支在确认 #git 剩余分支并不是真正必要后合并到其中。

然而,gitk 对我的存储库历史的可视化结果被完全搞砸了。

基本上是这样的:

http://i48.tinypic.com/90r512.png

随着提交的这些分支突然出现,最终会回到前面的其他提交中。所有点都没有发生合并,我只有大约 5 个额外的分支。

这是正常的吗?有什么解决办法吗?

4

3 回答 3

4

您是否尝试过重新加载显示器?有时 gitk 会有点困惑,但退出并重新启动它,或重新加载(File > ReloadCtrl- F5)可以帮助它以更友好的方式重新绘制历史记录。

编辑:现在我看到了存储库,我可以看到发生了什么。

看起来你在 master 上做了一些开发,同时也在一些分支上工作。当你这样做的时候,你master多次合并到那些分支中。gitk在列表中显示提交,因此它需要提交的线性排序。每当您有分支历史记录时,您都可以将这些历史记录放入几种可能的线性排序中。例如,以下结构:

       /-- c -- e --\
a -- b               g -- h
       \-- d -- f --/

可以通过以下任何一种方式订购:

  1. a, b, c, e, d, f, g, h
  2. a, b, c, d, e, f, g, h
  3. a, b, c, d, f, e, g, h
  4. a, b, d, c, e, f, g, h
  5. a, b, d, c, f, e, g, h
  6. a, b, d, f, c, e, g, h

默认情况下,gitk使用拓扑排序,它尝试将每个分支上的提交分组在一起,因此您可以看到每个分支的提交的逻辑进展,而不是根据发生时间穿插的分支每一侧的提交。因此,例如,它可能按顺序 (1) 显示它们:

a -- b -- c -- e ------------ g -- h
       \----------- d -- f --/

如果您只是查看线性日志,则此排序可以正常工作,并且gitk如果您不经常在分支之间合并(如给出的示例中所示),也可以正常工作。但是如果你做你所做的,master经常合并到主题分支中,那么这就会产生你所看到的那种混乱;首先显示提交master,然后显示侧分支上的提交,但是频繁合并master到侧分支中成为长连接,堆积起来,让历史看起来很混乱。(请注意,Git 实际上并没有存储哪些提交来自哪个分支,但它对它们进行排序的方式最终会将来自每个分支的提交保持在一起,看起来)。

据我所知,最简单的处理方法就是gitk按时间顺序显示提交。打开View > Edit view...,然后选中Strictly sort by date选项。现在您应该看到您的历史记录显示得更加清晰。要直接启动到此视图,您可以将--date-order选项传递到gitk.

于 2010-02-02T15:32:02.417 回答
1

我不知道您的历史记录是什么样的,但要记住一点:删除合并的分支只会删除名称(引用),而不是提交,也不删除历史的任何部分。

因此,可视化历史的工具仍将显示过去发生的所有分支。

于 2010-03-12T03:05:14.980 回答
0

只有当你有不同的头指向​​根时(比如在树中),分支才会出现,而不是当你有 n 行返回主分支时(合并的牧场与它合并到的分支并没有真正的不同)。检查gitk --all以查看存储库中的所有分支(作为指向每个分支头部的颜色标签)。并仔细检查 gitk 向您显示的合并点,如果它们有两个父母,那么它们是真正的合并。git log --graph可以帮助您了解这不是 gitk 的问题。

于 2010-02-04T18:54:25.650 回答