Git удалить файл из индекса
В любой момент вам может потребоваться что-либо отменить. Здесь мы рассмотрим несколько основных способов отмены сделанных изменений. Будьте осторожны, не все операции отмены в свою очередь можно отменить! Это одна из редких областей Git, где неверными действиями можно необратимо удалить результаты своей работы.
Отмена может потребоваться, если вы сделали коммит слишком рано, например, забыв добавить какие-то файлы или комментарий к коммиту. Если вы хотите переделать коммит — внесите необходимые изменения, добавьте их в индекс и сделайте коммит ещё раз, указав параметр --amend :
Например, если вы сделали коммит и поняли, что забыли проиндексировать изменения в файле, который хотели добавить в коммит, то можно сделать следующее:
В итоге получится единый коммит — второй коммит заменит результаты первого.
Очень важно понимать, что когда вы вносите правки в последний коммит, вы не столько исправляете его, сколько заменяете новым, который полностью его перезаписывает. В результате всё выглядит так, будто первоначальный коммит никогда не существовал, а так же он больше не появится в истории вашего репозитория.
Отмена индексации файла
Следующие два раздела демонстрируют как работать с индексом и изменениями в рабочем каталоге. Радует, что команда, которой вы определяете состояние этих областей, также подсказывает вам как отменять изменения в них. Например, вы изменили два файла и хотите добавить их в разные коммиты, но случайно выполнили команду git add * и добавили в индекс оба. Как исключить из индекса один из них? Команда git status напомнит вам:
Прямо под текстом «Changes to be committed» говорится: используйте git reset HEAD <file>… для исключения из индекса. Давайте последуем этому совету и отменим индексирование файла CONTRIBUTING.md :
Команда выглядит несколько странно, но — работает! Файл CONTRIBUTING.md изменен, но больше не добавлен в индекс.
Команда git reset может быть опасной если вызвать её с параметром --hard . В приведенном примере файл не был затронут, следовательно команда относительно безопасна.
На текущий момент этот магический вызов — всё, что вам нужно знать о команде git reset . Мы рассмотрим в деталях что именно делает reset и как с её помощью делать действительно интересные вещи в разделе Раскрытие тайн reset главы 7.
Отмена изменений в файле
Что делать, если вы поняли, что не хотите сохранять свои изменения файла CONTRIBUTING.md ? Как можно просто отменить изменения в нём — вернуть к тому состоянию, которое было в последнем коммите (или к начальному после клонирования, или еще как-то полученному)? Нам повезло, что git status подсказывает и это тоже.
В выводе команды из последнего примера список изменений выглядит примерно так:
Здесь явно сказано как отменить существующие изменения. Давайте так и сделаем:
Как видите, откат изменений выполнен.
Важно понимать, что git checkout -- <file> — опасная команда. Все локальные изменения в файле пропадут — Git просто заменит его версией из последнего коммита. Ни в коем случае не используйте эту команду, если вы не уверены, что изменения в файле вам не нужны.
Если вы хотите сохранить изменения в файле, но прямо сейчас их нужно отменить, то есть способы получше, такие как ветвление и припрятывание — мы рассмотрим их в главе Ветвление в Git.
Помните, все что попало в коммит почти всегда Git может восстановить. Можно восстановить даже коммиты из веток, которые были удалены, или коммиты, перезаписанные параметром --amend (см. Восстановление данных). Но всё, что не было включено в коммит и потеряно — скорее всего, потеряно навсегда.
Отмена действий с помощью git restore
Git версии 2.23.0 представил новую команду: git restore . По сути, это альтернатива git reset, которую мы только что рассмотрели. Начиная с версии 2.23.0, Git будет использовать git restore вместо git reset для многих операций отмены.
Давайте проследим наши шаги и отменим действия с помощью git restore вместо git reset .
Отмена индексации файла с помощью git restore
В следующих двух разделах показано, как работать с индексом и изменениями рабочей копии с помощью git restore . Приятно то, что команда, которую вы используете для определения состояния этих двух областей, также напоминает вам, как отменить изменения в них. Например, предположим, что вы изменили два файла и хотите зафиксировать их как два отдельных изменения, но случайно набираете git add * и индексируете их оба. Как вы можете убрать из индекса один из двух? Команда git status напоминает вам:
Прямо под текстом «Changes to be committed», написано использовать git restore --staged <file> … для отмены индексации файла. Итак, давайте воспользуемся этим советом, чтобы убрать из индекса файл CONTRIBUTING.md :
Файл CONTRIBUTING.md изменен, но снова не индексирован.
Откат измененного файла с помощью git restore
Что, если вы поймете, что не хотите сохранять изменения в файле CONTRIBUTING.md ? Как легко его откатить — вернуть обратно к тому, как он выглядел при последнем коммите (или изначально клонирован, или каким-либо образом помещён в рабочий каталог)? К счастью, git status тоже говорит, как это сделать. В выводе последнего примера, неиндексированная область выглядит следующим образом:
Он довольно недвусмысленно говорит, как отменить сделанные вами изменения. Давайте сделаем то, что написано:
Важно понимать, что git restore <file> — опасная команда. Любые локальные изменения, внесенные в этот файл, исчезнут — Git просто заменит файл последней зафиксированной версией. Никогда не используйте эту команду, если точно не знаете, нужны ли вам эти несохраненные локальные изменения.
он не удаляется из локальной файловой системы, что является целью. Но если вы уже версировали и фиксировали файл, поместили его в центральное хранилище и перетащили его в еще одно хранилище, прежде чем использовать команду, он удалит файл из этой системы.
Есть ли способ просто удалить файл из версий, не удаляя его из какой-либо файловой системы?
Редактировать: уточнил, я надеюсь.
Возможно, вы могли бы расширить свой вариант использования. Индекс является промежуточной областью для следующего коммита, так почему вы хотите удалить файл из индекса, если не хотите удалять его из текущей ветви? Мне жаль. Я хотел сказать, что myfile по какой-то причине был зафиксирован и распространен давно. Теперь цель состоит в том, чтобы удалить его из версий, не удаляя его из систем людей. Причина, по которой это произошло, заключается в том, что я случайно установил версию файла конфигурации. Файл конфигурации необходим, поэтому я не хочу удалять его из сторонних систем. git rm --cached не удалит файл из другого рабочего каталога. Файл будет удален только в том случае, если кто-то, работающий в этом каталоге, выполнит извлечение. Файл может быть легко восстановлен с помощью «git checkout HEAD @ <1>foo» (если выполняется сразу после извлечения).Я не думаю, что коммит Git может записать намерение типа «прекратите отслеживать этот файл, но не удаляйте его».
Принятие такого намерения потребует вмешательства вне Git в любые репозитории, которые объединяют (или перебазируют) коммит, который удаляет файл.
Сохранить копию, применить удаление, восстановить
Вероятно, самое простое, что нужно сделать, - это попросить своих нижестоящих пользователей сохранить копию файла, вытащить удаление и восстановить файл. Если они вытягивают через rebase и «переносят» изменения в файл, они получат конфликты. Чтобы разрешить такие конфликты, используйте git rm foo.conf && git rebase --continue (если конфликтующий коммит имеет изменения помимо тех, что были в удаленном файле) или git rebase --skip (если конфликтующий коммит был изменен только на удаленный файл).
Восстановить файл как неотслеживаемый после извлечения коммита, который удаляет его
Если они уже извлекли ваш коммит удаления, они могут восстановить предыдущую версию файла с помощью git show :
Или с Git Checkout (за комментарий Уильяма Перселла; но не забудьте удалить его из индекса!):
Если они предприняли другие действия с тех пор, как вы удалили ваше удаление (или они тянут с ребазой в отдельную ГОЛОВКУ), им может понадобиться что-то другое @ . Они могли бы использовать git log -g чтобы найти коммит непосредственно перед тем, как вытащить ваше удаление.
В комментарии вы упоминаете, что файл, который вы хотите «отследить, но сохранить», является своего рода файлом конфигурации, который необходим для запуска программного обеспечения (непосредственно из репозитория).
Сохранить файл как «по умолчанию» и вручную / автоматически активировать его
Если не совсем неприемлемо продолжать поддерживать содержимое файла конфигурации в хранилище, вы можете переименовать отслеживаемый файл из (например) foo.conf в, foo.conf.default а затем проинструктировать пользователей cp foo.conf.default foo.conf после применения коммита переименования. Или, если пользователи уже используют какую-либо существующую часть хранилища (например, сценарий или другую программу, сконфигурированную с помощью содержимого в хранилище (например, Makefile или аналогичное)) для запуска / развертывания вашего программного обеспечения, вы можете включить механизм запуска по умолчанию в запуск / запуск. процесс развертывания:
При наличии такого механизма по умолчанию пользователи должны иметь возможность получить коммит, который переименовывается foo.conf в foo.conf.default без необходимости делать какие - либо дополнительные работы. Кроме того, вам не нужно вручную копировать файл конфигурации, если в будущем вы сделаете дополнительные установки / репозитории.
В любом случае переписывание истории требует ручного вмешательства .
Если недопустимо поддерживать содержимое в хранилище, вы, вероятно, захотите полностью удалить его из истории, например git filter-branch --index-filter … . Это равносильно переписыванию истории, что потребует ручного вмешательства для каждой ветви / репозитория (см. Раздел «Восстановление из исходной перебазировки» на справочной странице git rebase ). Специальная обработка, требуемая для вашего файла конфигурации, будет просто еще одним шагом, который нужно выполнить при восстановлении после перезаписи:
Мой первоначальный коммит содержал несколько файлов журнала. Я добавил *log в свой .gitignore , и теперь я хочу удалить файлы журнала из моего хранилища.
удалит файл из хранилища, но также удалит его из локальной файловой системы.
Как я могу удалить этот файл из репозитория, не удаляя мою локальную копию файла?
Когда --cached задано, поэтапное содержимое должно соответствовать либо концу ветви, либо файлу на диске, что позволяет удалить файл только из индекса.
Итак, для одного файла:
и для одного каталога:
Легко пропустить, потому что это не так само за себя, как svn rm --keep-local . Но как мне сохранить файлы на удаленных серверах? Это сохраняет мой локальный, но если я нажму и потяну с другого сервера, файл будет удален. Я также добавил .gitignore для файла, но он все еще удален Это все равно удаляет файлы, git pull если вы находитесь за коммитом после git rm Стоит отметить, что после запуска команды в ответе необходимо использовать git commit -m "Commit message" и git push . Если у вас есть какие-либо другие поэтапные изменения (проверьте с помощью git status ), они также будут зафиксированы в это время. Так как это самый приемлемый ответ и он не делает то, о чем просят, я расскажу, что я делаю. Я использую команду git rm --cached mylogfile.log и удаляю файл из репозитория. Чтобы не потерять файл в продуктивной системе, я делаю резервную копию файла и вытащу после этого. Файл будет удален, как упоминалось ранее, и его необходимо скопировать обратно из резервной копии. Это довольно больно, но я не нашел лучшего решения этой проблемы.Чтобы удалить всю папку из репозитория (например, файлы Resharper), сделайте следующее:
Я зафиксировал некоторые файлы для изменения резкости и не хотел, чтобы они сохранялись для других пользователей проекта.
Просто добавленная заметка для будущих посетителей: не используйте графический интерфейс для «синхронизации» фиксации обратно в репо. Это вернет файлы обратно в ваш локальный репозиторий. Вы должны сделать, Git Push repo branch чтобы фактически удалить файлы с пульта.Вы также можете удалить файлы из хранилища на основе вашего .gitignore, не удаляя их из локальной файловой системы:
Или, в качестве альтернативы, в Windows Powershell:
Работает на Windows, если вы используете Git Bash вместо cmd-консоли Люблю это. Работал за исключением того, что у меня были некоторые файлы, которые заканчивались тем, что имели пробелы в имени файла. Я изменил решение здесь это: git ls-files -i -X .gitignore | xargs -I<> git rm --cached "<>" . Пожалуйста, подумайте об изменении или добавлении этого решения к ответу здесь, потому что это отличный инструмент для . Я не пробовал, но это должно быть проверено, удалит ли он также такие файлы, .gitkeep которые сохраняют пустую папку в хранилище. Например. .gitignore содержать папку uploads и репо вынужден отслеживать .gitkeep . Удалив все из репо под uploads него, удалят также .gitkeep . Это предложение отлично работает в powershell: git rm --cached $ (git ls-files -i -X .gitignore)Чтобы удалить папку / каталог или файл только из репозитория git, а не из локального, попробуйте 3 простых шага.
Шаги по удалению каталога
Действия по игнорированию этой папки в следующих коммитах
Чтобы игнорировать эту папку из следующих коммитов, создайте в корневом каталоге один файл с именем .gitignore и поместите в него имя этой папки. Вы можете положить столько, сколько хотите
Файл .gitignore будет выглядеть так
Более общее решение:
Редактировать .gitignore файл
ECHO mylogfile.log >> .gitignore
Удалить все элементы из индекса.
git rm -r -f --cached .
Сделать новый коммит
git commit -m "Removed mylogfile.log"
Из GitHub? NO. Если вы уже нажали на github, он не удалит его с сайта. Но это обновит ваш локальный репозиторий git. Комментарий, который вы удалили, был на самом деле более удален :) Проблема с решением rm --cashed состоит в том, что он в конечном итоге удалит файл, когда вы нажмете - правильно? И это не то, что люди хотят, когда говорят «Удалить файл из хранилища, не удаляя его из локальной файловой системы ». Теперь, почему принятое выше решение мне не подходит - возможно, ОП работал один и никогда не работал? Не знаю. Я понимаю, что GitHub "когда-то толкнул всегда" проблема ofc Я не думаю, что есть 100% решение, если вы не спросите сам Github. А пока придерживайтесь этого. Скопируйте файл, добавьте в gitignore, выполните git rm -r, зафиксируйте, нажмите, восстановите файл. Вам удалось найти другое решение?Git позволяет игнорировать эти файлы, предполагая, что они не изменены. Это делается с помощью git update-index --assume-unchanged path/to/file.txt команды. После пометки файла как такового, git будет полностью игнорировать любые изменения в этом файле; они не будут отображаться при запуске git status или git diff и никогда не будут зафиксированы.
Следовательно, не удаляя это, но игнорируя изменения к этому навсегда. Я думаю, что это работает только локально, поэтому коллеги по-прежнему могут видеть изменения, если они не выполняют ту же команду, что и выше. (Тем не менее, необходимо проверить это.)
Примечание. Это не дает прямого ответа на вопрос, а основано на последующих вопросах в комментариях к другим ответам.
Итак, у вас имеется настоящий Git-репозиторий и рабочая копия файлов для некоторого проекта. Вам нужно делать некоторые изменения и фиксировать «снимки» состояния (snapshots) этих изменений в вашем репозитории каждый раз, когда проект достигает состояния, которое вам хотелось бы сохранить.
Запомните, каждый файл в вашем рабочем каталоге может находиться в одном из двух состояний: под версионным контролем (отслеживаемые) и нет (неотслеживаемые). Отслеживаемые файлы — это те файлы, которые были в последнем снимке состояния проекта; они могут быть неизменёнными, изменёнными или подготовленными к коммиту. Если кратко, то отслеживаемые файлы — это те файлы, о которых знает Git.
Неотслеживаемые файлы — это всё остальное, любые файлы в вашем рабочем каталоге, которые не входили в ваш последний снимок состояния и не подготовлены к коммиту. Когда вы впервые клонируете репозиторий, все файлы будут отслеживаемыми и неизменёнными, потому что Git только что их извлек и вы ничего пока не редактировали.
Как только вы отредактируете файлы, Git будет рассматривать их как изменённые, так как вы изменили их с момента последнего коммита. Вы индексируете эти изменения, затем фиксируете все проиндексированные изменения, а затем цикл повторяется.
Определение состояния файлов
Основной инструмент, используемый для определения, какие файлы в каком состоянии находятся — это команда git status . Если вы выполните эту команду сразу после клонирования, вы увидите что-то вроде этого:
Это означает, что у вас чистый рабочий каталог, другими словами — в нем нет отслеживаемых измененных файлов. Git также не обнаружил неотслеживаемых файлов, в противном случае они бы были перечислены здесь. Наконец, команда сообщает вам на какой ветке вы находитесь и сообщает вам, что она не расходится с веткой на сервере. Пока что это всегда ветка master , ветка по умолчанию; в этой главе это не важно. В главе Ветвление в Git будут рассмотрены ветки и ссылки более детально.
Предположим, вы добавили в свой проект новый файл, простой файл README . Если этого файла раньше не было, и вы выполните git status , вы увидите свой неотслеживаемый файл вот так:
Понять, что новый файл README неотслеживаемый можно по тому, что он находится в секции «Untracked files» в выводе команды status . Статус Untracked означает, что Git видит файл, которого не было в предыдущем снимке состояния (коммите); Git не станет добавлять его в ваши коммиты, пока вы его явно об этом не попросите. Это предохранит вас от случайного добавления в репозиторий сгенерированных бинарных файлов или каких-либо других, которые вы и не думали добавлять. Мы хотели добавить README, так давайте сделаем это.
Отслеживание новых файлов
Для того чтобы начать отслеживать (добавить под версионный контроль) новый файл, используется команда git add . Чтобы начать отслеживание файла README , вы можете выполнить следующее:
Если вы снова выполните команду status , то увидите, что файл README теперь отслеживаемый и добавлен в индекс:
Вы можете видеть, что файл проиндексирован, так как он находится в секции «Changes to be committed». Если вы выполните коммит в этот момент, то версия файла, существовавшая на момент выполнения вами команды git add , будет добавлена в историю снимков состояния. Как вы помните, когда вы ранее выполнили git init , затем вы выполнили git add (файлы) — это было сделано для того, чтобы добавить файлы в вашем каталоге под версионный контроль. Команда git add принимает параметром путь к файлу или каталогу, если это каталог, команда рекурсивно добавляет все файлы из указанного каталога в индекс.
Индексация изменённых файлов
Давайте модифицируем файл, уже находящийся под версионным контролем. Если вы измените отслеживаемый файл CONTRIBUTING.md и после этого снова выполните команду git status , то результат будет примерно следующим:
Файл CONTRIBUTING.md находится в секции «Changes not staged for commit» — это означает, что отслеживаемый файл был изменён в рабочем каталоге, но пока не проиндексирован. Чтобы проиндексировать его, необходимо выполнить команду git add . Это многофункциональная команда, она используется для добавления под версионный контроль новых файлов, для индексации изменений, а также для других целей, например для указания файлов с исправленным конфликтом слияния. Вам может быть понятнее, если вы будете думать об этом как «добавить этот контент в следующий коммит», а не как «добавить этот файл в проект». Выполним git add , чтобы проиндексировать CONTRIBUTING.md , а затем снова выполним git status :
Теперь оба файла проиндексированы и войдут в следующий коммит. В этот момент вы, предположим, вспомнили одно небольшое изменение, которое вы хотите сделать в CONTRIBUTING.md до коммита. Вы открываете файл, вносите и сохраняете необходимые изменения и вроде бы готовы к коммиту. Но давайте-ка ещё раз выполним git status :
Что за чёрт? Теперь CONTRIBUTING.md отображается как проиндексированный и непроиндексированный одновременно. Как такое возможно? Такая ситуация наглядно демонстрирует, что Git индексирует файл в точности в том состоянии, в котором он находился, когда вы выполнили команду git add . Если вы выполните коммит сейчас, то файл CONTRIBUTING.md попадёт в коммит в том состоянии, в котором он находился, когда вы последний раз выполняли команду git add , а не в том, в котором он находится в вашем рабочем каталоге в момент выполнения git commit . Если вы изменили файл после выполнения git add , вам придётся снова выполнить git add , чтобы проиндексировать последнюю версию файла:
Сокращенный вывод статуса
Вывод команды git status довольно всеобъемлющий и многословный. Git также имеет флаг вывода сокращенного статуса, так что вы можете увидеть изменения в более компактном виде. Если вы выполните git status -s или git status --short вы получите гораздо более упрощенный вывод:
Новые неотслеживаемые файлы помечены ?? слева от них, файлы добавленные в отслеживаемые помечены A , отредактированные файлы помечены M и так далее. В выводе содержится два столбца — в левом указывается статус файла, а в правом модифицирован ли он после этого. К примеру в нашем выводе, файл README модифицирован в рабочем каталоге, но не проиндексирован, а файл lib/simplegit.rb модифицирован и проиндексирован. Файл Rakefile модифицирован, проиндексирован и ещё раз модифицирован, таким образом на данный момент у него есть те изменения, которые попадут в коммит, и те, которые не попадут.
Игнорирование файлов
Зачастую, у вас имеется группа файлов, которые вы не только не хотите автоматически добавлять в репозиторий, но и видеть в списках неотслеживаемых. К таким файлам обычно относятся автоматически генерируемые файлы (различные логи, результаты сборки программ и т. п.). В таком случае, вы можете создать файл .gitignore . с перечислением шаблонов соответствующих таким файлам. Вот пример файла .gitignore :
Первая строка предписывает Git игнорировать любые файлы заканчивающиеся на «.o» или «.a» — объектные и архивные файлы, которые могут появиться во время сборки кода. Вторая строка предписывает игнорировать все файлы заканчивающиеся на тильду (
), которая используется во многих текстовых редакторах, например Emacs, для обозначения временных файлов. Вы можете также включить каталоги log, tmp или pid; автоматически создаваемую документацию; и т. д. и т. п. Хорошая практика заключается в настройке файла .gitignore до того, как начать серьёзно работать, это защитит вас от случайного добавления в репозиторий файлов, которых вы там видеть не хотите.
К шаблонам в файле .gitignore применяются следующие правила:
Стандартные шаблоны являются глобальными и применяются рекурсивно для всего дерева каталогов.
Чтобы избежать рекурсии используйте символ слеш (/) в начале шаблона.
Чтобы исключить каталог добавьте слеш (/) в конец шаблона.
Можно инвертировать шаблон, использовав восклицательный знак (!) в качестве первого символа.
Glob-шаблоны представляют собой упрощённые регулярные выражения, используемые командными интерпретаторами. Символ ( * ) соответствует 0 или более символам; последовательность [abc] — любому символу из указанных в скобках (в данном примере a, b или c); знак вопроса ( ? ) соответствует одному символу; и квадратные скобки, в которые заключены символы, разделённые дефисом ( 1 ), соответствуют любому символу из интервала (в данном случае от 0 до 9). Вы также можете использовать две звёздочки, чтобы указать на вложенные каталоги: a/**/z соответствует a/z , a/b/z , a/b/c/z , и так далее.
Вот ещё один пример файла .gitignore :
В простейшем случае репозиторий будет иметь один файл .gitignore в корневом каталоге, правила из которого будут рекурсивно применяться ко всем подкаталогам. Так же возможно использовать .gitignore файлы в подкаталогах. Правила из этих файлов будут применяться только к каталогам, в которых они находятся. Например, репозиторий исходного кода ядра Linux содержит 206 файлов .gitignore .
Детальное рассмотрение использования нескольких .gitignore файлов выходит за пределы этой книги; детали доступны в справке man gitignore .
Просмотр индексированных и неиндексированных изменений
Допустим, вы снова изменили и проиндексировали файл README , а затем изменили файл CONTRIBUTING.md без индексирования. Если вы выполните команду git status , вы опять увидите что-то вроде:
Чтобы увидеть, что же вы изменили, но пока не проиндексировали, наберите git diff без аргументов:
Эта команда сравнивает содержимое вашего рабочего каталога с содержимым индекса. Результат показывает ещё не проиндексированные изменения.
Если вы хотите посмотреть, что вы проиндексировали и что войдёт в следующий коммит, вы можете выполнить git diff --staged . Эта команда сравнивает ваши проиндексированные изменения с последним коммитом:
Важно отметить, что git diff сама по себе не показывает все изменения сделанные с последнего коммита — только те, что ещё не проиндексированы. Такое поведение может сбивать с толку, так как если вы проиндексируете все свои изменения, то git diff ничего не вернёт.
Другой пример: вы проиндексировали файл CONTRIBUTING.md и затем изменили его, вы можете использовать git diff для просмотра как проиндексированных изменений в этом файле, так и тех, что пока не проиндексированы. Если наше окружение выглядит вот так:
Используйте git diff для просмотра непроиндексированных изменений
а так же git diff --cached для просмотра проиндексированных изменений ( --staged и --cached синонимы):
Мы будем продолжать использовать команду git diff различными способами на протяжении всей книги. Существует еще один способ просматривать эти изменения, если вы предпочитаете графический просмотр или внешнюю программу просмотра различий, вместо консоли. Выполнив команду git difftool вместо git diff , вы сможете просмотреть изменения в файле с помощью таких программ как emerge, vimdiff и других (включая коммерческие продукты). Выполните git difftool --tool-help чтобы увидеть какие из них уже установлены в вашей системе.
Коммит изменений
Теперь, когда ваш индекс находится в таком состоянии, как вам и хотелось, вы можете зафиксировать свои изменения. Запомните, всё, что до сих пор не проиндексировано — любые файлы, созданные или изменённые вами, и для которых вы не выполнили git add после редактирования — не войдут в этот коммит. Они останутся изменёнными файлами на вашем диске. В нашем случае, когда вы в последний раз выполняли git status , вы видели что всё проиндексировано, и вот, вы готовы к коммиту. Простейший способ зафиксировать изменения — это набрать git commit :
Эта команда откроет выбранный вами текстовый редактор.
Редактор устанавливается переменной окружения EDITOR — обычно это vim или emacs, хотя вы можете установить любой другой с помощью команды git config --global core.editor , как было показано в главе Введение).
В редакторе будет отображён следующий текст (это пример окна Vim):
Для ещё более подробного напоминания, что же именно вы поменяли, можете передать аргумент -v в команду git commit . Это приведёт к тому, что в комментарий будет также помещена дельта/diff изменений, таким образом вы сможете точно увидеть все изменения которые вы совершили.
Есть и другой способ — вы можете набрать свой комментарий к коммиту в командной строке вместе с командой commit указав его после параметра -m , как в следующем примере:
Итак, вы создали свой первый коммит! Вы можете видеть, что коммит вывел вам немного информации о себе: на какую ветку вы выполнили коммит ( master ), какая контрольная сумма SHA-1 у этого коммита ( 463dc4f ), сколько файлов было изменено, а также статистику по добавленным/удалённым строкам в этом коммите.
Запомните, что коммит сохраняет снимок состояния вашего индекса. Всё, что вы не проиндексировали, так и висит в рабочем каталоге как изменённое; вы можете сделать ещё один коммит, чтобы добавить эти изменения в репозиторий. Каждый раз, когда вы делаете коммит, вы сохраняете снимок состояния вашего проекта, который позже вы можете восстановить или с которым можно сравнить текущее состояние.
Игнорирование индексации
Несмотря на то, что индекс может быть удивительно полезным для создания коммитов именно такими, как вам и хотелось, он временами несколько сложнее, чем вам нужно в процессе работы. Если у вас есть желание пропустить этап индексирования, Git предоставляет простой способ. Добавление параметра -a в команду git commit заставляет Git автоматически индексировать каждый уже отслеживаемый на момент коммита файл, позволяя вам обойтись без git add :
Обратите внимание, что в данном случае перед коммитом вам не нужно выполнять git add для файла CONTRIBUTING.md , потому что флаг -a включает все файлы. Это удобно, но будьте осторожны: флаг -a может включить в коммит нежелательные изменения.
Удаление файлов
Для того чтобы удалить файл из Git, вам необходимо удалить его из отслеживаемых файлов (точнее, удалить его из вашего индекса) а затем выполнить коммит. Это позволяет сделать команда git rm , которая также удаляет файл из вашего рабочего каталога, так что в следующий раз вы не увидите его как «неотслеживаемый».
Если вы просто удалите файл из своего рабочего каталога, он будет показан в секции «Changes not staged for commit» (измененные, но не проиндексированные) вывода команды git status :
Затем, если вы выполните команду git rm , удаление файла попадёт в индекс:
После следующего коммита файл исчезнет и больше не будет отслеживаться. Если вы изменили файл и уже проиндексировали его, вы должны использовать принудительное удаление с помощью параметра -f . Это сделано для повышения безопасности, чтобы предотвратить ошибочное удаление данных, которые ещё не были записаны в снимок состояния и которые нельзя восстановить из Git.
Другая полезная штука, которую вы можете захотеть сделать — это удалить файл из индекса, оставив его при этом в рабочем каталоге. Другими словами, вы можете захотеть оставить файл на жёстком диске, но перестать отслеживать изменения в нём. Это особенно полезно, если вы забыли добавить что-то в файл .gitignore и по ошибке проиндексировали, например, большой файл с логами, или кучу промежуточных файлов компиляции. Чтобы сделать это, используйте опцию --cached :
В команду git rm можно передавать файлы, каталоги или шаблоны. Это означает, что вы можете сделать что-то вроде:
Обратите внимание на обратный слеш ( \ ) перед * . Он необходим из-за того, что Git использует свой собственный обработчик имён файлов вдобавок к обработчику вашего командного интерпретатора. Эта команда удаляет все файлы, имеющие расширение .log и находящиеся в каталоге log/ . Или же вы можете сделать вот так:
Эта команда удаляет все файлы, имена которых заканчиваются на
Перемещение файлов
В отличие от многих других систем контроля версий, Git не отслеживает перемещение файлов явно. Когда вы переименовываете файл в Git, в нём не сохраняется никаких метаданных, говорящих о том, что файл был переименован. Однако, Git довольно умён в плане обнаружения перемещений постфактум — мы рассмотрим обнаружение перемещения файлов чуть позже.
Таким образом, наличие в Git команды mv выглядит несколько странным. Если вам хочется переименовать файл в Git, вы можете сделать что-то вроде:
и это отлично сработает. На самом деле, если вы выполните что-то вроде этого и посмотрите на статус, вы увидите, что Git считает, что произошло переименование файла:
Однако, это эквивалентно выполнению следующих команд:
Git неявно определяет, что произошло переименование, поэтому неважно, переименуете вы файл так или используя команду mv . Единственное отличие состоит лишь в том, что mv — одна команда вместо трёх — это функция для удобства. Важнее другое — вы можете использовать любой удобный способ для переименования файла, а затем воспользоваться командами add/rm перед коммитом.
Читайте также: