September 02, 2014
Команда git rm
Как хорошо известно, в системе Git файл может одновременно существовать в трех ипостасях: в области “Working Directory”, в области “Staging Area”, в области “Repository”. Удаление файла из области “Working Directory” не приведет к его удалению из областей “Staging Area” и “Repository”.
Поэтому, чтобы удалить файл, нужно (в идеале) выполнить три команды подряд для удаления файла из Рабочей области “Working Directory”, затем из области индекса “Staging Area” и потом из области репозитория “Repository”:
Команда git rm является ни чем иным, как “вшитым” в Git сокращением двух первых команд:
Удалим его командой git rm :
Любой последующий commit зафиксирует удаление этого файла:
Остается только зафиксировать эти изменения любым коммитом:
Переименуем файл index.html с помощью команды git mv :
git rm
Обзор команды git rm
Обратите внимание, что git rm не удаляет ветки. Подробнее об использовании веток Git см. здесь.
Использование
Указывает файлы, подлежащие удалению. Можно указать один файл, несколько файлов через пробел ( file1 file2 file3 ) или шаблон подстановки (
Параметр dry run является защитным механизмом. Он позволяет выполнить пробный запуск команды git rm без удаления файлов. В выходных данных отображаются файлы, которые должны были быть удалены.
Параметр cached указывает, что должны быть удалены только файлы, находящиеся в разделе проиндексированных файлов. Файлы в рабочем каталоге при этом остаются нетронутыми.
Отмена изменений, внесенных командой git rm
Пояснения
Область действия команды git rm
Действие команды git rm распространяется только на текущую ветку. Удаление выполняется только в деревьях рабочего каталога и раздела проиндексированных файлов. Удаление файла не сохраняется в истории репозитория до тех пор, пока не создан новый коммит.
Почему следует использовать git rm, а не rm
Примеры
В данном примере шаблон поиска файлов используется для удаления всех файлов *.txt в каталоге Documentation и всех его подкаталогах.
Удаление файлов, которых уже нет в файловой системе
Команда git rm: заключение
Команда git rm выполняет действия над двумя главными деревьями управления внутренним состоянием Git: рабочим каталогом и разделом проиндексированных файлов. Команда git rm позволяет удалять файлы из репозитория Git. Это удобный инструмент, объединяющий функции стандартной команды оболочки rm и команды git add : сначала git rm удаляет целевой объект из файловой системы, а затем добавляет событие удаления в раздел проиндексированных файлов. Эта команда — одна из многих, которые можно использовать для отмены изменений в Git.
Запись изменений в репозиторий
Итак, у вас имеется настоящий 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
Git очень удобная система контроля версий, которая сейчас используется практические повсеместно. Она нужна для того, чтобы команды могли кооперироваться в создании программного продукта и совмещать код написанный разными людьми в одном репозитории.
Когда я учил Git мне говорили, что в работе мне понадобятся всего 3 команды:
Правда, по сути мне немного слукавили, нужен был ещё как минимум:
Однако, на этом все мои теоретические знания по Git заканчивались и достаточно долгое время я пользовался только этими командами, покуда в один момент не начал работать над веб-приложениями, над которыми со мной работали ещё несколько человек.
Там мне объяснили какие команды также нужны в разработке, зачем они используются и как часто они используются. Сегодня я решил поделиться этими командами с вами.
Основная терминология
Работа с Git
Прежде всего нам понадобятся команды для работы с файлами. Знать add конечно хорошо, но нужно иногда и удалять что-то из кэшируемых файлов или изменять поведение Git для определенных файлов. Сегодня я разберу некоторые команды, которые позволят вам манипулировать с файлами, ветками, коммитами в Git.
init
Данная команда инициализирует систему контроля версий. Для того чтобы создать новый репозиторий достаточно просто ввести:
clone
Данная команда нужна для того, чтобы клонировать репозиторий из облака. Можно клонировать репозитории из Github, Gitlab, BitBucket и других сервисов. Для того чтобы склонировать репозиторий нужно ввести:
Данная команда понадобится вам, когда вам нужно добавить файл для кэширования. Давайте разберёмся как это работает:
Вы изменяете файлы, можете изменять достаточно много файлов, задачи изменения которых вообще никак не связаны
Вы решаете «закоммитить» ваши файлы (сделать сохранение версии, для того чтобы Git запомнил все ваши изменения в файлах и как-то назвал их, для этого есть отдельная команда git commit )
Вы также можете добавить файлы, которые ранее не отслеживались, для того чтобы Git занёс их в свою систему хранения версий и вы могли откатываться на какую-то из версий файла
Проделав данный алгоритм, состоящий из двух команд вы занесёте все файлы из вашего проекта в систему контроля версий Git.
Но, что если вам не хочется вносить все файлы? Тогда вы может использовать следующий синтаксис:
Также мы можем сделать так, чтобы Git искал некоторые названия в дочерних директориях и игнорировал их:
Данная команда поможет, когда нам нужно избавиться от файла, она подобно команде rm удаляет файл из файловой системы и кэша Git, позволяя нам быстро избавиться от файла.
Данный пример удалит файл file.txt из кэша и файловой системы.
Но, что если мы добавили файл, который нам более не нужен в кэше, но нужен в файловой системе? Тогда мы можем воспользоваться следующей командой:
Данная команда удалит файл из «кэша», но что это значит? Допустим, что мы «закоммитили» (сохранили версию, об этом поговорим вот уже совсем скоро) наш файл, а теперь хотим, чтобы Git считал что мы его удалили, а сами просто оставили его на диске. Для этого и нужна команда выше. Она просто говорит Git: «Слушай, а давай ты просто удалишь этот файл из кэша и не будешь его показывать в репозитории, а я оставлю копию у себя на ПК, ок?»
Таким образом мы можем работать с данным файлом и Git не будет знать что именно в нём мы изменяем, а затем просто можем опять добавить его. Файл будет висеть в состоянии «untracked» (не отслеживается) до тех пор, покуда мы его опять не добавим.
commit
Думаю, что стоит поговорить об этом уже сейчас, ибо позже без данной команды уже никуда. Данная команда буквально сохраняет версию, в которой указывается что именно в файлах мы изменили.
Обычно разработчики сохраняют версию программы с помощью данной команды:
В данном случае мы просто скажем, чтобы Git сохранил все изменения, которые мы сделали в файлах, которые отслеживаются. Файлы, которые не отслеживаются просто не попадают в версию, а также их изменения никак нельзя отследить.
Для того чтобы отменить последний коммит (отменить не изменения, а именно просто разкоммитить изменения) и совместить его с текущими изменениями используйте команду:
show
Данная команда нужна для того, чтобы быстро показать что было сделано за предыдущие коммит:
Выведутся изменения следующим образом:
status
До этого момента мы могли только посмотреть что творилось в предыдущем коммите, однако с помощью git log мы можем посмотреть историю наших коммитов:
Если же вы хотите красиво вывести все ваши коммиты в столбик, то используйте данную команду:
В данной команде мы описываем что хотим просматривать коммиты и их названия в одну строку, хотим чтобы коммиты сокращали свой ID, а также чтобы всё это красиво было разбито по списку
diff
С помощью данной команды мы можем посмотреть на изменения между коммитами. Эта комманда является одной из самых мощных в Git, вам стоит обратить на неё внимание:
Так называемые «ID-коммита» можно взять и вышеприведенной git log
Если вы хотите посмотреть историю изменений в файлах в определенном коммите, то используйте следующую команду:
Если вы хотите посмотреть на изменения только тех файлов, которые добавлены для отслеживания, то нужно ввести следующую команду:
branch
В Git есть ветки для разделения версий. Если коммит нужен для того, чтобы сделать snapshot (слепок изменений) файлов, то ветки нужны для того, чтобы эти snapshot’ы разделять. У вас может быть ветка
любое другое название
Для того чтобы перечислить все ветки с помощью Git нужно ввести следующую команду:
Для того чтобы создать новую ветку нужно ввести:
checkout
Checkout используют для того, чтобы переходить между ветками. Для того чтобы перейти на другую ветку достаточно просто написать:
Для того чтобы создать ветку и сразу же перейти на неё достаточно ввести:
merge
Соединение веток не являются сложной темой. Для того чтобы слить текущую ветку с другой нужно ввести:
push
В завершение
Здесь мы чуть более глубже познакомились с основами Git, поняли как работать с ветками, как их мерджить, как коммитить файлы, смотреть изменения, а также как показывать последние коммиты.
Если вы хотите больше узнать о веб-разработке, а также о линуксе, то милости прошу в мой блог на телеграм.
Надеюсь данная статья помогла вам чуть лучше узнать Git. Хорошего дня и продуктивной недели!
Git rm cached что это
Setup and Config
Getting and Creating Projects
Basic Snapshotting
Branching and Merging
Sharing and Updating Projects
Inspection and Comparison
Patching
Debugging
External Systems
Server Admin
Guides
Administration
Plumbing Commands
Check your version of git by running
SYNOPSIS
DESCRIPTION
OPTIONS
The command removes only the paths that are known to Git.
For more details, see the pathspec entry in gitglossary[7].
Override the up-to-date check.
Don’t actually remove any file(s). Instead, just show if they exist in the index and would otherwise be removed by the command.
Allow recursive removal when a leading directory name is given.
This option can be used to separate command-line options from the list of files, (useful when filenames might be mistaken for command-line options).
Use this option to unstage and remove paths only from the index. Working tree files, whether modified or not, will be left alone.
Exit with a zero status even if no files matched.
Allow updating index entries outside of the sparse-checkout cone. Normally, git rm refuses to update index entries whose paths do not fit within the sparse-checkout cone. See git-sparse-checkout[1] for more.
git rm normally outputs one line (in the form of an rm command) for each file removed. This option suppresses that output.
REMOVING FILES THAT HAVE DISAPPEARED FROM THE FILESYSTEM
There is no option for git rm to remove from the index only the paths that have disappeared from the filesystem. However, depending on the use case, there are several ways that can be done.
When accepting a new code drop for a vendor branch, you probably want to record both the removal of paths and additions of new paths as well as modifications of existing paths.
Typically you would first remove all tracked files from the working tree using this command:
and then untar the new code in the working tree. Alternately you could rsync the changes into the working tree.
After that, the easiest way to record all removals, additions, and modifications in the working tree is:
Other ways
SUBMODULES
A submodule is considered up to date when the HEAD is the same as recorded in the index, no tracked files are modified and no untracked files that aren’t ignored are present in the submodules work tree. Ignored files are deemed expendable and won’t stop a submodule’s work tree from being removed.
If you only want to remove the local checkout of a submodule from your work tree without committing the removal, use git-submodule[1] deinit instead. Also see gitsubmodules[7] for details on submodule removal.
EXAMPLES
Removes all *.txt files from the index that are under the Documentation directory and any of its subdirectories.
Note that the asterisk * is quoted from the shell in this example; this lets Git, and not the shell, expand the pathnames of files and subdirectories under the Documentation/ directory.
