Как очистить историю коммитов github

11.01.202312.01.2023 admin 0 Comments

Как привести в порядок историю ваших коммитов в 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-репозитория. Из других наиболее полезных возможностей этой команды я бы выделил объединение и разделение коммитов. Благодаря этим приемам историю можно сделать более аккуратной. С полным списком возможностей можно ознакомиться в документации.

Источник

Как удалять старые коммиты в «GitHub Desktop»?

Приветствую, мне нужно, чтобы остался только последний. Репозиторий публичный.

rebase. Но готовься получить по жопе за это.

Хочу получить по жопе что делоть

Это не по жопе, @Шериф @Рейнджер прошу удалить эту клевету.

Но зачем? Вся суть систем контроля версий в том, чтобы у тебя была история изменений.

Хочет красивую историю изменений, значит

Не знаю что насчет Desktop, но для таких вещей я обычно rebase делаю

Наверное сквош и форс пуш.

Если история линейная (есть только одна ветка), то можно сделать совсем по-простому: удалить репозиторий и создать его заново, залить туда весь код одним коммитом и всё. Но если кто-то ссылался на этот репозиторий через git submodules, то у них всё поломается, потому что рефы будут уже другие

Какого flow предержиааещься?
В целом в нормальной ситуации тебе не должно хотеться изменять фиксации после их создания. Если тебе хочется это делать, то явно что-то не так идёт. Если тебе прсото хочется откатить изменения используй `revert`.
А вообще хочется больше входной информации.

Я разместил там свою политику конфиденциальности, изменил почту (т.к. не хотел чтобы боты засирали основную почту) и хотел потереть предыдущие версии. Все равно, приложение еще не вышло.

https://sparkbox.com/foundry/remove_file_from_git_history_with_git_filter-branch
Вот хорошая статья. В целом я когда-то использовал утилиту BFG (попали ключи от dev сервера)

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

Источник

Как привести в порядок историю ваших коммитов в Git