Ваш вопрос упоминает папки и файлы . Git не хранит папки и на самом деле не работает с файлами - во всяком случае, не на уровне общения с другим Git на другом компьютере. Вместо этого Git работает с коммитами . Когда у вас есть Git вызов другого Git на другом компьютере, ваш Git получает от этого Git все свои коммиты, которые у вас нет, которые вы должны иметь. Это операция git fetch. (Или ваш Git дает на , что Git любые коммиты, которые у вас есть, а они нет, которые вы хотите их иметь: это операция git push. Но это звучит как один из них, который вас волнует, это «получить от них», т. е. получить.)
Итак, когда ваши Git вызвали их Git и получили от них коммиты, ваша задача теперь сравнить их совершает. Каждый коммит содержит файлы. Он содержит только файлы , но не папки, но файлы часто имеют имена, которые могут заставить вашу ОС создавать папки. Например, файл с именем dir/sub/file.ext, вероятно, требует, чтобы ваша ОС сначала создала папку dir, а затем в dir папку sub. (Это проблема вашей ОС, а не Git: что касается Git, то это просто файл с длинным именем. Git будет обходить фиксацию вашей ОС на «папках», как это необходимо здесь.)
Каждый коммит имеет полный, полный снимок всех файлов этого коммита. Так, например, если вы сравните коммит C123 с коммитом C456 , вы можете увидеть, какие файлы являются общими для обоих, какие уникальны для каждого, и какие различия существуют между любыми общими -в обоих файлах. Команда git diff делает это с большим количеством опций:
git diff --name-only <commit#1> <commit#2>
сообщает вам, какие файлы (с полными именами, такими как a/b/c.ext) отличаются в двух коммитах или находятся только в одном из два. Или:
git diff --name-status <commit#1> <commit#2>
сообщает, какие файлы различаются и каким образом: например, файл может нуждаться в A добавлении для фиксации # 1 для фиксации # 1, чтобы начать приближение к фиксации # 2. Другой файл может просто нуждаться в odified M, чтобы немного изменить его содержимое. git diff выводит здесь, по сути, инструкции: если вы внесете эти изменения в левый коммит, вы получите правый коммит. По умолчанию для git diff предусмотрено полное инструкции: все, что вы должны сделать.
Относительно вашего редактирования
Кроме того, я только что понял, что мне нужно в конечном итоге git add новых локальных файлов и локально создайте новые git commit до git fetch и git diff. Я прав?
Это может быть мудрее , но это, вероятно, не необходимо .
Я упоминал выше о Git работе с коммитами, и все приведенные выше различия используют коммиты. Коммиты содержат замороженные снимки всех ваших (зафиксированных) файлов. Все коммиты полностью доступны только для чтения: после внесения ни одна часть коммита не может быть изменена. Файлы, хранящиеся внутри коммитов, находятся в специальном, только для чтения, Git -только замороженном формате, который может использовать только Git. (Этот формат делает сравнение коммитов быстрее и проще, а также для других вещей, которые делает Git. Он также делает хранение коммитов более компактным, потому что, как только файл навсегда заморожен, каждый новый коммит может просто повторно используйте старые файлы коммитов, если они совпадают. Их невозможно изменить, поэтому, если вы делаете новый коммит, и 97 из 100 файлов совпадают, Git может просто повторно использовать этих 97 файлов. «Копия» в новом коммите на самом деле является просто ссылкой на существующую, совместно используемую, уже замороженную копию.)
Материал, который заморожен навсегда отлично подходит для архивирования. Но Git не просто архиватор. Его данные в этом Git -только формате: ничего другого на вашем компьютере не может использовать файлов. Так что это совершенно бесполезно для выполнения любой реальной работы. Это означает, что Git должен , чтобы позволить вам выполнить работу, копировать замороженные файлы из некоторого коммита в какую-то рабочую область. Файлы в этой рабочей области - области Git, называемой рабочим деревом или рабочим деревом или аналогичными, - являются обычными обычными файлами. Они не заморожены, и они в обычном повседневном формате, который использует ваш компьютер, что бы это ни было. (Они находятся в папках и всё!)
Этот процесс копирования замороженных файлов в ваше рабочее дерево также копирует замороженные файлы в Git index . Когда вы git add и git commit, то вы копируете файлы рабочего дерева обратно в индекс (git add), а затем делаете новый коммит из того, что находится в индексе (git commit).
Индекс может быть сложным (во время слияния), но его можно описать довольно просто: это , где вы создаете свой следующий коммит . Файлы, которые в нем 1 находятся в замороженном формате, готовы к go в новый коммит, но, в отличие от коммита, не заморожены. Вы можете перезаписать их, добавить новые файлы и удалить их из индекса. Таким образом, вы можете скопировать каждый файл рабочего дерева в индекс, чтобы подготовить его к фиксации. Этот процесс копирования файла рабочего дерева обратно в индекс - замены старой копии, если она была, создания нового файла, если нет - называется подготовкой файла , и, следовательно, индекс также называется промежуточной областью .
Итак: для работы с файлами вы копируете их из коммитов в индекс и рабочее дерево. Вы можете просматривать и изменять файлы в своем рабочем дереве и повторно копировать файлы из рабочего дерева обратно в индекс, размещая их для фиксации.
1 Технически, в индексе есть ссылка на файл в замороженном формате, как в коммитах. Это появляется, если вы начинаете просматривать внутренние детали индекса, используя git ls-files --stage или git update-index. Но по большей части вы можете просто думать об индексе как о собственной отдельной копии каждого файла: эта ментальная модель работает нормально, пока вы не достигнете этого низкого уровня.
git status
Команда git status запускает две git diff с: одна сравнивает текущий commit (замороженный, запомните) с index . Что бы здесь ни отличалось, готовится к коммиту . То есть, если вы сейчас выполните git commit , Git сделает новый коммит из того, что находится в индексе. Все файлы, которые соответствуют HEAD (текущая) фиксация, не очень интересны: они абсолютно одинаковы. Так что git status ничего не говорит о них. Для любого файла, который является новым, или удаленным, или другим, однако, git status перечисляет имя этого файла.
Это то, что делает git diff --name-only, и это то, что git status делает для этого шага: он сравнивает и отличается , выводит имя файла. Вместо того, чтобы сравнивать два коммита, он сравнивает один коммит, в частности, тот, который сейчас HEAD, и индекс.
Но git status затем запускает второй git diff. На этот раз он сравнивает файлы в индексе с файлами в вашем рабочем дереве. Для всего, что является таким же , это ничего не говорит. Для всего, что отличается , он печатает имена файлов.
Опять же, это то же самое, что git diff --name-only будет делать, за исключением того, что вместо сравнения двух коммитов, это сравнение индекса и ваше рабочее дерево.
Поскольку ваше рабочее дерево представляет собой обычный набор папок, вы можете создавать файлы (и подпапки), которых нет в индексе. Это ваши неотслеживаемые файлы . Поскольку их нет в индексе, они не будут присутствовать в следующем коммите. Если вы запустите на них git add, Git скопирует их из рабочего дерева в индекс, и теперь они будут в индексе, а будет в следующем коммите.
Если вы не скопируете их в индекс, они останутся без отслеживания. Они не будут участвовать в git diff. Git будет просто скулить о них: Я нашел эти неотслеживаемые файлы, что мне с ними делать? Файл .gitignore говорит Git замолчать о неотслеживаемых файлах. Это не влияет на отслеживаемые файлы - файлы, которые находятся в индексе - потому что эти файлы находятся в индексе. Но вы можете помещать файлы в индекс и извлекать их из индекса в любое время.
Как все это идет с вашей первоначальной проблемой
Если вы сравните sh для сравнения два коммита, вам нужно будет сделать коммит. Это позволяет вам корректировать содержимое индекса по мере необходимости, и тогда у вас есть два коммита, где сравнение легко: вы просто даете git diff оба идентификатора ha sh или имена для двух идентификаторов ha sh.
Но, если вы хотите использовать индекс или рабочее дерево в качестве источника одного из двух наборов файлов, вы можете сделать это тоже. При использовании рабочего дерева в качестве одного набора файлов Git будет полагать, что только те файлы, которые также в index , являются частью этого рабочего дерева: другие файлы все не отслежены и, следовательно, не принимают участия в git diff. И теперь у вас есть еще одна проблема: git diff --cached <hash> сравнивается с индексом справа, и с данным коммитом слева, например. Но есть флаг -R (перевернуть стороны), если вы хотите сравнить с go другим способом.
Если после получения различий вы решите, что хотите отправить коммит до другой Git, вы, вероятно, захотите просто сделать коммит. Создание коммита, как правило, довольно дешево: это просто вопрос упаковки всего, что уже есть в индексе, и добавления метаданных, которые идут с новым коммитом.