мне нужно клонировать исходный код emacs в два уникальных каталога в моей локальной системе?
Нет, но вам нужны нужны — или, по крайней мере, хотите — два рабочих дерева или рабочих деревьев (мне нравится чтобы использовать более короткое имя, большая часть документации Git в основном использует более длинную форму из двух слов без дефиса).
Два клона дадут два рабочих дерева, так что вы можете сделать это таким образом. Другой способ — использовать git worktree add, если у вас Git 2.5 или новее (предпочтительно 2.15 или новее).
Сохраняет ли git скомпилированные объекты, разделенные двумя ветвями...
Нет. В частности, файлы, с которыми вы работаете — как извлеченные из какого-либо коммита с помощью git checkout или git switch, так и созданные в процессе сборки — находятся вне репозитория Git. правильно. Они находятся в вашем рабочем дереве или рабочем дереве (два способа сказать одно и то же). Эти файлы на самом деле вообще не находятся в Git.
Когда вы используете git checkout или git switch для выбора коммита, Git:
- убедитесь, что следующие несколько шагов выполнены правильно; потом
- удалить из вашего рабочего дерева файлы, которые были включены в фиксацию, которую вы извлекли ранее, если таковые имеются; и
- добавьте в ваше рабочее дерево файлы, связанные с фиксацией, которую вы проверяете сейчас.
Это удаление и добавление допустимо, если у вас нет несохраненной работы в различных файлах, которые Git перезапишет или удалит в процессе.
Обратите внимание, что создать продукты из какой-либо другой, более ранней проверки — это просто неотслеживаемые файлы: файлы, которые вы или какая-либо программа, которую вы запустили, поместили в ваше рабочее дерево (это ваш, так что вы можете поместить в него все, что вам нравится), о котором Git ничего не знает. Они не появились в результате какого-то коммита, и если вы переключитесь с этого коммита на какой-то другой, их не нужно удалять,1, поэтому их и не будет.
Если вы хотите работать с двумя разными коммитами одновременно, вам нужны две разные рабочие области, в которых можно работать с файлами, извлеченными из этих двух разных коммитов. Поскольку один репозиторий поставляется с одним начальным рабочим деревом (и одним индексом, также известным как промежуточная область, также известным как кэш), вам нужно либо два репозитория, либо git worktree add код, впервые появившийся в Git 2.5. Используя git worktree add, вы можете добавить вторую пару индекс-и-рабочее дерево со вторым HEAD, которое идет с ним, и использовать его для проверки какого-то второго коммита.
В нем было несколько неприятных ошибок, которые не были исправлены до Git 2.15. Если вы просто быстро взглянете на какой-то коммит, ошибки не будут кусаться. Они кусаются, когда вы делаете дополнительное рабочее дерево и выполняете в нем какую-то работу и оставляете его на две недели или больше. (Это случилось со мной. К счастью, я действительно закончил с добавленным рабочим деревом и смог просто удалить его.)
1Обратите внимание, что из этого правила есть исключение. Предположим, вы находитесь на каком-то коммите c123456 или что-то в этом роде. В этом коммите нет файла с именем README.md. Вы создаете свой собственный README.md, так что теперь он не отслеживается. Затем вы решаете, что хотите проверить коммит fedcba9 или что-то еще, но этот коммит действительно содержит файл README.md. Git будет жаловаться, что ему придется перезаписать ваш неотслеживаемый файл README.md в вашем рабочем дереве, чтобы извлечь коммит fedcba9.
24.01.2021
