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

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

Источник

4 ответа

Решение

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

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

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

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

Источник

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

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

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

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

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

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

Источник

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

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

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

Источник

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

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

Источник
Другие вопросы по тегам