Перебазинг и что такое ребазинг на нажатых коммитах

Часто говорят, что не следует перебазировать уже отправленные коммиты. Что это могло значить?

В книге ProGit есть хорошее объяснение .

Конкретный ответ на ваш вопрос можно найти в разделе « Опасности ребазинга ». Цитата из этого раздела:

Когда вы перемещаете материал, вы отказываетесь от существующих коммитов и создаете новые, похожие, но разные. Если вы куда-то отправляете коммиты, а другие снимают их и основывают работу на них, а затем вы переписываете эти коммиты с помощью git rebase и снова подталкиваете их, вашим соавторам придется повторно объединить свою работу, и все станет беспорядочно, когда вы попытаетесь перетащите их работу обратно в свою.

Обновление:
судя по вашему комментарию ниже, похоже, что у вас проблемы с рабочим процессом Git. Вот несколько ссылок, которые могут помочь:

• gitworkflowsСтраница людей: См «Объединение Ввысь» и «Тема Ветвь»
• ProGit: см. « Частная управляемая команда »
• Блог Джаррода Спиллера: см. « Git merge vs git rebase: Avoiding Rebase Hell »

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

у него есть четыре коммита в главной ветке, и у каждого коммита есть идентификатор (в данном случае a, b, c и d). Вы заметите, что d в настоящее время является последней фиксацией (или HEAD) основной ветки.

Здесь у нас есть две ветки: master и my-branch. Вы можете видеть, что master и my-branch содержат коммиты a и b, но затем они начинают расходиться: master содержит c и d, а my-branch содержит e и f. b считается «базой слияния» моей ветки по сравнению с master - или, чаще, просто «базой». В этом есть смысл: вы можете видеть, что моя ветка была основана на предыдущей версии master.

Итак, предположим, что my-branch устарел, и вы хотите обновить его до последней версии master. Другими словами, my-branch должен содержать c и d. Вы можете выполнить слияние, но это приведет к тому, что ветка будет содержать странные коммиты слияния, которые значительно усложнят просмотр запроса на перенос. Вместо этого вы можете выполнить перебазирование.

Когда вы перебазируете, git находит базу вашей ветки (в данном случае b), находит все коммиты между этой базой и HEAD (в данном случае e и f) и повторно воспроизводит эти коммиты в HEAD ветки. вы переустанавливаете на (в данном случае master). Git фактически создает новые коммиты, которые представляют, как ваши изменения выглядят поверх master: на диаграмме эти коммиты называются e ′ и f ′. Git не стирает ваши предыдущие коммиты: e и f остаются нетронутыми, и если что-то пойдет не так с перебазированием, вы можете вернуться к тому, как было раньше.

Когда много разных людей работают над проектом одновременно, запросы на вытягивание могут быстро устареть. «Устаревший» запрос на вытягивание - это запрос, который больше не соответствует основной линии разработки, и его необходимо обновить, прежде чем его можно будет объединить в проект. Наиболее распространенная причина, по которой запросы на вытягивание устаревают, связана с конфликтами: если два запроса на вытягивание изменяют аналогичные строки в одном файле, и один запрос на вытягивание объединяется, в несмешанном запросе на вытягивание теперь будет конфликт. Иногда запрос на вытягивание может устареть без конфликтов: возможно, изменения в другом файле в кодовой базе требуют соответствующих изменений в вашем запросе на вытягивание, чтобы соответствовать новой архитектуре, или, возможно, ветвь была создана, когда кто-то случайно слил неудачные модульные тесты с главная ветка. Независимо от причины,

Ребазинг переписывает историю. Если об этой истории никто не знает, то это прекрасно. Однако, если эта история общеизвестна, то переписывание истории в Git работает точно так же, как и в реальном мире: вам нужен заговор.

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

Обратите внимание , что есть примеры успешных заговоров: puфилиал мерзавец хранилища Junio C. Hamano ( в официальном репозитории в Git SCM) является нормированным часто. Это работает так, что почти все, кто использует pu, также подписаны на список рассылки разработчиков Git, а факт puперебазирования ветки широко освещается в списке рассылки и на веб-сайте Git.

Перебазирование изменяет историю вашего репозитория. Если вы отправляете коммиты в мир, то есть делаете их доступными для других, а затем меняете свой взгляд на историю коммитов, становится трудно работать с кем-либо, у кого есть ваша старая история.

Считаю, что ребасе, считающееся вредным, - хороший обзор.