Короткий ответ
Отменить любые изменения в вашем рабочем дереве, которые могли быть добавлены в индекс с помощью
git checkout HEAD -- .
Для хранилища в файловой системе Windows FAT32, скажите git игнорировать биты выполнения в файловых режимах.
git config core.fileMode false
, после чего вы сможете оформить свою основную ветку.
git checkout master
или используя свой псевдоним
git ck master
Подробное объяснение
После того, как вы скажете git добавить все новые файлы и изменения в текущий каталог (.) и в любые дочерние каталоги
git add .
и затем зафиксируйте, обратите внимание, что git сообщает вам, что права доступа к файлу изменены, например, ,
mode change 100644 => 100755 .gitignore
в сочетании с линией, расположенной непосредственно над ней
264 files changed, 0 insertions(+), 0 deletions(-)
мы заключаем, что содержимое не изменилось - только разрешения.
Контекст имеет решающее значение для этого абзаца. Сразу после того, как вы запустили git commit -m 'many changes were not ...', вы могли бы подтвердить это, запустив git diff origin/master, и вывод будет состоять из множества последовательностей вида
$ git diff origin/master
diff --git a/.gitignore b/.gitignore
old mode 100644
new mode 100755
[...]
, но без добавления новых строк или удаления строк.
Появление ваших скриншотов и каталога с именем Desktop заставляет меня поверить (что подтвердил ваш более поздний комментарий), что вы используете Microsoft Windows в файловой системе, которая не представляет биты режима выполнения, поэтому git должен быть уведомлен игнорировать его с помощью git config core.fileMode false, что объясняет документация git config .
core.fileMode
Сообщает Git, следует ли выполнять исполняемый бит файлов в рабочем дереве.
Некоторые файловые системы теряют исполняемый бит, когда файл, помеченный как исполняемый, извлекается или извлекает неисполняемый файл с включенным исполняемым битом. git-clone или git-init проверяют файловую систему, чтобы определить, правильно ли она обрабатывает исполняемый бит, и эта переменная автоматически устанавливается при необходимости.
Однако хранилище может находиться в файловой системе, которая правильно обрабатывает файловый режим, и эта переменная устанавливается равной true при создании, но позже ее можно сделать доступной из другой среды, которая теряет файловый режим (например, экспорт ext4 через монтирование CIFS, посещение созданного Cygwin репозитория с Git для Windows или Eclipse). В таком случае может потребоваться установить для этой переменной значение false. См. git-update-index.
Git Philosophy
Git чрезвычайно осторожен, чтобы не разрушить вашу работу. Перед тем, как приступить к проверке мастера, git сравнивает состояние вашего текущего рабочего дерева с заголовком нужной ветви и, например, видит, что .gitignore в его положении отличается от .gitignore в мастере.
Поскольку git видит неподтвержденные изменения, которые он должен будет перезаписать для мастера проверки, он прерывает проверку и дает вам знать, что вам нужно либо намеренно отбросить эти изменения
git checkout HEAD -- .
или положите их куда-нибудь для безопасного хранения с помощью git stash или git add, за которыми следует git commit. С чистым рабочим деревом вы можете смело проверять различные ветви.
Сравнение файлов
Для получения подробной информации о том, что именно изменилось, выполните одну из следующих команд. Правильный вызов зависит от контекста.
После создания нового коммита
Вы добавили изменения и создали коммит на ветке master с именем объекта SHA-1 644ccb8 (как видно на скриншоте с вывода git commit -m [...]). В то время, когда вы его создали, 644ccb8 стал HEAD вашей основной ветки, и чтобы увидеть все изменения между ним и master в исходном, запустите
git diff origin/master
На английском это означает «Показать все изменения между origin/master и кончиком ветви, над которой я сейчас работаю». Фактически, приведенная выше команда эквивалентна git diff HEAD origin/master, что явно требует сравнения против HEAD.
Чтобы показать изменения для одного или нескольких файлов, названных в качестве разделителя --, используйте
git diff origin/master -- .gitignore README.md
После постановки, но до совершения
Ваши скриншоты показывают не все, но текст зеленого цвета из значения git status означает, что определенные изменения были «поставлены» или добавлены в индекс.В git мы постепенно создаем следующий коммит в индексе (также называемый промежуточной областью или кэшем) с одним или несколькими вызовами git add и, реже, удаляем изменения из индекса с помощью git reset.Как только индекс будет в хорошей форме, git commit добавляет новый коммит с содержимым индекса в историю.
Ваши скриншоты показывают, что вы запустили git add . из корня хранилища.
- В сторону: знайте, что
git add . рисует широкой кистью.Иногда это то, что вы хотите, но часто он собирает больше файлов, чем вы предполагаете, особенно когда в вашем .gitignore отсутствует несколько шаблонов.После большого git add всегда обязательно запускайте git status, чтобы убедиться, что вы не подобрали автостопщиков.
После запуска git add один или несколько раз, но до работает git commit, чтобы увидеть изменения, которые в данный момент находятся в индексе или кэше, добавьте параметр --cached.
git diff --cached
или ограничьте одним или несколькими конкретными файлами
git diff --cached -- README.md
Перед подготовкой
Чтобы увидеть разницу между тем, что находится в вашем рабочем дереве, и тем, что находится в индексе (или кеше), запустите один из
git diff
git diff -- README.md
Это режим по умолчанию git diff.
Detached HEAD
Обратите внимание, что из вашего скриншота в вашем хранилище есть detached HEAD , определенное в документации как
Это просто означает, что HEAD ссылается на конкретный коммит, а не на именованную ветвь.
Как правило, вы обычно не делаете хотите извлекать удаленные ветви отслеживания ( например , origin/master), теги или хэши SHA-1 напрямую, если вы планируете создатьКе модификации.