Git удалить неотслеживаемые файлы

Обновлено: 05.07.2024

Команда git status отображает состояние рабочего каталога и раздела проиндексированных файлов. С ее помощью можно проверить индексацию изменений и увидеть файлы, которые не отслеживаются Git. Информация об истории коммитов проекта не отображается при выводе данных о состоянии. Для этого используется команда git log .

Связанные команды git

    • Теги — это ссылки, указывающие на определенные точки в истории Git. Команда git tag обычно используется для захвата некой точки в истории, которая используется для релиза нумерованной версии (например, v1.0.1).
    • Общее назначение git blame — отображение метаданных автора, связанных со строками, которые были внесены в файл при коммите. Таким образом можно проследить историю кода и выяснить, какой именно код был внесен в репозиторий, как это было сделано и по какой причине.
    • Команда git log отображает отправленные снимки состояния и позволяет просматривать и фильтровать историю проекта, а также проводить поиск по ней.

    Использование

    Выводит список проиндексированных и неотслеживаемых файлов, а также файлов, удаленных из индекса Git.

    Пояснения

    Игнорирование файлов

    Неотслеживаемые файлы обычно подразделяются на две категории: файлы, недавно добавленные в проект и пока не отправленные в качестве коммитов, либо скомпилированные бинарные файлы (например, .pyc , .obj , .exe и т. д.). Включать файлы первой категории в выходные данные git status очень полезно, в то время как файлы второй категории могут затруднить отслеживание изменений в репозитории.

    По этой причине в Git можно полностью игнорировать файлы, поместив пути к ним в специальный файл .gitignore . Каждый игнорируемый файл указывается в отдельной строке. При этом можно использовать символ * в качестве шаблона подстановки. Так, добавление следующего выражения в файл .gitignore в корневом каталоге проекта исключит скомпилированные модули Python из выходных данных git status :

    Пример

    Перед отправкой изменений рекомендуется проверить состояние репозитория. Так вы сможете убедиться, что коммит включает только нужные данные. В следующем примере показано состояние репозитория до и после индексирования и отправки снимка состояния:

    Первая строка данных о состоянии указывает на файл, который не был проиндексирован. Операция git add отражена во второй команде git status , а в последней строке данных сообщается, что элементы для коммита отсутствуют (рабочий каталог соответствует последнему коммиту). Для некоторых команд Git (например, git merge ) требуется очистка рабочего каталога, чтобы исключить случайную перезапись изменений.

    git log

    Команда git log отображает отправленные снимки состояния и позволяет просматривать и фильтровать историю проекта, а также искать в ней конкретные изменения. С помощью git status можно просматривать рабочий каталог и раздел проиндексированных файлов, в то время как git log показывает только историю коммитов.

    Существует множество вариантов для настройки выходных данных команды git log: от простой фильтрации коммитов до их отображения в пользовательском формате. Ниже показаны наиболее распространенные конфигурации git log .

    Использование

    Выводит полную историю коммитов в стандартном формате. Если выходные данные занимают более одного экрана, можно выполнить прокрутку с помощью клавиши Пробел или нажать q для выхода.

    Записывает каждый коммит в одну строку. Так можно получить подробный обзор всей истории проекта.

    Кроме обычных данных git log указывается, какие файлы были изменены, а также относительное число добавленных или удаленных строк в каждом из них.

    Выводит патчи, соответствующие определенным коммитам. Это самое подробное представление истории проекта, поскольку так можно просмотреть полный список изменений каждого коммита.

    Выполняет поиск коммитов конкретного автора. Аргумент

    может быть обычной строкой или регулярным выражением.

    . Этот аргумент может быть обычной строкой или регулярным выражением.

    Отображает только коммиты в диапазоне значений и . Эти аргументы могут быть идентификаторами коммитов, именами веток, указателями HEAD или другими ссылками на версии.

    Выводит только коммиты, содержащие указанный файл. Так можно удобно просмотреть историю конкретного файла.

    Пояснения

    Команда git log является основным инструментом Git для изучения истории репозитория. С помощью этой команды можно найти конкретную версию проекта или определить изменения, которые будут внесены при выполнении слияния в функциональной ветке.

    Большая часть этой информации проста для понимания, но все же первую строку стоит пояснить. Строка длиной 40 знаков, следующая за элементом commit , является контрольной суммой SHA‑1 содержимого коммита. Она играет роль механизма для обеспечения целостности коммита (при нарушении целостности контрольная сумма изменится) и служит для него уникальным идентификатором.

    Этот идентификатор может использоваться в таких командах, как git log .. , в качестве ссылки на конкретные коммиты. Так, команда git log 3157e..5ab91 отображает данные в диапазоне между коммитами с идентификаторами 3157e и 5ab91 . Кроме контрольных сумм, на конкретные коммиты указывают имена веток (см. раздел Модуль веток) и ключевое слово HEAD , которое всегда ссылается на текущий коммит, будь то ветка или конкретный коммит.

    используется для относительных ссылок на родительский элемент коммита. Например, 3157e

    1 ссылается на коммит, предшествующий коммиту 3157e , а HEAD

    3 находится на 3 уровня выше текущего коммита.

    Все перечисленные методы идентификации позволяют выполнять различные действия с конкретными коммитами. Обычно отправной точкой таких операций выступает команда git log , поскольку она позволяет найти нужные коммиты.

    Пример

    В разделе Использование приводится множество примеров использования git log , однако следует помнить, что в одной команде можно объединить несколько параметров:

    Эта команда выводит данные по всем изменениям, которые Джон Смит внес в файл hello.py .

    Синтаксис «..» удобно использовать при сравнении веток. В следующем примере показана команда для вывода краткого обзора всех коммитов, которые включены в ветку some-feature и не включены в main .

    Часто при работе над проектом, использующим Git, вам нужно исключить определенные файлы или каталоги из отправки в удаленный репозиторий. Здесь .gitignore файл .gitignore .

    Файл .gitignore указывает, какие неотслеживаемые файлы Git должен игнорировать.

    Какие файлы следует игнорировать?

    Игнорируемые файлы обычно представляют собой файлы для конкретной платформы или автоматически созданные файлы из систем сборки. Вот некоторые общие примеры:

    • Файлы времени выполнения, такие как файлы журнала, блокировки, кеша или временные файлы.
    • Файлы с конфиденциальной информацией, такой как пароли или ключи API.
    • Скомпилированный код, например .class или .o .
    • /node_modules зависимостей, например /vendor или /node_modules .
    • Каталоги сборки, например /public , /out или /dist .
    • Системные файлы, такие как .DS_Store или Thumbs.db
    • Файлы конфигурации IDE или текстового редактора .

    .gitignore Шаблоны

    Он использует шаблоны подстановки для сопоставления имен файлов с подстановочными знаками. Если у вас есть файлы или каталоги, содержащие шаблон подстановки, вы можете использовать одиночную обратную косую черту ( ) для экранирования символа.

    Комментарии

    Символ косой черты ( / ) представляет собой разделитель каталогов. .gitignore черта в начале шаблона относится к каталогу, в котором находится .gitignore .

    Если шаблон начинается с косой черты, он соответствует файлам и каталогам только в корне репозитория.

    Если шаблон не начинается с косой черты, он соответствует файлам и каталогам в любом каталоге или подкаталоге.

    Если шаблон заканчивается косой чертой, он соответствует только каталогам. Когда каталог игнорируется, все его файлы и подкаталоги также игнорируются.

    Буквальные имена файлов

    Шаблон Примеры совпадений
    /access.log access.log
    access.log access.log
    logs/access.log
    var/logs/access.log
    build/ build

    Подстановочные символы

    Шаблон Примеры совпадений
    *.log error.log
    logs/debug.log
    build/logs/error.log

    Шаблон Примеры совпадений
    logs/** Соответствует чему-либо в каталоге logs .
    **/build var/build
    pub/build
    build
    foo/**/bar foo/bar
    foo/a/bar
    foo/a/b/c/bar

    Шаблон Примеры совпадений
    access?.log access0.log
    access1.log
    accessA.log
    foo?? fooab
    foo23
    foo0s

    Квадратных скобок

    Шаблон Примеры совпадений
    *.[oa] file.o
    file.a
    *.[!oa] file.s
    file.1
    file.0
    access.2.log access.0.log
    access.1.log
    access.2.log
    file.[ac].out file.a.out
    file.b.out
    file.c.out
    file.[a-cx-z].out file.a.out
    file.b.out
    file.c.out
    file.x.out
    file.y.out
    file.z.out
    access.[!0-2].log access.3.log
    access.4.log
    access.Q.log

    Отрицательные паттерны

    Шаблон, который начинается с восклицательного знака ( ! ), Отменяет (повторно включает) любой файл, который игнорируется предыдущим шаблоном. Исключением из этого правила является повторное включение файла, если его родительский каталог исключен.

    Шаблон Примеры совпадений
    *.log
    !error.log    		 error.log или logs/error.log не будут проигнорированы

    .gitignore Пример

    Ниже приведен пример того, как может выглядеть ваш файл .gitignore :

    Местный .gitignore

    .gitignore файл .gitignore обычно помещается в корневой каталог репозитория. Однако вы можете создать несколько файлов .gitignore в разных подкаталогах вашего репозитория. Шаблоны в файлах .gitignore сопоставляются относительно каталога, в котором находится файл.

    Шаблоны, определенные в файлах, которые находятся в каталогах (подкаталогах) более низкого уровня, имеют приоритет над шаблонами в каталогах более высокого уровня.

    Локальные файлы .gitignore используются совместно с другими разработчиками и должны содержать шаблоны, полезные для всех других пользователей репозитория.

    Личные правила игнорирования

    Шаблоны, специфичные для вашего локального репозитория и не подлежащие распространению в другие репозитории, должны быть установлены в файле .git/info/exclude .

    Например, вы можете использовать этот файл, чтобы игнорировать файлы, сгенерированные из ваших личных инструментов проекта.

    Глобальный .gitignore

    Git также позволяет вам создать глобальный файл .gitignore , в котором вы можете определить правила игнорирования для каждого репозитория Git в вашей локальной системе.

    Файл можно назвать как угодно и хранить в любом месте. Чаще всего этот файл хранится в домашнем каталоге. Вам придется вручную создать файл и настроить Git для его использования.

    Например, чтобы установить

    /.gitignore_global в качестве глобального файла игнорирования Git, вы должны сделать следующее:

    Добавьте файл в конфигурацию Git:

    Откройте файл в текстовом редакторе и добавьте в него свои правила.

    Глобальные правила особенно полезны для игнорирования определенных файлов, которые вы никогда не хотите фиксировать, например файлов с конфиденциальной информацией или скомпилированных исполняемых файлов.

    Игнорирование ранее зафиксированных файлов

    Файлы в вашей рабочей копии можно отслеживать или нет.

    Чтобы проигнорировать файл, который был ранее зафиксирован, вам нужно деактивировать и удалить файл из индекса, а затем добавить правило для файла в .gitignore :

    Параметр --cached указывает git не удалять файл из рабочего дерева, а только удалять его из индекса.

    Чтобы рекурсивно удалить каталог, используйте параметр -r :

    Если вы хотите удалить файл и из индекса, и из локальной файловой системы, опустите параметр --cached .

    При рекурсивном удалении файлов используйте параметр -n , который выполнит «пробный запуск» и покажет вам, какие файлы будут удалены:

    Отладка файла .gitignore

    Иногда бывает сложно определить, почему игнорируется конкретный файл, особенно когда вы используете несколько файлов .gitignore или сложные шаблоны. Здесь пригодится команда git check-ignore с параметром -v , которая сообщает git отображать сведения о соответствующем шаблоне.

    Например, чтобы проверить, почему файл www/yarn.lock игнорируется, вы должны запустить:

    Вывод показывает путь к файлу gitignore , номер совпадающей строки и фактический шаблон.

    Команда также принимает в качестве аргументов более одного имени файла, и файл не обязательно должен существовать в вашем рабочем дереве.

    Отображение всех игнорируемых файлов

    Команда git status с параметром --ignored отображает список всех игнорируемых файлов:

    Выводы

    Файл .gitignore позволяет исключить файлы из репозитория. Файл содержит шаблоны подстановки, которые описывают, какие файлы и каталоги следует игнорировать.

    Если у вас есть какие-либо вопросы или отзывы, не стесняйтесь оставлять комментарии.

    В этом разделе мы подробно рассмотрим команду git clean . Команда git clean в некоторой степени является командой отмены действия. Можно также сказать, что git clean дополняет другие команды, такие как git reset и git checkout . Эти две команды нужны в работе с файлами, ранее добавленными в индекс отслеживания Git, в то время как git clean используется для операций с неотслеживаемыми файлами. Неотслеживаемые файлы — это файлы, которые созданы в рабочем каталоге репозитория, но еще не добавлены в индекс отслеживания репозитория с помощью команды git add . Рассмотрим различия между отслеживаемыми и неотслеживаемыми файлами более наглядно на следующем примере командной строки

    В примере создается новый репозиторий Git в каталоге git_clean_test . Далее создается отслеживаемый файл tracked_file , который включается в индекс Git, затем создается неотслеживаемый файл untracked_file и неотслеживаемый каталог untracked_dir . Далее вызывается команда git status — эта операция отображает данные о внутреннем состоянии отслеживаемых и неотслеживаемых изменений в Git. При текущем состоянии репозитория можно выполнить команду git clean , чтобы понять принцип ее работы.

    Если на этом этапе выполнить команду git clean в конфигурации по умолчанию, может возникнуть критическая ошибка. Выше показан пример такой ошибки. По умолчанию в Git используется глобальная настройка, которая требует при запуске git clean передавать команде параметр force. Это важный механизм обеспечения безопасности. Отменить действие команды git clean невозможно. По завершении выполнения git clean происходит окончательное удаление данных из файловой системы (как и в случае с командой rm), поэтому перед выполнением убедитесь, что неотслеживаемые файлы действительно нужно удалить.

    Распространенные параметры и варианты использования

    Мы рассмотрели поведение и особенности команды git clean. Теперь перейдем к изучению различных примеров использования git clean и сопутствующих параметров командной строки.

    Параметр -n запускает тестовый прогон команды git clean. Этот прогон позволяет определить файлы, которые будут удалены, без фактического удаления. Рекомендуется всегда сначала выполнять тестовый прогон git clean. Изучим работу параметра в демонстрационном репозитории, созданном ранее.

    Данные вывода указывают, что файл untracked_file будет удален при выполнении команды git clean . Обратите внимание, что каталог untracked_dir не указан в этих данных. По умолчанию git clean не обрабатывает каталоги рекурсивно. Это еще один механизм обеспечения безопасности, предотвращающий окончательное удаление по ошибке.

    Параметр force инициирует фактическое удаление неотслеживаемых файлов из текущего каталога. Этот параметр является обязательным, если для параметра конфигурации clean.requireForce не установлено значение false. При этом не будут удалены неотслеживаемые папки или файлы, указанные в файле .gitignore . Теперь выполним рабочий прогон git clean в демонстрационном репозитории.

    Эта команда выводит удаляемые файлы. Здесь видно, что файл untracked_file удален. Если на этом этапе выполнить команду git status или ls, можно также увидеть, что файл untracked_file удален и не может быть найден. По умолчанию git clean -f обрабатывает все неотслеживаемые файлы в текущем каталоге. Кроме того, параметру -f можно передать значение , чтобы удалить конкретный файл.

    Параметр -d сообщает команде git clean о том, что необходимо удалить также любые неотслеживаемые каталоги. Команда не обрабатывает их по умолчанию. Можно добавить параметр -d в предыдущие примеры:

    Здесь мы выполнили тестовый прогон команды, добавив комбинацию параметров -dn. Вывод команды показывает, что неотслеживаемый каталог untracked_dir будет удален. После выполнения принудительной команды clean мы видим, что каталог untracked_dir удален.

    При выпуске программного обеспечения принято использовать каталог сборки или распределения, не привязанный к индексу отслеживания репозитория. Каталог сборки содержит динамические артефакты сборки, создаваемые на основе исходного кода в репозитории. Обычно каталог сборки добавляется в файл репозитория .gitignore . Очистку этого каталога удобно выполнять вместе с удалением других неотслеживаемых файлов. При добавлении параметра -x команда git clean удалит в том числе игнорируемые файлы. Как и прежде, перед окончательным удалением рекомендуется выполнить тестовый прогон команды git clean. Параметр -x обрабатывает все игнорируемые файлы, а не только те, что используются в сборке проекта. К ним могут относиться различные непредвиденные файлы, такие как файлы конфигурации IDE ./.idea.

    Как и параметр -d, параметр -x можно передавать и сочетать с другими параметрами. В этом примере показана комбинация с параметром -f, которая удаляет неотслеживаемые файлы из текущего каталога вместе с файлами, обычно игнорируемыми Git.

    Интерактивный режим или интерактивная команда git clean

    Команду git clean можно использовать не только со специальными параметрами, которые были рассмотрены выше, но и в «интерактивном» режиме. Этот режим запускается с помощью параметра -i . Вернемся к демонстрационному репозиторию из первой части документа. Из этого начального состояния запустим интерактивный сеанс очистки.

    Мы запустили интерактивный сеанс с параметром -d , поэтому каталог untracked_dir также будет обработан. В интерактивном сеансе отобразится запрос What now> на применение одной из команд к неотслеживаемым файлам. Принцип работы команд вполне очевиден из их названия. Вкратце рассмотрим каждую из них в произвольном порядке, начиная с 6: help . Это позволит лучше понять назначение последующих команд.

    Эта простая команда выполняет выход из интерактивного сеанса.

    Данная команда удаляет выбранные элементы. Выполнение команды 1: clean на этом этапе приведет к удалению untracked_dir/ untracked_file .

    Эта команда обращается к каждому неотслеживаемому файлу и выводит запрос на его удаление ( Y/N ). Операция выглядит следующим образом:

    Эта команда выводит дополнительный запрос, который использует входные данные для фильтрации списка неотслеживаемых файлов.

    Ввод подстановочного шаблона *_file на этом этапе ограничит список неотслеживаемых файлов каталогом untracked_dir .

    Как и команда 2, команда 3 ограничивает список неотслеживаемых файлов. В интерактивном сеансе будут представлены номера, соответствующие именам неотслеживаемых файлов.

    Резюме

    Подведем итог: команда git clean представляет собой удобный способ удаления неотслеживаемых файлов в рабочем каталоге репозитория. Неотслеживаемые файлы — это файлы в каталоге репозитория, которые еще не добавлены в раздел проиндексированных файлов репозитория с помощью команды git add . Результат использования git clean в целом можно получить с помощью команды git status и встроенных средств удаления в операционной системе. Команду git clean можно использовать вместе с командой git reset для полной отмены изменений и коммитов в репозитории.

    Git рассматривает каждый файл в вашей рабочей копии как файл одного из трех нижеуказанных типов.

    1. Отслеживаемый файл — файл, который был предварительно проиндексирован или зафиксирован в коммите.
    2. Неотслеживаемый файл — файл, который не был проиндексирован или зафиксирован в коммите.
    3. Игнорируемый файл — файл, явным образом помеченный для Git как файл, который необходимо игнорировать.

    Игнорируемые файлы — это, как правило, артефакты сборки и файлы, генерируемые машиной из исходных файлов в вашем репозитории, либо файлы, которые по какой-либо иной причине не должны попадать в коммиты. Вот некоторые распространенные примеры таких файлов:

    • кэши зависимостей, например содержимое /node_modules или /packages ;
    • скомпилированный код, например файлы .o , .pyc и .class ;
    • каталоги для выходных данных сборки, например /bin , /out или /target ;
    • файлы, сгенерированные во время выполнения, например .log , .lock или .tmp ;
    • скрытые системные файлы, например .DS_Store или Thumbs.db ;
    • личные файлы конфигурации IDE, например .idea/workspace.xml .

    Игнорируемые файлы отслеживаются в специальном файле .gitignore , который регистрируется в корневом каталоге репозитория. В Git нет специальной команды для указания игнорируемых файлов: вместо этого необходимо вручную отредактировать файл .gitignore , чтобы указать в нем новые файлы, которые должны быть проигнорированы. Файлы .gitignore содержат шаблоны, которые сопоставляются с именами файлов в репозитории для определения необходимости игнорировать эти файлы.

    Шаблоны игнорирования в Git

    Для сопоставления с именами файлов в .gitignore используются шаблоны подстановки. С помощью различных символов можно создавать собственные шаблоны.

    Две звездочки (**) означают, что ваш файл .gitignore находится в каталоге верхнего уровня вашего репозитория, как указано в соглашении. Если в репозитории несколько файлов .gitignore, просто мысленно поменяйте слова «корень репозитория» на «каталог, содержащий файл .gitignore» (и подумайте об объединении этих файлов, чтобы упростить работу для своей команды)*.

    Если у вас есть файлы или каталоги, в имени которых содержатся спецсимволы шаблонов, для экранирования этих спецсимволов в .gitignore можно использовать обратную косую черту (\):

    Общие файлы .gitignore в вашем репозитории

    Обычно правила игнорирования Git задаются в файле .gitignore в корневом каталоге репозитория. Тем не менее вы можете определить несколько файлов .gitignore в разных каталогах репозитория. Каждый шаблон из конкретного файла .gitignore проверяется относительно каталога, в котором содержится этот файл. Однако проще всего (и этот подход рекомендуется в качестве общего соглашения) определить один файл .gitignore в корневом каталоге. После регистрации файла .gitignore для него, как и для любого другого файла в репозитории, включается контроль версий, а после публикации с помощью команды push он становится доступен остальным участникам команды. В файл .gitignore , как правило, включаются только те шаблоны, которые будут полезны другим пользователям репозитория.

    Персональные правила игнорирования в Git

    В специальном файле, который находится в папке .git/info/exclude , можно определить персональные шаблоны игнорирования для конкретного репозитория. Этот файл не имеет контроля версий и не распространяется вместе с репозиторием, поэтому он хорошо подходит для указания шаблонов, которые будут полезны только вам. Например, если у вас есть пользовательские настройки для ведения журналов или специальные инструменты разработки, которые создают файлы в рабочем каталоге вашего репозитория, вы можете добавить их в .git/info/exclude , чтобы они случайно не попали в коммит в вашем репозитории.

    Глобальные правила игнорирования в Git

    Кроме того, для всех репозиториев в локальной системе можно определить глобальные шаблоны игнорирования Git, настроив параметр конфигурации Git core.excludesFile . Этот файл нужно создать самостоятельно. Если вы не знаете, куда поместить глобальный файл .gitignore , расположите его в домашнем каталоге (потом его будет легче найти). После создания этого файла необходимо настроить его местоположение с помощью команды git config :

    Будьте внимательны при указании глобальных шаблонов игнорирования, поскольку для разных проектов актуальны различные типы файлов. Типичные кандидаты на глобальное игнорирование — это специальные файлы операционной системы (например, .DS_Store и thumbs.db ) или временные файлы, создаваемые некоторыми инструментами разработки.

    Игнорирование ранее закоммиченного файла

    Чтобы игнорировать файл, для которого ранее был сделан коммит, необходимо удалить этот файл из репозитория, а затем добавить для него правило в .gitignore . Используйте команду git rm с параметром --cached , чтобы удалить этот файл из репозитория, но оставить его в рабочем каталоге как игнорируемый файл.

    Опустите опцию --cached , чтобы удалить файл как из репозитория, так и из локальной файловой системы.

    Коммит игнорируемого файла

    Можно принудительно сделать коммит игнорируемого файла в репозиторий с помощью команды git add с параметром -f (или --force ):

    Этот способ хорош, если у вас задан общий шаблон (например, *.log ), но вы хотите сделать коммит определенного файла. Однако еще лучше в этом случае задать исключение из общего правила:

    Этот подход более прозрачен и понятен, если вы работаете в команде.

    Скрытие изменений в игнорируем файле

    Команда git stash — это мощная функция системы Git, позволяющая временно отложить и отменить локальные изменения, а позже применить их повторно. По умолчанию команда git stash ожидаемо не обрабатывает игнорируемые файлы и создает отложенные изменения только для тех файлов, которые отслеживаются Git. Тем не менее вы можете вызвать команду git stash с параметром --all, чтобы создать отложенные изменения также для игнорируемых и неотслеживаемых файлов.

    Отладка файлов .gitignore

    Если шаблоны .gitignore сложны или разбиты на множество файлов .gitignore , бывает непросто отследить, почему игнорируется определенный файл. Используйте команду git check-ignore с параметром -v (или --verbose ), чтобы определить, какой шаблон приводит к игнорированию конкретного файла:

    При желании команде git check-ignore можно передать несколько имен файлов, причем сами имена могут даже не соответствовать файлам, существующим в вашем репозитории.

    Читайте также: