Часто говорится, что, Вы не должны повторно основывать фиксации, которые Вы уже продвинули. Что могло означать этого?
В книге ProGit есть хорошее объяснение .
Конкретный ответ на ваш вопрос можно найти в разделе « Опасности ребазинга ». Цитата из этого раздела:
Когда вы перебазируете материал, вы отказываетесь от существующих коммитов и создаете новые, похожие, но разные. Если вы отправляете коммиты куда-то, а другие снимают их и основывают на них работу, а затем вы переписываете эти коммиты с помощью git rebase и снова подталкиваете их вверх , вашим соавторам придется повторно объединить свою работу, и все станет беспорядочно , когда вы попытаетесь вернуть их работу в свою.
Обновление:
Судя по вашему комментарию ниже, похоже, что у вас проблемы с рабочим процессом Git. Вот несколько ссылок, которые могут помочь:
gitworkflows
: См. «Слияние вверх» и «Тематические ветви» Ребазинг переписывает историю. Если никто не знает об этой истории, это прекрасно. Однако если эта история общеизвестна, то переписывание истории в Git работает точно так же, как и в реальном мире: вам нужен заговор.
Заговоры на самом деле трудно удерживать вместе, поэтому вам лучше вообще избегать переназначения публичных веток.
Обратите внимание, что есть примеров успешных заговоров: ветвь pu
репозитория git Джунио К. Хамано (официальный репозиторий Git SCM) часто перебазируется. Это работает так: почти каждый, кто использует pu
, также подписан на список рассылки разработчиков Git, а тот факт, что ветвь pu
перебазирована, широко публикуется в списке рассылки и веб-сайт Git.
Перебазирование изменяет историю вашего репозитория. Если вы отправляете коммиты в мир, то есть делаете их доступными для других, а затем меняете свой взгляд на историю коммитов, становится трудно работать с кем-либо, у кого есть ваша старая история.
Rebase считается вредным , я думаю, хороший обзор.