Как исправить последний коммит

Изменение последнего коммита — Основы Git

Рекомендуем перейти в курс Введение в Git

Мы обновили этот курс — добавили новые темы, самостоятельные задания и практические упражнения. Посмотрите этот урок по ссылке: https://ru.hexlet.io/courses/intro_to_git/lessons/git-commit-amend/theory_unit

Изменение последнего коммита

Сегодня мы поговорим о том, как можно быстро отменить выполненые изменения. На любой стадии может возникнуть необходимость что-либо отменить. Будьте осторожны, ибо не всегда можно отменить сами отмены. Это одно из немногих мест в Git’е, где вы можете потерять свою работу если сделаете что-то неправильно.

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

Эта команда берёт индекс и применяет его к последнему коммиту. Если после последнего коммита не было никаких проиндексированных изменений (например, вы запустили приведённую команду сразу после предыдущего коммита), то состояние проекта будет абсолютно таким же и всё, что вы измените, это комментарий к коммиту.

Появится всё тот же редактор для ввода комментария к коммиту, но уже с введённым комментарием к последнему коммиту. Вы можете отредактировать это сообщение так же, как обычно, и оно перепишет предыдущее.

Эффект от выполнения этой команды такой, как будто вы не выполнили предыдущий коммит, а еще раз выполнили команду git add и выполнили коммит.

Вот так просто можно изменить последний выполненный коммит.

Остались вопросы? Задайте их в разделе «Обсуждение»

Вам ответят команда поддержки Хекслета или другие студенты.

Источник

Переписывание истории

Введение

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

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

Изменение комментария к последнему коммиту Git

Допустим, при выполнении коммита вы допустили ошибку в комментарии к нему. Выполнение этой команды в отсутствие проиндексированных файлов позволяет отредактировать комментарий к предыдущему коммиту без изменения состояния кода.

Изменение файлов после коммита

Не используйте amend для публичных коммитов

Измененные коммиты по сути являются новыми коммитами. При этом предыдущий коммит не останется в текущей ветке. Последствия этой операции аналогичны сбросу (reset) публичного состояния кода. Не изменяйте коммит, после которого уже начали работу другие разработчики. Эта ситуация только запутает разработчиков, и разрешить ее будет непросто.

Обзор

Изменение старых или нескольких коммитов

Для изменения старых или нескольких коммитов используйте команду git rebase для объединения нескольких коммитов в новый базовый коммит. В стандартном режиме команда git rebase позволяет в буквальном смысле перезаписать историю: она автоматически применяет коммиты в текущей рабочей ветке к указателю head переданной ветки. Поскольку новые коммиты заменяют старые, команду git rebase запрещено применять к коммитам, которые стали доступны публично. Иначе история проекта исчезнет.

Изменение файлов после коммита

Несколько комментариев

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

Склеивайте коммиты для поддержания чистой истории

Команда склеивания ( s ) позволяет в полной мере понять смысл rebase. Склеивание позволяет указать коммиты, которые нужно объединить в предыдущие коммиты. Таким образом создается «чистая история». Во время перемещения Git будет исполнять указанную команду rebase для каждого коммита. В случае склеенных коммитов Git откроет выбранный текстовый редактор и предложит объединить комментарии к указанным коммитам. Этот процесс можно показать следующим образом:

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

Современные решения для хостинга Git (например, Bitbucket) предлагают возможности «автосклеивания» при слиянии. Эти возможности позволяют автоматически выполнять rebase и склеивать коммиты ветки при использовании интерфейса решений для хостинга. Дополнительную информацию см. в разделе «Склеивание коммитов при слиянии ветки Git в Bitbucket».

Обзор

Команда git rebase позволяет изменять историю, а интерактивное выполнение rebase «подчищает» за вами следы. Теперь вы можете совершать и исправлять ошибки, оттачивая свою работу и сохраняя чистую, линейную историю проекта.

Страховка: git reflog

Справочные журналы (reflog) — это механизм, который используется в Git для регистрации обновлений, применяемых к концам веток и другим ссылкам на коммиты. Reflog позволяет вернуться к коммитам, даже если на них нет ссылок из какой-либо ветки или метки. После перезаписи истории reflog содержит информацию о старом состоянии веток и позволяет при необходимости вернуться к этому состоянию. Каждый раз при обновлении конца ветки любым способом (переключение веток, загрузка новых изменений, перезапись истории или просто добавление новых коммитов) в reflog добавляется новая запись. В данном разделе мы рассматриваем команду git reflog и стандартные примеры ее использования.

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

Отображается reflog локального репозитория.

Отображается reflog с относительными датами (например, 2 недели назад).

Пример

В приведенной выше команде reflog показан переход из главной ветки в ветку 2.2 и обратно. Отсюда можно выполнить жесткий сброс к старому коммиту. Последнее действие указано в верхней строчке с пометкой HEAD@ <0>.

Если вы случайно переместитесь назад, reflog будет содержать главный коммит, указывающий на (0254ea7) до случайного удаления вами 2 коммитов.

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

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

Резюме

В данной статье мы рассмотрели несколько способов изменения истории Git и отмены изменений в Git. Мы вкратце рассмотрели процесс git rebase. Вот основные заключения.

Узнайте больше об описанных командах на соответствующих страницах:

Источник

Git: исправление ошибок и наведение порядка в коммитах

Ошибка в коммите… Как её исправить? Беспорядок в истории коммитов… Как привести всё в пристойный вид? Автор статьи, перевод которой мы публикуем сегодня, говорит, что она написана специально для тех, кто задавался такими вопросами. По его словам, изучив методики работы с Git, представленные здесь, можно значительно продвинуться по пути освоения Git.

Исправление ошибок в коммитах

Здесь мы рассмотрим несколько сценариев появления ошибок в коммитах и их исправления.

▍Сценарий №1

▍Сценарий №2

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

▍Сценарий №3

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

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

▍Примечание

Используйте команду amend только в своём локальном репозитории. Её применение в удалённых репозиториях может привести к огромной путанице.

Наведение порядка в истории коммитов

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

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

Каждый раз, когда вы загружаете код из удалённого в локальный репозиторий, в локальном репозитории создаётся новый коммит-слияние (Merge Commit). Это означает, что в вашей локальной истории коммитов будет много таких коммитов, которые могут запутать того, кто будет просматривать ваш код.

История коммитов в локальном репозитории

▍Команда git rebase

Рассмотрим команду git rebase на примере.

Коммиты в ветке Release и в ветке Feature

В результате применение команды rebase будет выглядеть так:

▍Особенности команды rebase

Ветка Feature и три шага работы команды rebase

Шаг 1

Шаг 2

Шаг 3

▍Примечание

В случае использования команды merge вы получите коммит-слияние. В случае использования rebase никаких дополнительных коммитов у вас не будет.

Итоги

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

Уважаемые читатели! Сталкивались ли вы с беспорядком в Git-коммитах?

Источник

ВНИМАНИЕ: Никогда не вносите изменения в последний коммит при помощи команды [cci]—amend[/cci], если данный коммит вы уже успели запушить на удаленный центральный репозиторий. В таких случаях вам нужно внести изменения в код с помощью нового коммита.

Правка кода в последнем коммите (ключ —amend).

На иллюстрации ниже показана история коммитов в текущем репозитории при помощи команды:

[cce lang=’bash’]
$ git log
[/cce]

В данном примере при создании последнего коммита была допущена неточность в комментарии к коммиту, и еще требуется внести небольшое изменение в код проекта. Для начала сделаем небольшие правки в файл first.php и воспользуемся для этого редактором nano.

Теперь, мы можем увидеть, что в нашем локальном репозитории, есть измененнные файлы, чье состояние пока что незафиксировано в системе контроля версий Git. Сделаем это при помощи команды:

[cce lang=’bash’]
$ git status
[/cce]

Данные изменения нужно добавить для фиксации в коммите, при помощи:

[cce lang=’bash’]
$ git add first.php
[/cce]

В иллюстрации выше видно, что сделанные изменения подготовлены к фиксации в коммите, но нам необходимо сделать это не в новом коммите, а добавить к последнему старому, и мы сделаем это с помощью ключа —amend (в переводе с англ.: изменять, вносить правки).

В результате применения команды выше, НЕ СОЗДАЕТСЯ новый коммит, а вносятся изменения в последний уже существующий. Убедиться в этом можно применив команду [cci]$ git log[/cci]

Как видно на изображении выше, в результате применения команды [cci]$ git commit —amend[/cci] изменилось содержимое последнего коммита, о чем свидетельствует изменившийся ХЕШ-коммита, а также изменился последний комментарий коммита. Но без изменений остались дата и время коммита.

Как изменить только комментарий последнего коммита?

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

Рассмотрим эту ситуацию на примере выше. Нам необходимо сделать только правку комментария, в этом случае мы сразу воспользуемся командой:

На изображении выше показан результат работы команды, а также вывод полученный при [cci]
$ git log[/cci] для просмотра имеющихся коммитов. Так видно, что изменилось описание
и ХЕШ-сумма последнего коммита, а время и дата остались прежними.

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

Источник

Как изменить сообщение коммита в Git

Главное меню » Статьи » Как изменить сообщение коммита в Git

В этой статье объясняется, как изменить сообщение о самых последних или старых коммитах в Git.

Изменение самого последнего коммита

Команда git commit –amend позволяет вам изменить самое последнее сообщение о коммите.

Не изменять коммит

Чтобы изменить сообщение самого последнего коммита, который не был передан в удаленный репозиторий, передайте его снова, используя флаг –amend.

Команда выполняет перезапись самого последнего коммита новым.

Перед изменением сообщения о коммите вы также можете добавить другие ранее забытые изменения:

Измененный коммит

Измененный коммит – это новый объект с другим SHA-1. Предыдущий коммит больше не будет существовать в текущей ветке.

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

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

Изменение более старых или нескольких коммитов

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

N, где N число коммитов для выполнения перебазирования. Например, если вы хотите изменить 4-й и 5-й последние коммиты, введите:

Команда отобразит последние X коммитов в текстовом редакторе по умолчанию :

Заключение

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

Если вы столкнулись с проблемой или у вас есть отзыв, оставьте комментарий ниже.

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

Источник