Файлы, в очень важном техническом смысле, не находятся в какой-либо ветке, в Git. Другими словами, вы задаете неправильный вопрос. Вы должны спросить: Какие коммиты, если они есть, содержат этот файл? Затем вы можете уточнить вопрос до , который содержит именно эту версию этого файла или которые коммиты изменили этот файл по сравнению с их родительским коммитом и т. д.
(я подозреваю, что один из этих ответов прямо сейчас таков: no commit содержит этот файл, или эту версию этого файла, но вы не дали нам достаточно go здесь, чтобы я был уверен.)
Git работает немного хитроумно:
Git хранилища репозиториев фиксирует , а не файлы. Конечно, каждая фиксация хранит несколько файлов, поэтому можно с уверенностью сказать, что Git хранит файлы, верно? Ну, вроде как, но это приведет вас по садовой дорожке . Попробуйте представить коммиты как некую единицу. Это единица памяти, с которой вы будете работать, когда будете работать с Git.
Само слово ветка сложно: см. Что именно мы подразумеваем под «ветвью»?
Конечным результатом всего этого является то, что дана ветка имя как master , мы должны сначала найти один конкретный c commit . Затем мы можем решить, находится ли какая-либо версия какого-либо файла в этой c фиксации или нет.
В любом случае файлы, которые находятся внутри коммитов, полностью, полностью, 100% только для чтения. Они хранятся в специальном формате, который понимает только Git, и они дедуплицируются, потому что каждая фиксация хранит полную копию каждого файла! Дедупликация делает это нормально.
Когда вы активно работаете с репозиторием, вы начинаете с выполнения:
git checkout master
или git checkout другого имени ветки. 1 Эта операция проверки копирует файлы только замороженного формата Git из некоторой фиксации, расширяя их в обычные повседневные файлы.
Эти обычные повседневные файлы go в рабочая зона где вы можете поработать над ними. Git называет эту рабочую область вашим рабочим деревом или рабочим деревом . 2 Файлы, которые вы можете просматривать и с которыми / работать, находятся в этом рабочем дереве . Рабочее дерево не является частью репозитория! Здесь хранятся только изменения.
Обратите внимание, что это рабочее дерево представляет собой обычный набор файлов и папок, поэтому все команды вашего компьютера, которые работают над такими вещами, работайте над этим. Это означает, что вы можете создавать файлы, которых нет в Git вообще , потому что они существуют только в вашем рабочем дереве, а не в каком-либо коммите.
Git делает новые коммиты не из файлов, которые находятся в вашем рабочем дереве, а скорее из файлов, которые хранятся в Git index . Индекс немного сложен, и я не буду здесь go вдаваться в детали, за исключением того, что git checkout заполняет оба Git индекс и ваше рабочее дерево из выбранного вами коммита. Это не мешает работе файлов дерева работы, о которых Git ничего не знает. Опять же, таких файлов нет в Git. Они просто существуют в вашем рабочем дереве.
Если файл равен в репозитории Git, он сохраняется внутри фиксации в специальном замороженном формате Git -only. Выполнение git checkout приведет к извлечению этого файла, в результате чего появятся еще две копии: одна, которую вы не можете увидеть в индексе Git, готова go к следующей фиксации , 3 и тот, который вы можете видеть и работать с ним в вашем рабочем дереве. Когда вы изменили копию своего рабочего дерева, обновленный файл не будет go в новую фиксацию, пока вы не скопируете его обратно в индекс, заменив старую копию индекса: это то, для чего git add.
Git использует фразу неотслеживаемый файл для обозначения файла, который в настоящее время не находится в индексе Git, но находится в вашем рабочем дереве . Команда git status покажет такие файлы, как untracked . 4
1 В Git 2.23 или более поздних версиях вы здесь можно использовать git switch. Он делает то же самое - он просто был отделен от git checkout, поскольку git checkout выполнял как минимум две отдельные команды для разных заданий. В Git 2.23 git switch выполняет одно задание, а git restore - другое, вместо того, чтобы втиснуть оба в git checkout.
2 В Git 2,5 или более поздних версиях , вы можете добавить дополнительные рабочие деревья с помощью git worktree add. Для этого лучше всего иметь Git 2.15 или новее из-за довольно неприятной ошибки, которая не была исправлена до тех пор. (Ошибка проявляется только в том случае, если вы оставите добавленное дерево работы как минимум на две недели, поэтому, если у вас есть старый Git и вы хотите использовать git worktree add для быстрого исправления, это нормально, просто не позволяйте ему сидеть слишком долго.)
3 Технически, то, что находится в индексе, не является буквальной копией файла, а скорее именем файла , режим и внутренний Git ID объекта . Но это проявляется только в том случае, если вы копаетесь в записях индекса, используя внутренние команды Git, такие как git ls-files --stage и git update-index.
4 Чтобы git status заткнулся файлы, вы можете перечислить их в формате .gitignore. Обратите внимание, что перечисление отслеживаемого файла - того, что является в индексе Git - в .gitignore, тем не менее, не имеет никакого эффекта.