Что произойдет при выполнении git rebase без возникновения конфликтов

git rebase для начинающих

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

Итак git работает с комитами. Каждый комит — набор изменений. У каждого комита есть уникальный hash. Когда происходит слияние веток посредством merge:

то все комиты сохраняются — сохраняются комментарии комита, его hash + как правило добавляется еще один искусственный комит. При этом комиты могут чередоваться друг с другом. Это не всегда удобно. Допустим ваш комит решили откатить — выискивать в общем списке где ваш комит, а где не ваш не очень приятно. И вообще — в общей истории хочется видеть действительно важные изменения, а не «ой, я забыл поставить ;». Для того, чтобы несколько комитов склеивать в один можно использовать rebase. Хотя в интерфейсе GitHub есть кнопочка squash & commit — это когда вы создаете pull request (PR) из одной ветки в другую (как правило из вашей рабочей ветки в основную) и после прохождения всех формальностей можно нажать squash & commit, обновить комментарий и ваши изменения появятся в основной ветке как один комит.

Из плюсов — можно весь код, все изменения посмотреть в IDE. Иногда бывает удобнее, чем через web UI, который на GitHub.

Осторожно rebase может менять hash комита и приводить к конфликтам слияний, особенно если над одной веткой трудятся несколько человек.

Хочу написать о двух случаях использования rebase:

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

Вдогонку напишу что у меня получилось. Дано — 2 ветки — master и b1. В процессе работы мы сделали комиты:

Комиты в master и b1 были сделаны независимо. Написал в один список, чтобы был понятен порядок в котором все делалось. Вот список комитов в каждом бранче:

# git checkout master && git log
8dcef6c «+1»
b505f18 «master after b1.1»
2fbbe67 «Initial commit»

# git checkout b1 && git log
2d7d4ea «b1.2»
85eac43 «b1.1»
2fbbe67 «Initial commit»

Делаем git merge master в b1

# git checkout b1 && git merge master && git log
5383781 «Merge branch ‘master’ into b1»
8dcef6c «+1»
2d7d4ea «b1.2»
b505f18 «master after b1.1»
85eac43 «b1.1»
2fbbe67 «Initial commit»

Добавился новый синтетический комит

Теперь делаем rebase

# git checkout b1 && git rebase master && git log
7f18e47 «b1.2»
6fb80cb «b1.1»
8dcef6c «+1»
b505f18 «master after b1.1»
2fbbe67 «Initial commit»

Обратите внимание — наши локальные комиты встали в конец списка, номера комитов изменились, синтетический комит исчез.

Ну и напоследок склеиваем наши комиты в один

pick 6fb80cb b1.1
pick 7f18e47 b1.2

Файл стало после нашего редактирования

pick 6fb80cb b1.1
fixup 7f18e47 b1.2

# git checkout b1 && git log
9062cd7 «b1.1»
8dcef6c «+1»
b505f18 «master after b1.1»
2fbbe67 «Initial commit»

Такие дела

Источник

Золотое правило git rebase

Мы тут немного переделали наш курс посвящённый web-разработке и добавили ещё целый месяц изучения JS. Ну и как обычно у нас — рассмотрим что-нибудь интересное, что разбирается у нас на курсе. В данном случае — git rebase.

Что на самом деле происходит во время git rebase, и почему вас должно это волновать.

Таким вы могли бы представить себе rebase в git:

Вы могли бы подумать, что когда вы делаете rebase, вы «отсоедините» ветвь, которую хотите перебазировать, и «присоедините» ее к концу другой ветви. Это не очень далеко от истины, но стоит копнуть немного глубже. Вот что написано в документации про rebase:

“git-rebase: Forward-port local commits to the updated upstream head”— документация git

Не очень полезно, не так ли? Примерный перевод (и перевод перевода) может быть таким:

git-rebase: Переприменить (reapply) все коммиты из вашей ветки к концу другой ветки.

Самое важное слово здесь — «переприменить (reapply)», потому что rebase — это не просто ctrl-x/ctrl-v от одной ветки к другой. Rebase будет последовательно брать все коммиты из ветки, в которой вы находитесь, и повторно применять их к другой ветке. Это имеет два важных последствия:

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

Теперь давайте поговорим о знаменитом золотом правиле.

Золотое правило rebase-а

«Не следует делать rebase общей ветки» — Все и каждый о rebase

Вы, вероятно, уже сталкивались с этим правилом, возможно, сформулированном по-другому. Для тех, кому не довелось, это правило довольно простое. Никогда, НИКОГДА, НИКОГДА не делайте rebase общей ветки. Под общей веткой я подразумеваю ветку, которая существует в удаленном репозитории и которую другие люди из вашей команды могут запулить себе.

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

Для этого давайте представим себе ситуацию, когда разработчик нарушает это правило, и посмотрим, что произойдет.

Скажем, Боб и Анна работают над одним и тем же проектом. Вот репозиторий Боба, Анны, и удаленный репозиторий на GitHub:

Все синхронизируются с удаленным репозиторием (GitHub)

Теперь Боб, невинно нарушает золотое правило rebase-а, в это же время Анна решает поработать над этой фичей и создает новый коммит:

Догадываетесь, что произойдет?

Боб пытается запушить, он получает отказ и видит такое сообщение:

Oh My Zsh с темой agnoster для тех, кому интересно.

Git не доволен, потому что он не знает, как объединить ветку feature Bob с веткой feature GitHub. Обычно, когда вы пушите свою ветку на удаленный репозиторий, git объединяет ветку, которую вы пытаетесь запушить с ветвью, находящейся в удаленном репозитории. Если быть точным, git пытается перемотать(fast-forward) вашу ветку, и мы поговорим об этом в будущем посте. Что вы должны запомнить, так это то, что удаленный репозиторий не может, простым способом, справиться с перебазированной веткой, которую Боб пытается запушить.

Одним из решений для Боба было бы сделать git push-force, который сообщает удаленному репозиторию:
“Don’t try to merge or do whatever work between what I push and what you already have. Erase your version of the feature branch, what I push is now the new feature branch”
And this is what we end up with:
“Не пытайся объединять или делать какую-либо другую работу между тем, что я пушу, и тем, что у тебя уже есть. Сотри свою версию ветки feature: то, что я пушу, теперь является новой веткой feature”

И это то, что мы получаем:

Если бы Анна знала, что произойдет, она не пошла бы на работу этим утром.

Теперь Анна хочет запушить ее изменения:

Это нормально, git просто сказал Анне, что у нее нет синхронизированной версии ветки feature, т.е. ее версия ветки и версия ветки GitHub разные. Естественно, Анна пулит. Точно так же, как git пытается объединить вашу локальную ветку с тем, что находится в удаленном репозитории при пуше, git пытается объединить то, что находится в удаленном репозитории, с тем, что находится в вашей локальной ветви, когда вы пулите.

Так выглядят коммиты в удаленной и локальной feature перед пулом:

Когда вы пулите, git должен выполнить слияние, чтобы разрешить эту проблему. И вот что происходит:

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

Одного взгляда на этот беспорядок, должно быть достаточно, чтобы убедить вас в справедливости золотого правила. Вы должны иметь в виду, что вы находитесь перед беспорядком, созданным только одним человеком, в ветке, совместно используемой только двумя людьми. Представьте, что вы делаете это с командой из 10 человек. Одна из многочисленных причин, по которой люди используют git, состоит в том, что вы можете легко “вернуться назад во времени”, но чем более беспорядочна ваша история, тем сложнее это становится.

Вы также можете заметить дублирующиеся коммиты в репозитории — D и D’, которые имеют одинаковый набор изменений. Количество дублированных коммитов может быть таким же большим, как количество коммитов внутри вашей перебазированной ветки.

Если вы все еще не уверены, попробуйте представить Эмму, третьего разработчика. Она работала на feature еще до того, как Боб все испортил, и теперь хочет запушить изменения. Обратите внимание, что она пушит после нашего предыдущего мини-сценария.

черт возьми, Боб!

update: Как заметил один reddit-юзер, этот пост может заставить вас думать, что rebase можно использовать только для перебазирования ветки в верхнюю часть другой ветки. Это не так, вы можете перебазировать одну и ту же ветку, но это уже другая история.

Спасибо за внимание.

Как всегда ждём ваши вопросы, комментарии тут или на можно помучать преподавателей на открытом уроке.

Источник

git rebase

Перебазирование — это один из двух инструментов Git для внедрения изменений из одной ветки в другую. Такие же возможности предоставляет команда git merge (слияние). Операция слияния фиксирует изменения, всегда двигаясь вперед по истории проекта, в то время как перебазирование позволяет эффективно ее переписывать. Подробные сведения об операциях слияния и перебазирования см. в руководстве Сравнение слияния и перебазирования. Перебазирование может выполняться в двух режимах: ручном и интерактивном. Эти режимы будут подробно рассмотрены далее.

Что такое git rebase?

Перебазирование — это процесс перемещения последовательности коммитов к новому базовому коммиту или их объединение. Операцию перебазирования удобнее всего применить и отобразить в контексте создания функциональных веток. В общих чертах процесс можно представить следующим образом:

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

Использование

Перебазирование выполняется прежде всего для обеспечения линейной истории проекта. Представим ситуацию: вы работаете над функциональной веткой feature, при этом код в главной ветке main уже изменился с начала вашей работы. Вам нужно отразить последние изменения ветки main в ветке feature, не засоряя при этом историю вашей ветки, чтобы создать впечатление, что ваша работа велась на основе последней версии ветки main. Впоследствии это позволит выполнить беспроблемное слияние ветки feature с веткой main. Почему не следует засорять историю? Ее аккуратность сыграет решающую роль при поиске в Git коммита, в котором появилась проблема. Можно привести более реалистичный пример.

Узнайте больше о командах git log и git bisect на соответствующих страницах.

Внедрить функцию в главную ветку main можно двумя способами: прямым слиянием или перебазированием с последующим слиянием. Первая операция выполняет трехстороннее слияние и создает коммит слияния, а вторая обеспечивает ускоренное слияние и абсолютно линейную историю. На приведенной ниже схеме показано, как перебазирование на ветку main обеспечивает ускоренное слияние.

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

Не выполняйте перебазирование публичной истории

Ранее на странице Переписывание истории мы уже обозначили, что ни при каких обстоятельствах не следует выполнять перебазирование коммитов, отправленных в публичный репозиторий. Команда rebase заменит старые коммиты на новые, и другим разработчикам покажется, будто часть истории проекта просто исчезла.

Сравнение стандартного и интерактивного режимов команды git rebase

В стандартном режиме команда git rebase автоматически берет коммиты из текущей рабочей ветки и применяет их в конце переданной ветки.

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

Дополнительные команды перебазирования

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

Обзор

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

Большинство разработчиков используют интерактивное перебазирование, чтобы придать функциональной ветке аккуратность перед слиянием с основной базой кода. Они могут склеить незначительные коммиты, удалить устаревшие элементы и в целом навести порядок в ветке, прежде чем выполнить перенос в «официальную» историю проекта. Со стороны будет казаться, что для разработки функции потребовалось лишь несколько коммитов и тщательное планирование.

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

Варианты конфигурации

Останавливает перебазирование и выводит предупреждения о том, что коммиты были удалены.

Расширенные возможности перебазирования

Ветка featureB основана на featureA. При этом мы понимаем, что ветка featureB не зависит ни от одного изменения в ветке featureA, поэтому она могла бы отходить от главной ветки main.

Опасности перебазирования

Сама по себе команда git rebase не сопряжена с серьезной опасностью. Риск возникает, если вы используете интерактивное перебазирование для перезаписи истории и затем принудительно отправляете результаты в удаленную ветку, где работают другие пользователи. Этого делать не стоит, поскольку работа удаленных пользователей может быть перезаписана при осуществлении pull.

Восстановление при перебазировании восходящей ветки

Резюме

Готовы изучить Git?

Ознакомьтесь с этим интерактивным обучающим руководством.

Источник

Руководство по Git. Часть №2: золотое правило и другие основы rebase

Посмотрим, что происходит, когда вы выполняете git rebase и почему нужно быть внимательным.

Это вторая и третья части гайда по Git из блога Pierre de Wulf в переводе команды Mail.ru Cloud Solutions. Первую часть можно почитать тут.

Суть rebase

Как именно происходит rebase:

Можно сказать, что rebase — это открепить ветку (branch), которую вы хотите переместить, и подключить ее к другой ветке. Такое определение соответствует действительности, но попробуем заглянуть чуть глубже. Если вы посмотрите документацию, вот что там написано относительно rebase: «Применить коммиты к другой ветке (Reapply commits on top of another base tip)».

Главное слово здесь — применить, потому что rebase — это не просто копипаст ветки в другую ветку. Rebase последовательно берет все коммиты из выбранной ветки и заново применяет их к новой ветке.

Такое поведение приводит к двум моментам:

Как видите, ветка feature содержит абсолютно новые коммиты. Как было сказано ранее, тот же самый набор изменений, но абсолютно новые объекты с точки зрения Git.

Это также означает, что старые коммиты не уничтожаются. Они становятся просто недоступными напрямую. Если вы помните, ветка — всего лишь ссылка на коммит. Таким образом, если ни ветка, ни тег не ссылаются на коммит, к нему невозможно получить доступ средствами Git, хотя на диске он продолжает присутствовать.

Теперь давайте обсудим «Золотое правило».

Золотое правило rebase

Золотое правило rebase звучит так — «НИКОГДА не выполняйте rebase расшаренной ветки!». Под расшаренной веткой понимается ветка, которая существует в сетевом репозитории и с которой могут работать другие люди, кроме вас.

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

Давайте рассмотрим ситуацию, когда разработчик нарушает золотое правило, и что происходит в этом случае.

Предположим, Боб и Анна вместе работают над проектом. Ниже представлено, как выглядят репозитории Боба и Анны и исходный репозиторий на GitHub:

У всех пользователей репозитории синхронизируются с GitHub.

Теперь Боб, нарушая золотое правило, выполняет rebase, и в это же время Анна, работая в ветке feature, создает новый коммит:

Вы видите, что произойдет?

Боб пытается выполнить пуш коммита, ему приходит отказ примерно такого содержания:

Выполнение Git не было успешным, потому что Git не знает, как объединить feature ветку Боба с feature веткой GitHub.

Единственным решением, позволяющим Бобу выполнить push, станет использование ключа force, который говорит GitHub-репозиторию удалить у себя ветку feature и принять за эту ветку ту, которая пушится Бобом. После этого мы получим следующую ситуацию:

Теперь Анна хочет запушить свои изменения, и вот что будет:

Это нормально, Git сказал Анне, что у нее нет синхронизированной версии ветки feature, то есть ее версия ветки и версия ветки в GitHub — разные. Анна должна выполнить pull. Точно таким же образом, как Git сливает локальную ветку с веткой в репозитории, когда вы выполняете push, Git пытается слить ветку в репозитории с локальной веткой, когда вы выполняете pull.

Перед выполнением pull коммиты в локальной и GitHub-ветках выглядят так:

Когда вы выполняете pull, Git выполняет слияние для устранения разности репозиториев. И вот, к чему это приводит:

Коммит M — это коммит слияния (merge commit). Наконец, ветки feature Анны и GitHub полностью объединены. Анна вздохнула с облегчением, все конфликты устранены, она может выполнить push.

Боб выполняет pull, теперь все синхронизированы:

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

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

Также учтите, что появляются дубликаты коммитов в сетевом репозитории. В нашем случае — D и D’, содержащие одни и те же данные. По сути, количество дублированных коммитов может быть таким же большим, как и количество коммитов в вашей rebased ветке.

Если вы все еще не убеждены, давайте представим Эмму — третью разработчицу. Она работает в ветке feature перед тем, как Боб совершает свою ошибку, и в настоящий момент хочет выполнить push. Предположим, что к моменту ее push наш маленький предыдущий сценарий уже завершился. Вот что выйдет:

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

Красота pull rebase

Как вы видели выше, проблем Анны можно было избежать, если бы она использовала pull rebase. Рассмотрим этот вопрос подробнее.

Допустим, Боб работает в ветке, отходящей от мастера, тогда его история может выглядеть вот так:

Боб решает, что настало время выполнить pull, что, как вы уже поняли, приведет к некоторым неясностям. Поскольку репозиторий Боба отходил от GitHub, Git спросит делать ли объединение, и результат будет таким:

Это решение подходит и работает нормально, однако, вам может быть полезно знать, что есть другие варианты решения проблемы. Одним из них является pull-rebase.

Когда вы делаете pull-rebase, Git пытается выяснить, какие коммиты есть только в вашей ветке, а какие — в сетевом репозитории. Затем Git объединяет коммиты из сетевого репозитория с самым свежим коммитом, присутствующим и в локальном, и в сетевом репозитории. После чего выполняет rebase ваших локальных коммитов в конец ветки.

Звучит сложно, поэтому проиллюстрируем:

Как вы помните, при rebase Git применяет коммиты один за одним, то есть в данном случаем применяет в конец ветки master коммит E, потом F. Получился rebase сам в себя. Выглядит неплохо, но возникает вопрос — зачем так делать?

По моему мнению, самая большая проблема с объединением веток в том, что загрязняется история коммитов. Поэтому pull-rebase — более элегантное решение. Я бы даже пошел дальше и сказал, что когда нужно скачать последние изменения в вашу ветку, вы всегда должны использовать pull-rebase. Но нужно помнить: поскольку rebase применяет все коммиты по очереди, то когда вы делаете rebase 20 коммитов, вам, возможно, придется решать один за другим 20 конфликтов.

Как правило, можно использовать следующий подход: одно большое изменение, сделанное давно — merge, два маленьких изменения, сделанных недавно — pull-rebase.

Сила rebase onto

Предположим, история ваших коммитов выглядит так:

Итак, вы хотите выполнить rebase ветки feature 2 в ветку master. Если вы выполните обычный rebase в ветку master, получите это:

Нелогично выглядит то, что коммит D существует в обоих ветках: в feature 1 и feature 2. Если вы переместите ветку feature 1 в конец ветки мастер, получится, что коммит D будет применен два раза.

Предположим, что вам нужно получить другой результат:

Для реализации подобного сценария как раз и предназначен git rebase onto.

Сначала прочтем документацию:

Нас интересует вот это:

С помощью этой опции указывается, в какой точке создавать новые коммиты.

Если эта опция не указана, то стартовой точкой станет upstream.

Для понимания приведу еще один рисунок:

То есть ветка master — это newbase, а ветка feature 1 — upstream.

Источник