Переключение ветки в Visual Studio сохраняет файлы из более старой ветки

Git не «делает» папки. Git понимает только файлы.

Файлы имеют такие имена, как path/to/file.ext, в Git. Это не папка с именем path, содержащая папку с именем to, содержащую файл с именем file.ext: это файл с именем path/to/file.ext, дополненный косой чертой (даже если ваша ОС использует обратную косую черту, как в path\to\file.ext).

Ваша ОС, однако, не могу справиться с этим. Таким образом, Git приспосабливается к вашей ОС, когда это необходимо, папками создание в файловой системе для хранения файлов, в именах которых есть косые черты. Если вы также создадите такие папки:

mkdir path path/to

а затем создайте файлы в этих папках и git add их:

echo new stuff > path/to/file.ext
git add path/to/file.ext

Git понимает, что вы хотите добавить в Гит файл со слешами в имени, и делает это. Он не обращает никакого внимания на папки — он не добавляет ни path/, ни path/to/, только последний path/to/file.ext — но он знает, что ваша ОС не может работать без них, поэтому приспосабливает их.

Когда вы затем переключаетесь обратно на какой-либо другой коммит, Git иногда очищает ненужные папки. Есть несколько условий, необходимых для того, чтобы Git смог это сделать, и одно из них — папка должна быть пустой после Git удаляет все файлы, которые идут с перемещаемым вами коммитом подальше от, и устанавливает все файлы, которые идут с перемещаемым вами коммитом к . (См. боковую панель ниже.)

Если Git не удалял папку сам по себе, и git clean -df тоже не удаляет, то папка непустая: в ней находится какой-то файл, которого либо вообще нет в Git, либо он идет с коммитом, на который вы переключились . Обратите внимание, что эти файлы могут быть скрыты: всегда используйте «показать все файлы, включая скрытые» во всем, что вы используете для просмотра содержимого папки. Будьте осторожны с git clean! См. боковую панель ниже.

Боковая панель (длинная и необязательная): фиксирует стоп-снимки.

Каждый коммит Git содержит две вещи:

• В нем есть некоторые метаданные или информация о самом коммите, включая такие вещи, как имя и адрес электронной почты человека, который сделал коммит, некоторые отметки даты и времени, сообщение журнала и так далее. Мы проигнорируем это здесь, хотя одна часть метаданных абсолютно важна для собственных внутренних операций Git: без нее в репозитории не было бы истории.

• Помимо метаданных, каждая фиксация действует как снимок из все файлы, о которых знал Git в то время, когда вы (или кто-то другой) сделал фиксацию. Этот моментальный снимок очень похож на tarball или архив WinRar для каждого файла. Однако файлы в этого моментального снимка находятся в специальном, сжатом, доступном только для чтения и только для Git формате, в котором файл содержимое не дублируется.

Это означает, что если у вас есть миллион коммитов, каждый из которых содержит файл размером в миллион байт, но все 1 миллион этих файлов совпадение, на самом деле есть только файл размером один в миллион байт. Каждый снимок использует файл такой же снова и снова. Только если вы изменить и git add файла, вы получите новый и другой снимок (который можно повторно использовать для следующего миллиона коммитов, если он снова не изменится).

(Хотя это происходит не сразу, Git в конечном итоге «суперсжимает» файлы, если может, так что, если две копии по миллиону байт можно сжать друг относительно друга, одна из них может уменьшиться до нескольких десятков байт. в конце концов. Это зависит от дельта-кодирование, который довольно хорошо работает для некоторых текстовых форматов, но почти никогда не работает для предварительно сжатых двоичных данных, таких как изображения JPG.)

Снимок внутри каждой фиксации полностью, полностью, на 100% доступен только для чтения. (На самом деле, таковы и метаданные.) Это Зачем. Различные коммиты могут совместно использовать файлы в своих моментальных снимках: поскольку ни одному из коммитов не разрешено сдача любого из них, всем коммитам разрешено Поделиться любого из них. Но тот факт, что эти файлы только удобочитаемый, да и то, только Git сам, означает, что вы буквально не можете делать с этими файлами никакой работы с.

Следовательно, вы этого не сделаете. Вы никогда не работаете с файлами в коммита. Вместо этого вы работаете с копии файлов, скопировано из коммита в рабочей области. Другими словами, вы не работаете с файлами в Git, вы работаете с файлами не в Git. Файлы с находятся в Git — это не те, которые вы используете, и те, которые вы используете, не находятся в Git.

Только когда вы запускаете git add и git commit, Git делает снимок новый. Новый снимок состоит из:

• все ранее извлеченные файлы снимка,
• минус любой вы git rm-ed,
• плюс любой ваш git add-ред

Git поддерживает своего рода работающий предложенный следующий коммит, изначально заполняемый git checkout или git switch, когда вы переключаете к в какой-то коммит. Когда вы git add какой-то файл существующий, Git корректирует предложенную следующую фиксацию, загружая копию Текущий и вставляя копию новый: Git сжимает копию рабочего дерева — ту, что нет в Git — во внутреннюю, доступную только для чтения форму, проверяет на дубликаты, и если есть дубликат, использует его сейчас. Если нет, Git подготавливает сжатый файл к фиксации и использует его. В любом случае предлагаемая следующая фиксация теперь обновляется.

Когда вы git rm создаете файл, Git удаляет копию рабочего дерева (которую вы можете видеть и с которой вы можете работать) и — предполагаемую копию следующей фиксации. Предлагаемая следующая фиксация теперь обновлена.

Когда вы git add создаете совершенно новый файл, Git сжимает копию рабочего дерева, проверяет, не является ли он дубликатом (как при git add-инге существующего файла), а затем либо добавляет дубликат, либо подготовленный файл в предлагаемую следующую фиксацию. Предлагаемая следующая фиксация теперь обновлена.

Каждый раз, когда вы переключатель фиксирует, Git:

• Проверяет текущую «предложенную следующую фиксацию»: все ли файлы в ней точно такие же, как в фиксации Текущий? Если да, то их можно смело выбрасывать. Если нет, то их нет.

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

Вся эта проверка приводит к сложному ответу на Проверить другую ветку, когда в текущей ветке есть незафиксированные изменения. Однако здесь мы можем использовать два очень важных кратких понятия:

• Если мы просим Git «переключиться» с фиксации a123456, скажем, на фиксацию a123456, т. е. если хэш-идентификатор фиксации Текущий точно соответствует хэш-идентификатору фиксации новый, на которую мы хотели бы переключиться, то мы вообще не переключая коммиты. Это означает, что вообще нет необходимости обновлять предложенный следующий коммит, а это, в свою очередь, означает, что переключение ветвей разрешено. Таким образом, мы всегда можем создать и переключиться на новая ветка, если мы не изменим зафиксировать хэш-идентификаторы в процессе. Это всегда так для простого:

  git switch -c new-branch
  

  или

  git checkout -b new-branch
  

  который создает и переключается на новую ветку без изменения коммитов. Это означает, что если мы начали работу и забыли сначала создать ветку новый, мы просто делаем это перед запуском git commit, и все в порядке.

• Если все файлы «чистые» — если мы не вносили никаких изменений с момента последнего коммита, например, так что git status говорит nothing to commit, working tree clean — тогда мы можем безопасно переключать ветки, независимо от того, от какого коммита мы и к чему переходим. .

Есть, однако, одна очень большая оговорка ко второму пункту списка. Git переходит к удалять из нашего рабочего дерева и из его индекса/индексной области — т. е. из предлагаемого следующего коммита — все файлы, которые есть из-за текущего коммита и собирается установить в нашем рабочем дереве все файлы, которые идут с коммитом Другие. Это правда. даже если некоторые файлы помечены как «игнорируемые» с помощью .gitignore: файл, который на самом деле на сценической площадке, «отслеживается» по определению и, таким образом, подлежит удалению и замене (при условии, что он «чистый», как в git status говорит nothing to commit, working tree clean ).

Итак, вкратце: файлы отслеживаются — это файлы в предложенный следующий коммит, т. е. в промежуточной области индекса Git он же. Они будут удалены и заменены при переключении коммитов, и если целевой коммит — тот, который вы переключаете к — не хватает файла, они будут просто удалены.

Это оставляет нас с понятием неотслеживаемые файлы, и определение их простое: Неотслеживаемый файл — это тот, который имеет является в вашем рабочем дереве, но не является в индексе / промежуточной области Git Сейчас. Неважно, Зачем его сейчас нет. Его может не быть, потому что его там никогда не было: ни в одном коммите. Его может не быть, потому что его не было в коммите, на который вы переключились (например, возможно, в коммите b789abc есть файл read.me, а в более ранней фиксации a123456 нет, и вы переключились на более раннюю фиксацию, поэтому файла нет в commit, но затем вы все равно сохранили копию в своем рабочем дереве). Или его может не быть, потому что вы сбежали git rm --cached. Так или иначе, файл является есть в вашем рабочем дереве и не в предложенном следующем коммите.

Учитывая, что файла нет в предлагаемом следующем коммите — в промежуточной области — есть значительный шанс, что его вообще нет в Git, в коммите Любые. Это мог в каком-то коммите; возможно, это один из более странных случаев, перечисленных выше. Но обычно какой-то файл, например main.pyc (файл, скомпилированный с помощью байтов Python), не находится в коммите Любые, потому что вы сообщили Git никогда не добавляйте это, перечислив его в .gitignore, и вы никогда не добавляли его и, следовательно, никогда его не коммитили. Затем Python пошел и создал его, так что он находится в вашем рабочем дереве. Если это файл Python *.pyc, можно смело удалить его.

Но это не относится к неотслеживаемому файлу каждый. Иногда какой-то неотслеживаемый файл — это результат часов или даже дней работы, а вы просто еще не запускали git add и git commit. Это ценно, но это единственная копия... и она сидит в вашем рабочем дереве, где Git может перезаписывать файлы.

Поскольку его нет ни в одном коммите, этому неотслеживаемому файлу в данный момент ничего не угрожает. Переключение с одной фиксации на другую приведет только к удалению и замене файлов отслеживаются, а фиксация нет в репозитории имеет этот файл как отслеживаемый файл, поэтому этот файл останется нетронутым: ваша драгоценная работа в полной безопасности, даже если она находится в этом, а не рискованное место в рабочем дереве Git. Его неотслеживаемость и незафиксированность — это почти невидимый щит, защищающий файл. Но есть одна команда Git, которая пробивает этот щит, и это git clean. Команда git cleanработа равна удалить неотслеживаемые файлы.

Поэтому вы должны быть очень осторожны с git clean. Он удалит неотслеживаемые файлы, а этих неотслеживаемых файлов по определению нет в предложенный следующий коммит, и есть очень большая вероятность, что они даже не в коммите Любые. Это означает, что Git не могу помочь вам вернуть эти файлы, если вы их удалите. Если это сгенерированные компьютером файлы, как в нашем примере main.pyc, в этом нет ничего страшного, но если для их воссоздания потребуются часы или дни работы, что ж, тотявляется Большое дело. Так что будьте осторожны с git clean!