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