Git Interactive Rebase Squash создает совершенно новую ветку - PullRequest
0 голосов
/ 06 мая 2019

Вот фотография последней части моей простой прямой истории (от SourceTree, время идет снизу вверх):

enter image description here

Итак, в этой ситуации я попросил SourceTree сделать интерактивную перебазировку дочерних элементов самого нижнего коммита («Xcode 10.2, Swift 5»), потому что я хотел свернуть следующие два коммита («darn, кодировка списка свойств»). "и" v1.1.1build24 ") в один коммит. Там нет пульта, поэтому я могу переписать историю и сохранить ее в чистоте и информативности.

Но когда я это сделал, была создана целая куча новых коммитов, ответвляющихся от «Xcode 10.2, Swift 5» - копий существующей цепочки коммитов. Я не мог понять, почему, и мне понадобилось много времени, чтобы убрать его.

Это была не совсем новая "ветка" (как у моего вопроса в заголовке); но существующие коммиты до "v1.1.2build28" оказались на своей собственной тупиковой ветке, и master теперь содержал в себе эти новые коммиты, дублируя эти коммиты, но без тегов и с сегодняшней датой.

Мой вопрос: почему это произошло, и что я должен был сделать вместо этого?

Ответы [ 2 ]

1 голос
/ 06 мая 2019

Все сделано как положено.

"darn, кодировка списка свойств" и "v1.1.1build24" подавляются как один коммит. Git реализует этот сквош, создав новый коммит, чьим родителем является «Xcode 10.2, Swift 5» и чьи изменения эквивалентны изменениям «darn, кодировка списка свойств» и «v1.1.1build24».

Родителем или базой "v1.1.1build25" было "v1.1.1build24". Теперь новый коммит заменил "v1.1.1build24" и "darn, кодировка списка свойств". В результате родитель «v1.1.1build25» должен быть новым коммитом. В противном случае коммиты выше "v1.1.1build24" больше не будут существовать на master. Чтобы переместить «v1.1.1build25» из старой базы в новую, Git также генерирует новый коммит для «v1.1.1build25», чьим родителем теперь является сдавленный коммит, а изменения эквивалентны изменениям в «v1». .1.1build25" . Соответственно, все остальные потомки воссоздаются, потому что их родители / базы изменены.

Git создает новые коммиты, как будто старые заменяются, но старые все еще существуют в хранилище, за исключением того, что они больше не доступны с master. Однако теги типа "v1.1.1build25" и ветви типа "temp" по-прежнему указывают на старые коммиты. Так как эти старые коммиты сейчас не на текущем master, эти теги и ветви также не видны на master.

0 голосов
/ 06 мая 2019

Ничего плохого.Это именно то, как работает Git.Git rebase - это не что иное, как маленький робот, который делает новую версию группы коммитов.

Это просто плохая формулировка, что некоторые люди, даже доктора, говорят о «переписывании истории».Переписывание истории вообще невозможно в git - то, что когда-то было совершено, никогда не может быть изменено снова.git rebase помогает только копировать старую историю в новую версию истории.Однако - если старая история, как и в вашем случае, имеет другие теги или ветви, они будут продолжать указывать на старую историю даже после перебазирования.

Так что это совершенно нормальночто репозиторий git состоит из множества мертвых веток.Иногда вы можете видеть их (потому что другие теги / ветви все еще ссылаются на них), иногда вы не можете видеть их, но вы всегда можете обратиться к ним, если вам удалось запомнить идентификатор SHA.(Время от времени приходит сборщик мусора git и собирает действительно мертвые части истории, на которые ничто не указывает).

Это здорово, потому что вы не можете делать никаких ошибок (1).Вы всегда можете просто git reset --hard до некоторой точки в истории, потому что история никогда не может быть изменена в git.Если вы попытались выполнить перебазирование, слияние или что-то еще, и это не сработало, как ожидалось - если вы запомнили SHA, которым вы были раньше (или если вы пометили его), вы можете вернуться туда.(Если вы этого не сделали, вы можете найти его по git reflog).И у вас всегда есть пара дней, чтобы сделать это перед сборкой мусора.

Очевидно, что это плохо для вас, потому что у вас есть много тегов, которые вы также хотите указать на новую историю.Я немного погуглил, могут быть инструменты, чтобы перенести их в новую ветку, но я никогда не использовал такой инструмент.Попробуйте или примите это как факт, что у git неизменная история.Возможно, когда-нибудь вам понравится, что вы можете экспериментировать без всякого риска: -)

(1) Единственный способ действительно потерять работу - это внести изменения в ваш рабочий каталог и не фиксировать их,Если вы внесли незафиксированные изменения и внесли reset --hard, они будут навсегда потеряны, и никто не предупредит вас.

...