Git не отслеживает файл

Обновлено: 02.07.2024

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

Помните, что каждый файл в вашем рабочем каталоге может находиться в одном из двух состояний: отслеживается или не отслеживается. Отслеживаемые файлы — это файлы, которые были в последнем моментальном снимке, а также любые недавно подготовленные файлы; они могут быть немодифицированными, модифицированными или поэтапными. Короче говоря, отслеживаемые файлы — это файлы, о которых Git знает.

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

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

Проверка статуса ваших файлов

Основной инструмент, который вы используете для определения того, в каком состоянии находятся файлы, — это команда git status. Если вы запустите эту команду сразу после клона, вы должны увидеть что-то вроде этого:

Это означает, что у вас есть чистый рабочий каталог; другими словами, ни один из ваших отслеживаемых файлов не изменяется. Git также не видит неотслеживаемых файлов, иначе они были бы перечислены здесь. Наконец, команда сообщает вам, на какой ветке вы находитесь, и сообщает, что она не отклонилась от той же ветки на сервере. На данный момент эта ветвь всегда master , которая используется по умолчанию; вы не будете беспокоиться об этом здесь. Git Branching подробно расскажет о ветках и ссылках.

Допустим, вы добавили в проект новый файл, простой файл README. Если файла раньше не существовало, и вы запускаете git status , вы видите свой неотслеживаемый файл следующим образом:

Вы можете видеть, что ваш новый файл README не отслеживается, потому что он находится под заголовком «Неотслеживаемые файлы» в выводе статуса. Неотслеживаемый в основном означает, что Git видит файл, которого у вас не было в предыдущем моментальном снимке (фиксации) и который еще не был подготовлен; Git не начнет включать его в ваши снимки коммитов, пока вы явно не скажете ему об этом. Это делается для того, чтобы вы случайно не начали включать сгенерированные двоичные файлы или другие файлы, которые вы не хотели включать. Вы действительно хотите включить README , так что давайте начнем отслеживать файл.

Отслеживание новых файлов

Чтобы начать отслеживать новый файл, используйте команду git add . Чтобы начать отслеживать файл README, вы можете запустить это:

Если вы снова запустите команду состояния, вы увидите, что ваш файл README теперь отслеживается и готовится к фиксации:

Вы можете сказать, что это постановочное, потому что оно находится под заголовком «Изменения, которые необходимо зафиксировать». Если вы зафиксируете в этот момент, версия файла на момент запуска git add будет такой же, как и в последующем историческом моментальном снимке. Вы можете вспомнить, что когда вы запускали git init ранее, вы затем запускали git add — это должно было начать отслеживать файлы в вашем каталоге. Команда git add принимает путь либо к файлу, либо к каталогу; если это каталог, команда рекурсивно добавляет все файлы в этом каталоге.

Подготовка измененных файлов

Давайте изменим уже отслеженный файл. Если вы измените ранее отслеживаемый файл с именем CONTRIBUTING.md, а затем снова запустите команду git status, вы получите что-то вроде этого:

Файл CONTRIBUTING.md отображается в разделе «Изменения, не подготовленные для фиксации». Это означает, что отслеживаемый файл был изменен в рабочем каталоге, но еще не подготовлен. Чтобы подготовить его, вы запускаете команду git add. 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 довольно полный, он также довольно многословен. Git также имеет краткий флаг состояния, чтобы вы могли видеть свои изменения в более компактном виде. Если вы запустите git status -s или git status --short, вы получите гораздо более упрощенный вывод команды:

Новые файлы, которые не отслеживаются, помечаются знаком ?? рядом с ними новые файлы, которые были добавлены в промежуточную область, имеют A , измененные файлы имеют M и так далее. На выходе есть два столбца: левый столбец указывает состояние промежуточной области, а правый столбец указывает состояние рабочего дерева. Так, например, в этом выводе файл README изменен в рабочем каталоге, но еще не подготовлен, а файл lib/simplegit.rb изменен и подготовлен. Rakefile был изменен, подготовлен и затем изменен снова, поэтому в нем есть изменения, которые являются как подготовленными, так и неустановленными.

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

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

Первая строка указывает Git игнорировать любые файлы, оканчивающиеся на «.o» или «.a» — объектные и архивные файлы, которые могут быть результатом сборки вашего кода. Вторая строка указывает Git игнорировать все файлы, имена которых заканчиваются на тильду ( ~ ), которая используется многими текстовыми редакторами, такими как Emacs, для пометки временных файлов. Вы также можете включить каталог log, tmp или pid; автоматически формируемая документация; и так далее. Настроить файл .gitignore для вашего нового репозитория перед тем, как вы начнете, как правило, хорошая идея, чтобы вы случайно не зафиксировали файлы, которые вам действительно не нужны в вашем репозитории Git.

Правила для шаблонов, которые вы можете поместить в файл .gitignore, следующие:

Стандартные шаблоны глобусов работают и будут применяться рекурсивно ко всему рабочему дереву.

Вы можете начинать шаблоны с косой черты ( / ), чтобы избежать рекурсии.

Вы можете заканчивать шаблоны косой чертой ( / ), чтобы указать каталог.

Вы можете отменить шаблон, начав его с восклицательного знака ( ! ).

Шаблоны Glob похожи на упрощенные регулярные выражения, используемые оболочками. Звездочка ( * ) соответствует нулю или более символов; [abc] соответствует любому символу в квадратных скобках (в данном случае a, b или c); знак вопроса ( ? ) соответствует одному символу; а скобки, заключающие символы, разделенные дефисом (7), соответствуют любому символу между ними (в данном случае от 0 до 9). Вы также можете использовать две звездочки для соответствия вложенным каталогам; a/**/z будет соответствовать a/z , a/b/z , a/b/c/z и т. д.

Вот еще один пример файла .gitignore:

В простом случае репозиторий может иметь один файл .gitignore в корневом каталоге, который рекурсивно применяется ко всему репозиторию. Однако также возможно иметь дополнительные файлы .gitignore в подкаталогах. Правила в этих вложенных файлах .gitignore применяются только к файлам в каталоге, в котором они расположены. Репозиторий исходного кода ядра Linux содержит 206 файлов .gitignore.

В задачу этой книги не входит детальное рассмотрение нескольких файлов .gitignore; подробности см. в man gitignore.

Просмотр поэтапных и неустановленных изменений

Если команда git status кажется вам слишком расплывчатой — вы хотите точно знать, что вы изменили, а не только то, какие файлы были изменены, — вы можете использовать команду git diff. Мы рассмотрим git diff более подробно позже, но вы, вероятно, будете использовать его чаще всего, чтобы ответить на эти два вопроса: что вы изменили, но еще не проиндексировали? И что вы инсценировали, что собираетесь совершить? Хотя git status отвечает на эти вопросы в общих чертах, перечисляя имена файлов, git diff показывает вам точные добавленные и удаленные строки — так сказать, патч.

Допустим, вы снова отредактировали и подготовили файл 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):

Вы можете видеть, что сообщение фиксации по умолчанию содержит последние выходные данные команды git status, закомментированные, и одну пустую строку сверху. Вы можете удалить эти комментарии и ввести сообщение о коммите или оставить их там, чтобы лучше помнить, что вы делаете.

Для еще более явного напоминания о том, что вы изменили, вы можете передать параметр -v в git commit . При этом в редакторе также отображается разница ваших изменений, чтобы вы могли точно видеть, какие изменения вы вносите.

Когда вы выходите из редактора, Git создает вашу фиксацию с этим сообщением фиксации (с удаленными комментариями и различиями).

Кроме того, вы можете напечатать сообщение фиксации вместе с командой фиксации, указав его после флага -m, например:

Теперь вы создали свой первый коммит! Вы можете видеть, что фиксация предоставила вам некоторую информацию о себе: какую ветку вы зафиксировали ( master ), какую контрольную сумму SHA-1 имеет фиксация ( 463dc4f ), сколько файлов было изменено и статистику о строках, добавленных и удаленных в зафиксировать.

Помните, что коммит записывает моментальный снимок, который вы настроили в своей тестовой области. Все, что вы не поставили, все еще находится там в измененном виде; вы можете сделать еще один коммит, чтобы добавить его в свою историю. Каждый раз, когда вы выполняете фиксацию, вы записываете моментальный снимок своего проекта, к которому можно вернуться или сравнить позже.

Пропуск области подготовки

Хотя это может быть удивительно полезно для создания коммитов именно так, как вы хотите, область подготовки иногда немного сложнее, чем вам нужно в вашем рабочем процессе. Если вы хотите пропустить промежуточную область, Git предоставляет простой ярлык. Добавление параметра -a к команде git commit заставляет Git автоматически публиковать каждый файл, который уже отслежен, перед выполнением фиксации, позволяя вам пропустить часть git add:

Обратите внимание, что в этом случае вам не нужно запускать git add для файла CONTRIBUTING.md перед фиксацией. Это потому, что флаг -a включает все измененные файлы. Это удобно, но будьте осторожны; иногда этот флаг заставит вас включить нежелательные изменения.

Удаление файлов

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

Если вы просто удалите файл из своего рабочего каталога, он появится в области «Изменения, не подготовленные для фиксации» (то есть не подготовленные) вашего вывода статуса git:

Затем, если вы запустите git rm , он поэтапно удалит файл:

При следующей фиксации файл исчезнет и больше не будет отслеживаться. Если вы изменили файл или уже добавили его в промежуточную область, вы должны принудительно удалить его с помощью параметра -f. Это функция безопасности, предотвращающая случайное удаление данных, которые еще не были записаны в моментальный снимок и которые нельзя восстановить из Git.

Еще одна полезная вещь, которую вы можете сделать, это оставить файл в рабочем дереве, но удалить его из области подготовки. Другими словами, вы можете захотеть сохранить файл на жестком диске, но Git больше не будет его отслеживать. Это особенно полезно, если вы забыли добавить что-то в свой файл .gitignore и случайно подставили его, например, большой файл журнала или кучу скомпилированных файлов .a. Для этого используйте параметр --cached:

Команде git rm можно передавать файлы, каталоги и шаблоны файловых шаблонов. Это означает, что вы можете делать такие вещи, как:

Обратите внимание на обратную косую черту ( \ ) перед * . Это необходимо, потому что Git выполняет собственное расширение имени файла в дополнение к расширению имени файла вашей оболочки. Эта команда удаляет все файлы с расширением .log в каталоге log/. Или вы можете сделать что-то вроде этого:

Эта команда удаляет все файлы, имена которых заканчиваются на ~ .

Перемещение файлов

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

Поэтому немного сбивает с толку наличие в Git команды mv. Если вы хотите переименовать файл в Git, вы можете запустить что-то вроде:

и это работает нормально. На самом деле, если вы запустите что-то подобное и посмотрите на статус, вы увидите, что Git считает это переименованным файлом:

Однако это эквивалентно запуску чего-то вроде этого:

Git неявно определяет, что это переименование, поэтому не имеет значения, переименовываете ли вы файл таким образом или с помощью команды mv. Единственная реальная разница в том, что git mv — это одна команда вместо трех — это функция удобства. Что еще более важно, вы можете использовать любой инструмент, который вам нравится, для переименования файла и обращения к add/rm позже, до фиксации.

Я клонировал проект, содержащий несколько файлов .csproj. Мне не нужно/не нравится, чтобы мои локальные файлы csproj отслеживались Git (или вызывались при создании патча), но очевидно, что они необходимы в проекте.

Я добавил *.csproj в свой LOCAL .gitignore , но файлы уже находятся в репозитории.

Когда я набираю git status, он показывает мои изменения в csproj, которые мне не интересно отслеживать или отправлять на исправления.

Как мне удалить "отслеживание" этих файлов из моего личного репозитория (но оставить их в исходном коде, чтобы я мог их использовать), чтобы я не видел изменений, когда я делаю статус (или создаю исправление )?

Есть ли правильный/канонический способ справиться с этой ситуацией?

@Cupcake, вопрос, на который вы ссылаетесь, был написан через 15 дней после этого? Возможно, вы имеете в виду другое?

Канонические вопросы @marflar не обязательно должны быть самыми старыми, достаточно лучшими. У того, на который я ссылаюсь, 20 ответов, а у этого только 5.

20 ответов 20

Достаточно просто вызвать git rm --cached для каждого файла, который вы хотите удалить из системы контроля версий. Пока ваши локальные шаблоны игнорирования верны, вы не увидите эти файлы, включенные в вывод git status.

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

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

Что вы, вероятно, хотите сделать: (ответ @Ryan Taylor снизу)

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

"git rm --cached " удаляется из системы контроля версий, но остается в рабочем репозитории. Является ли это тем, что вы хотите.

Но когда другие будут извлекать репозиторий, будет ли удален их собственный файл *.csproj? Потому что, если мы хотим, чтобы файл не отслеживался, но не удалялся.

Если вы пытаетесь удалить ВСЕ файлы в каталоге, объедините его с git ls-files: git ls-files | xargs git rm --cached -- это удалит все из индекса git в данном каталоге без удаления самих файлов.

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

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

git rm --cached или git rm -r --cached

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

Это нужно для того, чтобы сообщить Git, что вам нужна собственная независимая версия файла или папки. Например, вы не хотите перезаписывать (или удалять) рабочие/промежуточные файлы конфигурации.

Важно знать, что git update-index не будет распространяться вместе с Git, поэтому каждому пользователю придется запускать его независимо.

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

Очень хороший ответ. Но git выдает ошибку, когда я пытаюсь переключиться на другую ветку: ошибка: «Ваши локальные изменения в следующих файлах будут перезаписаны при проверке». И решение состоит в том, чтобы спрятать изменения перед переключением и удалить, когда вы вернетесь к филиал.

@RyanTaylor, возможно ли сохранить свою собственную локальную версию файла, не отправляя свои собственные изменения, но при этом извлекая изменения, которые отправляются в репозиторий?

Если вы выполните команду git update-index --assume-unchanged file.csproj , git не будет автоматически проверять наличие изменений в файле csproj: это предотвратит их появление в статусе git при каждом изменении. Таким образом, вы можете пометить все свои файлы .csproj, хотя вам придется вручную помечать любые новые файлы, которые вам отправляет вышестоящий репозиторий. (Если они есть в вашем .gitignore или .git/info/exclude , то созданные вами будут игнорироваться)

Я не совсем уверен, что такое файлы .csproj. если они представляют собой что-то вроде конфигураций IDE (аналогично файлам Eclipse .eclipse и .classpath), то я бы предложил, чтобы они вообще никогда не контролировались исходным кодом. С другой стороны, если они являются частью системы сборки (например, Makefiles), то, очевидно, они должны --- и был бы полезен способ получить необязательные локальные изменения (например, из local.csproj а-ля config.mk). : разделите компоновку на глобальные части и локальные переопределения.

Это единственный правильный ответ здесь! Я использую ответ @araqnids в течение многих лет, и он работает точно так, как требуется для решения этой проблемы.

Есть ли способ определить, что это было сделано для файла или для каких файлов это было сделано в репозитории? Я немного нервничаю из-за того, что забыл, что сделал это, а потом удивляюсь, почему, черт возьми, этот файл не обновляется позже!

@GreenAsJade: git ls-files -v покажет файлы, которые считаются неизмененными, с индикатором нижнего регистра (например, h вместо обычного H для кэшированных файлов).

Это двухэтапный процесс:

Удалить отслеживание файла/папки, но оставить их на диске, используя

Теперь они не отображаются как "измененные", а по-прежнему отображаются как

Добавить их в .gitignore

Нет, это удалит файл из списка отслеживания, сохранит его локально, но приведет к удалению его для всех, кто извлечет.

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

Принятый ответ по-прежнему не работает для меня

git rm -r --cached .

git add .

git commit -m "исправление .gitignore"

Нашел ответ здесь

Комментарий @Edward Newell, как и в приведенном выше ответе, применим и здесь: «это удалит файл из отслеживания, сохранит его локально, но приведет к его удалению для всех, кто извлекает » .

Если у вас есть весь проект локально, но вы забыли добавить git ignore и теперь отслеживаете некоторые ненужные файлы, используйте эту команду, чтобы удалить все

убедитесь, что вы находитесь в корне проекта.

Тогда вы можете сделать как обычно

Зафиксировать

Заключение

Надеюсь, это поможет людям, которые должны внести изменения в свой .gitignore или забыли все это вместе.

Удаляет весь кеш
Просматривает ваш .gitignore
Добавляет файлы, которые вы хотите отслеживать
Отправляет в репозиторий

Когда вы говорите об удалении или добавлении, вы забываете сказать, когда и где. Удаление из списка треков? Из репозитория? Из локального пространства проекта? Удаление на вытяжку? При фиксации? При толчке? Увы, у всех авторов здесь одна и та же проблема.

@Gangnus Я не думаю, что кто-то «уточнил» то, что вы пытаетесь донести, потому что совершенно очевидно, что файл на самом деле не удаляется с диска или из хранилища. Этот ответ указывает хронологический порядок команд. Это не загадочно и не плохо объяснено, как можно предположить из вашего комментария.

Как указано в других ответах, выбранный ответ неверен.

Ответ на другой вопрос предполагает, что может потребоваться skip-worktree.

--assume-untchanged предполагает, что разработчик не должен изменять файл. Этот флаг предназначен для повышения производительности неизменяемых папок, таких как SDK.

--skip-worktree полезен, когда вы указываете git никогда не трогать определенный файл, потому что разработчики должны его изменить. Например, если основной репозиторий восходящей ветки содержит несколько готовых к работе файлов конфигурации, и вы не хотите случайно зафиксировать изменения в этих файлах, --skip-worktree — это именно то, что вам нужно.

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

Нет, не совсем так: --skip-worktree используется для сохранения файла в репозитории, но прекращения отслеживания его изменений. Как говорится в вашем ответе: --skip-worktree полезен, когда вы указываете git никогда не трогать определенный файл, потому что разработчики должны его изменить

@ЭрдалГ. Точно. Согласно вопросу, они хотят игнорировать любые изменения в файле, но сохранить файл в репозитории

Согласитесь с @the_new_mr , --assume-untchanged и --skip-worktree имеют одинаковый эффект, но их цели совершенно разные. Первый предназначен для ускорения работы git, обманывая git не проверять определенные файлы, а второй — для игнорирования будущих изменений в определенных файлах, которые подходят для среды выполнения. но важные файлы.

Чтобы предотвратить мониторинг файла или пути с помощью git

Чтобы вернуть его обратно, используйте

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

git rm --cached app/**/*.xml

git rm --cached -r приложение/виджеты/вашапапка/

Многие советуют использовать git update-index --assume-untchanged . Действительно, это может быть хорошим решением, но только в краткосрочной перспективе.

Возможно, вы захотите сделать следующее: git update-index --skip-worktree .

(Третий вариант, который вам, вероятно, не нужен: git rm --cached . Он сохранит ваш локальный файл, но будет помечен как удаленный из удаленного репозитория.)

Разница между первыми двумя вариантами?

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

Случай использования предположения без изменений

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

Мне нравится использовать его, когда я хочу только на некоторое время прекратить отслеживать изменения + зафиксировать кучу файлов ( git commit -a ), связанных с одной и той же модификацией.

Случай использования skip-worktree

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

1. Создайте первую версию этого класса, заполните поля, которые вы можете заполнить, и оставьте остальные пустыми/нулевыми.
2: зафиксируйте и отправьте на удаленный сервер.
3: git update-index --skip-worktree MySetupClass.java
4. Обновите класс конфигурации с помощью собственных параметров.
5. Вернитесь к работе над другой функциональностью.

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

PS: сделайте одно или другое, но не оба, так как у вас будут нежелательные побочные эффекты. Если вы хотите попробовать другой флаг, сначала отключите последний.

В Git игнорируемые файлы отслеживаются в файле с именем .gitignore. У вас есть возможность добавить в этот файл пути к файлам и каталогам, которые вы не хотите отслеживать с помощью Git. Почти все программисты, работающие с Git, хотят узнать, как перестать отслеживать файлы, которые уже были вставлены в репозиторий git. Этот фрагмент предназначен для объяснения процесса остановки отслеживания и игнорирования изменений в файле в Git. .gitignore предотвратит добавление неотслеживаемых файлов в набор файлов, отслеживаемых Git, однако Git продолжит отслеживать уже отслеживаемые файлы, даже если они будут добавлены в .gitignore .

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

Если у вас есть отслеживаемый файл и вы хотите игнорировать его, вам нужно добавить путь к этому файлу или каталогу в файл .gitignore. После этого вам нужно сказать Git, чтобы он не отслеживал его. Для этого вам нужно запустить следующую команду:

Если вы хотите сделать это для папок, а не для файлов, вам следует добавить параметр -r к приведенной выше команде следующим образом:

Приведенные выше команды сохраняют для вас локальные игнорируемые файлы или каталоги. Однако, если кто-то другой потянет, эти файлы будут удалены для него.

Предположим, у вас есть папка, содержащая множество файлов. Следующая команда указывает Git прекратить каждый раз проверять эту папку на наличие изменений, поскольку в ней их не будет. Индекс --assume-unchanged будет сброшен, а файлы будут перезаписаны, если при извлечении в файл или папку будут внесены восходящие изменения. Поскольку идея заключается в игнорировании локальных изменений, вы можете удалить их все, выполнив команду git reset --hard.

Чтобы получить список каталогов или файлов --assume-unchanged , вы должны выполнить следующую команду:

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

Что такое репозиторий Git

Репозиторий Git служит специальным хранилищем для файлов вашего проекта. С помощью репозитория git можно сохранять версии своего кода, а также иметь к ним доступ. Если вы хотите создать новый репозиторий git, вам нужно запустить команду git init. Он используется один раз для инициализации нового репозитория. Еще одна одноразовая операция — команда git clone, с помощью которой можно создать клон существующего репозитория.

Что такое команда git rm

Команда git rm может удалить отдельные файлы или группу файлов из репозитория git. Вы также можете использовать его для удаления файлов из рабочего каталога и промежуточного индекса. Но удалить файл только из рабочего каталога невозможно. Команда git rm также не удаляет ветки.

Что такое файл .gitignore

Как правило, Git классифицирует файлы рабочей копии по трем параметрам:

Отслеживаемый файл — тот, который был зафиксирован или подготовлен ранее;
Неотслеживаемый файл — тот, который не был зафиксирован или помещен ранее;
Игнорируемый файл — тот, который был проигнорирован.

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

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

В этом руководстве вы узнаете, как:

Используйте gitignore для предотвращения отслеживания файлов
Игнорировать файлы только в вашей системе
Игнорировать файлы во всех репозиториях в вашей системе
Игнорировать изменения в зафиксированных файлах

Используйте gitignore для предотвращения отслеживания файлов

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

Создайте .gitignore

В Visual Studio 2019 версии 16.8 и более поздних версиях есть новое меню Git для управления рабочим процессом Git с меньшим переключением контекста, чем в Team Explorer. Процедуры, представленные в этой статье на вкладке Visual Studio 2019, предоставляют информацию об использовании возможностей Git, а также Team Explorer. Дополнительные сведения см. в разделе Сравнение Git и Team Explorer.

Visual Studio автоматически создает файл .gitignore в вашем репозитории, когда вы создаете новый репозиторий для своего проекта.

Загрузите файл шаблона .gitignore для своего типа проекта и настройте его в соответствии со своими потребностями. Если ваш проект не соответствует шаблону, вы можете создать пустой файл .gitignore из командной строки. Перейдите в репозиторий Git и выполните одну из следующих команд, используя информацию о репозитории:

Окна

Linux и macOS

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

Настройте свой .gitignore

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

Вы можете отредактировать файл .gitignore для своего репозитория, перейдя в представление "Настройки" в Team Explorer и выбрав "Настройки репозитория". Выберите Изменить для вашего .gitignore.

Используйте текстовый редактор, например следующий пример, в котором используется Vim:

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

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

Игнорировать файлы только в вашей системе

Ваш файл .gitignore передается членам команды в виде файла, зафиксированного и отправленного в репозиторий Git. Чтобы исключить файлы только в вашей системе, отредактируйте файл .git/info/exclude в локальном репозитории. Изменения в этом файле недоступны другим пользователям. Они применяются только к файлам в этом репо. Синтаксис этого файла такой же, как и в .gitignore.

Игнорировать файлы во всех репозиториях в вашей системе

Настройте глобальный файл .gitignore для использования во всех репозиториях в вашей системе с помощью инструмента git config из командной строки, как показано в следующем примере:

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

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

Временно игнорировать изменения

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

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

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

Чтобы отключить отслеживание изменений:

Чтобы возобновить отслеживание изменений:

Навсегда прекратить отслеживание файла

Если файл уже отслеживается Git, .gitignore не применяется. Git продолжит отслеживать изменения в этом файле.

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

Добавьте файл в свой .gitignore .

Выполните следующую команду:

Зафиксируйте удаление файла и обновленного .gitignore в своем репозитории.

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