git почистить историю коммитов
Хочу сделать не совсем обычную вещь.
Мне нужно удалить всю историю правок, и оставить только последнее актуальное состояние проекта. Ветка одна, 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
Публикуем перевод статьи, которую мы нашли на 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. Вывод
Главное, что нужно сделать перед пушем в удаленный репозиторий и особенно перед мержем вашей ветки, — убедиться в том, что вы привели в порядок историю коммитов. Как только вы запушите все в удаленный репозиторий, уже ничего поправить нельзя.
17. Удаление коммитов из ветки
Revert из предыдущего раздела является мощной командой, которая позволяет отменить любые коммиты в репозиторий. Однако, и оригинальный и «отмененный» коммиты видны в истории ветки (при использовании команды git log ).
01 Команда reset
Мы уже видели команду reset и использовали ее для согласования буферной зоны и выбранного коммита (мы использовали коммит HEAD в нашем предыдущем уроке).
При получении ссылки на коммит (т.е. хэш, ветка или имя тега), команда reset …
02 Проверьте нашу историю
Давайте сделаем быструю проверку нашей истории коммитов.
Выполните:
Результат:
03 Для начала отметьте эту ветку
Но прежде чем удалить коммиты, давайте отметим последний коммит тегом, чтобы потом можно было его найти.
Выполните:
04 Сброс коммитов к предшествующим коммиту Oops
Глядя на историю лога (см. выше), мы видим, что коммит с тегом «v1» является коммитом, предшествующим ошибочному коммиту. Давайте сбросим ветку до этой точки. Поскольку ветка имеет тег, мы можем использовать имя тега в команде сброса (если она не имеет тега, мы можем использовать хэш-значение).
Выполните:
Результат:
05 Ничего никогда не теряется
Что же случается с ошибочными коммитами? Оказывается, что коммиты все еще находятся в репозитории. На самом деле, мы все еще можем на них ссылаться. Помните, в начале этого урока мы создали для отмененного коммита тег «oops». Давайте посмотрим на все коммиты.
Выполните:
Результат:
06 Опасность сброса
Сброс в локальных ветках, как правило, безопасен. Последствия любой «аварии» как правило, можно восстановить простым сбросом с помощью нужного коммита.
Однако, если ветка «расшарена» на удаленных репозиториях, сброс может сбить с толку других пользователей ветки.
Спаси щеночка – держи свои git-репозитории в чистоте
Помните, что о каждом бессистемном git-репозитории в мире грустит один щеночек. Вы ведь не хотите расстраивать еще одного?
Бросим все силы на борьбу с собачьей грустью!
Все приведенные в статье советы могут быть использованы как в краткосрочных, так и в долговременных проектах. Они сочетают в себе лучшие практики, а также личный опыт профессиональных разработчиков.
Совет 1. Комментируйте коммиты с умом
Пишите к вашим коммитам короткие и осмысленные сообщения. В идеале они должны быть связаны с тикетами в вашей системе управления проектами. Это позволит легко найти соответствующую задачу и всю необходимую информацию по коммиту.
Например, если вы используете JIRA, начинайте каждый комментарий с префикса JIRA-тикетов. Так вы сможете перейти к задаче простым кликом и получить список всех относящихся к ней коммитов.
Совет 2. Gitflow: действуйте по плану
Если вы незнакомы с Gitflow, то обязательно загляните в руководство Atlassian или наш материал.
Это очень полезная штука, которая помогает придерживаться плана и держать проект в чистоте и порядке независимо от его размера. Использование единого соглашения облегчает работу в команде.
Когда проект поддерживает множество разработчиков, становится трудно отслеживать, где, когда и почему была развернута какая-то ветка. В продакшн может попасть то, что не должно там быть, особенно после мелких правок. Gitflow устанавливает четкие правила работы в git-репозитории проекта и позволяет избежать таких ошибок.
Совет 3. Создавайте пулл-запросы
Pull request, или запрос на слияние, – это простой способ сообщить вашим товарищам по команде, что функциональность, над которой вы работали, готова. Gitlab дает возможность уведомить об этом заинтересованных лиц.
Главная идея таких запросов – создать точку в git-репозитории, в которой можно обсудить конечный вариант новой фичи.
Есть еще один большой плюс. Когда ваш код мержит кто-то другой, знания и ответственность в отношении конкретной функции разделяются.
Совет 4. Поддерживайте чистоту в git-репозитории
Это простой способ изменить последний коммит. Вместо того, чтобы фиксировать новые изменения отдельно, вы просто объединяете их с предыдущими.
Git rebase
Rebasing (перебазирование или перемещение) позволяет сохранить в вашей feature-ветке ту же историю коммитов, что и в master. Это предотвратит опережение других веток и спасет от ужасных конфликтов слияния.
Внимание!
Совет 5. Версионируйте проект
Семантическое управление версиями – отличная практика, которая позволит навести порядок в вашем git-репозитории.
Выглядит это так: v Major.Minor.Patch, например, v3.5.2.
Вот пример версионированного проекта. В версии 3.3 появилась новая функция Test module. После минорного выпуска было 4 патча: обновления безопасности и конфиденциальности, а также фиксы багов.
Советы для PRO
Именование файлов (core.ignorecase)
По какой-то причине Mac OS по умолчанию не учитывает регистр в файловой системе. Это вызывает много проблем.
Например, в вашем проекте есть два файла: HelloController.php и helloController.php. На Mac OS все работает отлично, вы делаете коммит и отправляете изменения в репозиторий. Но на другой операционной системе появится сообщение об ошибке вида «HelloController.php not found».
Вы можете переименовать файл, но git этого не увидит, ведь по умолчанию он игнорирует регистр.
Эту опцию можно глобально отключить с помощью команды:
Файловый режим (core.fileMode)
Хотя по умолчанию git игнорирует регистр, он отслеживает режимы файлов. Если вы изменили права доступа к файлам, не изменив в них ни строчки, git все же покажет изменения.
Эту опцию можно отключить глобально, выполнив следующую команду:
Grumphp
Grumphp – это инструмент, который пропускает все изменения кода через набор тестов и проверяет, соответствуют ли они настроенным требованиям.
Щеночек счастлив!
Ура, вы спасли щеночка и сохранили чистоту и уют в вашем git-репозитории. Если у вас есть собственные приемы поддержания порядка, поделитесь ими в комментариях.
Шпаргалка по Git. Решение основных проблем
Восстановление накопленных изменений
В том случае, если изменения, внесённые пользователем, находятся в режиме накопления, применить их к ветке можно с помощью команды git stash apply. Также можно запустить git diff — эта команда поможет выявить различия. Для того, чтобы затем избавиться от накопленных данных, нужно запустить команду:
Если существует более одного накопления, найти нужное можно с помощью команды:
git stash list затем можно применить его, воспользовавшись его индексом:
Необходимо учитывать, что отсчёт индексов ведётся от нуля.
Восстановление удалённого тега
В том случае, если необходимо восстановить случайно удалённый тег, начать можно с его поиска:
После того, как нужный тег найден, его следует восстановить:
Восстановление удалённого файла
Если вы случайно удалили файл, его можно быстро восстановить:
Если требуется восстановить файл из конкретной временной точки истории коммитов, следует узнать хеш нужного коммита и запустить команду:
Восстановление удалённой ветки
С помощью комманды git reflog можно узнать хеш (SHA1) последнего коммита в удалённой ветке. Скопируйте этот хеш и используйте в команде:
После этого восстановить удалённую ветку можно будет вот такой командой:
Изменение сообщения коммита перед его отправкой
Сообщение можно изменить и напрямую с помощью команды
Изменение сообщения коммита после его отправки
Предупреждение: подобная насильная перезапись может привести к потери коммитов из внешней ветки, если с ней давно не было синхронизации, соблюдайте осторожность.
Использование алиасов команд в командной строке
Устали каждый раз печатать git status? Этой команде можно присвоить простой алиас, который проще и быстрее вбивать в git.
— теперь нужно писать только git st
Можно пойти дальше и присвоить алиасы более сложным командам:
Теперь алиас git logme будет выводить все наши коммиты.
Коммит в неправильную ветку
Нужно переключиться на новую ветку, которую вы забыли предварительно создать:
А затем переключиться к оригинальной ветке:
. и «откатиться» до последнего коммита, который нужно сохранить.
Чтобы это сделать, можно воспользоваться командой git log и сохранить хеш (SHA1) последнего коммита, который нужно оставить.. Например, это a31a45c.
Предупреждение: Убедитесь в том, что никто не отправлял коммиты в оригинальную ветку во время выполнения вышеописанных процедур, в противном случае эти изменения будут потеряны!
Обновление конкретного подмодуля
Чтобы обновить конкретный подмодуль в репозитории, нужно добавить путь к подмодулю:
Откат к конкретному коммиту в истории
Если вас не очень беспокоят изменения в локальном репозитории, то можно «откатиться» к конкретному коммиту в истории с помощью команды:
Эта команда установит HEAD на конкретный коммит. Также можно воспользоваться хешем коммита.
Отмена коммита до публикации изменений
Если вы сделали коммит, который впоследствии понадобилось отредактировать или полностью стереть, поможет команда git reset.
Будьте осторожны используя второй вариант, поскольку изменения ваших локальных файлов будут потеряны.
Чтобы сохранить сообщение коммита, наберите: :
Отмена коммита после отправки его в master-репозиторий
Рассмотрим процедуру возврата одного или нескольких коммитов, которые нужно стереть из удалённой ветки. Обозначить конкретный коммит можно с помощью его хеша:
Отмена только коммита, который является вторым после последнего:
Простая отмена последнего коммита:
Отмена локальных изменений файлов
Простейшим способом избавиться от нежелательных изменений для файлов и папок является восстановление состояния последнего коммита. Сделать это можно с помощью специальной команды:
Кроме того, можно восстановить конкретный путь к файлу:
Отображение всех коммитов одного файла
Аргумент —follow позволяет вывести все изменения над файлом, даже если в процессе работы он был переименован.
Отображения числа коммитов от каждого участника
Хотите узнать, сколько коммитов сделал каждый участник команды?
Отобразить коммиты, содержащие удалённые файлы
Узнать, в каких коммитах содержатся удалённые файлы, можно с помощью команды:
Она покажет список коммитов, в которых удалялись файлы.
Отсортировать коммиты по автору
Чтобы вывести список коммитов, отфильтрованных по автору, следует воспользоваться следующей командой:
Очистка всех скрытых состояний
Очистить все скрытые состояния можно следующей командой:
Переименование локальной и удалённой ветки
Предложим, у вас есть ветка «fix-bug25», которую вы захотели переименовать в «hotfix-users». Прежде всего, нужно будет изменить локальную ветку:
А затем — удалённую ветку: переименовать её напрямую нельзя, поэтому нужно будет её удалить, и затем опубликовать заново уже с новым именем. Прежде чем приступать к этим процедурам, следует убедиться, что никто из членов команды не работает с этой веткой! Удаляем ветку: git push origin :fix-bug25
А теперь заново публикуем её с новым именем: git push origin hotfix-users
Переименование тега
Чтобы переименовать существующий тег:
Перестать отслеживать существующие файлы
Если вы хотите перестать отслеживать файлы, которые уже есть в репозитории, но при этом желаете сохранить его локально, осуществите коммит изменений и запустите команду:
Она удалит изменённые файлы из зоны подготовленных файлов (staging area). Затем нужно запустить команду:
и отправить изменения.
Подготовка удалённых файлов
Чтобы подготовить к коммиту файлы и папки, которые были удалены локально, можно использовать специальную команду:
Если требуется подготовить только используемый в данный момент путь, воспользуйтесь командой
Поиск конкретного сообщения во всех коммитах
Чтобы найти конкретный текст сообщения коммита, соответствующий регулярному выражению, нужно воспользоваться командой
Пометить конфликтующий файл, как разрешённый
Чтобы пометить один или несколько конфликтующих файлов, как разрешённые, чтобы их можно было нормально изменять, воспользуйтесь командой:
Затем можно запустить git commit, чтобы разрешить конфликты и опубликовать изменения.
Просмотр всех неотправленных коммитов
Чтобы просмотреть все коммиты, которые ещё не были отправлены в соответствующие ветки, воспользуйтесь следующей командой:
Кроме того, можно использовать:
Просмотр старой ревизии файла
Существует возможность просмотреть содержимое файла в конкретный момент времени в прошлом. Для этого нужно использовать команду:
Публикация локальной ветки для удалённого редактирования
Если вы создали локальную ветку, и хотите, чтобы другие пользователи могли с ней работать, воспользуйтесь командой:
Теперь они тоже смогут вносить изменения в эту ветку.
Сброс локальной ветки до состояния удалённой
В том случае, если отсутствуют изменения, которые необходимо сохранить, сбросить локальную ветку до состояния удалённой можно с помощью двух простых команд.
Прежде всего нужно получить свежие обновления из удалённой ветки:
А затем нужно сообщить git, что локальную ветку следует «откатить» до состояния удалённой:
Синхронизировать ветку с master-репозиторием
Чтобы синхронизировать последние изменения в репозитории master (или с любой другой веткой, с которой вы работали) необходимо «перебазировать» локальную ветку. Предположим, вы работаете над веткой foobar:
А затем осуществляете «перебазирование»:
После этого будут применены коммиты origin из master. После разрешения конфликтов процесс можно продолжить с помощью команды git rebase —continue. Теперь можно продолжать работу над своей веткой или осуществить её слияние (merge) с главным репозиторием.
Слияние локальных изменений с другой веткой
Это можно сделать прямо в процессе стандартного слияния (merge). Вам стоит сохранить историю слияний используя флаг —no-ff, что означает no fast forward.
Перейдите в ветку, в которую будут вливаться изменения, убедитесь в её актуальности и запустите процесс:
Затем появится сообщение о коммите merge X into Y branch, после чего вы можете смело запушить ваше слияние.>
Совмещение двух и более коммитов
Если есть необходимость в совмещении двух последних коммитов, можно использовать команду
После её ввода появятся инструкции по выбору коммитов. В том случае, если необходимо совместить все коммиты с первым старейшим коммитов, то в первой строке нужно написать pick, а для всех остальных коммитов изменить букву на f. Подробнее здесь
Совмещение коммитов по конкретной функции для добавления в ветку релиза
Если вы решите совместить и опубликовать коммиты, то возникнет новый коммит в ветке релиза, поэтому история ветки конкретной функции останется неизменной.
Ниже представлен пример того, как достичь подобного эффекта:
В конечном итоге останется только один коммит в ветке релиза, а история изменений в ветке разработки конкретной функции останется нетронутой.
Создание новой ветки с изменениями текущей
Часто возникает ситуация, при которой пользователи начинают изменять файлы в ветке, чтобы что-то исправить, и лишь позднее вспоминают, что предварительно не создали новую ветку. К счастью, есть способ сделать это уже в процессе:
Эта команда перенесёт файлы из текущей ветки в новую, которую потом уже можно «закоммитить».
Убрать файл из буфера
Чтобы убрать добавленный по ошибке файл из буфера, нужно воспользоваться простой командой:
Удаление внешней ветки
Если вы хотите удалить ветку, введите команду:
Удаление неотслеживаемых файлов и папок
Чтобы удалить неотслеживаемые файлы и папки из рабочей копии наберите следующую команду:
Чтобы в принципе удалить их:
Подсказка: чтобы увидеть, какие файлы являются лишними, перед их непосредственным удалением, наберите:
Удаление старых веток, стёртых из внешнего репозитория
Если ветка удалена из внешнего репозитория, её также можно стереть из локального репозитория с помощью команды
Она удалит старую ветку под названием название-удалённой-ветки, которая уже была стёрта из внешнего репозитория, но всё ещё доступна локально в remotes/название-удалённой-ветки.
Удаление файла из git с сохранением его локальной копии
Для того, чтобы удалить файл из git, но сохранить его локально нужно использовать следующую команду:
Без Гита и жизнь не та
Получите практику в Git на курсах HTML Academy. Мы расскажем всё, что знаем сами, чтобы вы прокачали навыки в веб-разработке.