Обслуживание репозитория и восстановление данных
Изредка вам потребуется делать «уборку» — сделать репозиторий более компактным, очистить импортированный репозиторий от лишних файлов или восстановить потерянные данные. Данный раздел охватывает некоторые из этих сценариев.
Обслуживание репозитория
Время от времени Git выполняет автоматическую сборку мусора. Чаще всего эта команда ничего не делает. Однако, если у вас накопилось слишком много «рыхлых» объектов (не в pack-файлах), или, наоборот, отдельных pack-файлов, Git запускает полноценный сборщик — git gc (здесь «gc» это сокращение от «garbage collect», что означает «сборка мусора»). Эта команда выполняет несколько действий: собирает все «рыхлые» объекты и упаковывает их в pack-файлы; объединяет несколько упакованных файлов в один большой; удаляет недостижимые объекты, хранящиеся дольше нескольких месяцев.
Сборку мусора можно запустить вручную следующим образом:
Ещё одно действие, выполняемое gc — упаковка ссылок в единый файл. Предположим, репозиторий содержит следующие ветки и теги:
Восстановление данных
Ниже приведён пример, в котором мы сбрасываем ветку master с потерей данных до более раннего состояния, а затем восстанавливаем потерянные коммиты. Для начала, давайте посмотрим, как сейчас выглядит история изменений:
Теперь сбросим ветку master на третий коммит:
Итак, теперь два последних коммита по-настоящему потеряны — они не достижимы ни из одной ветки. Необходимо найти SHA-1 хеш последнего коммита и создать ветку, указывающую на него. Сложность в том, чтобы узнать этот самый SHA-1, ведь вряд ли вы его запомнили, да?
В нашем случае потерянный коммит указан после слов «dangling commit» («висячий коммит»). Его можно восстановить аналогичным образом, создав новую ветку, указывающую на этот SHA-1.
Удаление объектов
Git — замечательный инструмент с кучей классных возможностей, но некоторые из них способны стать источником проблем; например, команда git clone загружает проект вместе со всей историей, включая все версии всех файлов. Это нормально, если в репозитории хранится только исходный код, так как Git хорошо оптимизирован под такой тип данных и может эффективно сжимать их. Однако, если когда-либо в проект был добавлен большой файл, каждый, кто потом захочет клонировать проект, будет вынужден скачивать этот файл, даже если он был удалён в следующем коммите. Он будет в базе всегда, просто потому, что он доступен в истории.
Это может стать большой проблемой при конвертации Subversion или Perforce репозиториев в Git. В этих системах вам не нужно загружать всю историю, поэтому добавление больших файлов не имеет там особых последствий. Если при импорте из другой системы или при каких-либо других обстоятельствах стало ясно, что ваш репозиторий намного больше, чем он должен быть, то как раз сейчас мы расскажем, как можно найти и удалить большие объекты.
Предупреждаем: дальнейшие действия переписывают историю изменений. Каждый коммит, начиная с самого раннего, из которого нужно удалить большой файл, будет переписан. Если сделать это непосредственно после импорта, пока никто ещё не работал с репозиторием, то всё окей, иначе придётся сообщить всем участникам о необходимости перебазирования их правок относительно ваших новых коммитов.
Для примера добавим большой файл в тестовый репозиторий, удалим его в следующем коммите, а потом найдём и удалим его полностью из базы. Сначала добавим большой файл в нашу историю:
Упс, мы нечаянно. Нам лучше избавиться от этого файла:
git reflog
Основное назначение
Журнал ссылок используется главным образом для вызова следующих данных:
Это ярлык, эквивалентный следующей команде:
Другие распространенные примеры использования журнала ссылок см. на странице Переписывание истории.
Ссылки из журнала ссылок
Для вызова полного журнала ссылок выполните следующую команду:
Чтобы просмотреть журнал ссылок для конкретной ветки, передайте имя этой ветки команде git reflog show :
С помощью этого кода выводится журнал ссылок для git stash. Полученные указатели можно передавать другим командам Git:
С помощью этого кода выводится результат применения команды git diff, которая выполняет сравнение изменений stash@ <0>относительно указателя otherbranch@ <0>.
Журналы ссылок с заданным сроком действия
К каждой записи журнала ссылок привязана метка времени. Эти метки можно использовать в качестве токена qualifier в синтаксисе указателя на ссылку Git, чтобы фильтровать журналы ссылок Git по времени. Ниже в качестве примеров приводится несколько префиксов времени:
Префиксы времени можно комбинировать (например, 1.day.2.hours.ago ). Кроме того, возможно использование форм множественного числа (например, 5.minutes.ago ).
Указатели префиксов времени можно передавать другим командам Git.
В этом примере выполняется сравнение актуальной главной ветки с главной веткой по состоянию на 1 день назад. Эту функцию удобно использовать для просмотра изменений за определенный период времени.
Подкоманды и параметры конфигурации
В команде git reflog можно использовать несколько дополнительных аргументов, которые имеют статус подкоманд.
Просмотр: git reflog show
По умолчанию аргумент show передается неявным образом. Так, команда
Истечение срока действия: git reflog expire
Удаление: git reflog delete
Восстановление потерянных коммитов
Мы отправляем эти изменения и выполняем следующий код:
С появлением нового коммита журнал теперь имеет следующий вид:
На данном этапе выполним интерактивное перебазирование для главной ветки. При этом используем следующую команду:
После склеивания коммитов вывод команды git log примет следующий вид:
При анализе git log видно, что на данном этапе больше нет коммитов, отмеченных для склеивания. Но что делать, если необходимо обработать один из склеенных коммитов, например удалить связанные с ним изменения из истории? Для этого можно использовать журнал ссылок.
При выполнении команды сброса указатель HEAD переместится на коммит, в котором были добавлены изменения под названием «some WIP changes». При этом будут восстановлены другие склеенные коммиты.
Резюме
Мы кратко рассмотрели использование git reflog с другими командами Git, такими как git checkout, git reset и git merge. Дополнительные сведения см. на страницах этих команд. Более подробную информацию о ссылках и журнале ссылок см. здесь.
Готовы изучить Git?
Ознакомьтесь с этим интерактивным обучающим руководством.
Git reflog что это
The command takes various subcommands, and different options depending on the subcommand:
Reference logs, or «reflogs», record when the tips of branches and other references were updated in the local repository. Reflogs are useful in various Git commands, to specify the old value of a reference. For example, HEAD@ <2>means «where HEAD used to be two moves ago», master@
This command manages the information recorded in the reflogs.
The «expire» subcommand prunes older reflog entries. Entries older than expire time, or entries older than expire-unreachable time and not reachable from the current tip, are removed from the reflog. This is typically not used directly by end users — instead, see git-gc[1].
The «delete» subcommand deletes single entries from the reflog. Its argument must be an exact entry (e.g. » git reflog delete master@ <2>«). This subcommand is also typically not used directly by end users.
The «exists» subcommand checks whether a ref has a reflog. It exits with zero status if the reflog exists, and non-zero status if it does not.
OPTIONS
Options for show
Options for expire
Process the reflogs of all references.
Update the reference to the value of the top reflog entry (i.e. @<0>) if the previous top entry was pruned. (This option is ignored for symbolic references.)
If a reflog entry’s predecessor is pruned, adjust its «old» SHA-1 to be equal to the «new» SHA-1 field of the entry that now precedes it.
Prune any reflog entries that point to «broken commits». A broken commit is a commit that is not reachable from any of the reference tips and that refers, directly or indirectly, to a missing commit, tree, or blob object.
This computation involves traversing all the reachable objects, i.e. it has the same cost as git prune. It is primarily intended to fix corruption caused by garbage collecting using older versions of Git, which didn’t protect objects referred to by reflogs.
Do not actually prune any entries; just show what would have been pruned.
Print extra information on screen.
Options for delete
Git, я хочу все отменить! Команды исправления допущенных ошибок
Git — удобная, но довольно сложная система. Сложность, прежде всего, в том, что по невнимательности можно допустить ошибку, которую затем сложно или вообще невозможно исправить. Документация Git предоставляет описание множества команд, которые дают возможность исправить ошибку.
Но вся штука в том, что для исправления проблемы нужно знать точное название команды. И здесь у нас возникает типичная проблема курицы и яйца. В этой статье рассказывается о командах, которые помогают решить проблемные ситуации.
Черт, я сделал что-то не то. Дайте мне волшебную машину времени!
Эта команда позволяет восстановить случайно удаленные данные, откатив слияние, после которого случилась неприятность. refLog используется ну очень часто — давайте скажем спасибо тому, что предложил добавить эту команду.
Я сделал коммит, но сразу же заметил ошибку, ее нужно исправить!
NB! Никогда не изменяйте коммиты в публичной ветке. Применяйте команду лишь для коммитов в локальной ветке, иначе у вас будут проблемы.
Хочу изменить сообщение последнего коммита!
Это просто… глупые требования к оформлению сообщений.
Я случайно закоммитил в мастер, хотя это должен был в новую ветку!
Если вы уже закоммитили в публичную ветку, команды не сработают. В этом случае поможет git reset HEAD@ <укажите количество коммитов, на которое нужно вернуться>вместо HEAD
Ну вот, я ошибочно закоммитил не в ту ветку
Есть еще один способ, который использует большое количество разработчиков — это cherry-pick.
Мне нужно запустить diff, но ничего не получается
Если вы уверены в том, что изменения были внесены, но diff пустой, вполне может быть, что вы индексировали изменения через add. Поэтому стоит использовать специальный флаг.
В общем, это не баг, а фича, но она чертовски неочевидная ¯\_(ツ)_/¯
Мне срочно нужно отменить коммит, который сделан 5 коммитов назад
К счастью, не нужно отказываться назад на 5 коммитов, занимаясь копипастом старых и новых файлов. Отменить все это можно при помощи revert.
Кроме того, откатить можно не только коммит, но и целый файл. Правда, это уже будут другие команды…
Отменить изменения в файле
А вот и они, эти другие команды.
Когда я впервые нашел эту возможность, это было КРУТО, КРУТО, К-Р-У-Т-О. Но если задуматься — почему именно checkout — лучший вариант для отмены изменений в файле? :shakes-fist-at-linus-torvalds:
Спасибо Eric V. За этот способ. И все жалобы по поводу использования sudo адресуйте ему.
Если вам нужно обнулить изменения и полностью откатиться до исходной версии, то можно попробовать сделать именно так. Но помните — эти команды разрушительны и необратимы.
Внимание! Эта статья не является исчерпывающим руководством. И да, есть и другие способы сделать то же самое, причем еще лучше. Но я пришел именно к этим вариантам методом проб и ошибок. Потом у меня появилась сумасшедшая идея поделиться находками. Берите это или уходите!
Даниил Пилипенко, директор центра подбора IT-специалистов SymbioWay и евангелист бэкенд-направления онлайн-университета Skillbox, дополнил перевод мнением о Git и его актуальности для разработчиков.
Git появился в 2005-ом году, и он далеко не сразу занял рынок. Помню, когда мы ещё в 2008-ом году в команде разработчиков внедряли SVN. И даже в 2012-ом одна близкая ко мне компания усиленно внедряла Mercurial. С годами для многих стало очевидным, что Git — это лучшая система контроля версий, и её теперь используют практически все разработчики.
Если вы начинающий разработчик и собираетесь устраиваться на работу, обязательно изучите Git! Вы должны знать, что такое система контроля версий и зачем она нужна, что такое коммит, ветка, как клонировать репозиторий и отправлять сделанные изменения на сервер, как получать новые изменения с сервера, как делать merge, какие бывают виды “reset”. Поначалу эта тема вам может показаться непонятной и сложной, но вам нужно лишь привыкнуть пользоваться Git, и отвыкнуть вы уже не сможете.
Объяснение полезных Git команд с помощью визуализации
Это перевод замечательной статьи Лидии Холли, где она объясняет основные гит команды в очень понятном виде с помощью визуализаций.
Я подумала, что это будет идеальный вариант для создания наглядных примеров наиболее распространенных и полезных команд! Многие из описываемых мной команд имеют необязательные аргументы, которые вы можете использовать для изменения их поведения. В моих примерах я расскажу о поведении команд по умолчанию, не добавляя (слишком много) параметров конфигурации! 😄
Merge
Наличие нескольких веток чрезвычайно удобно для того, чтобы новые изменения были отделены друг от друга, а также чтобы вы случайно не запушили несанкционированные или поврежденные изменения в продакшин. Как только изменения будут одобрены, мы хотим получить эти изменения в нашей прод ветке!
Fast-forward merge когда текущая ветка не имеет дополнительных коммитов по сравнению с веткой, которую мы мержим. Git у нас ленив и сначала попытается выполнить самый простой вариант: Fast-forward! Этот тип менжа не создает новый коммит, а скорее объединяет коммит(ы) в ветку, которую мы объединяем прямо в текущей ветке
Хорошо, если ваша текущая ветка не имеет каких-либо дополнительных коммитов по сравнению с веткой, которую вы хотите смержить, но, к сожалению, это случается редко! Если мы зафиксировали изменения в текущей ветке, которых нет в ветке, которую мы хотим объединить, git выполнит объединение без fast-forward merge. При слиянии без fast-forward Git создает новый коммит мержа в активную ветку. Родительский коммит указывает на активную ветку и ветку, которую мы хотим объединить!
Merge конфликты
Хотя Git хорошо решает, как объединять ветки и добавлять изменения в файлы, он не всегда может принять это решение сам по себе. Это может произойти, когда две ветки, которые мы пытаемся смержить, имеют изменения в одной строке в одном и том же файле, или если одна ветка удалила файл, который изменила другая ветка, и так далее.
В этом случае Git попросит вас помочь решить, какой из двух вариантов мы хотим сохранить. Допустим, что в обеих ветках мы отредактировали первую строку в файле README.md.
При попытке объединить ветки, Git покажет вам, где происходит конфликт. Мы можем вручную удалить изменения, которые не хотим сохранять, сохранить изменения, снова добавить файл и закоммитить изменения.
Rebase
Git rebase копирует коммиты из текущей ветки и помещает эти скопированные коммиты поверх указанной ветки.
Отлично, теперь у нас есть все изменения, которые были сделаны в master ветке и в dev ветке. 🎊
Большая разница по сравнению с мержем заключается в том, что Git не будет пытаться выяснить, какие файлы сохранить и не сохранить. В ветке, которую мы обновляем, всегда есть последние изменения, которые мы хотим сохранить! Таким образом, вы не столкнетесь ни с какими мерж конфликтами и у вас будет хорошая линейная история.
Этот пример показывает rebase в master ветке. Однако в больших проектах вы обычно не захотите этого делать. Git rebase изменяет историю проекта, поскольку для скопированных коммитов создаются новые хэши.
Rebase отлично подходит, когда вы работаете над feature branch, а master ветка была обновлена. Вы можете получить все обновления в своей ветке, которые предотвратят будущие merge конфликты 😄
Interactive Rebase
Перед rebas’ом коммитов мы можем их изменить! 😃 Мы можем сделать это с помощью Interactive Rebase. Interactive Rebase также может быть полезен для ветки, над которой вы сейчас работаете, и хотите изменить некоторые коммиты.
Есть 6 действий, которые мы можем выполнить над коммитами, которые мы rebas’им:
Таким образом, мы можем иметь полный контроль над нашими коммитами. Если мы хотим удалить коммит, мы можем просто drop’нуть его.
Или, если мы хотим объединить несколько коммитов вместе, чтобы получить более чистую историю, нет проблем!
Interactive rebasing дает вам большой контроль над коммитами, которые вы пытаетесь rebase’нуть, даже в текущей активной ветке.
Reset
git reset избавляет от всех текущих промежуточных файлов и дает нам контроль над тем, куда должен указывать HEAD.
Soft reset
Soft reset перемещает HEAD к указанному коммиту (или индексу коммита по сравнению с HEAD), не избавляясь от изменений, которые были внесены в коммиты позже.
Набрав git status, вы увидите, что у нас все еще есть доступ ко всем изменениям, которые были сделаны во время предыдущих коммитов. Это здорово, так как это означает, что мы можем исправить содержимое этих файлов и закоммитить их позже.
Hard reset
Иногда мы не хотим сохранять изменения, внесенные некоторыми коммитами. В отличие от soft reset, нам не нужно больше иметь к ним доступ. Git должен просто сбросить свое состояние обратно туда, где он был в указанном коммите: это даже включает изменения в вашей working directory и stage файлах! 💣
Git отменил изменения, которые были внесены в 9e78i и 035cc, и сбросил свое состояние до того, где он был при коммите ec5be.
Revert
Cherry-pick
Когда определенная ветка содержит коммит, который внес изменения, которые нам нужны в нашей активной ветке, мы можем черипинуть коммит в нашу ветку. Cherry-pick создает новый коммит в нашей активной ветке, который содержит изменения, которые были в чери-пикнутом коммите.
Fetch
Если у нас есть remote Git ветка, например ветка на Github, может случиться так, что remote ветка имеет коммиты, которых нет у текущей ветки! Возможно, другая ветка была объединена, или ваш коллега добавил hot fix и так далее.
Мы можем получить эти изменения локально, выполнив git fetch на remote ветке. Это никак не влияет на вашу локальную ветку: fetch просто загружает новые данные.
Reflog
Все делают ошибки, и это совершенно нормально! Иногда может показаться, что вы испортили свой репозиторий Git настолько сильно, что просто хотите полностью его удалить.
Если вы допустили ошибку, вы можете легко отменить ее, сбросив HEAD на основе информации, которую нам предоставляет reflog.
Как мы видим, последнее действие было перенесено в рефлог.
