Git отдел выписки извне
Проблема. Мне нужно как-то проверить существующую ветвь проекта, который уже клонирован локально в моей файловой системе, не находясь в этой конкретной папке этого проекта.
Решение: Я пытаюсь сделать следующее:
- git clone 'github-project-url' 'файловая система-папка'
- git checkout 'existing-branch' 'файловая система-папка'
Я понимаю, что второй шаг не совсем прав, но я также стараюсь избегать "cd" файловой системы-папки ".
Ответы
Ответ 1
Вы можете использовать --git-dir
для указания каталога .git
для использования в качестве репозитория и --work-tree
для указания рабочего дерева для проверки. См. git
man page.
git --git-dir=file-system-folder/.git --work-tree=file-system-folder checkout existing-branch
Ответ 2
git clone ./foo ./foo-copy
git --git-dir=./foo-copy/.git --work-tree=./foo-copy checkout branch
Ответ 3
Вы можете использовать --git-dir
и --work-tree
, чтобы избежать cd'ing, но, честно говоря, проще всего использовать cd. Чтобы избежать необходимости восстановления cd, вы можете сделать это в подоболочке:
git clone foo foo-copy
(cd foo-copy && git checkout branch)
Конечно, в этом конкретном случае вам действительно не нужны две команды:
git clone -b <branch-to-checkout> foo foo-copy
Ответ 4
git 2.5 добавлена возможность иметь несколько рабочих деревьев, используя git worktree. Итак, в этом случае вы бы использовали что-то вроде
git worktree add -b new-branch-name ../dir-name existing-branch
вы можете перейти на dir-name и сделать свои записи как обычно. Коммиты будут попадать в исходный репозиторий (где вы использовали worktree add
).
Когда вы закончите, и все, что вы хотите, зафиксировано, вы можете удалить папку dir-name
и запустить git worktree prune
, чтобы очистить потерянную рабочую папку в своем репо.
Ответ 5
Вы также можете использовать -C в качестве опции. Не используйте его перед любой другой командой, например
git -C ~/my-git-repo checkout master
Обратите внимание, что это не обязательно должна быть папка .git. Вот предписание человека:
-C <path>
Run as if git was started in <path> instead of the current
working directory. When multiple -C options are given, each
subsequent non-absolute -C <path> is interpreted relative to
the preceding -C <path>.
This option affects options that expect path name like --git-dir
and --work-tree in that their interpretations of the path names
would be made relative to the working directory caused by the -C option.
For example the following invocations are equivalent:
git --git-dir=a.git --work-tree=b -C c status
git --git-dir=c/a.git --work-tree=c/b status