На самом деле это просто ответ на последнюю часть вашего вопроса, но с помощью git log --all --decorate --oneline --graph. Вы задаетесь вопросом, почему вы не видите узел фиксации для незафиксированных изменений.
gitk (графический интерфейс, который поставляется с Git) показывает такой узел; git log --graph нет. Каждый зритель должен решить, притворяться ли незафиксированные изменения узлом фиксации, который можно показать, или это просто незафиксированные изменения и, следовательно, не узел.
Последнее является более точным с технической точки зрения: незафиксированные изменения не коммит! Однако отображение их в графическом интерфейсе может быть более удобным для пользователя. Так что решать, показывать ли их, зависит от графического интерфейса.
Обратите внимание, что с точки зрения Git, на самом деле три версии каждого файла доступны для вас всегда. 1 Если у вас есть файл с именем README.md, для Например, у вас есть три README.md файла:
Один README.md сохраняется в текущем (HEAD) коммите, доступен только для чтения. Эту копию нельзя изменить! Он хранится в специальной, только для Git, сжатой форме. Поскольку он сохраняется в коммите, он сохраняется на все время или, по крайней мере, до тех пор, пока коммит продолжает существовать.
Если вы испортили две другие версии README.md, вы можете восстановить версию HEAD, используя git checkout HEAD README.md в командной строке. Это перезаписывает обе другие две копии.
Второй README.md, который войдет в следующий коммит, находится там, для чтения / записи, хранится в чрезвычайно важной, но обычно почти полностью невидимой (!) Сущности. У Git есть три разных имени для этой вещи: он называется index , или staging-area , или cache , в зависимости от того, кто выполняет вызов. Все ваши текущие файлы находятся в индексе, также в специальном формате Git-only, но здесь, в индексе, вы можете изменить их.
Пока вы не измените эту копию файла, если вы сделаете новый коммит, README.md в новом коммите будет совпадать с README.md, полученным из текущего коммита. Это верно и для всех других файлов.
В командной строке вы обычно изменяете эту копию файла, используя git add README.md. Это копирует версию файла рабочего дерева (см. Последний пункт) в индекс. Если вы решили, что хотите, чтобы индексная копия вернулась к тому, как она выглядит в текущем коммите, вы можете использовать git reset HEAD README.md. Это очень похоже на git checkout -- README.md за исключением того, что только перезаписывает индексную версию из HEAD версии.
Наконец, есть файл README.md, который вы действительно можете открыть в редакторе, просмотреть с помощью средства просмотра файлов и т. Д. Этот файл находится в вашем рабочем дереве . Это в обычном формате, не Git, так что вы можете работать с ним.
В некоторых отношениях это файл, который Git заботит меньше всего. Пока вы не скопируете это в индекс, это просто шум - Git даже не смотрит на это. Команда git status, однако, сравнит версию индекса с версией рабочего дерева и сообщит вам, отличаются ли они.
Обратите внимание, что git status выполняет два git diff с: первый сравнивает фиксацию HEAD с индексом. Что бы здесь ни отличалось, готовится к коммиту . Вторая git diff сравнивает индекс с рабочим деревом. Что бы здесь ни отличалось, это , не предназначенное для коммита .
Когда графический просмотрщик, такой как gitk, показывает вам узел для незафиксированных изменений, он либо объединяет индекс и рабочее дерево, либо игнорирует один из этих двух. В любом случае, то, что он показывает, не является правдой! Тем не менее, знание того, что у вас do есть незафиксированные изменения, является ценным, независимо от того, являются ли эти файлы промежуточными, неустановленными или и тем, и другим (например, может быть README.md является промежуточным, а какой-то другой файл - нетегированным). Приятно иметь способ показать это.
1 Это преувеличение и занижение. Поскольку вы можете создавать новые файлы или удалять существующие, иногда у индекса и / или рабочего дерева есть версии, которых нет в HEAD, или наоборот. Вот где это преувеличение: может быть только одна или две версии какого-либо файла. В то же время вы можете извлечь любую подтвержденную версию любой файл в в любое время , так что это занижение, но версия HEAD особенно важно то, что git status будет использовать при сравнении с индексом. Наконец, есть еще один особый случай при работе с объединением, которое имеет конфликты: в этом случае сам индекс содержит (до) трех версий конфликтующих файлов, так что вы получаете еще больше одновременно доступных версий каждого файла. .