Перебазирование и что означает перебазирование толкнутых коммитов

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

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

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

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

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

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

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

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

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

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

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