git очистить историю коммитов
Как привести в порядок историю ваших коммитов в 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. Вывод
Главное, что нужно сделать перед пушем в удаленный репозиторий и особенно перед мержем вашей ветки, — убедиться в том, что вы привели в порядок историю коммитов. Как только вы запушите все в удаленный репозиторий, уже ничего поправить нельзя.
Хочу сделать не совсем обычную вещь.
Мне нужно удалить всю историю правок, и оставить только последнее актуальное состояние проекта. Ветка одна, 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 на тот же реп»?
Как удалить старую историю из репозитория 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:
Теперь просто введите:
17. Удаление коммитов из ветки
Revert из предыдущего раздела является мощной командой, которая позволяет отменить любые коммиты в репозиторий. Однако, и оригинальный и «отмененный» коммиты видны в истории ветки (при использовании команды git log ).
01 Команда reset
Мы уже видели команду reset и использовали ее для согласования буферной зоны и выбранного коммита (мы использовали коммит HEAD в нашем предыдущем уроке).
При получении ссылки на коммит (т.е. хэш, ветка или имя тега), команда reset …
02 Проверьте нашу историю
Давайте сделаем быструю проверку нашей истории коммитов.
Выполните:
Результат:
03 Для начала отметьте эту ветку
Но прежде чем удалить коммиты, давайте отметим последний коммит тегом, чтобы потом можно было его найти.
Выполните:
04 Сброс коммитов к предшествующим коммиту Oops
Глядя на историю лога (см. выше), мы видим, что коммит с тегом «v1» является коммитом, предшествующим ошибочному коммиту. Давайте сбросим ветку до этой точки. Поскольку ветка имеет тег, мы можем использовать имя тега в команде сброса (если она не имеет тега, мы можем использовать хэш-значение).
Выполните:
Результат:
05 Ничего никогда не теряется
Что же случается с ошибочными коммитами? Оказывается, что коммиты все еще находятся в репозитории. На самом деле, мы все еще можем на них ссылаться. Помните, в начале этого урока мы создали для отмененного коммита тег «oops». Давайте посмотрим на все коммиты.
Выполните:
Результат:
06 Опасность сброса
Сброс в локальных ветках, как правило, безопасен. Последствия любой «аварии» как правило, можно восстановить простым сбросом с помощью нужного коммита.
Однако, если ветка «расшарена» на удаленных репозиториях, сброс может сбить с толку других пользователей ветки.
Как привести в порядок историю ваших коммитов в 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. Вывод
Главное, что нужно сделать перед пушем в удаленный репозиторий и особенно перед мержем вашей ветки, — убедиться в том, что вы привели в порядок историю коммитов. Как только вы запушите все в удаленный репозиторий, уже ничего поправить нельзя.