Как привести в порядок историю ваших коммитов в Git
Публикуем перевод статьи, которую мы нашли на hackernoon.com. Ее автор, Thiago Miranda, пишет о том, как сделать работу с Git более удобной и эффективной.
О некоторых крайне полезных командах в Git
Последний месяц я занимался парным программированием и создал несколько сотен коммитов в Git. В статье я поделюсь самым важным из того, что узнал за это время: расскажу о работе с историей коммитов, об удачных приемах и о том, как реализовать их с помощью десятка команд.
1. Что такое история в Git?
Точный реестр всех коммитов, содержащих произведенные с файлами изменения. В нем вы можете отследить конкретные изменения и время их внесения или сравнить текущую версию с предыдущей. Где посмотреть историю? Введите через Git Bash команду:
Если у вас слишком много коммитов, вы можете переходить от одного комментария к другому с помощью клавиш со стрелками или клавиш Page Up / Page Down — как и в любом другом файле. Чтобы выйти, нажмите горячую клавишу (q).
2. О комментариях к коммитам
Не пишите бессодержательные комментарии, они должны быть краткими и не требующими пояснений. Их задача — указать, какие изменения вы внесли в код и на что они влияют.
Но после пуша внезапно все перестает работать, и первое, что вы проверяете — изменения, внесенные за время разработки этой фичи. В логе Git вы находите множество коммитов с комментариями в стиле «исправлен». Вообразите, сколько времени придется потратить на то, чтобы найти нужное!
3. Всегда делайте коммиты
Коммиты, коммиты и еще раз коммиты. Закончили функцию — добавьте коммит, улучшили стиль блочного элемента — добавьте коммит и так далее. В идеале вы должны отправлять коммит при каждом изменении.
Возможно, вы думаете: зачем так много коммитов? Основная причина в том, что ваш новый функционал может вступить в конфликт с чьим-нибудь кодом, но если вы всегда коммитите небольшие изменения, найти их и поправить будет проще. Так вы сэкономите время на отслеживании десятков или сотен строк, измененных в одном и том же коммите.
4. Исправьте последний комментарий к коммиту
Что, если уже после добавления небольшого коммита в ваш локальный репозиторий вы захотели исправить допущенную опечатку или сделать комментарий к коммиту подробнее? Внести изменения довольно просто сделать с помощью команды:
Обратите внимание: если вы уже запушили коммит в удаленный репозиторий, эту команду лучше не использовать.
5. Объедините последние Х коммитов в один
Ситуация: отправив коммит к новой фиче, вы понимаете, что нужно еще одно небольшое изменение, вносите минимальные правки и снова коммитите… В итоге 5 коммитов об одном и том же. Бывало? Подобные коммиты выбиваются из общего вида вашей истории в Git, но при желании их несложно поправить, применив команду:
3 откатывает 3 верхних коммита, включая самый последний. В этом примере три ваших последних коммита будут стерты из лога, но изменения в коде останутся на месте. Теперь пора посмотреть, какой код нужно закоммитить, для этого вводим команду:
Вы увидите, что все изменения в коммитах, которые вы убрали из истории, теперь индексированы, так что их можно закоммитить снова, в этот раз в один прием.
Обратите внимание, что HEAD обычно относится к последнему добавленному вами коммиту. Если вы не уверены, сверьтесь с логом Git. Если ваш последний коммит был замержен (не самый распространенный случай), команда HEAD
1 сотрет все коммиты из замерженной ветки. Чтобы узнать больше, посмотрите документацию.
6. Удалите последний коммит с изменениями
Будьте осторожны, так как этот способ сотрет все изменения без возможности откатить. Обычно он используется после экспериментов с кодом, если их результат не соответствует ожиданиям. Я рекомендую сперва попробовать в репозитории-песочнице.
Теперь ваш последний коммит удален, как и все соответствующие изменения в коде.
7. Очистите историю своих коммитов
Как только вы вошли в него, вы увидите список из 5 последних коммитов (HEAD
5) внутри терминала. Все коммиты отсортированы по дате, т. е. наверху будет самый новый (этот список открывается с помощью Vim — текстового редактора Git по умолчанию, позволяющего редактировать текстовые файлы внутри терминала). И здесь же краткая инструкция с несколькими полезными командами. В большинстве случаев вам понадобятся команды squash и reword.
Заменив команду pick командой squash, вы удалите этот коммит из лога, и все изменения в коде будут сгруппированы с последним коммитом, выделенным командой pick.
Если вы хотите откорректировать комментарий, можно заменить команду pick командой reword и переписать комментарий.
Теперь вы можете перейти к следующему окну, где нужно написать один комментарий для группы коммитов, которые вы собираетесь склеить с помощью squash. Чтобы продолжить, нажмите ESC и введите:
Двоеточие (:) необходимо, чтобы показать, что вы хотите передать команду, (w) — чтобы записать (сохранить) изменения, (q) — чтобы выйти, а (!) — чтобы выполнить команду.
Обратите внимание, что каждая группа коммитов получит ваш комментарий. Результат можно проверить в логе Git.
Если по какой-то причине вы покидаете это окно, не завершив операцию, вы можете вернуться в любой момент с помощью команды:
Если вы хотите покинуть окно, не сохранив изменения, нажмите клавишу ESC и введите:
Vim получит команду закрыть файл без сохранения.
8. Управляйте индексацией
Обычно следует отправлять коммиты к одному файлу или к группе связанных файлов. Но как тогда оперативно вносить изменения при индексации?
Скажем, у вас есть 3 файла, и нужно закоммитить только 2 из них. В этом случае можно попробовать следующую команду:
Теперь удалите из индексации тот файл, который вам не нужен:
И проверьте результат:
Добавьте все файлы из какого-либо расширения, например CSS:
Добавили все по ошибке? Тогда очистите индексацию, воспользовавшись командой:
Если вам нужны более сложные операции, можно добавить файлы в индексацию с помощью диалогового режима:
Сначала выберите опцию, введя соответствующий номер, например (3), чтобы откатить свои действия.
Выбрав опцию, можно ввести список файлов, которые вы хотите убрать из индексации, один за другим.
Когда завершите, нажмите (Enter).
Добавление файлов происходит по той же схеме. С помощью опции (4) добавьте неотслеживаемый файл.
Чтобы выйти, введите (q) в меню опций.
9. Вывод
Главное, что нужно сделать перед пушем в удаленный репозиторий и особенно перед мержем вашей ветки, — убедиться в том, что вы привели в порядок историю коммитов. Как только вы запушите все в удаленный репозиторий, уже ничего поправить нельзя.
Правим историю Git с помощью интерактивного rebase
Система контроля версий — неотъемлемый инструмент в рабочем процессе любого разработчика. С его помощью вы можете сохранять состояния вашего проекта, переключаться между ними и поддерживать разработку несколькими людьми. Самой популярной системой контроля версий на текущий момент является git.
В этом посте мы не будем изучать основы git — есть множество туториалов, в том числе интерактивных. Предполагается, что вы знаете как создавать коммиты, просматривать историю и выполнять другие базовые команды. Мы займемся не самой распространенной проблемой при использовании git. Бывают ситуации, когда по невнимательности или чьей-то некомпетентности в репозитории оказывается нежелательная информация. Возможно даже, что после этого она была удалена и в текущей версии проекта ее нет, но она осталась в истории git и, откатившись к определенной версии, ее можно будет восстановить. Изменять историю мы будем с помощью git-команды rebase в режиме interactive.
Какие проблемы будем решать
Для большей реалистичности мы решим эту задачу на примере реальных проблем, которые могут возникнуть в вашей программистской практике.
Предостережение
Перезапись истории — очень опасный прием в том случае, если вы изменяете коммиты, которые уже находятся в публичном репозитории. Если есть разработчики, которые пользуются вашим проектом, то обновление истории в удаленном репозитории может сильно осложнить им жизнь, когда они получат несогласованные изменения. Поэтому используйте интерактивный rebase и любые другие способы изменения истории на коммитах, которые существуют только в вашем локальном репозитории либо, если вы знаете всех людей, которые занимаются проектом и вы можете согласовать с ними этот процесс.
Исправить опечатку в commit message
Для демонстрации возможностей interactive rebase я создал тестовый репозиторий, в котором буду моделировать описанные выше проблемы.
Начнем с ситуации, когда вы сделали коммит и сразу осознали, что допустили ошибку в его message:
Итак, после коммита с опечаткой было сделано несколько других изменений:
Здесь в дело вступает интерактивный rebase. Команда rebase позволяет перемещать коммиты между ветками, в данном случае мы будем их перемещать на то же самое место. А благодаря интерактивному режиму (флаг —interactive/-i), каждый из перемещаемых коммитов можно редактировать, изменяя текст сообщения, используемые файлы и их содержимое.
Необходимо вызвать rebase на коммите, предшествующем тому, в котором нужно, что-то изменить. Для этого нужно либо передать хэш этого коммита (972078a), либо насколько он отстает от текущего (HEAD
3). Я предпочитаю первый вариант, поскольку история может быть гораздо длиннее, а считать коммиты не хочется.
Вновь откроется дефолтный редактор, в котором необходимо выбрать коммиты для изменения.
Как можно увидеть, вся необходимая информация описана в этом файле. Изначально все коммиты берутся без изменений (об этом говорит слово pick). Для тех коммитов, которые требуют исправлений, замените pick на соответствующий вариант. Так как мы хотим изменить сообщение коммита 0be0764, заменим pick на reword либо в сокращенном варианте – r:
Удалить приватную информацию из файла
Допустим, в какой-то момент мы добавили в публичный доступ логин и пароль к нашему сервису. Так выглядит история:
Снова воспользуемся interactive rebase. Вызов на коммите bfe4560, откроет редактор со следующим содержимым:
У нас есть два варианта. Если коммит b94ffdb содержит и другие изменения помимо нежелательных, то следует заменить pick на edit, что означает исправление данного коммита, и переименовать коммит соответствующим образом. В случае, если это единственная правка в коммите, то его следует удалить (для этого используйте слово drop).
Исправьте состояние файла на текущем коммите:
В случае удаления коммита процесс будет аналогичным.
Избавиться от ненужных файлов
У нас имеется репозиторий, в который в определенный момент был добавлен файл с логами. После этого разработка продолжалась, причем этот файл тоже менялся. Потом мы наконец заметили, что тащим с собой логи, и удалили их. После этого мы все же решили, что это не лучшее решение и будет правильнее удалить логи из всего репозитория.
Для этого для начала найдем, в каких коммитах файл с логами менялся (в первую очередь нас интересует, когда он появился). Это можно сделать с помощью команды git log. Укажите путь к файлу, который ищем (используйте —follow, если файл мог быть переименован).
Теперь, зная к какому коммиту откатываться, воспользуемся интерактивным rebase.
Далее во всех коммитах, в которых этот файл изменялся, необходимо удалять его из stage-области (git reset HEAD path_to_file) и продолжать процесс. В итоге вы очистите историю от ненужного файла, а сам файл в своем конечном состоянии останется на диске.
Другие возможности interactive rebase
С помощью интерактивного rebase можно существенно изменить историю git-репозитория. Из других наиболее полезных возможностей этой команды я бы выделил объединение и разделение коммитов. Благодаря этим приемам историю можно сделать более аккуратной. С полным списком возможностей можно ознакомиться в документации.
Как удалить старую историю из репозитория git?
Боюсь, я не смог найти ничего похожего на этот конкретный сценарий.
У меня есть git-репозиторий с большой историей: 500+ веток, 500+ тегов, начиная с середины 2007 года. Он содержит
19 500 коммитов. Мы хотели бы удалить всю историю до 1 января 2010 года, чтобы сделать ее меньше и легче иметь дело (мы сохраним полную копию истории в архивном хранилище).
Я знаю, что коммит, который я хочу, стал корнем нового хранилища. Однако я не могу найти правильный git mojo для усечения репо, чтобы начать с этого коммита. Я угадываю какой-то вариант
Кто-нибудь когда-нибудь делал что-то подобное? У меня есть git 1.7.2.3, если это имеет значение.
После создания трансплантата он вступает в силу сразу же; вы сможете git log увидеть и увидеть, что ненужные старые коммиты исчезли:
ВНИМАНИЕ: после выполнения шага ответвления фильтра все идентификаторы коммитов будут изменены, поэтому любой, кто использует старое репо, никогда не должен сливаться с кем-либо, использующим новое репо.
Возможно, уже слишком поздно отправлять ответ, но поскольку эта страница является первым результатом Google, она все равно может оказаться полезной.
Если вы хотите освободить место в своем репозитории git, но не хотите перестраивать все свои коммиты (перебазирование или трансплантация), и при этом можете толкать / извлекать / объединять людей, имеющих полное репо, вы можете использовать git клон мелкий клон ( параметр —depth ).
Вы можете обуздать существующее репо, выполнив следующие действия:
Ps: Старые версии git не поддерживали клонирование / push / pull из / для мелких репозиториев.
Обратите внимание, что старые теги все еще будут присутствовать; поэтому вам может потребоваться удалить их вручную
примечание: я знаю, что это почти то же самое, что и @yoyodin, но здесь есть несколько важных дополнительных команд и информации. Я пытался отредактировать ответ, но, поскольку это существенное изменение в ответе @ yoyodin, мое редактирование было отклонено, поэтому вот информация!
Нажав коммит, вы можете сделать
Мне нужно было прочитать несколько ответов и другую информацию, чтобы понять, что я делаю.
1. Игнорировать все, что старше определенного коммита
git rev-parse дает нам идентификатор коммита 2000-го родителя текущего коммита. Приведенная выше команда перезапишет файл трансплантатов, если он присутствует. Проверьте, если это там в первую очередь.
2. Переписать историю Git (необязательно)
Если вы хотите, чтобы этот привитый поддельный родитель был реальным, выполните:
Это изменит все идентификаторы коммитов. Каждая копия этого хранилища должна быть принудительно обновлена.
3. Очистить место на диске
Я не сделал шаг 2, потому что я хотел, чтобы моя копия оставалась совместимой с апстримом. Я просто хотел сэкономить место на диске. Чтобы забыть все старые коммиты:
Альтернатива: мелкие копии
Запись на мелководье работает как прививка. Но будьте осторожны, чтобы не использовать трансплантаты и мелкие одновременно. По крайней мере, там нет одинаковых записей, это не удастся.
Если у вас все еще есть старые ссылки (теги, ветви, удаленные заголовки), которые указывают на более старые коммиты, они не будут очищены и вы не сэкономите больше дискового пространства.
При перебазировании или толкании к голове / мастеру эта ошибка может возникнуть
Для решения этой проблемы в git dashboard следует удалить главную ветку из «Защищенных веток»
тогда вы можете запустить эту команду
Здесь слишком много ответов, которые не актуальны, а некоторые не полностью объясняют последствия. Вот что сработало для меня, чтобы урезать историю, используя последний git 2.26:
Теперь просто введите:
Хочу сделать не совсем обычную вещь.
Мне нужно удалить всю историю правок, и оставить только последнее актуальное состояние проекта. Ветка одна, master. Как это можно сделать?
Сие удаление нужно сделать как в локальном репозитарии, так и на удаленном (основном, серверном) репозитарии.
Готовые команды приветствуются.
Не стоит этого делать.
Если ты коммитер и в проекте есть другие люди, то тебя поймают и отпиздят. Это как пить дать
Я единственный разработчик, других людей нет, да это по большей части не проект, а хранилище данных с историей. Нужно отдать на сторону без истории, ибо данных там на 50Mb, а история 1,5Gb.
А ещё можно zfs со своими снэпшотами, но это не то.
Ещё ты можешь попытаться сделать хотя бы git gc
Нужно отдать на сторону без истории, ибо данных там на 50Mb, а история 1,5Gb.
И не нужно убивать историю.
Нужно отдать на сторону без истории
Нужно отдать на сторону без истории
You’ve successfully authenticated, but server does not provide shell access.
git archive master
Разве rebase удаляет всю историю??
Как эта команда удалит историю на сервере?
Как эта команда удалит историю на сервере?
Никак. Тебе сервер надо передать или что?
С помощью rebase можно объединить предыдущие коммиты (в т.ч. все предыдущие коммиты) в один, который и будет последним.
Нужно отдать на сторону без истории
Отдай на сторону тарбол. Это так трудно?
В общем, оказалось проще всего удалить на сервере репозитарий и создать новый с таким же именем.
Локально тоже был удален репозитарий, и создан новый с текущим состоянием.
Потом этот новый локальный был залит на новый серверный.
Тупо, зато железобетонно.
Послушайте этого оратора, он дело говорит
Если че, потом добавляешь remote на тот же реп
Что вы имеете в виду под этой фразой?
Что значит «добавить remote на тот же реп»?
17. Удаление коммитов из ветки
Revert из предыдущего раздела является мощной командой, которая позволяет отменить любые коммиты в репозиторий. Однако, и оригинальный и «отмененный» коммиты видны в истории ветки (при использовании команды git log ).
01 Команда reset
Мы уже видели команду reset и использовали ее для согласования буферной зоны и выбранного коммита (мы использовали коммит HEAD в нашем предыдущем уроке).
При получении ссылки на коммит (т.е. хэш, ветка или имя тега), команда reset …
02 Проверьте нашу историю
Давайте сделаем быструю проверку нашей истории коммитов.
Выполните:
Результат:
03 Для начала отметьте эту ветку
Но прежде чем удалить коммиты, давайте отметим последний коммит тегом, чтобы потом можно было его найти.
Выполните:
04 Сброс коммитов к предшествующим коммиту Oops
Глядя на историю лога (см. выше), мы видим, что коммит с тегом «v1» является коммитом, предшествующим ошибочному коммиту. Давайте сбросим ветку до этой точки. Поскольку ветка имеет тег, мы можем использовать имя тега в команде сброса (если она не имеет тега, мы можем использовать хэш-значение).
Выполните:
Результат:
05 Ничего никогда не теряется
Что же случается с ошибочными коммитами? Оказывается, что коммиты все еще находятся в репозитории. На самом деле, мы все еще можем на них ссылаться. Помните, в начале этого урока мы создали для отмененного коммита тег «oops». Давайте посмотрим на все коммиты.
Выполните:
Результат:
06 Опасность сброса
Сброс в локальных ветках, как правило, безопасен. Последствия любой «аварии» как правило, можно восстановить простым сбросом с помощью нужного коммита.
Однако, если ветка «расшарена» на удаленных репозиториях, сброс может сбить с толку других пользователей ветки.