删除 git 中的分支会导致 gitk 崩溃
在 #git 上确认剩余分支实际上并不需要后，我决定从我的（个人项目）存储库中删除一些分支，这些分支已合并到 master 中。
然而，gitk 对我的存储库历史的可视化结果完全搞砸了。
基本上是这样的：
随着提交中的那些分支突然出现，最终会回到前面的其他提交中。所有的点都没有发生合并，我只有大约 5 个额外的分支。
这是正常的吗？有什么解决办法吗？
I decided to delete a few branches from a (personal project) repository of mine that were merged into master after confirming on #git that leftover branches aren't really necessary.
However, gitk's visualisation of my repository's history as a result has been completely screwed up.
Basically something like this:
With those branches from commits appearing out of nowhere eventually going back into some other commits up ahead. A merge did not occur at all of the points, and I only had around 5 extra branches.
Is this normal? Is there any fix for this?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
您是否尝试过重新加载显示器？有时 gitk 会有点混乱，但退出并重新启动它，或重新加载（文件>重新加载，或Ctrl-F5< /kbd>）可以帮助它以更友好的方式重新绘制历史。
编辑：现在我看到了存储库，我可以看到发生了什么。
看起来您在 master 上做了一些开发，同时还在一些侧分支上工作。当您执行此操作时，您多次将
master合并到这些侧分支中。 gitk 在列表中显示提交，因此它需要提交的线性排序。每当您有分支历史记录时，您都可以将该历史记录放入几种可能的线性排序中。例如，以下结构：可以按以下任何方式排序：
默认情况下，gitk 使用拓扑排序，它尝试将每个提交分组在一起分支，因此您可以看到每个分支的提交的逻辑进展，而不是根据发生时间散布分支每一侧的提交。因此，例如，它可能会按顺序 (1) 显示它们：
如果您只是查看线性日志，则此顺序可以正常工作，并且如果您不合并，那么在 gitk 中也可以正常工作经常分支（如给出的示例）。但是，如果您按照您所做的那样，频繁地将
master合并到主题分支中，那么这会产生您所看到的那种混乱；首先显示master上的提交，然后显示侧分支上的提交，但是master频繁合并到侧分支中成为堆积的长连接，使得历史看起来很混乱。 （请注意，Git 实际上并不存储来自哪个分支的提交，但它对它们进行排序的方式似乎最终将每个分支的提交保留在一起）。据我所知，处理这个问题的最简单方法就是按时间顺序显示 gitk 中的提交。打开查看> 编辑视图...，然后选中严格按日期排序选项。现在您应该会看到您的历史记录显示得更加清晰。要直接启动到此视图，您可以将
--date-order选项传递到gitk中。Have you tried reloading your display? Sometimes gitk gets a bit confused, but quitting and restarting it, or reloading (File > Reload, or Ctrl-F5) can help it re-draw the history in a more friendly fashion.
edit: Now that I see the repository, I can see what's going on.
It looks like you did some development on master, while also working on some side branches. While you were doing this, you merged
masterinto those side branches several times.gitkdisplays commits in a list, so it needs a linear ordering of commits. Whenever you have branching history, there are several possible linear orderings you can put that history in. For instance, the following structure:Could be ordered an any of the following ways:
By default,
gitkuses a topological ordering, which tries to group together commits on each branch, so you can see a logical progression of commits for each branch, rather than commits of each side of the branch interspersed based on when they happened. So, for instance, it might display them in ordering (1):This ordering works fine if you're just looking at a linear log, and also works fine in
gitkif you don't merge between the branches very often (as in the example given). But if you do what you did, mergingmasterinto the topic branches frequently, then this produces the kind of mess that you're seeing; the commits onmasterare shown first, then the commits on the side branches, but the frequent merging ofmasterinto the side branches become the long connections that pile up and make the history look confusing. (Note that Git doesn't actually store which commits came from which branch, but the way it sorts them it winds up keeping the commits from each branch together, it appears).The easiest way to deal with this that I know of is just to display commits in
gitkin chronological order. Open View > Edit view..., and check the Strictly sort by date option. Now you should see your history displayed much more sanely. To launch directly into this view, you can pass the--date-orderoption intogitk.我不知道您的历史记录是什么样的，但要记住一点：删除合并的分支只会删除名称（引用），而不是提交，也不会删除历史记录的任何部分。
因此，可视化历史的工具仍然会显示过去发生的所有分支。
I don't know what your history looks like, but something to keep in mind: deleting merged branches only deletes the names (refs), not the commits, nor any part of the history.
So tools that visualize history will still show all the branching that has occurred in the past.
只有当你有不同的头从根指向（就像在树中）时，分支才是，而不是当你有 n 行返回主分支时（合并的牧场与它合并到的分支并没有真正的不同）。检查 gitk --all 来查看存储库中的所有分支（作为指向每个分支头部的颜色标签）。并仔细检查 gitk 向您显示的合并点，如果它们有两个父级，那么它们就是真正的合并。
git log --graph可以帮助你看出这不是 gitk 的问题。A branch is only when you have different heads pointing from root (like in tree), not when you have n-lines going back to main branch (merged ranch is not really different from branch it was merged to). Check
gitk --allto see all branches you have in repository (as colour labels pointing at head of each branch). And check carefully merge points which gitk shows you, if those have two parents, then they're real merges.git log --graphcan help you to see that it's not issue of gitk.