Git Шпаргалка | Список часто используемых команд
Специальной команды для этого нет, нужно выполнить ряд действий:
# переключиться на коммит к которому мы хотим откатить ветку git checkout hash> # создать новую ветку от текущего коммита и переключиться на нее git checkout -b new_tmp_branch # удалить старую ветку git branch -d old_branch_name # переименовать новую ветку в старое имя git branch -m new_tmp_branch old_branch_name # при необходимости прокинуть ветку в удаленный репозиторий и назначить отслеживание локальной веткой удаленной Прятанье источник
- спрятать изменения без коммита
git stash - просмотр списка спрятанных изменениц
git stash list - достать спрятанные изменения
# восстановить последние спрятанные данные git stash apply # восстановить последние спрятанные данные, без добавления файлов в индекс git stash apply --index # восстановить выбранные спрятанные данные git stash apply stash@2> - удалить спрятанные изменения
git stash drop stash@0> Работа с ветками
- создание ветки
git branch new-branch - переключение на ветку
git checkout new-branch - создание ветки и переключение на нее в одну команду
git checkout -b new-branch - удаление ветки
git branch -d branch-name - переименование ветки
git branch -m old_name new_name - просмотр веток
git branch -v - просмотр всех веток вместе с удаленными
git branch -a - просмотр только удаленных веток
git branch -r - совместный просмотр и локальных и удаленных веток с подробной информацией
git branch -avv - просмотр веток, влитых в текущую
git branch --merged - просмотр веток, не влитых в текущую
git branch --no-merged - Слияние веток
# все вливается в текущую ветку на которой вы находитесь, поэтому перед слиянием переключитесь на нужную ветку git checkout branch1-name # льем другую ветку в текущую git merge --no-ff branch2-name # если после слияния ветка не нужна, то можно ее удалить git branch -d branch2-name Работа с метками (тегами) источник
- просмотр списка тегов
git tag - поиск по маске
git tag -l 'v1.4.*' - создание аннотированной метки
git tag -a v1.4 -m 'my version 1.4' - создание легковесной метки
git tag v1.4 - добавление метки на созданный ранее коммит
git tag -a v1.2 -m 'version 1.2' [код коммита] - проталкивание данных о метках в удаленный репозиторий
# все git push origin --tags # одну конкретную git push origin v1.5 Просмотр логов
- просмотр лога
https://git-scm.com/book/ru/v1/%D0%9E%D1%81%D0%BD%D0%BE%D0%B2%D1%8B-Git-%D0%9F%D1%80%D0%BE%D1%81%D0%BC%D0%BE%D1%82%D1%80-%D0%B8%D1%81%D1%82%D0%BE%D1%80%D0%B8%D0%B8-%D0%BA%D0%BE%D0%BC%D0%BC%D0%B8%D1%82%D0%BE%D0%B2 git log git log -p git log --pretty=oneline --graph git log --pretty=format:"%h - %an, %ar : %s" gitk //это GUI утилита, в линукс потребуется установка через sudo apt-get install gitk - список коммитов, сделанных за последние две недели
git log --since=2.weeks // так же можно указать дату например "2008-01-15", // Опция --author позволяет фильтровать по автору, опция --grep позволяет искать по ключевым словам в сообщении - поиск по сообщениям коммитов
git log --all --grep='some text' Сравнение изменений
- сравнение текущих изменений с последним комитом
# все файлы git diff HEAD # определенный файл git diff HEAD fileName.ext - сравнение комитов между собой
git diff [commit_code_1] [commit_code_2] - просмотр объема правок перед коммитом
git count-objects -vH Работа с подмодулями
- привязка подмодуля
git submodule add path/to/submodule/folder - первичная инициализация подмодулей
git submodule init - получение/обновление содержимого подмодулей
git submodule update - просмотр списка подмодулей
git submodule status - Удаление подмодуля
mv a/submodule a/submodule_tmp git submodule deinit -f -- a/submodule rm -rf .git/modules/a/submodule git rm -f a/submodule # Note: a/submodule (no trailing slash) # or, if you want to leave it in your working tree git rm --cached a/submodule mv a/submodule_tmp a/submodule В случае получения ошибки “already exists in the index” при добавлении подмодуля:
#просмотреть наличие проиндексированных данных git ls-files —stage projectfolder # удалить данные из индекса git rm —cached projectfolder # повторно пытаемся добавить подмодуль git add submodule
Оптимизация репозитория
- Очистка логов
git reflog expire --all --expire=now - Запуск сборщика мусора
git gc --prune=now --aggressive Материалы для обучения
- Пошаговый учебник
- Видеокурс “Git для профессионалов” от http://pr-of-it.ru найдете при желании 🙂
- Статья о rebase и слиянии веток
- Обучающие видео http://monsterlessons.com/project/categories/git
- Полезные алиасы git команд https://habrahabr.ru/company/mailru/blog/318508/?utm_campaign=email_digest&utm_source=email_habrahabr&utm_medium=email_week_20170110&utm_content=link2post
- Шпаргалка по работе с Git http://eax.me/git-commands/
- Поддержание аккуратной истории в Git с помощью интерактивного rebase
установка средства сравнения
sudo aptitude install meld
0.2) создаем скрипт питона
cd ~/scriptHelpers touch diff.py
#!/usr/bin/python import sys import os os.system('meld "%s" "%s"' % (sys.argv[2], sys.argv[5])) 0.3) прописываем в настройках гита
git config –global diff.external ~/scriptHelpers/diff.py что бы отменить эту настройку используем git config –global –unset diff.external
Проверить что настройки применились git config –list
3) создание репозитория git init
добавление удаленного репозитория к текушему git remote add origin https://github.com/gdecider/tscc.git
проталкивание изменений в удаленный репозиторий git push -u origin master
клонирование репозитория в текущую папку git clone https://github.com/gdecider/tscc.git .
удаление файлов из подготовленных к коммиту git rm –cached если это папка, то добавляем флаг -r для рекурсивного удаления
git reset –hard HEAD git clean -f
Это отбросит все сделанные изменения которые вы возможно добавили в индекс git, а также все другие изменения в вашей рабочем дереве. Другими словами, результат этого — вывод команд “git diff” и “git diff –cached” будет пустым.
About MELD http://meldmerge.org/help/
1) Installing Meld on Ubuntu (http://linuxpitstop.com/install-meld-on-ubuntu-and-mint-linux/)
sudo apt-get update sudo apt-get install meld
настройки можно внести в глобальный файл настроек гита, который находится ~/.gitconfig [user] name = decider_op email = decider@ya.ru [core] editor = subl -n -w [diff] tool = meld [difftool] prompt = false [merge] tool = meld [mergetool] keepBackup = false или через команды
git config –global diff.tool meld git config –global merge.tool meld . . . и т.д.
— . то что ниже не проверено
git config –global mergetool.meld.trustExitCode false
// Fix git mergetool meld –help error git config mergetool.meld.hasOutput true
Для доступа к репозиторию нужно добавить SSH ключ в настройках аккаунта github https://help.github.com/articles/connecting-to-github-with-ssh/
0) Проверим есть ли ключ на ПК с которого нужно соединиться ls -al ~/.ssh
1) Сгенерируем ключ, если нет существующего ssh-keygen -t rsa -b 4096 -C “your_email@example.com”
На вопрос об имени файла можно оставить имя по умолчанию
На вопрос о пароле введите пароль или оставьте его пустым
2) Привязка ключа в аккаунт github Для получения содержимомо ключа выведем его на экран
Копируем то что вывелось в буфер обмена
Можно воспользоваться утилитой xcopy
В Вашем аккаунте GitHub идем в настройки, пункт SSH and GPG keys — New SSH key, вставляем скопированный ключ.
Git Submodules
Иногда возникает потребность использовать в проекте готовый модуль или библиотеку. Причем это может быть как стороннее решение, так и ваша собственная разработка. Вы можете скопировать код библиотеки в проект, либо подключить его с помощью пакетного менеджера вроде npm, Rubygems или Composer.
Но что если стабильной версии модуля нет, и ему еще требуется отладка и доработка? Система контроля версий Git позволяет подключать один репозиторий, как поддиректорию другого. Эти вложенные репозитории называются подмодулями Git. Такая структура удобна для разработки и тестирования — у вас будет система контроля версий для каждого репозитория, а также вы сможете отлавливать и исправлять ошибки прямо в подмодуле.
Помимо отладки, подмодули — способ абстрагировать какой-то компонент, чтобы его можно было использовать в нескольких проектах и дорабатывать независимо от основного приложения. Из этой статьи вы узнаете, как добавлять в проект git-подмодули и как работать с ними.
Добавление Git-подмодуля
Вам нужно зарегистрироваться на GitHub и создать репозиторий. Если вы не работали с этой системой контроля версий, то о первых шагах можно почитать в этой статье.
Склонируем Git-репозиторий на компьютер. Для этого переместимся в директорию с проектами, выполнив в консоли команду:
cd path/to/your/projects_folder
Затем создадим директорию project_dir и скопируем туда проект:
git clone https://github.com/your_user_name/project project_dir
Перейдем в только что созданную папку с проектом:
cd project_dir
Теперь добавим подмодуль. Вам потребуется адрес репозитория подмодуля и папка, в которой он должен оказаться:
git submodule add https://github.com/any_user_name/submodule_name submodules_folder/submodule_name
Если в проекте не было папки submodules_folder, она будет создана автоматически.
Копирование займет некоторое время. Когда оно завершится, вы увидите что-то подобное:
Cloning into ‘/path/to/your/project_dir/submodules_folder/submodule_name’. remote: Counting objects: 29875, done. remote: Compressing objects: 100% (51/51), done. remote: Total 29875 (delta 38), reused 65 (delta 33), pack-reused 29771 Receiving objects: 100% (29875/29875), 5.71 MiB | 85.00 KiB/s, done. Resolving deltas: 100% (18713/18713), done.
Если сейчас выполнить git status, вы заметите, что в проекте появились новые файлы:
git status On branch master Your branch is up-to-date with ‘origin/master’. Changes to be committed: (use «git reset HEAD <file>. » to unstage) new file: .gitmodules new file: submodule_name
Это конфигурационный файл .gitmodules и папка подмодуля, который вы только что добавили.
Теперь нам нужно зафиксировать изменения в репозитории. Для начала выберем файлы git add file1 file2.
git add .gitmodules submodule_name
Далее зафиксируем изменения локально. Не забываем про commit message после флага -m
git commit -m ‘Submodule submodule_name added’
И отправим изменения в репозиторий на GitHub:
Вы великолепны! Теперь другие разработчики могут склонировать ваш репозиторий с подмодулями и начать работу.
Клонирование проекта с подмодулями
Если вы склонировали репозиторий, а папки подмодулей оказались пустыми, то не удивляйтесь. Вам нужно выполнить две команды.
Так вы инициализируете локальный конфигурационный файл .gitmodules:
git submodule init
А затем загрузите подмодуль проекта в свою директорию командой:
git submodule update
Либо при клонировании проекта с подмодулями используйте флаг —recursive:
git clone —recursive https://github.com/your_user_name/project
После этого в папке подмодуля появятся его файлы.
Обновление подмодуля
Если вы хотите обновить подмодуль до актуальной версии, перейдите в его директорию и проверьте наличие изменений:
И затем для обновления локальной версии из ветки master репозитория подмодуля выполните:
Удаление подмодуля
Если вы хотите удалить подмодуль, избавиться от папки в проекте недостаточно — придется поправить ещё конфигурационные файлы. Итак, поехали.
1. Для начала необходимо удалить нужную секцию в файле .gitmodules.
[submodule «submodule_name»] path = submodule_name url = git://github.com/any_user_name/submodule_name.git
2. Зафиксировать изменения, выполнив:
git add .gitmodules
3. Удалить соответствующие модулю строки из .git/config. Это можно сделать, открыв файл в текстовом редакторе nano: nano .git/config
[submodule «submodule_name»] url = git://github.com/any_user_name/submodule_name.git
4. Удалить пути, созданные для подмодулей, из области индексирования:
git rm —cached path/to/submodule_name
Где path/to/submodule_name — путь к директории подмодуля.
5. Удалить каталог подмодуля:
rm -rf .git/modules/submodule_name
Где submodule_name — имя подмодуля.
6. Сделать коммит изменений.
7. Удалить ненужные файлы подмодулей:
rm -rf path/to/submodule_name
Итого
Git позволяет подключать в проекты модули или библиотеки в виде вложенных директорий. Подмодули обновляются независимо от главного репозитория и имеют свою систему контроля версий. Использование подмодулей удобно на этапе разработки и отладки, потому что в такой структуре удобно отслеживать и исправлять баги. А ещё с их помощью можно использовать свою библиотеку в нескольких проектах.
If you like this article, share a link with your friends
Read more
We talk about interesting technologies and share our experience of using them.
Вопросы и ответы по AWS CodeCommit
AWS CodeCommit – это безопасный высокомасштабируемый управляемый сервис управления исходным кодом, облегчающий специалистам совместную работу с кодом. С AWS CodeCommit вам не придется создавать собственную систему управления исходным кодом и заниматься масштабированием инфраструктуры для нее. AWS CodeCommit обеспечивает хранение любых ресурсов, от исходного кода до исполняемых файлов. Сервис эффективно интегрируется с существующими инструментами Git.
Вопрос. Что такое Git?
Git – это распределенная система управления версиями с открытым исходным кодом. Для работы с репозиториями AWS CodeCommit можно воспользоваться интерфейсом командной строки Git или любым подходящим клиентом Git. Дополнительные сведения о Git см. в документации Git. Дополнительные сведения о работе с AWS CodeCommit и Git см. на странице Начало работы с AWS CodeCommit.
Вопрос. Для кого предназначен сервис AWS CodeCommit?
AWS CodeCommit предназначен для разработчиков программного обеспечения, которым нужна безопасная, надежная и масштабируемая система управления исходным кодом для хранения кода и управления его версиями. Кроме того, AWS CodeCommit будет полезен всем, кому требуется простое в использовании, полностью автоматизированное хранилище данных с возможностью управления версиями. Например, системные администраторы могут использовать AWS CodeCommit для хранения скриптов и настроек. Веб-дизайнеры могут использовать AWS CodeCommit для хранения HTML-страниц и изображений.
Вопрос. Чем сервис AWS CodeCommit отличается от других систем управления исходным кодом на основе Git?
AWS CodeCommit предоставляет целый ряд возможностей, недоступных в других системах управления исходным кодом на основе Git.
- Полностью управляемый сервис. С AWS CodeCommit вам не придется заниматься размещением, обслуживанием, резервным копированием и масштабированием собственных серверов управления исходным кодом.
- Безопасность. Сервис AWS CodeCommit автоматически выполняет шифрование файлов при пересылке и хранении. AWS CodeCommit интегрирован с сервисом AWS Identity and Access Management (IAM), что позволяет назначать разрешения для ваших репозиториев на уровне пользователей.
- Высокая доступность. AWS CodeCommit работает на основе высокомасштабируемых, избыточных и надежных сервисов AWS, таких как Amazon S3 и Amazon DynamoDB.
- Масштабируемость. AWS CodeCommit позволяет хранить любое количество файлов без ограничений объема репозиториев.
- Ускоренный жизненный цикл разработки. С AWS CodeCommit ваши репозитории будут находиться в облаке AWS, в непосредственной близости от сред разработки и предпроизводственного тестирования, а также рабочей среды. Это повышает скорость жизненного цикла разработки и частоту обновлений.
Вопрос. Чем AWS CodeCommit отличается от корзины S3 с поддержкой управления версиями?
AWS CodeCommit предусматривает совместную разработку программного обеспечения. Он управляет пакетами изменений множества файлов, обеспечивает параллельную разработку и сравнение версий. Функция управления версиями сервиса Amazon S3 обеспечивает восстановление предыдущих версий отдельных файлов, но не поддерживает отслеживание пакетов изменений, охватывающих множество файлов, и другие возможности, требуемые для совместной разработки программного обеспечения.
Работа с AWS CodeCommit
Вопрос. Как начать работу с AWS CodeCommit?
Вы можете войти в Консоль управления AWS, создать репозиторий и начать работу с ним с помощью Git. Для знакомства с сервисом перейдите на страницу Начало работы, где приводится пошаговое руководство.
Вопрос. Как создать репозиторий?
Чтобы создать репозиторий, воспользуйтесь Консолью управления AWS, интерфейсом командной строки AWS, AWS SDK или API сервиса AWS CodeCommit.
Вопрос. Как обновлять файлы в репозитории?
Редактировать файлы можно непосредственно из консоли CodeCommit. Кроме того, для работы с репозиторием можно использовать Git. В качестве примера команды Git можно воспользоваться командой git clone, чтобы создать локальную копию репозитория AWS CodeCommit. Внесите изменения в локальные файлы и запустите команду git commit, чтобы сохранить изменения. Наконец, воспользуйтесь командой git push для загрузки изменений в репозиторий AWS CodeCommit. Пошаговые инструкции см. на странице Начало работы с AWS CodeCommit.
Вопрос. Как импортировать существующий репозиторий в AWS CodeCommit?
С помощью Git можно импортировать в AWS CodeCommit любой существующий репозиторий Git. Другие репозитории, например Subversion или Perforce, сначала нужно перенести в репозиторий Git с помощью инструмента импорта Git. Пошаговые инструкции по импорту репозиториев Git см. на странице Перенос существующего репозитория в AWS CodeCommit. Пошаговые инструкции по переносу локального или безверсионного контента см. в документации Git по выполнению миграции.
Вопрос. Какие операции Git в настоящее время поддерживает сервис AWS CodeCommit?
AWS CodeCommit в настоящее время поддерживает команды clone, pull, push и fetch.
Вопрос. Поддерживает ли AWS CodeCommit подмодули Git?
Да. AWS CodeCommit можно использовать с репозиториями Git, содержащими подмодули.
Вопрос. Каковы ограничения сервиса AWS CodeCommit?
Сведения о лимитах для сервиса см. в разделе Лимиты.
Вопрос. Какой максимальный размер отдельного файла допустим для сохранения его в CodeCommit?
Размер отдельного файла в репозитории может составлять не более 2 ГБ.
Вопрос. Как выполнять резервное копирование репозиториев?
Для восстановления данных можно использовать полную локальную копию репозитория, созданную командой git clone. Дополнительные резервные копии можно создавать разными способами. Один из них заключается в установке Git на сервере резервного копирования и запуске задания планировщика с использованием команды git clone для регулярного создания снимков состояния репозитория. Если требуется копировать только инкрементные изменения, вы можете воспользоваться командой git pull вместо команды git clone. Обратите внимание, что использование этих операций может увеличить затраты на количество пользователей и/или запросов в зависимости от ваших настроек сервера резервного копирования и частоты опросов.
Вопрос. Как восстановить удаленный репозиторий AWS CodeCommit?
Удаление репозитория AWS CodeCommit является необратимой операцией стирания данных. Для восстановления репозитория, который был удален, потребуется создать репозиторий заново и загрузить в него данные из резервной или локальной копии, полученной путем полного клонирования. Для ограничения круга пользователей с правами удаления репозиториев рекомендуется использовать политики IAM и защиту посредством многофакторной аутентификации. Дополнительные сведения см. в ответе на вопрос «Можно ли использовать AWS Identity and Access Management (IAM) для управления доступом к AWS CodeCommit?» в разделе «Безопасность» на этой странице вопросов и ответов.
Вопрос. Как выполнять проверку кода в AWS CodeCommit?
В сервисе CodeCommit поддерживается проверка кода. Кроме того, вы можете настроить разрешения на доступ к ветвям кода. При возникновении проблем с проверкой кода или назначением разрешений на уровне ветви, ознакомьтесь с соответствующей документацией.
Вопрос. Как интегрировать систему непрерывной интеграции с сервисом AWS CodeCommit?
Системы непрерывной интеграции можно настраивать для извлечения кода из AWS CodeCommit с помощью Git. Примеры использования систем непрерывной интеграции с сервисом AWS CodeCommit см. в публикации в блоге, посвященной интеграции AWS CodeCommit с Jenkins.
Вопрос. Как создавать объекты webhook с помощью AWS CodeCommit?
В консоли Amazon SNS можно создать тему SNS, указав для нее адрес сервера HTTP и URL для объекта webhook. Затем в консоли AWS CodeCommit вы сможете связать эту тему SNS с событием в репозитории с помощью триггеров. Кроме того, клиенты, использующие AWS Chatbot, могут настроить отправку оповещений в каналы Slack или чат‑комнаты Amazon Chime. Подробную информацию см. здесь.
Вопрос. Можно ли получить журнал всех вызовов API и операций Git AWS CodeCommit своего аккаунта для анализа уровня безопасности и текущего устранения неполадок?
Да. Последние события CodeCommit, в том числе операции Git и вызовы API, можно просмотреть в консоли AWS CloudTrail. Чтобы непрерывно записывать все события, создайте отслеживание и ведите журнал событий в корзине Amazon S3. Дополнительные сведения см. в разделе «Ведение журнала вызовов API AWS CodeCommit с помощью AWS CloudTrail».
Безопасность
Вопрос. Можно ли использовать AWS Identity and Access Management (IAM) для управления доступом к AWS CodeCommit?
Да. AWS CodeCommit поддерживает разрешения на уровне ресурсов. Для каждого репозитория AWS CodeCommit можно указать действия, разрешенные определенным пользователям. Можно также использовать для действий CodeCommit многофакторную аутентификацию (MFA) AWS. Это обеспечивает дополнительный уровень защиты от разрушительных действий, таких как удаление репозиториев. Можно установить контроль доступа клиентов Git не только к API AWS CodeCommit, но и к командам git pull и git push. К примеру, можно создать пользователя репозитория с правами только для чтения, разрешив ему выполнение команды git pull, но не команды git push. Дополнительные сведения по использованию IAM с сервисом AWS CodeCommit см. на странице аутентификации и контроля доступа для AWS CodeCommit. Дополнительные сведения об аутентификации доступа к API с использованием многофакторной аутентификации см. в разделе Настройка доступа к API с защитой посредством MFA.
Вопрос. Какие протоколы передачи данных поддерживает AWS CodeCommit?
Для обмена данными с AWS CodeCommit можно использовать как HTTPS, так и SSH. Для использования протокола HTTPS сначала необходимо установить интерфейс командной строки AWS. Интерфейс командной строки AWS позволяет установить Git credential helper, настраиваемый с использованием данных доступа AWS. Он автоматически подписывает все запросы HTTPS к AWS CodeCommit цифровой подписью в спецификации Signature Version 4. Для использования протокола SSH пользователи создают собственные пары публичных и частных ключей и добавляют публичные ключи к своим пользователям IAM. Частный ключ обеспечивает шифрование обмена данными с AWS CodeCommit. Пошаговые инструкции по настройке доступа по HTTPS и SSH см. на странице Настройка AWS CodeCommit.
Вопрос. Какие порты должны быть открыты в брандмауэре для доступа к AWS CodeCommit?
Вам потребуется открыть исходящий доступ в адрес сервиса AWS CodeCommit для порта 22 (SSH) или 443 (HTTPS).
Вопрос. Как можно шифровать репозитории в AWS CodeCommit?
Шифрование репозиториев при хранении выполняется автоматически. От пользователя не требуется дополнительных действий. Для шифрования репозиториев сервис AWS CodeCommit использует AWS Key Management Service (KMS). При создании первого репозитория в вашем аккаунте AWS будет создан ключ CodeCommit под управлением AWS. Дополнительные сведения см. на странице Шифрование репозиториев AWS CodeCommit.
Вопрос. Можно ли разрешить доступ к репозиторию для нескольких аккаунтов?
Да. Вы можете создать в своем аккаунте AWS роль IAM для предоставления доступа к репозиторию пользователям IAM других аккаунтов AWS. После этого пользователи IAM могут настроить свой интерфейс командной строки AWS для работы с сервисом AWS Security Token Service (STS) и использовать данную роль при запуске команд. Дополнительные сведения см. в разделе Использование роли документации по интерфейсу командной строки AWS.
git-rm
Удалите файлы, соответствующие спецификации пути, из индекса или из рабочего дерева и индекса. git rm не удалит файл только из вашего рабочего каталога. (There — нет возможности удалить файл только из рабочего дерева и при этом оставить его в индексе; используйте /bin/rm , если вы хотите сделать that.) Удаляемые файлы должны быть идентичны кончику ветки, и никакие обновления их содержимого не могут быть помещены в индекс, хотя это поведение по умолчанию можно переопределить с помощью параметра -f . При задании —cached промежуточное содержимое должно совпадать либо с верхушкой ветки, либо с файлом на диске, что позволяет удалить файл только из индекса. Когда используются разреженные проверки (см. git-sparse-checkout[1] ), git rm удалит пути только в шаблонах разреженной проверки.
Options
Файлы для удаления. Начальное имя каталога (e.g. dir для удаления dir/file1 и dir/file2 ) может быть задано для удаления всех файлов в каталоге и рекурсивно всех подкаталогов, но для этого требуется явно указанный параметр -r .
Команда удаляет только пути, известные Git.
Подстановка файлов соответствует границам каталогов. Таким образом, при наличии двух каталогов d и d2 существует разница между использованием git rm ‘d*’ и git rm ‘d/*’ , поскольку первый также удалит весь каталог d2 .
Дополнительные сведения см. в записи pathspec в gitglossary[7] .
Переопределить актуальную проверку.
На самом деле не удаляйте никакие file(s).. Вместо этого просто покажите, существуют ли они в индексе и в противном случае были бы удалены командой.
Разрешить рекурсивное удаление, если задано начальное имя каталога.
Этот параметр можно использовать для отделения параметров командной строки от списка файлов (полезно, когда имена файлов могут быть ошибочно приняты за имена командной строки options).
Используйте этот параметр, чтобы отменить подготовку и удалить пути только из индекса. Файлы рабочего дерева, независимо от того, изменены они или нет, останутся нетронутыми.
Выход с нулевым статусом, даже если файлы не совпадают.
Разрешить обновление записей индекса за пределами конуса разреженной проверки. Обычно git rm отказывается обновлять записи индекса, пути которых не соответствуют конусу разреженной проверки. См. git-sparse-checkout[1] для получения дополнительной информации.
git rm обычно выводит одну строку (в form команды rm ) для каждого удаленного файла. Эта опция подавляет этот вывод.
Pathspec передается в вместо аргументов командной строки. Если точно соответствует — , то используется стандартный ввод. Элементы Pathspec разделены символами LF или CR/LF.. Элементы Pathspec могут быть заключены в кавычки, как объяснено для переменной конфигурации core.quotePath (см. git-config[1] ). См. также —pathspec-file-nul и глобальный —literal-pathspecs .
Имеет смысл только с —pathspec-from-file . Элементы Pathspec разделены символом NUL, а все остальные символы воспринимаются буквально (включая символы новой строки и quotes).).
Удаление файлов, которые исчезли из файловой системы
У git rm нет возможности удалить из индекса только те пути, которые исчезли из файловой системы. Однако, в зависимости от варианта использования, есть несколько способов, которые можно сделать.
Использование «git commit -a»
Если вы предполагаете, что ваша следующая фиксация должна записывать все изменения отслеживаемых файлов в рабочем дереве и записывать все удаления файлов, которые были удалены из рабочего дерева с помощью rm (в отличие от git rm ), используйте git commit -a , так как он автоматически заметит и запишет все удаления. Вы также можете получить аналогичный эффект без фиксации, используя git add -u .
Используя «git добавить -A”
Принимая новое падение кода для ветки поставщика, вы, вероятно, захотите записать как удаление путей, так и добавление новых путей, а также модификации существующих путей.
Обычно вы сначала удаляете все отслеживаемые файлы из рабочего дерева с помощью этой команды:
git ls-files -z | xargs -0 rm -f
а затем распаковать новый код в рабочем дереве. В качестве альтернативы вы можете rsync внести изменения в рабочее дерево.
После этого проще всего зафиксировать все удаления, добавления и изменения в рабочем дереве:
git add -A
Other ways
Если все, что вы действительно хотите сделать, это удалить из индекса файлы, которых больше нет в рабочем дереве (возможно, из-за того, что ваше рабочее дерево грязное, поэтому вы не можете использовать git commit -a ), используйте следующую команду:
git diff --name-only --diff-filter=D -z | xargs -0 git rm --cached
Submodules
Только подмодули, использующие файл git (что означает, что они были клонированы с Git версии 1.7.8 или новее), будут удалены из рабочего дерева, поскольку их репозиторий находится в каталоге .git суперпроекта. Если подмодуль (или один из вложенных в него) по-прежнему использует каталог .git, git rm переместит каталог submodules git в каталог superprojects git, чтобы защитить историю подмодуля. Если он существует, раздел submodule. в файле gitmodules[5] также будет удален, и этот файл будет подготовлен (если только —cached или -n не являются used).).
Субмодуль считается обновленным, когда HEAD совпадает с записанным в индексе, никакие отслеживаемые файлы не изменяются и в рабочем дереве подмодулей нет неотслеживаемых файлов, которые не игнорируются. Игнорируемые файлы считаются расходными и не остановят удаление рабочего дерева подмодуля.
Если вы хотите удалить только локальное извлечение подмодуля из вашего рабочего дерева без фиксации удаления, используйте вместо этого git-submodule[1] deinit . Также см. gitsubmodules[7] для получения подробной информации об удалении субмодуля.
Examples
git rm Documentation/\*.txt
Удаляет из индекса все файлы *.txt , находящиеся в каталоге Documentation и любых его подкаталогах.
Обратите внимание, что в этом примере звездочка * взята из оболочки; это позволяет Git, а не оболочке, расширять пути к файлам и подкаталогам в каталоге Documentation/ .
Поскольку этот пример позволяет оболочке расширять звездочку (i.e., которую вы перечисляете, файлы explicitly), не удаляют subdir/git-foo.sh .
Bugs
Каждый раз, когда обновление суперпроекта удаляет заполненный подмодуль (e.g. при переключении между фиксациями до и после удаления, проверка устаревшего подмодуля останется в старом месте. Удаление старого каталога безопасно только в том случае, если он использует gitfile, так как в противном случае история подмодуля также будет удалена. Этот шаг станет устаревшим, когда будет реализовано рекурсивное обновление подмодуля.