git restore staged что делает
Операции отмены
В любой момент вам может потребоваться что-либо отменить. Здесь мы рассмотрим несколько основных способов отмены сделанных изменений. Будьте осторожны, не все операции отмены в свою очередь можно отменить! Это одна из редких областей Git, где неверными действиями можно необратимо удалить результаты своей работы.
Эта команда использует область подготовки (индекс) для внесения правок в коммит. Если вы ничего не меняли с момента последнего коммита (например, команда запущена сразу после предыдущего коммита), то снимок состояния останется в точности таким же, а всё что вы сможете изменить — это ваше сообщение к коммиту.
Запустится тот же редактор, только он уже будет содержать сообщение предыдущего коммита. Вы можете редактировать сообщение как обычно, однако, оно заменит сообщение предыдущего коммита.
Например, если вы сделали коммит и поняли, что забыли проиндексировать изменения в файле, который хотели добавить в коммит, то можно сделать следующее:
В итоге получится единый коммит — второй коммит заменит результаты первого.
Очень важно понимать, что когда вы вносите правки в последний коммит, вы не столько исправляете его, сколько заменяете новым, который полностью его перезаписывает. В результате всё выглядит так, будто первоначальный коммит никогда не существовал, а так же он больше не появится в истории вашего репозитория.
Очевидно, смысл изменения коммитов в добавлении незначительных правок в последние коммиты и, при этом, в избежании засорения истории сообщениями вида «Ой, забыл добавить файл» или «Исправление грамматической ошибки».
Отмена индексации файла
Следующие два раздела демонстрируют как работать с индексом и изменениями в рабочем каталоге. Радует, что команда, которой вы определяете состояние этих областей, также подсказывает вам как отменять изменения в них. Например, вы изменили два файла и хотите добавить их в разные коммиты, но случайно выполнили команду git add * и добавили в индекс оба. Как исключить из индекса один из них? Команда git status напомнит вам:
Прямо под текстом «Changes to be committed» говорится: используйте git reset HEAD … для исключения из индекса. Давайте последуем этому совету и отменим индексирование файла CONTRIBUTING.md :
Команда выглядит несколько странно, но — работает! Файл CONTRIBUTING.md изменен, но больше не добавлен в индекс.
Отмена изменений в файле
В выводе команды из последнего примера список изменений выглядит примерно так:
Здесь явно сказано как отменить существующие изменения. Давайте так и сделаем:
Как видите, откат изменений выполнен.
Если вы хотите сохранить изменения в файле, но прямо сейчас их нужно отменить, то есть способы получше, такие как ветвление и припрятывание — мы рассмотрим их в главе Ветвление в Git.
Отмена действий с помощью git restore
Отмена индексации файла с помощью git restore
Файл CONTRIBUTING.md изменен, но снова не индексирован.
Откат измененного файла с помощью git restore
Он довольно недвусмысленно говорит, как отменить сделанные вами изменения. Давайте сделаем то, что написано:
Важно понимать, что git restore — опасная команда. Любые локальные изменения, внесенные в этот файл, исчезнут — Git просто заменит файл последней зафиксированной версией. Никогда не используйте эту команду, если точно не знаете, нужны ли вам эти несохраненные локальные изменения.
Git restore staged что делает
Restore specified paths in the working tree with some contents from a restore source. If a path is tracked but does not exist in the restore source, it will be removed to match the source.
See «Reset, restore and revert» in git[1] for the differences between the three commands.
THIS COMMAND IS EXPERIMENTAL. THE BEHAVIOR MAY CHANGE.
OPTIONS
Restore the working tree files with the content from the given tree. It is common to specify the source tree by naming a commit, branch or tag associated with it.
When restoring files in the working tree from the index, use stage #2 (ours) or #3 (theirs) for unmerged paths.
When restoring files on the working tree from the index, recreate the conflicted merge in the unmerged paths.
In sparse checkout mode, by default is to only update entries matched by
Do not interpret any more arguments as options.
Limits the paths affected by the operation.
For more details, see the pathspec entry in gitglossary[7].
EXAMPLES
The following sequence switches to the master branch, reverts the Makefile to two revisions back, deletes hello.c by mistake, and gets it back from the index.
take a file out of another commit
restore hello.c from the index
If you want to restore all C source files to match the version in the index, you can say
To restore all files in the current directory
or to restore all working tree files with top pathspec magic (see gitglossary[7])
To restore a file in the index to match the version in HEAD (this is the same as using git-reset[1])
or you can restore both the index and the working tree (this the same as using git-checkout[1])
or the short form which is more practical but less readable:
Запись изменений в репозиторий
Итак, у вас имеется настоящий Git-репозиторий и рабочая копия файлов для некоторого проекта. Вам нужно делать некоторые изменения и фиксировать «снимки» состояния (snapshots) этих изменений в вашем репозитории каждый раз, когда проект достигает состояния, которое вам хотелось бы сохранить.
Запомните, каждый файл в вашем рабочем каталоге может находиться в одном из двух состояний: под версионным контролем (отслеживаемые) и нет (неотслеживаемые). Отслеживаемые файлы — это те файлы, которые были в последнем снимке состояния проекта; они могут быть неизменёнными, изменёнными или подготовленными к коммиту. Если кратко, то отслеживаемые файлы — это те файлы, о которых знает Git.
Неотслеживаемые файлы — это всё остальное, любые файлы в вашем рабочем каталоге, которые не входили в ваш последний снимок состояния и не подготовлены к коммиту. Когда вы впервые клонируете репозиторий, все файлы будут отслеживаемыми и неизменёнными, потому что Git только что их извлек и вы ничего пока не редактировали.
Как только вы отредактируете файлы, Git будет рассматривать их как изменённые, так как вы изменили их с момента последнего коммита. Вы индексируете эти изменения, затем фиксируете все проиндексированные изменения, а затем цикл повторяется.
Определение состояния файлов
Отслеживание новых файлов
Индексация изменённых файлов
Теперь оба файла проиндексированы и войдут в следующий коммит. В этот момент вы, предположим, вспомнили одно небольшое изменение, которое вы хотите сделать в CONTRIBUTING.md до коммита. Вы открываете файл, вносите и сохраняете необходимые изменения и вроде бы готовы к коммиту. Но давайте-ка ещё раз выполним git status :
Сокращенный вывод статуса
Игнорирование файлов
Первая строка предписывает Git игнорировать любые файлы заканчивающиеся на «.o» или «.a» — объектные и архивные файлы, которые могут появиться во время сборки кода. Вторая строка предписывает игнорировать все файлы заканчивающиеся на тильду (
Стандартные шаблоны являются глобальными и применяются рекурсивно для всего дерева каталогов.
Чтобы избежать рекурсии используйте символ слеш (/) в начале шаблона.
Чтобы исключить каталог добавьте слеш (/) в конец шаблона.
Можно инвертировать шаблон, использовав восклицательный знак (!) в качестве первого символа.
Просмотр индексированных и неиндексированных изменений
Чтобы увидеть, что же вы изменили, но пока не проиндексировали, наберите git diff без аргументов:
Эта команда сравнивает содержимое вашего рабочего каталога с содержимым индекса. Результат показывает ещё не проиндексированные изменения.
Важно отметить, что git diff сама по себе не показывает все изменения сделанные с последнего коммита — только те, что ещё не проиндексированы. Такое поведение может сбивать с толку, так как если вы проиндексируете все свои изменения, то git diff ничего не вернёт.
Другой пример: вы проиндексировали файл CONTRIBUTING.md и затем изменили его, вы можете использовать git diff для просмотра как проиндексированных изменений в этом файле, так и тех, что пока не проиндексированы. Если наше окружение выглядит вот так:
Используйте git diff для просмотра непроиндексированных изменений
Коммит изменений
Эта команда откроет выбранный вами текстовый редактор.
В редакторе будет отображён следующий текст (это пример окна Vim):
Вы можете видеть, что комментарий по умолчанию для коммита содержит закомментированный результат работы команды git status и ещё одну пустую строку сверху. Вы можете удалить эти комментарии и набрать своё сообщение или же оставить их для напоминания о том, что вы фиксируете.
Итак, вы создали свой первый коммит! Вы можете видеть, что коммит вывел вам немного информации о себе: на какую ветку вы выполнили коммит ( master ), какая контрольная сумма SHA-1 у этого коммита ( 463dc4f ), сколько файлов было изменено, а также статистику по добавленным/удалённым строкам в этом коммите.
Запомните, что коммит сохраняет снимок состояния вашего индекса. Всё, что вы не проиндексировали, так и висит в рабочем каталоге как изменённое; вы можете сделать ещё один коммит, чтобы добавить эти изменения в репозиторий. Каждый раз, когда вы делаете коммит, вы сохраняете снимок состояния вашего проекта, который позже вы можете восстановить или с которым можно сравнить текущее состояние.
Игнорирование индексации
Удаление файлов
Если вы просто удалите файл из своего рабочего каталога, он будет показан в секции «Changes not staged for commit» (измененные, но не проиндексированные) вывода команды git status :
В команду git rm можно передавать файлы, каталоги или шаблоны. Это означает, что вы можете сделать что-то вроде:
Эта команда удаляет все файлы, имена которых заканчиваются на
Перемещение файлов
В отличие от многих других систем контроля версий, Git не отслеживает перемещение файлов явно. Когда вы переименовываете файл в Git, в нём не сохраняется никаких метаданных, говорящих о том, что файл был переименован. Однако, Git довольно умён в плане обнаружения перемещений постфактум — мы рассмотрим обнаружение перемещения файлов чуть позже.
Таким образом, наличие в Git команды mv выглядит несколько странным. Если вам хочется переименовать файл в Git, вы можете сделать что-то вроде:
и это отлично сработает. На самом деле, если вы выполните что-то вроде этого и посмотрите на статус, вы увидите, что Git считает, что произошло переименование файла:
Однако, это эквивалентно выполнению следующих команд:
Секреты Git: 7 команд, о которых вы, возможно, не знаете
Перевод статьи «Git Secrets: 7 Commands You Might Not Know».
За последнюю пару лет Git стал частью стека практически любого разработчика. Знание этой технологии подразумевается по умолчанию. Но хотя сам Git знаком буквально всем, многие его команды остаются неизвестными.
В этом коротком посте я бы хотел показать семь маленьких команд, которые могут помочь вам стать более продуктивными в использовании Git.
Поиск изменений в файле
Быть в курсе всех дел может быть сложно, особенно если над одной кодовой базой работает много людей.
Чтобы разобраться, как именно (а также — когда и кем) был изменен файл, можно воспользоваться старой доброй командой git log с небольшим дополнением:
Эффектная отмена последнего коммита
Порой мы уверены, что набор изменений готов к сохранению, но как только сделан коммит, мы понимаем, что поспешили.
Может, забыли добавить какие-то изменения или указали не ту ветку. В общем, причины могут быть совершенно разные. Ясно одно: нам хотелось бы отменить последний коммит и вернуть все назад в нашу рабочую копию.
Для этого можно использовать команду git reset с особым набором опций:
1 это отличный шорткат, указывающий, что HEAD должен быть переключен на «коммит перед самым последним».
Если хотите узнать больше об отмене изменений, почитать можно здесь.
Определяем, чем отличается файл в другой ветке
После внесения изменений в файл в ветке вашей фичи вы можете захотеть сравнить его с тем же файлом в другой ветке. Чтобы пример был более конкретным, предположим, что..
Разницу можно посмотреть при помощи команды git diff с нужными параметрами:
В выводе вы увидите красивый понятный diff, показывающий, чем именно отличается ваш файл от версии этого же файла в другой ветке.
Использование switch вместо checkout
Поскольку это довольно новый член семьи Git, проверьте, включен ли он в вашу инсталляцию Git.
Переключение туда-сюда между двумя ветками
Иногда бывает необходимо по нескольку раз подряд переключаться между двумя ветками. Вместо того чтобы все время писать полное имя веток, можно воспользоваться следующим шорткатом:
Когда в качестве единственного параметра использован дефис, git switch переключает вас в предыдущую активную ветку. Это очень удобно, когда вам нужно постоянно переключаться между двумя ветками.
Использование git restore для отмены локальных изменений
До недавнего времени, чтобы отменить локальные изменения, вам приходилось использовать git checkout или git reset в той или иной форме.
Вот быстрый обзор самых важных вещей, которые можно делать при помощи git restore :
Восстановление произвольной версии файла из истории
Вы просто указываете хэш версии, которую хотите восстановить (и имя файла, конечно).
Если вам нужна помощь в поиске подходящей версии, можете воспользоваться десктопным клиентом Git, например, Tower. Функционал «File History» позволит вам легко просмотреть только изменения, произошедшие в определенном файле, а затем выбрать нужный вариант для восстановления.
Открывайте для себя всю мощь Git
Хотя в наше время Git хорошо всем знаком, большинство людей не углубляются в его изучение и не используют имеющийся функционал по максимуму. Да, вы вполне можете «выжить», зная лишь несколько простых команд вроде commit, push и pull. Но это примерно как водить Ferrari, пользуясь только первой передачей!
Если вы копнете хоть немного глубже, вы откроете для себя много интересных и мощных функций Git. Это потенциально может сделать вас не только более продуктивным, но и в целом лучшим разработчиком!
Git Commands
An overview of the most important Git commands
git restore
The «restore» command helps to unstage or even discard uncommitted local changes.
One the one hand, the command can be used to undo the effects of git add and unstage changes you have previously added to the Staging Area.
On the other hand, the restore command can also be used to discard local changes in a file, thereby restoring its last committed state.
Important Options
—staged
—source
—patch
Allows you to select individual chunks to restore. Git steps through all of the individual chunks of changes in an interactive way and asks you, for each chunk, if you want to discard/unstage it.
Discarding / Unstaging Chunks or Even Lines of Changes
Using the Tower Git client, you can easily select the exact chunks & lines you want to stage, unstage, or even discard:
Usage Examples
You can of course also remove multiple files at once from the Staging Area:
Another interesting use case is to restore a specific historic revision of a file:
The first example will restore the file as it was in commit #7173808e, while the second one will restore it as it was «two commits before the current tip of the master branch».
Learn More
Get our popular Git Cheat Sheet for free!
You’ll find the most important commands on the front and helpful best practice tips on the back. Over 100,000 developers have downloaded it to make Git a little bit easier.
About Us
As the makers of Tower, the best Git client for Mac and Windows, we help over 100,000 users in companies like Apple, Google, Amazon, Twitter, and Ebay get the most out of Git.
Just like with Tower, our mission with this platform is to help people become better professionals.
That’s why we provide our guides, videos, and cheat sheets (about version control with Git and lots of other topics) for free.