Git - почему git игнорирует мой измененный файл?

Что если файлы из gitignore уже добавлены в репозиторий

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

Нам придется вручную их удалить из репозитория.

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

git rm --cached `git ls-files -i --exclude-from=.gitignore`

То же самое для Powershell

foreach ($i in iex 'git ls-files -i --exclude-from=.gitignore') { git rm --cached $i }

При выполнении этой команды, файлы останутся у вас на диске, однако из репозитория они будут удалены.

Либо можно удалять файлы вручную, таким образом:

git rm --cached path/to/file

Либо если нам нужно удалить целую директорию из git, то воспользуемся следующей командой:

git rm  -r --cached path/to/directory

Либо так мы могли бы удалить все файлы с расширением .log в папке log:

git rm --cached log/\*.log

Параметр означает, что файлы будут удалены только из раздела «проиндексированных файлов».
На диске (рабочем каталоге) они останутся нетронутыми.

Прочие команды и необходимые возможности

Хэш — уникальная идентификация объектов

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

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

Ищет разницу текущего состояния проекта и коммита за номером… сами видите,
каким:

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

Иногда хватает и четырех символов:

Читает лог с коммита по коммит:

Разумеется, человеку пользоваться хэшами не так удобно, как машине, именно
поэтому были введены другие объекты — тэги.

git tag — тэги как способ пометить уникальный коммит

Тэг (tag) — это объект, связанный с коммитом; хранящий ссылку на сам коммит,
имя автора, собственное имя и некоторый комментарий. Кроме того, разработчик
может оставлять на таких тегах собственную цифровую подпись.

Кроме этого в git представленные так называемые «легковесные тэги» (lightweight
tags), состоящие только из имени и ссылки на коммит. Такие тэги, как правило,
используются для упрощения навигации по дереву истории; создать их очень легко.

Создаёт «легковесный» тэг, связанный с последним коммитом; если тэг уже есть,
то еще один создан не будет:

Помечает определенный коммит:

Удаляет тег:

Перечисляет тэги:

Создаёт тэг для последнего коммита, заменяет существующий, если таковой уже был:

После создания тэга его имя можно использовать вместо хэша в любых командах
вроде git diff, git log и так далее:

Обычные тэги имеет смысл использовать для приложения к коммиту какой-либо
информации, вроде номера версии и комментария к нему. Иными словами, если в
комментарии к коммиту пишешь «исправил такой-то баг», то в комментарии к тэгу по
имени «v1.0» будет что-то вроде «стабильная версия, готовая к использованию».

Создаёт обычный тэг для последнего коммита; будет вызван текстовый редактор для
составления комментария:

Создаёт обычный тэг, сразу указав в качестве аргумента комментарий:

Команды перечисления, удаления, перезаписи для обычных тэгов не отличаются от
команд для «легковесных» тэгов.

Относительная адресация

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

Если после «птички» поставить цифру, то можно адресоваться по нескольким предкам
коммитов слияния:

Ищет изменения по сравнению со вторым предком последнего коммита в master; HEAD
здесь — указатель на последний коммит активной ветки.

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

Что привнес «дедушка» нынешнего коммита:

То же самое:

Обозначения можно объединять, чтобы добраться до нужного коммита:

Файл .gitignore — объясняем git, какие файлы следует игнорировать

Иногда по директориям проекта встречаются файлы, которые не хочется постоянно
видеть в сводке git status. Например, вспомогательные файлы текстовых редакторов,
временные файлы и прочий мусор.

Заставить git status игнорировать определенные файлы можно, создав в корне или
глубже по дереву (если ограничения должны быть только в определенных директория)
файл .gitignore. В этих файлах можно описывать шаблоны игнорируемых файлов
определенного формата.

Пример содержимого такого файла:

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

Серверные команды репозитория

Команда создания вспомогательных файлов для dumb-сервера в $GIT_DIR/info и
$GIT_OBJECT_DIRECTORY/info каталогах, чтобы помочь клиентам узнать, какие ссылки
и пакеты есть на сервере:

Проверяет сколько объектов будет потеряно и объём освобождаемого места при
перепаковке репозитория:

Переупаковывает локальный репозиторий:

Git add

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

1) Давайте просто начнем с добавления одного файла к заявке. Чтобы использовать команду git add, просто введите git add filename. Слово filename здесь относится к имени файла, который вы редактировали, например CustomerData_IND.txt. Кроме того, используйте команду git status, чтобы увидеть, что git теперь может рассказать нам о состоянии репозитория.

Changes to be comitted: здесь отображается информация о отслеживаемых файлах, хранящихся на промежуточном этапе. Это тот самый, который мы добавили с помощью команды git add.

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

Ответы 3

Ниже приведены шаги для решения проблемы «Не зарегистрированы поставщики системы контроля версий».

1) Установите GIT

2) Убедитесь, что GIT добавлен в переменную среды Path. Вы можете проверить, установлена ли установка GIT, набрав «CTRL + SHFT + P» в VS Code и введя «GIT: Show Git Output». См. Снимок экрана ниже

3) Код Visual Studio ожидает, что репозиторий GIT будет загружен в него с использованием открытой папки. Вам необходимо вручную клонировать репозиторий GIT и загрузить его в Visual Studio, используя «Открыть папку» в меню файла или на боковой панели.

4) Теперь на вкладке Source Control вы обнаружите, что GIT успешно интегрирован.

Комментарии (3)

Единственное, что вам нужно сделать, чтобы решить проблему, это открыть папку appdata folder:

победа + r
напишите% appdata% и ENTER
удалить папку кода.
Снова запустить код VS

Он перезапущен. Теперь вы можете увидеть доступный значок git.

Комментарии (1)

Я была такая же проблема. Дважды проверьте, что у вас включены правильные настройки:

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

Вы также можете создать файл .p4config в корне вашей рабочей области с переменными perforce.

Я настроил свойства в настройках рабочего процесса и установил для perforce.activationMode значение , и теперь он работает.

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

PS: Почему ни один из других ответов не относится к Perforce?

Другие вопросы по теме

Сворачивание кода vs на основе скобок — без отступовОтладка юнит-тестов jest с помощью приложения create-response-app не достигает точки останова в vscodeКак заставить среду разработки visual studio code использовать ‘/’ для путей в windowsКомментирование блока свернутого кода приводит к его развертыванию в коде visual studio.Путь к исполняемому файлу php в visualstudio в докереC#: время компиляции кода visual studioКод vs: есть ли способ игнорировать файлы в git?Ошибка отладки ansible-playbookКак я могу пропустить знаки доллара при создании сниппетов?Расширение visual studio code помечено как вредоносное, как (принудительно) установить?

2 ответа

Лучший ответ

никогда не обещает показать вам, что вы на самом деле сделали, или какой-то особый способ для достижения достигнутого вами результата. Он обещает только показать некоторый набор добавленных и удаленных строк (или в режиме word-diff, слова), которые достигнут того же результата.

Помимо этого, с различными опциями ignore-white-space-changes, кажется странным, что Git выбрал бы отображение последовательности, которая говорит: «удалите некоторые строки, а затем поместите некоторые из них обратно»

Обратите внимание, что в нем также сказано удалить исходный , а затем добавить обратно новый , который визуально (то есть, игнорируя любые изменения пробелов, такие как табуляция-пробелы), выглядит идентичным

Способ отладки и / или диагностики этого заключается в том, чтобы предоставить фактические файлы «до и после» или некоторое их подмножество, которое продолжает показывать то же самое поведение при запуске , кому-то, кто имеет время и интерес, чтобы выяснить, почему представил разницу, которая была визуально неоптимальной.

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

для игнорирования пробелов предназначены для того, чтобы сделать результат более визуально релевантным, но в этом случае, похоже, не получается

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

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

torek
7 Дек 2019 в 20:46

Смотрите документацию ( или ):

Таким образом, эта опция игнорирует изменения , которые содержат только пустые строки, но по-прежнему показывают их.

Смотрите мой тест:

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

dan1st
7 Дек 2019 в 15:37

Инструмент 2: Pull Requests

Pull Requests — отличный способ внести свой вклад в репозиторий, сделав его форк. В конце дня, если мы хотим, мы можем отправить pull request владельцу репозитория, чтобы объединить наши изменения кода. Сам pull request может включать обсуждение качества кода, функций или даже общей стратегии.

Давайте теперь рассмотрим основные шаги для pull request.

Инициирование pull request

В Github есть две модели для pull request:

Модель Fork & Pull — используется в общедоступном репозитории, на который у вас нет push-доступа
Share Repository Model — используется в частном репозитории, на который у нас есть push-доступ. В этом случае форк не требуется.

Здесь мы видим рабочий процесс между двумя пользователями ( и ) для модели Fork and Pull:

Определите репозиторий Github, в который вы хотите внести свой вклад, и нажмите кнопку «Fork», чтобы создать клон репозитория в вашей собственной учетной записи Github:
Это создаст точную копию репозитория в вашем собственном аккаунте
Выберите URL-адрес SSH, чтобы он запрашивал вашу парольную кодовую фразу SSH вместо имени пользователя и пароля каждый раз, когда вы делаете или . Затем мы будем клонировать этот репозиторий на наш локальный компьютер:
Как правило, мы создадим новую ветку git для каждой новой задачи. Это хорошая практика, потому что в будущем, если мы продолжим обновление ветки после некоторых обсуждений, запрос на перенос будет автоматически обновляться. Давайте создадим новую ветку, чтобы внести очень простое изменение в файл :
После внесения соответствующих дополнений для создания новых функций мы просто передадим новые изменения и проверку в ветку git master:
На этом этапе мы запушим ветку в удаленный репозиторий. Для этого мы сначала перейдем на ветку с новой задачей, а так же на псевдоним для удаленного репозитория. Затем мы будем пушить изменения с помощью :
На нашей развязанной странице Github репозитория мы перейдем к ветке с новой функцией, а затем нажмите кнопку «Pull Request».
После отправки пул реквеста он напрямую приведет нас к странице запроса в исходном репозитории. Мы увидим наш запрос на pull.
После обсуждения возможно, что владелец форкнутого репозитория может захотеть добавить изменения в новую функцию. В этом случае мы выберем одну и ту же ветку на нашей локальной машине, зафиксируем ее и запушим ее обратно на Github. Когда мы заходим на страницу запроса в оригинальном репозитории, он будет автоматически обновляться!

Слияние пул реквеста

Если вы являетесь владельцем оригинального репозитория, существует два способа слияния входящего пул реквеста:

Слияние непосредственно на Github: если мы делаем слияние непосредственно на Github, то убедитесь, что нет конфликтов, и реквест готов к объединению в ведущую ветку. Владелец оригинального хранилища может просто щелкнуть зеленую кнопку «Слить запрос», чтобы сделать это:
Слияние на наших локальных машинах: в других случаях могут возникнуть конфликты слияния, и после нажатия кнопки «Информация» у Github будут четкие инструкции о том, как мы можем объединить ветвь на нашей локальной машине, потянув за изменения из ветви контрибьютера:

Существуют различные модели создания веток, используемые для управления версиями в командах разработки программного обеспечения. Вот две популярные модели рабочего процесса git: (1) рабочий процесс Github, который имеет простую ветвящуюся модель и использует запросы на pull, и (2) Gitflow, который имеет более обширное разветвление. Модель, которая в конечном итоге будет выбрана, определенно будет меняться в зависимости от команды, проекта и ситуации.

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

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

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

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

Создайте файл:
Добавьте файл в конфигурацию Git:
Откройте файл в текстовом редакторе и добавьте в него свои правила.

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

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

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

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

Например, чтобы установить в качестве глобального файла игнорирования Git, выполните следующие действия:

1. Создайте файл:

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

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

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

Для чего нужен .gitignore

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

Мы конечно могли бы вручную добавлять нужные файлы в репозиторий, например так:

git add path/to/file

Однако это было бы очень трудоемко. Гораздо проще использовать команду:

git add .

Которая добавит все файлы в каталоге проекта.

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

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

3 ответа

Лучший ответ

У вас есть файл ? Вот информация, которая может быть полезна.

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

madhead
20 Янв 2013 в 15:43

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

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

Это говорит о том, что имеет смысл исключать имена исполняемых файлов в локальных файлах .gitignore, а не в info / exclude.

Donna
26 Сен 2014 в 22:03

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

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

Matthew Strawbridge
8 Дек 2016 в 18:40