Мы используем azure devops с репозиториями git. Репозиторий git нашего основного продукта в последнее время ведет себя странно. Примерно через три недели конкретный файл (проекта) в репозитории отсутствует после проверки веток на основе конкретной ветки разработки. Когда я смотрю на репозиторий, файл действительно присутствует в репозитории.
Впервые мы столкнулись с таким поведением во время сборки запроса на вытягивание. Сборки завершились неудачно, потому что он сказал, что не может найти конкретный файл, хотя файл присутствует в ветке. Внесение изменений в файл путем добавления пробела временно устраняет проблему.
Совсем недавно я обнаружил, что один и тот же файл иногда появляется как ожидающее удаления изменение на моем локальном компьютере для разработки, как только я переключаюсь на некоторые ветки, хотя я никогда не удалял файл.
Я уже пытался удалить файл, зафиксировать его и восстановить файл в новом коммите, но проблема, похоже, не исчезла.
Я уже запускал git fsck
, и он возвращает только некоторые висящие объекты
Кто-нибудь знает, что здесь происходит?
Обновлять:
У нас это случилось снова. git ls-files
перечисляет только 25 файлов в агенте с проблемой. При запуске той же команды в локальном репо она возвращает список, который кажется полным списком файлов репо. Интересно, что файл, который продолжает исчезать, ЯВЛЯЕТСЯ одним из 25 файлов, перечисленных в агенте. При переходе на другую ветку файл появляется снова. Я дважды проверил, и файл НЕ удаляется в ветке, в которой он не отображается. Более того, при переключении с ветки слияния обратно на исходную ветку и повторном переключении на ветку слияния файл НЕ исчезает. Есть предположения?
Примечание: удаление файла . Совершение этого, повторное добавление файла и удаление пробела, а также фиксация этого -> снова исправлено (возможно, временно)
Я не знаю, как проверить, в чем именно дело. Однако у нас есть эта проблема на нескольких несвязанных компьютерах (как клиентских, так и серверных). Поэтому я думаю, что вероятность того, что что-то еще на компьютере удалит этот файл, очень мала.
Чтобы проверить (напрямую), какие файлы находятся в индексной/промежуточной области, используйте git ls-files
(обратите внимание, что это предназначено для скриптов, это неудобная команда). Например, сравните «хорошую» систему или кассу с плохой.
Как только это произойдет снова, я расследую и обновлю вопрос. Спасибо за информацию
Я обновил вопрос с подробностями после запуска git ls-files
Каков результат git show-ref
?
Он показывает длинный список доступных ветвей. Только две ветки существуют локально, а все остальные ветки являются удаленными ветками.
Я думаю, мой вопрос: есть ли у вас имена веток, которые отличаются только регистром? Чтобы не просить вас вставить список веток, чего вы (разумно) не хотите делать, эта команда сообщит вам, есть ли у вас конфликтующие имена веток: git show-ref --head | tr A-Z a-z | awk '{print $2}' | sort | uniq -c | awk '{$1=$1;print}' | grep -v '^1 '
Нет, к сожалению, это тоже не проблема. Но, как я уже сказал в исходном вопросе, проблема (временно) исчезает при внесении незначительного (без регистра) изменения в файл и фиксации его в ветке, вызывающей проблему, поэтому я сомневаюсь, что это проблема с корпусом.
Вы не предоставили нам достаточно информации, чтобы с уверенностью определить проблему, но эта деталь:
Совсем недавно я обнаружил, что один и тот же файл иногда появляется как ожидающее удаления изменение на моем локальном компьютере для разработки, как только я переключаюсь на некоторые ветки, хотя я никогда не удалял файл.
предполагает, что вы зарегистрировали два файла с именами, различающимися только регистром.
Запустите эту команду в git bash (заменив filename
фактическое имя файла проекта):
git ls-files --stage | grep -i filename
Я подозреваю, что вы увидите более одной записи в списке, например:
100644 a5675676e903973a412f7aaa0a07ad45f586c02b 0 filename
100644 db0cc477c38714c4ee77b0bf462a7b7156a066a2 0 FileName
Это произошло потому, что git хранит имена файлов с учетом регистра, в то время как Windows хранит файлы без учета регистра (но с сохранением регистра). Либо кто-то на платформе, которая также чувствительна к регистру, добавил файл с похожим именем (отличается только регистром), либо кто-то по ошибке изменил значение core.ignoreCase
, ошибочно полагая, что это параметр конфигурации (это не так, это это кешированная информация о локальной файловой системе, и ее изменение вызовет подобные проблемы).
Чтобы исправить это, запустите git rm --cached
для разных имен файлов, затем запустите git add
для правильного имени файла. Например:
git rm --cached filename
git rm --cached FileName
git add filename
И используйте git log
, чтобы определить, кто из ваших коллег по ошибке изменил свою конфигурацию git, и убедитесь, что они не сделают этого снова.
К сожалению, это не случай. git ls-files
возвращает только одну строку для отсутствующего файла проекта. Вы говорите, что вам не хватает информации для определения проблемы. Я буду рад предоставить дополнительную информацию, если вы дадите мне знать, какую информацию вы хотели бы иметь
честь там, где должна быть честь, сегодня мы обнаружили, что на самом деле БЫЛА проблема с корпусом, но гораздо дальше по пути к файлу. Мы исправляем корпус, и, надеюсь, проблема не останется в стороне.
Когда вы говорите, что этот файл «отсутствует», он отсутствует только в рабочем дереве или как в рабочем дереве, так и в индексе Git, также известном как промежуточная область? Если первое, найдите на компьютере что-то, что удаляет файл сразу после его создания Git.