Удаление веток в git приводит к тому, что gitk становится диким

Question

Я решил удалить несколько веток из моего (личного проекта) репозитория, которые были объединены в master после подтверждения на #git, что оставшиеся ветви не нужны.

Однако визуализация истории моего репозитория в gitk была полностью испорчена.

В основном как-то так:

С этими ветвями из коммитов, появляющихся из ниоткуда, в конечном счете возвращаясь к некоторым другим коммитам впереди. Слияние не произошло во всех точках, и у меня было только около 5 дополнительных ветвей.

Это нормально? Есть ли какое-то решение для этого?

Answer 1

Вы пытались перезагрузить дисплей? Иногда gitk немного запутывается, но выйти и перезапустить его или перезагрузить ( File > Обновить или Ctrl - F5 ) может помоги перерисовать историю более дружелюбно.

edit : Теперь, когда я вижу хранилище, я могу видеть, что происходит.

Похоже, что вы сделали некоторые разработки для мастера, одновременно работая над некоторыми боковыми ветками Пока вы это делали, вы несколько раз сливали 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 в хронологическом порядке. Откройте Просмотр > Изменить представление ... и установите флажок Строго сортировать по дате . Теперь вы должны увидеть свою историю гораздо более вменяемой. Чтобы запустить непосредственно в этом представлении, вы можете передать параметр --date-order в gitk.

Answer 2

Я не знаю, как выглядит ваша история, но стоит иметь в виду: удаление объединенных ветвей удаляет только имена (ссылки), но не коммиты и не какую-либо часть истории.

Таким образом, инструменты, которые визуализируют историю, по-прежнему будут отображать все ветвления, которые произошли в прошлом.

Answer 3

Ветвь есть только тогда, когда у вас есть разные головы, указывающие от корня (как в дереве), а не когда у вас есть n-строк, возвращающихся к основной ветке (объединенное ранчо на самом деле не отличается от ветви, в которую оно было объединено). Отметьте gitk --all, чтобы увидеть все ветки, которые у вас есть в репозитории (как цветные метки, указывающие на заголовок каждой ветки). И тщательно проверяйте точки слияния, которые показывает вам Гитк: если у них есть два родителя, то это настоящие слияния. git log --graph может помочь вам понять, что это не проблема gitk.