git как исправить коммит
Как в git изменить комментарий к коммиту?
Рабочий процесс в системе контроля версий git сводится к тому, что разработчик создает от ветки develop новую ветку для реализации конкретной задачи. Принято, что в ветке каждому коммиту соответствует более-менее логически законченная единица работы или же изменения, которые в будущем может потребоваться отменить.
Однако порой в спешке под конец рабочего дня разработчик может закоммититься с подписью вроде такой «WIP» или «TMP». В статье рассмотрим, как в git переименовать коммит. При этом возможны два основных случая — коммит является последним или коммит не является последним.
Переименование последнего коммита
Изменение комментария к не последнему коммиту
Допустим разработчик забыл с утра откорректировать название коммита, и в течение дня сделал ещё несколько коммитов. Тогда встаёт вопрос, как обновить комментарий, например для четвёртого коммита вглубь истории.
Итак, чтобы в git исправить комментарий такого коммита потребуется выполнить rebase в интерактивном режиме.
Видим, что изменить комментарий нужно к коммиту «tmp», находящийся позади на четыре коммита относительно HEAD.
2. Теперь запускаем rebase в интерактивной режиме:
Затем сохраняем файл и выходим.
4. Автоматически начнется ребейз и откроется файл редактирования коммита. Здесь необходимо ввести новую подпись к коммиту.
5. Остаётся сохранить и выйти. Теперь название коммита изменено.
Однако, если работа в ветке ведётся несколькими разработчиками одновременно, тогда такой подход неприемлем.
Однако, если работа в ветке ведётся несколькими разработчиками одновременно, тогда такой подход неприемлем.
—
А какой будет приемен, в таком случае?
Здесь имелось ввиду, что если вы хотите переименовать коммиты, которые другие разработчики команды уже спулили себе. Когда вы внесёте изменения и запушите их с помощью force, то при следующем получении обновлений у остальных возникнут конфликты. Если же обновления ещё никто не забрал, тогда вы смело можете быстро запушить с force, предварительно проверив, не успел ли кто-то добавить коммиты, просто сделав git fetch.
При командной разработке есть несколько вариантов:
1. Сообщить всем, что сейчас вы хотите поменять историю. После того, как вы запушите изменения, всем членам команды нужно будет обновить актуальное состояние ветки либо путём git pull —force, либо откатиться на N коммитов с помощью git reset —hard HEAD
N и спулить актуальную версию. Всё это будет вполне нормально, если другие разработчики не успели за это время закоммитить в эту ветку свой код. В таком случае разрешать конфликты гораздо сложнее, поэтому более легким выходом станет перенести разработку в новую ветку.
Переписывание истории
Введение
В данном обучающем материале описаны различные способы перезаписи и изменения истории в 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
Мы обновили этот курс — добавили новые темы, самостоятельные задания и практические упражнения. Посмотрите этот урок по ссылке: https://ru.hexlet.io/courses/intro_to_git/lessons/git-commit-amend/theory_unit
Изменение последнего коммита
Сегодня мы поговорим о том, как можно быстро отменить выполненые изменения. На любой стадии может возникнуть необходимость что-либо отменить. Будьте осторожны, ибо не всегда можно отменить сами отмены. Это одно из немногих мест в Git’е, где вы можете потерять свою работу если сделаете что-то неправильно.
Довольно часто возникает такая ситуация, что вы делаете коммит слишком рано, при этом забыв добавить какие-то файлы, или напутали с комментарием к коммиту. В таком случае у вас может появиться желание отменить выполненный коммит и выполнить его ещё раз, но уже с правильными данными.
Эта команда берёт индекс и применяет его к последнему коммиту. Если после последнего коммита не было никаких проиндексированных изменений (например, вы запустили приведённую команду сразу после предыдущего коммита), то состояние проекта будет абсолютно таким же и всё, что вы измените, это комментарий к коммиту.
Появится всё тот же редактор для ввода комментария к коммиту, но уже с введённым комментарием к последнему коммиту. Вы можете отредактировать это сообщение так же, как обычно, и оно перепишет предыдущее.
Эффект от выполнения этой команды такой, как будто вы не выполнили предыдущий коммит, а еще раз выполнили команду git add и выполнили коммит.
Вот так просто можно изменить последний выполненный коммит.
Остались вопросы? Задайте их в разделе «Обсуждение»
Вам ответят команда поддержки Хекслета или другие студенты.
Как отменить commit и не облажаться
Возьмем простую ситуацию: разработчик решает реализовать математические функции. Но на половине пути понимает, что данную задачу было бы хорошо декомпозировать, допустим, на две подзадачи:
Проверять будет проще да и тестировать. Но он уже начал ее реализовывать, коммиты уже созданы, и что же делать? Не переписывать же!
git revert
Работа кипит и осталось дело за малым — смерджить мастер с данными ветками.
И что же мы получили? Ни класса Arithmetic, ни класса Numerical!
А все дело в том, что команда git revert создает новый коммит с отменой изменений и не удаляет из истории коммиты. И в нашем случае после слияния веток получается 4 коммита:
То есть вариант с отменой изменений с помощью команды revert вышел нам боком.
git reset
git rebase
Есть еще одно решение — использовать команду git rebase для отмены изменений.
Вернемся к моменту создания двух веток numerical и arithmetic и выполним
Теперь на уровне каждого коммита, который мы хотим отменить заменим pick на drop. И тогда выбранные нами коммиты сбросятся из истории. Например в ветке numerical :
Тогда в истории у нас останутся только нужные нам коммиты.
Теперь при слиянии веток в master получим оба класса.
Данный метод рабочий, только при условии работы в частной ветке, но если эти манипуляции провести в общей ветке, то при публикации ( git push ) git сообщает, что ветка устарела, так как в ней отсутствуют коммиты и отменяет публикацию.
Чтобы не бороться с git, старайтесь декомпозировать задачи заранее, а то можете словить сюрприз. Сталкивались ли вы с такими ситуациям, и если да, то как выходили из них?
Git: исправление ошибок и наведение порядка в коммитах
Ошибка в коммите… Как её исправить? Беспорядок в истории коммитов… Как привести всё в пристойный вид? Автор статьи говорит, что она написана специально для тех, кто задавался такими вопросами. По его словам, изучив методики работы с Git, представленные здесь, можно значительно продвинуться по пути освоения Git.
Предполагается, что читатель этой статьи уже знаком с основами Git. Если это не так — сначала рекомендуется освоить базу, например, воспользовавшись этим материалом.
Исправление ошибок в коммитах
Здесь мы рассмотрим несколько сценариев появления ошибок в коммитах и их исправления.
Сценарий №1
Сценарий №2
Предположим, вы хотели закоммитить шесть файлов, но, по ошибке, закоммитили лишь пять. Кажется, что исправить эту ошибку можно, просто создав новый коммит и добавив туда недостающий шестой файл.
Сценарий №3
К коммитам, которые делают в Git, привязаны имя автора и адрес его электронной почты. Обычно эти данные указывают, выполняя первоначальную настройку Git. В результате тот, кто использует Git, может, выполняя каждый коммит, не заботиться о сведениях об его авторе.
При этом вполне возможна ситуация, когда, при работе с некоторыми проектами, будет нужно пользоваться сведениями об авторе, например — адресом электронной почты, отличающимися от основных. Для подобного проекта нужно указать адрес электронной почты, воспользовавшись такой командой:
Примечание
Используйте команду amend только в своём локальном репозитории. Её применение в удалённых репозиториях может привести к огромной путанице.
Наведение порядка в истории коммитов
Предположим, вы работаете над неким фрагментом кода какого-то проекта. Вам известно, что это займёт примерно десять дней. В течение этих десяти дней другие разработчики делают коммиты в исходный репозиторий.
Рекомендуется поддерживать синхронизацию между локальным и удалённым репозиториями. Это позволяет избежать множества конфликтов, связанных со слиянием, возникающих при слишком редкой синхронизации репозиториев. Следуя этой практике, вы решаете загружать изменения из удалённого репозитория каждые два дня.
Каждый раз, когда вы загружаете код из удалённого в локальный репозиторий, в локальном репозитории создаётся новый коммит-слияние (Merge Commit). Это означает, что в вашей локальной истории коммитов будет много таких коммитов, которые могут запутать того, кто будет просматривать ваш код.
Команда git rebase
Рассмотрим команду git rebase на примере.
В результате применение команды rebase будет выглядеть так:
Особенности команды rebase
Шаг 1
Шаг 2
Шаг 3
Примечание
В случае использования команды merge вы получите коммит-слияние. В случае использования rebase никаких дополнительных коммитов у вас не будет.
Итоги
Изучив представленные в этом материале концепции, вы улучшили свои навыки владения Git и приблизились к уровню Git-эксперта. Надеемся, то, что вы тут узнали, вам пригодится. Но мир Git огромен, поэтому, освоив что-то новое, не останавливайтесь на достигнутом и двигайтесь дальше.