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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Как отключить отслеживание прав доступа к файлам в git

Декабрь 4, 2018 г.

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

Читать

Создание ветки на основе существующей в GIT

Июль 30, 2018 г.

Создание новой ветки - это рутинная операция в GIT. Как указать на основе какой существующей ветки нужно создать новую? По умолчанию, за основу будет взята текущая ветка, в которой вы находитесь. Например: [crayon-69f10cd972b1b141046565/] Сначала ...

Читать

Тонкости настройки в .gitignore

Июль 17, 2017 г.

Настройки в файле .gitignore позволяют исключить из списка файлов сканируемых GIT, все то что отслеживать не надо. Обычно это так называемые юзер-файлы, изображения, архивы, документация и т.п. В данной статье рассмотрим типовой случай настоек в .gitignore. ...

Читать

GIT может хранить пароли

Сентябрь 30, 2017 г.

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

Читать
 

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

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



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