Изменяем историю коммитов в GIT

Рассмотрим две наиболее частые операции — изменение названия коммита и слияние нескольких коммитов в один.

Допустим, вы выполнили команду

И увидели следующую историю ваших коммитов в ветке:

Вам не понравилось описание для 95631e29df — где есть ошибки, а также само описание начинается со строчной буквы.

А коммиты f30f70962a и f256b8a634 — это этапы одного процесса исправлений в коде, и их желательно просто свести в один.

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

В нашем случае — это ba29ebc296. Это первый коммит, идущий перед парочкой, которую мы хотим объединить.

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

Здесь нужно выбрать операции, который будет совершатся над коммитами. Внизу, в виде подсказки, они перечислены. В нашем примере нужны две — «reword» или «r» — для переименования, а также «squash» или «s» — для слияния соседних коммитов.

Поменяйте pick на нужную команду для каждого коммита. Squash работает как сведение коммита в тот, что идет выше по списку. Для нашего случая:

Pick — означает, что коммит будет взят без изменений.

На этом этапе не нужно менять тексты комментариев, только требуется выбрать тип операции, которую вы хотите произвести.

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

Например, изменение названия:

Измените название и сохраните файл, выйдите из редактора. И так для всех операций, которые меняют историю.

Что делаем после

Если вы изменяли историю коммитов, которые уже отправлены в origin, то ваша ветка окажется в состоянии:

Если вас устраивает то, что получилось. А также, если вашей веткой пользуетесь только вы. То можете смело push изменения, для этого нужно приложить некоторые усилия :)

Ветка в origin перепишется новой историей коммитов.

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

Если в результате rebase вы оказались в состоянии detached, но вас устраивает то, что вы видите в истории коммитов, то вы можете подцепить ветку к текущему положению.

Мало букафф? Читайте есчо !

Git pull с передачей логина и пароля

Декабрь 11, 2021 г.

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

Читать

GIT workflow или как работать с проектом

Апрель 2, 2024 г.

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

Читать

Получить в git список измененных файлов

Июль 26, 2017 г.

Небольшая шпаргалка по git. Файлы измененные с момента последнего коммита, т.е. текущие изменения, можно вывести командой [crayon-6a921ca92fbb5878766507/] Вы увидите два списка изменений - файлы, которые добавлены в commit и список unstaged changes ...

Читать

Как обновить ветку в Git без переключения на неё

Май 1, 2026 г.

Предположим, вы работаете в ветке feature, а коллеги обновили master. Вам нужно подтянуть свежие изменения в локальный master, но не хочется терять контекст и переключаться туда-обратно. Стандартный git pull работает только с текущей веткой. Что делать? ...

Читать
 

Комментарии к «Изменяем историю коммитов в GIT»

Понравилась статья? Есть вопросы? - пишите в комментариях.



Комментарий: