Какая команда git вносит файл в stage
Обновлено: 06.07.2024
Мне трудно понять мерзавца, так как я не мог найти значение слов, используемых для действий. Я проверил в словаре значение «stage», и ни одно из значений не было связано с концепциями управления исходным кодом.
Что означает «этап» в контексте git?
У Git действительно есть свой словарный запас. И так как каждая инструкция сформулирована в специальном словаре, трудно начать. «Стадия» - это сделать git add file.ext для определенного файла или git add . повлиять на все измененные и неотслеживаемые файлы. Файлы, которые были добавлены таким образом, называются «подготовленными», и они будут включены в следующий «коммит». Фиксация - это снимок вашей работы, созданный, например, с помощью git commit -m "I wrote something" . Git трудно понять, потому что там нет концептуального учебника. Все проходят через ненужные детали. Вы хотели удалить тег "терминология" из этого вопроса? Мне кажется, это совершенно правильный тег. По какой-то причине я лучше всего понял важность постановки из этого ответа в Quora: qr.ae/TbSK2IЧтобы поставить файл просто подготовить его тонко для фиксации. Git с его индексом позволяет вам фиксировать только те части изменений, которые вы сделали со времени последнего коммита. Допустим, вы работаете над двумя функциями - одна закончена, а другая все еще требует определенной работы. Вы хотели бы сделать коммит и вернуться домой (наконец, 5 часов!), Но не хотели бы фиксировать части второй функции, которая еще не сделана. Вы ставите части, которые, как вы знаете, принадлежат первой функции, и делаете коммит. Теперь ваш коммит - это ваш проект с первой функцией, а вторая все еще находится в стадии разработки в вашем рабочем каталоге.
Поскольку до сих пор все отвечали на это «формальным» способом, позвольте мне сделать это с помощью альтернатив, чтобы улучшить обучение силой метафор.
Таким образом, область подготовки выглядит так:
- кеш файлов, которые вы хотите зафиксировать
- не серия труб, а самосвал, готовый перенести работу, в которую вы его загружаете, в хранилище
- волшебное место, где выбранные файлы будут превращены в камень с помощью вашего волшебства и могут быть волшебным образом перенесены в хранилище по вашей прихоти
- дорога из желтого кирпича для файлов, чтобы они благополучно отправлялись в хранилище (или отваливались, если хотите вернуться)
- вымышленное место в морском порту, где файлы получают пару цементных башмаков, а затем выбрасывают в море хранилища
- Приемная в библиотеке, вы кладете туда файлы для библиотекаря, чтобы подготовить для подачи в библиотеку
- ящик, в который вы кладете вещи перед тем, как засунуть их под кровать, где ваша кровать - это хранилище коробок, в которые вы ранее положили вещи
- загрузочный отсек файлов перед его поступлением в хранилище хранилища с загрузчиком мощности
- фильтр электрической кофеварки, если файлы похожи на кофейный порошок, то сохраненные файлы - это заваренный кофе
- в офисе Скруджа МакДака рядом с хранилищем, файлы похожи на монеты, прежде чем они попадают в хранилище его огромной корзины для денег
- зоомагазин, как только вы приносите домашнее животное домой, вы преданы
Это волшебно !
Постановка - это шаг перед процессом фиксации в git. То есть фиксация в git выполняется в два этапа: подготовка и фактическая фиксация.
Пока набор изменений находится в промежуточной области, git позволяет вам редактировать его по своему усмотрению (заменять промежуточные файлы другими версиями промежуточных файлов, удалять изменения из промежуточной стадии и т. Д.).
Время сломанной метафоры:
Рассмотрим сценарий, в котором вы вызываете грузчиков, чтобы доставить ваши вещи из старой квартиры в новую. Прежде чем сделать это, вы изучите свои вещи, решите, что взять с собой, а что выбросить, упаковать в мешки и оставить в главном коридоре. Грузчики просто приходят, забирают (уже упакованные) сумки из прихожей и перевозят их. В этом примере все до тех пор, пока грузчики не получат ваши вещи, - это постановка: вы решаете, что куда идти, как упаковать его и так далее (например, вы можете решить, что половина ваших вещей будет выброшена до того, как грузчики даже доберутся до места - это часть постановки).
С технической точки зрения, подготовка также поддерживает транзакции, разделяя все операции на то, что может дать сбой (подготовка), а что не может (принятие):
Фиксация в git осуществляется транзакционно, после того, как подготовка прошла успешно. Несколько этапов подготовки могут завершиться неудачно (например, вам нужно выполнить фиксацию, но ваш жесткий диск заполнен на 99,9999%, а у git нет места для выполнения фиксации). Это не удастся подготовить (ваш репозиторий не будет поврежден при частичной фиксации), и процесс подготовки не повлияет на вашу историю фиксации (он не повредит ваше хранилище в случае ошибки).
Подготовить файл - значит подготовить его к коммиту. Поскольку git предоставляет это действие пользовательскому элементу управления, он позволяет вам создавать частичные коммиты или изменять файл, ставить его, снова модифицировать и только фиксировать или возвращать к исходной модификации.
Постановка позволяет вам лучше контролировать, как именно вы хотите приблизиться к управлению версиями.
Чтобы добавить к другим отличным ответам, вот откуда происходит название «этап»:
Я проверил словарь на предмет значения стадии, и ни одно из значений не было связано с концепциями контроля источников.
На английском языке «на сцену» может означать
организовать и принять участие (публичное мероприятие): сторонники ОДС провели демонстрацию в Софии
Название «подготовка» для функции git происходит от этого значения: при подготовке вы готовите и организуете коммит. Конечно, совершить не совсем такой же , как производительность, но это важное событие в VCS :-).
В рамках данного урока рассмотрим вопросы, касающиеся добавления, удаления и переименования файлов в git репозитории.
Добавление файлов в git репозиторий
Создайте в каталоге файл README.md любым удобным для вас способом, мы сделаем это с помощью команды touch .
Теперь проверим состояние отслеживаемой директории.
Как вы можете видеть: в рабочей директории есть один неотслеживаемый файл README.md . Git нам подсказывает, что нужно сделать для того, чтобы начать отслеживать изменения в файле README.md : необходимо выполнить команду git add , сделаем это.
Посмотрим ещё раз на состояние.
Видно, что информация о появлении нового файла попала в stage . Для того чтобы это изменение зафиксировалось в репозитории необходимо выполнить команду git commit .
Теперь в рабочей директории и в stage нет объектов, информацию об изменении которых необходимо внести в репозиторий.
В репозиторий был сделан один коммит.
Удаление файлов из git репозитория и из stage
Удаление файла из stage
Вначале разберемся со stage . Создадим ещё один файл.
Внесем изменения в README.md .
Информацию об этом также отправим в stage .
Посмотрим на состояние stage .
Теперь посмотрим на состояние рабочей директории и stage .
Удаление файлов из git репозитория
Удалим файл main.c из рабочей директории.
Уведомим об этом систему git .
Теперь в репозитории остался только один файл README.md .
Удалим файл из репозитория.
Файла main.c больше нет в репозитории.
Его также нет и в рабочем каталоге.
Удалите файл README.md из репозитория самостоятельно.
Переименование файлов в git репозитории
Первый способ. Создадим файл test_main_file.c и добавим его в репозиторий.
Содержимое репозитория после этого будет выглядеть так.
Переименуем его на test_main.c .
Сделаем это в рабочей директории.
Теперь отправим изменение в репозиторий.
В репозитории и в рабочей директории будет находится только файл test_main.c .
Второй способ.
В рамках второго способа рассмотрим работу с командой git mv . Переименуем файл test_main.c в main.c . Текущее содержимое репозитория и рабочего каталога.
Переименуем файл test_main.c на main.c средствами git .
Имя файла изменилось как в репозитории так и в рабочем каталоге.
Прежде чем мы начнем, важно знать, что как списки изменений IntelliJ IDEA, так и Git staging позволяют закоммитить часть файла, целый файл или несколько файлов в Git. То, как они этого достигают, немного отличается, но конечный результат тот же. Список изменений IntelliJ IDEA работает с понятием диапазона в вашем контенте. Все изменения в этом диапазоне будут частью коммита. Git staging использует стандартное для git понятие staging области (также известное как «index»).
Оба варианта: IntelliJ IDEA Changelists и Git Staging доступны из Commit окна инструментов. Из IntelliJ IDEA 2020.1 вы можете переключиться на использование этого немодального окна Commit с помощью ⌘, в macOS или Ctrl + Alt + S в Windows / Linux, чтобы отобразить Preferences/Settings. Оттуда введите commit и установите флажок «Use non-model commit interface». Вы также можете использовать ⌘⇧A (macOS) или Ctrl + Shift + A (Windows / Linux) для поиска действий и ввести «Commit». Затем вы можете получить к нему доступ, нажав ⌘0 в macOS или Alt+ 0 в Windows и Linux.
Наконец, прежде чем мы начнем сравнение, вы не можете использовать списки изменений IntelliJ IDEA и промежуточную область Git одновременно. Вы можете переключаться между ними, но не можете использовать их одновременно. Начнем с Changelists IntelliJ IDEA.
Что такое «Список изменений IntelliJ IDEA»?
До выпуска 2020.3 списки изменений IntelliJ IDEA были единственным способом закоммитить изменения в вашем репозитории Git.
Списки изменений IntelliJ IDEA предназначены не только для Git, они для любой поддерживаемой системы VCS, но в этом блоге мы сосредоточимся на Git, чтобы мы могли сравнить их с новой функциональностью Git staging.
Коммит всего файла
IntelliJ IDEA всегда предоставляет вам список изменений по умолчанию, и при изменении файла файл будет отображаться в списке изменений по умолчанию с флажком, который не установлен:
Оттуда, если вы хотите выбрать весь файл для коммита, вы можете установить флажок слева от имени файла:
Это означает, что, когда вы коммитите свои файлы в Git, все изменения в выбранном вами файле будут добавлены, а затем сохранены в git. IntelliJ IDEA запускает за вас как команду, так git add так и команду git commit .
Коммит части файла
В качестве альтернативы, если вы хотите закоммитить часть файла, а не весь, вы можете дважды щелкнуть по имени файла в Default Changelist (списке изменений по умолчанию), чтобы открыть представление diff. Это представление показывает последнюю известную версию Git слева, а вашу локальную копию справа с выделенными синим цветом изменениями, которую вы можете редактировать. Вы можете установить флажки рядом с каждым изменением кода, которое вы внесли справа, чтобы сказать, что вы хотите закоммитить изменения только в этом диапазоне, а не во всем файле.
Обратите внимание, что если вы выбираете только часть файла для коммита, как в этом примере, Default Changelist будет указывать, что файл будет частично закоммитен, с помощью линии внутри чекбокса рядом с именем файла в Default Changelist, как вы можете видеть выше.
Совет: Вы также можете использовать ⌘D или Ctrl + D, чтобы открыть представление diff из окна инструмента commit.
Отмена изменений
В представлении diff вы также можете отменить изменения индивидуально, используя стрелку >> на файле слева, чтобы отменить изменения в вашем локальном файле. В этом случае правая часть обновится, чтобы отразить ваши изменения. Если вы допустили ошибку, вы можете отменить изменение или использовать локальную историю, чтобы вернуть свои изменения.
Вы также можете откатить весь файл, щелкнув его правой кнопкой мыши и выбрав Rollback.
Несколько Changelists
Список изменений по умолчанию (Default Changelist) в IntelliJ IDEA - это только часть истории. IntelliJ IDEA поддерживает несколько списков изменений. Допустим, у вас есть изменения, которые не следует закоммитить, вы можете переместить их в отдельный список изменений. Списки изменений в IntelliJ IDEA используются для группировки изменений. Вы можете назначить только один Changelist за раз. Итак, чтобы создавать группы изменений одновременно, вам нужно создать несколько списков изменений. Полезно называть списки изменений в соответствии с функцией или ошибкой, к которой они относятся. Это поможет вам отслеживать, как следует разбивать коммиты на списки изменений.
Чтобы создать несколько списков изменений, вы можете щелкнуть правой кнопкой мыши на Default Changelist и выбрать «New Changelist»:
Перемещение изменений между списками изменений
Вы также можете перемещать файлы между списками изменений (Changelists). Вы можете переместить весь файл в новый список изменений и создать этот новый список изменений, если он еще не существует в рамках этого действия. Для этого вы можете щелкнуть правой кнопкой мыши файл в списке изменений в окне Commit и выбрать «Move to Another Changelist». Вам будет предложено выбрать список изменений, если он существует, или создать список изменений, если его нет. Когда вы создаете новый список изменений, вы можете дополнительно установить для него значение «Active». Это означает, что все будущие изменения будут назначены этому Changelist.
В этом примере все будущие изменения будут теперь назначены нашему списку изменений DateFormat, потому что мы установили его как «Активный» при его создании.
В диалоговом окне «New Changelist» есть флажок, который называется «Track context». Если вы работаете с задачами и контекстами и подключили IntelliJ IDEA к соответствующему стороннему приложению, вы можете использовать этот флажок, чтобы заставить IntelliJ IDEA управлять контекстом задачи.
Помимо перемещения целых файлов между списками изменений, вы также можете перемещать отдельные изменения в файле между списками изменений. Это особенно полезно, если вы работаете над изменениями, которые влияют на один файл, но вы хотите разделить коммиты по причинам, о которых мы говорили ранее. Для того, чтобы присвоить некоторые, но не все изменения в файле на другую группу изменений, щелкните правой кнопкой мыши на изменение в представлении diff в Your version на правой стороне. Затем вы можете выбрать «Move to another changelist». Вы также можете использовать клавиши ⇧⌘M в macOS или Alt + Shift + M в Windows и Linux.
Вы также можете перемещать изменения между списками изменений, используя цветные полосы в gutter:
Как сделать Changelist активным
Наконец, мы уже показали вам, как сделать новый список изменений активным, но стоит упомянуть, что IntelliJ IDEA необходимо знать, какой список изменений использовать для новых изменений; вам всегда нужен один активный список изменений. Вы можете выбрать, какой список изменений является активным, если у вас их несколько, щелкнув правой кнопкой мыши список изменений и выбрав «Set Active Changelist». Если вы не видите эту опцию, это потому, что выбранный вами Changelist уже является активным Changelist.
Когда вы коммитите какие-либо новые изменения, они по умолчанию будут помещены в ваш активный список изменений IntelliJ IDEA Changelist.
Коммит ваших изменений в Git
Теперь, когда у вас есть списки изменений IntelliJ IDEA и ваши изменения разделены так, как вы хотите, вы готовы закоммитить их в Git. Вы можете увидеть, что будет закоммитено в Git, в окне «Commit».
Когда вас это устраивает, вы можете использовать ⌘K в macOS или Ctrl + K в Windows и Linux, чтобы открыть окно Commit. Перед тем, как нажать «Commit», вам необходимо ввести комментарий к коммиту. После того, как вы это сделаете и нажмете Commit, чтобы закоммитить их в истории Git локально, IntelliJ IDEA выполнит две команды git:
git add
git commit
Что такое Git Staging?
IntelliJ IDEA 2020.3 представила поддержку Git staging. По умолчанию он не включен, но самый быстрый способ включить его - это использовать команду Find Actions ( ⇧⌘A в macOS или Ctrl + Shift + A в Windows и Linux) и ввести git staging. Git staging - это нативный для git способ коммита изменений файлов в репозитории git.
Затем вы можете включить его:
Вы также можете включить Git staging из диалогового окна Settings/Preferences с помощью команд ⌘ в macOS или Ctrl + Alt + S, а затем введя git staging.
С помощью Git staging процесс коммита управляется в два этапа. Когда вы обрабатываете файл или его часть, IntelliJ IDEA запускает команду git add для внесения изменений. Когда вы впоследствии закоммитите эти файлы или некоторые изменения файла, IntelliJ IDEA запускает команду git commit . Конечный результат тот же, однако с Git staging вы можете воспользоваться преимуществами добавления ваших изменений перед их коммитом, если вы более знакомы с этой моделью.
Папки Staged и Unstaged
С Git Staging вы увидите две папки, а не одну как в IntelliJ IDEA Changelist в окне Commit. Каждое изменение, которое вы вносите в свой файл, представляет собой разницу между вашим локальным файлом и HEAD. Папка Unstaged, где все ваши изменения будут появляться на начальном этапе. Чтобы включить изменения в следующий коммит, вам необходимо переместить его из Unstaged папки в Staged папки. Это означает, что IntelliJ IDEA выполняет команду git add для всех изменений в файле.
Staging - перемещение файла из папки Unstaged в папку Staged
Когда вы вносите изменения в файл, они сначала появятся в вашей папке Unstaged как изменения, которые вы можете подготовить к коммиту (stage). Вы можете подготовить весь файл, перетащив его в папку Staged, используя значок + в дереве или щелкнув правой кнопкой мыши и выбрав +Stage. IntelliJ IDEA запустит команду git add , когда вы выполните эти действия:
Git add изменяет содержимое файла в индексе (поэтапное содержимое). Если вы впоследствии измените контент внутри того же диапазона, он не будет закоммитен, пока не будет помещен в папку Staged. Вы можете использовать Staged область, чтобы изменить то, что будет закоммитено, независимо от любых изменений в локальных файлах. С помощью IntelliJ Changelists любое изменение внутри того же диапазона будет закоммитено.
Staging - перемещение части файла из папки Unstaged в папку Staged
Кроме того, вы можете добавить часть файла, дважды щелкнув файл в папке Unstaged и используя стрелки <> на Staged области слева:
Вы также можете откатить весь файл, выбрав его в области Unstaged и выбрав «Rollback» (или «Revert» до версии 2021.1»). Это откат файла до состояния в индексе, а не в HEAD.
Давайте посмотрим на эту функциональность в Staged области. Изменения в Staged области означают, что IntelliJ IDEA выполнила операцию git add для изменения файла.
Unstaging - перемещение файла из папки Staged в папку Unstaged
Вы можете передумать и решить, что хотите отменить изменения (Unstage) файла целиком. Как при выполнении Staging для файла, вы можете перетащить его из Staged папки в Unstaged папку, нажав значок * - ** в дереве, или правой кнопкой мыши и выбрав «Unstage»:
Когда вы Unstage файл или часть файла, IntelliJ IDEA запускает команду git reset для изменения файла.
Unstaging - перемещение части файла из папки Staged в папку Unstaged
Вы также можете отменить изменение в файле, если вам нужно. Чтобы сделать это, вам нужно открыть в представлении diff файл, который содержит изменения, которые вы хотите убрать из папки Staged. Затем вы можете использовать стрелки >> в staged части слева, чтобы отменить изменение (Unstage). Это приведет к отмене этого конкретного изменения, и снова IntelliJ IDEA запустит команду Git, чтобы отразить изменение. Вы также можете ввести текст в редакторе, если хотите.
Staging и Unstaging отдельных изменений с помощью значков в Gutter
Вы также можете использовать значки Gutter в IntelliJ IDEA для внесения отдельных изменений.
Когда вы кликните на сплошную цветную панель, вы можете выбрать внесение изменений (Staging), панель изменит вид после добавления изменений. Нажав на панель в gutter, вы сможете отменить эти изменения.
Коммит изменений
Если Git Staging включен, ваша коммит будет состоять из изменений (различий), которые есть в вашей Staging папке. Если вас они устраивают, вы можете использовать команду ⌘K (macOS) или Ctrl + K (Windows / Linux) для открытия окна Commit. Затем вы можете ввести комментарий к коммиту и нажать Commit, чтобы закоммитить выбранные вами изменения в Git. Кроме того, вы можете использовать команду ⌘⏎ (macOS) или Ctrl + Enter (Windows / Linux), чтобы закоммитить изменения. После чего IntelliJ IDEA выполнит необходимые команды Git для выбранных вами изменений.
Затем вы можете продолжить и выполнить push изменений в удаленный репозиторий, если хотите.
Резюме
Вам решать, какой подход вы предпочитаете. Оба они позволяют достичь одного и того же результата немного по-разному.
Changelists фокусируется на диапазонах в вашем контенте, то есть любые изменения в этом диапазоне в вашем файле включаются в коммит.
Git Staging фокусируется на создании коммита моментального снимка staging области. Staged контент эффективно блокируется. Вы можете приступить к редактированию файла, даже если он был помещен в папку Staged; Staged контент не изменится. Это позволяет вам готовить коммиты поэтапно.
Команда git stash позволяет на время «сдать в архив» (или отложить) изменения, сделанные в рабочей копии, чтобы вы могли применить их позже. Откладывание изменений полезно, если вам необходимо переключить контекст и вы пока не готовы к созданию коммита.
Откладывание кода
Команда git stash сохраняет неподтвержденные изменения (индексированные и неиндексированные) в отдельном хранилище, чтобы вы могли вернуться к ним позже. Затем происходит откат до исходной рабочей копии. Например:
Теперь вы можете вносить изменения, создавать новые коммиты, переключаться между ветками и выполнять другие операции Git. По необходимости отложенные изменения можно будет применить позже.
Отложенные изменения сохраняются в локальном репозитории Git и не передаются на сервер при выполнении команды push.
Применение отложенных изменений
Чтобы применить ранее отложенные изменения, воспользуйтесь командой git stash pop :
При извлечении отложенных изменений они удаляются из набора и применяются к рабочей копии.
Вы также можете применить изменения к рабочей копии, не удаляя их из набора отложенных изменений. Для этого воспользуйтесь командой git stash apply :
Это полезно, если вам нужно применить одни и те же отложенные изменения к нескольким веткам.
Теперь вы умеете выполнять основные операции с отложенными изменениями. Однако необходимо помнить о следующей особенности команды git stash : по умолчанию Git не создает отложенные изменения для неотслеживаемых или игнорируемых файлов.
Откладывание неотслеживаемых или игнорируемых файлов
По умолчанию команда git stash создает следующие отложенные изменения:
- изменения, добавленные в раздел проиндексированных файлов (индексированные изменения);
- изменения в файлах, отслеживаемых Git в настоящее время (неиндексированные изменения).
При этом следующие файлы отложены не будут:
- новые файлы в рабочей копии, которые еще не были проиндексированы; файлы.
Поэтому если в приведенный выше пример добавить третий файл — неиндексированный (т. е. без выполнения команды git add ), при выполнении команды git stash этот файл не будет отложен.
Запуск git stash с параметром -u (или --include-untracked ) позволяет отложить неотслеживаемые файлы:
Можно также отложить изменения, внесенные в игнорируемые файлы. Для этого используйте параметр -a (или --all ) при запуске команды git stash .
Управление несколькими наборами отложенных изменений
Вы можете создать несколько наборов отложенных изменений. Команду git stash можно выполнить несколько раз, после чего можно будет просмотреть список созданных наборов с помощью команды git stash list . По умолчанию отложенные изменения имеют пометку WIP (незавершенная работа) наверху ветки или коммита, в которых они были отложены. Возможно, со временем вам будет трудно вспомнить содержимое каждого набора:
По умолчанию команда git stash pop применяет последний набор отложенных изменений: stash@
Если вам нужно применить определенный набор ранее отложенных изменений, укажите его идентификатор в качестве последнего аргумента. Это можно сделать так:
Просмотр различий между наборами отложенных изменений
Выполните команду git stash show , чтобы просмотреть сводные данные по набору отложенных изменений:
Или укажите параметр -p (или --patch ), чтобы просмотреть разницу между наборами изменений:
Частичное откладывание изменений
При желании можно отложить один файл, несколько файлов или отдельные изменения в файлах. Если передать команде git stash параметр -p (или --patch ), она будет выполняться для каждого измененного участка кода в рабочей копии, запрашивая подтверждение на откладывание:
Нажмите ?, чтобы увидеть полный список команд для работы с участками кода. Часто используются следующие команды:
| Команда | Описание |
|---|---|
| / | искать участок кода по регулярному выражению |
| ? | Справка |
| n | не откладывать участок кода |
| q | выйти (все выбранные участки будут отложены) |
| s | разделить участок кода на меньшие части |
| y | отложить участок кода |
Специальной команды для прерывания не предусмотрено, но прекратить процесс откладывания можно, нажав CTRL-C (сигнал SIGINT).
Создание ветки из отложенных изменений
Если изменения в ветке отличаются от отложенных изменений, операции извлечения или применения последних могут привести к конфликтам. Вместо этого вы можете создать новую ветку с помощью команды git stash branch и применить отложенные изменения к ней. Это можно сделать так:
Новая ветка создается на основе коммита, изменения в котором использовались при создании набора. Затем к этой ветке применяются извлеченные изменения.
Удаление отложенных изменений
Удалить определенный набор отложенных изменений можно с помощью команды git stash drop :
Следующая команда удаляет все наборы отложенных изменений:
Принцип работы команды git stash
Если вы просто хотели получить информацию о том, как использовать команду git stash , то дальше читать необязательно. Однако если вам необходимо узнать о принципах работы Git (и git stash ) — продолжайте чтение!
Наборы отложенных изменений шифруются в репозитории в виде коммитов. Специальная ссылка в .git/refs/stash указывает на последний созданный набор отложенных изменений, а для ранее созданных наборов изменений используются ссылки из журнала ссылок stash . Именно поэтому для просмотра наборов отложенных изменений используется ссылка stash@ : при этом вы ссылаетесь на n-ю запись в журнале ссылок stash . Поскольку набор отложенных изменений представляет собой обычный коммит, его можно просмотреть с помощью команды git log :
В зависимости от отложенных элементов выполнение команды git stash создает два или три новых коммита. На приведенной выше схеме создаются следующие коммиты:
- stash@ — новый коммит для хранения отслеживаемых файлов, которые находились в рабочей копии при запуске команды git stash ;
- первый родитель stash@ — существующий коммит, который при запуске команды git stash находился в ветке, на которую указывал HEAD;
- второй родитель stash@ — новый коммит, выступавший в роли индекса при запуске команды git stash ;
- третий родитель stash@ — новый коммит, представляющий неотслеживаемые файлы, которые находились в рабочей копии при запуске команды git stash . Третий родитель создается, только если:
- рабочая копия действительно содержит неотслеживаемые файлы, и
- вы указали параметр --include-untracked или --all при вызове команды git stash .
Ниже показано, как команда git stash шифрует рабочий каталог и раздел проиндексированных файлов в виде коммитов:
Перед откладыванием изменений в рабочем каталоге могут находиться изменения отслеживаемых, неотслеживаемых и игнорируемых файлов. Часть этих изменений также может быть проиндексирована в разделе проиндексированных файлов.
При выполнении команды git stash все изменения отслеживаемых файлов шифруются в виде двух новых коммитов в ориентированном ациклическом графе. При этом один коммит используется для неиндексированных изменений, а другой — для индексированных изменений, добавленных в раздел проиндексированных файлов. Для указания на них используется специальная ссылка refs/stash .
Параметр --include-untracked позволяет также зашифровать все изменения неотслеживаемых файлов в виде дополнительного коммита.
Параметр --all позволяет включить изменения игнорируемых файлов в один коммит с изменениями неотслеживаемых файлов.
При выполнении команды git stash pop изменения из описанных выше коммитов применяются к рабочей копии и разделу проиндексированных файлов, извлеченный коммит удаляется из журнала ссылок на отложенные изменения, и ссылки в журнале сдвигаются. Извлеченные коммиты не удаляются сразу, но помечаются к удалению в будущем при сборе мусора.
Читайте также: