Rebasing и что означает,

Ответ 1

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

Конкретный ответ на ваш вопрос можно найти в разделе "The Reils of Rebasing". Цитата из этого раздела:

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

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

• Страница gitworkflows: см. "Объединение вверх" и "Филиалы тем".
• ProGit: см. "Частная управляемая команда "
• Блог Jarrod Spillers: см. "git merge vs git rebase: Избегайте Hell Rebase

Ответ 2

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

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

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

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

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

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

Ответ 3

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

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

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

Ответ 4

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

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