Импорт определенных .scss файловых разрывов Git?

Question

Были ли у вас изменения в файле, которые мешали git видеть соответствующие изменения? Я столкнулся с этим странным мерзавцем сегодня. Рассмотрим файл main.scss, в котором @imports .scss partials. Повседневный сценарий, на 100% легкий, всегда, верно? нет проблем. До сегодняшнего дня!

Когда я попытался импортировать файл с путем «layout / sidebars / header» (указывающий на соответствующий и существующий файл /layout/sidebars/header.scss), я обнаружил странное / любопытное / тревожное поведение из мерзавец .

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

Когда я пытаюсь переместить файл в новый файл с именем «test.scss» или даже «test.test» (для скептиков .gitignore), у меня не появляется чистый шанс зафиксировать новый добавленный файл как я и ожидал.

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

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

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

Любые идеи или теории по этому вопросу приветствуются.

Answer 1

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

Как указал @Torek, корректировка по сравнению с индексом ответила соответствующим образом ... это было просто обманчиво, потому что я не смог найти соответствующее правило .gitignore в моем работающем репозитории git, которое имело какой-то смысл ,

Копайте глубже, но не забывайте искать выше.

Answer 2

Вы бежали (как видно на вашем втором изображении):

mv main.scss test.scss

Это изменило ваше рабочее дерево , но не ваше index . ¹ Конечно, ваш текущий или HEAD коммит не изменился.

Поскольку git status запускает два отдельных git diff с (более или менее), вот что git status делает из этого:

1. Сравнить HEAD против индекса: ничего не изменилось.

   Следовательно, поскольку ничто не отличается, ничто еще не подготовлено для коммита.

2. Сравнить индекс с рабочим деревом. Хм, файл main.scss находится в индексе, но не в рабочем дереве. Должно быть, оно было удалено!

   Поскольку файл рабочего дерева пропал, вы должны в конечном итоге удалить main.scss. Однако, поскольку вы еще не попросили Git удалить его из индекса, он останется в следующем коммите. Так что это удаление еще не подготовлено для фиксации . Разумеется, вы можете запросить его постановку для коммита в любой момент.

Неясно, есть ли в вашем индексе файл с именем test.scss. ² Если его нет, то новый test.scss, который только что появился в вашем рабочем дереве, - неотслеживаемый файл. Это может или не может также быть проигнорировано - если это не проигнорировано, git status будет жаловаться на это, говоря, что это не отслежено. Если он не отслеживается и игнорируется, git status будет молчать об этом. Правила игнорирования могут быть введены в скрытых местах, поэтому используйте git check-ignore -v, чтобы узнать больше здесь.

Обратите внимание, что если вы используете git mv вместо обычного mv, Git будет одновременно переименовывать файл в вашем рабочем дереве и переименовывать файл в вашем индексе. Тогда в вашем индексе не будет main.scss (так что он будет запланирован для удаления при следующей фиксации), а в индексе и рабочем дереве будет test.scss.

Поскольку git status операции git diff выполняют обнаружение переименования , Git сравнит старый main.scss с новым test.scss, обнаружит, что он идентичен, и скажет, что вы переименован файл. (Фактически, следующий коммит будет просто не иметь main.scss и будет иметь test.scss - но другие сравнения будут также обнаруживать переименование и сообщать о нем как об одном, если вы спросите Git обнаружить переименования.)

---

¹ Помните, что индекс, также называемый промежуточной областью или иногда кеш , в зависимости от того, кто выполняет вызов, - это место, где вы строите свой далее совершить коммит. Он начинает совпадать с коммитом, который вы извлекли, запустив git checkout <em>branch</em>: то есть он имеет копию каждого файла в специальном формате Git, который использует Git, точно так же как HEAD commit.

Ключевое различие между копией в индексе и копией в HEAD коммите состоит в том, что копия в индексе может быть изменена или полностью удалена; и файлы, которых еще нет в индексе, могут быть добавлены в него. Поскольку сделанный вами следующий коммит будет создан из того, что находится в индексе при запуске git commit, ваша задача - создать новый индекс. Но поскольку файлы в индексе находятся в этой специальной сжатой форме, предназначенной только для Git, Git также копирует эти файлы в ваше рабочее дерево , где вы можете работать с ними. Использование git add <em>path</em> копирует файл обратно в индекс, перезаписывая версию, которая была там ранее - или, если ее там не было раньше, создает этот файл в индекса.

² Чтобы увидеть все в вашем индексе, используйте git ls-files --stage. Это довольно многословно, хотя. Обычно гораздо интереснее рассматривать индекс с точки зрения того, что отличается , поэтому git status diffs HEAD-vs-index, а затем index-vs-work-tree.