GIT клонирование репо через локальную файловую систему в окнах

Я полный Noob, когда дело доходит до GIT. За последние несколько дней я делал первые шаги. Я настраивал репо на своем ноутбуке, вытащил Trunk из проекта SVN (имел некоторые проблемы с ветвями, не получил их работу), но все вроде хорошо.

Теперь я хочу, чтобы можно было тянуть или отталкивать от ноутбука до моего основного рабочего стола. Причина в том, что ноутбук удобен в поезде, поскольку я провожу 2 часа в день, путешествуя и могу получить хорошую работу. Но моя главная машина дома отлично подходит для развития. Поэтому, когда я прихожу домой, я хочу, чтобы я мог нажать/вытащить из ноутбука на главный компьютер. Я думал, что самый простой способ сделать это - просто иметь общую папку кода по локальной сети и делать:

git clone file://192.168.10.51/code

К сожалению, это, похоже, не работает для меня:

поэтому я открываю git bash cmd и набираю приведенную выше команду, я нахожусь в C:\code (общая папка для обеих машин), это то, что я возвращаю:

Initialized empty Git repository in C:/code/code/.git/
fatal: 'C:/Program Files (x86)/Git/code' does not appear to be a git repository
fatal: The remote end hung up unexpectedly

Как я могу поделиться репозиторием между двумя машинами самым простым способом.

Там будут другие местоположения, которые станут официальными точками хранения и местами, где будут работать другие разработчики и сервер CI и т.д. Это просто так, что я могу работать с одним и тем же репо на двух машинах.

В соответствии с предложением Себастьяна я получаю следующее:

C:\code>git clone --no-hardlinks file://192.168.10.51/code
Initialized empty Git repository in C:/code/code/.git/
fatal: 'C:/Program Files (x86)/Git/code' does not appear to be a git repository
fatal: The remote end hung up unexpectedly

** РЕДАКТИРОВАТЬ - ОТВЕТ **

Спасибо всем, что помогло. Я попробовал сопоставление диска, и это сработало, поэтому я подумал, что вернусь и повторю попытку без сопоставления. Конечный результат:

git clone file://\\\\192.168.0.51\code

Это сработало отлично.

Спасибо

Ответ 1

Вы можете указать URL-адрес пультов, применяя путь UNC к файловому протоколу. Для этого необходимо использовать четыре слэша:

git clone file:////<host>/<share>/<path>

Например, если ваша основная машина имеет IP 192.168.10.51 и имя компьютера main, и у нее есть общий ресурс с именем code, который сам является репозиторием git, тогда обе следующие команды должны работать одинаково:

git clone file:////main/code
git clone file:////192.168.10.51/code

Если репозиторий git находится в подкаталоге, просто добавьте путь:

git clone file:////main/code/project-repository
git clone file:////192.168.10.51/code/project-repository

Ответ 2

$ git clone --no-hardlinks /path/to/repo

Вышеупомянутая команда использует нотацию пути POSIX для каталога с вашим репозиторием git. Для Windows это (каталог C:/path/to/repo содержит каталог .git):

C:\some\dir\> git clone --local file:///C:/path/to/repo my_project

Репозиторий будет клонирован к C:\some\dir\my_project. Если вы опустите file:/// часть, то подразумевается опция --local.

Ответ 3

ответ с именем хоста не работал у меня но это произошло:

git файл клона:////home/ git/repositories/MyProject.git/

Ответ 4

Мне удалось сделать это, используя файл://, но с одним дополнительным косой чертой для обозначения абсолютного пути.

git clone file:///cygdrive/c/path/to/repository/

В моем случае я использую Git в Cygwin для Windows, который вы можете увидеть из-за части /cygdrive/c на моих путях. С некоторой настройкой на путь он должен работать с любой установкой Git.

Добавление удаленного объекта работает одинаково

git remote add remotename file:///cygdrive/c/path/to/repository/

Ответ 5

Возможно, сопоставьте общий ресурс как сетевой диск, а затем выполните

git clone Z:\

В основном просто догадка; Я всегда делаю это с помощью ssh. Конечно, это будет означать, что вам нужно будет отображать этот диск каждый раз, когда вы нажимаете/тянете/с ноутбука. Я не уверен, как вы устанавливаете ssh для работы под окнами, но если вы собираетесь делать это много, возможно, стоит изучить.

Ответ 6

Не уверен, что это из-за моей версии git (1.7.2) или что-то, но перечисленные выше методы с использованием имени машины и IP-параметров не работали для меня. Дополнительная информация, которая может/не может быть важна, заключается в том, что репо было голой репо, которую я инициализировал и выталкивал с другой машины.

Я пытался клонировать проект1, как описано выше, с помощью команд типа:

$ git clone file:////<IP_ADDRESS>/home/user/git/project1
Cloning into project1...
fatal: '//<IP_ADDRESS>/home/user/git/project1' does not appear to be a git repository
fatal: The remote end hung up unexpectedly

и

$ git clone file:////<MACHINE_NAME>/home/user/git/project1
Cloning into project1...
fatal: '//<MACHINE_NAME>/home/user/git/project1' does not appear to be a git repository
fatal: The remote end hung up unexpectedly

Что работало для меня, было что-то более простое:

$ git clone ../git/project1
Cloning into project1...
done.

Примечание. Несмотря на то, что клонированный репо был голым, это создало "нормальный" клон со всеми фактическими файлами кода/изображения/ресурсов, на которые я надеялся (в отличие от внутренних репо git).

Ответ 7

Введите абсолютные пути или относительные пути.

Например, первый из них использует абсолютные пути:

(это изнутри папки, содержащей репозиторий и резервную копию, как вложенные папки. Также помните, что папка резервного копирования не изменяется, если она уже содержит что-либо, а если она отсутствует, будет создана новая папка)

~/git$ git clone --no-hardlinks ~/git/git_test1/   ~/git/bkp_repos/

Далее используются относительные пути:

~/git$ git clone --no-hardlinks git_test1/   bkp_repos2/

Ответ 8

Хотя путь UNC поддерживается начиная с Git 2.21 (февраль 2019 г., см. ниже), Git 2.24 (Q4 2019) разрешит

git clone file://192.168.10.51/code

Нет больше file:////xxx, достаточно "file://" для ссылки на общий путь UNC.
Смотрите "Ошибка Git Fetch с UNC".


Обратите внимание, что с 2016 года и MingW-64 git.exe в комплекте с Git для Windows поддерживается UNC-путь.
(См. "Как msys, msys2 и MinGW-64 связаны друг с другом?")

А в Git 2.21 (февраль 2019 г.) эта поддержка распространяется даже внутри оболочки msys2 (с кавычками вокруг пути UNC).

См. коммит 9e9da23, коммит 5440df4 (17 января 2019 г.) от Йоханнеса Шинделина (dscho).
Помощник: Ким Гайбелс (Jeff-G).
(Merged by Junio C Hamano -- [TG46] -- in commit f5dd919, 05 Feb 2019)

До Git 2.21, из-за причуды в методе Git для порождения git-upload-pack, существует проблема при прохождении путей с обратными слешами в них: Git заставит командной строки через оболочку, которая имеет различную семантику цитирования в Git для Windows (будучи программой MSYS2), чем обычные исполняемые файлы Win32 такой как сам TG48.

Симптом состоит в том, что первый из двух обратных слешей в UNC-путях форма \\myserver\folder\repository.git удаляется.

Теперь это смягчено:

mingw: аргументы специального случая для sh

Среда выполнения MSYS2 делает все возможное, чтобы эмулировать расширение подстановочного знака и удаление из кавычек командной строки, которое будет выполняться вызывающей оболочкой Unix в системах Unix.

Эти правила цитирования оболочки Unix отличаются от правил цитирования, применяемых к cmd и Powershell в Windows, что затрудняет правильное цитирование параметров командной строки при порождении других процессов.

В частности, git.exe передает аргументы подпроцессам, которые не предназначены для интерпретации как символы подстановки, и, если они содержат обратную косую черту, они не должны интерпретироваться как escape-символы, например при прохождении путей Windows.

Примечание: это проблема только при вызове исполняемых файлов MSYS2, а не при вызове исполняемых файлов MINGW, таких как git.exe. Однако мы часто вызываем исполняемые файлы MSYS2, особенно при установке флага use_shell в структуре child_process.

Не существует элегантного способа определить, является ли исполняемый файл .exe программой MSYS2 или MINGW.
Но так как прецедент передачи командной строки через оболочку настолько распространен, нам нужно обойти эту проблему, по крайней мере, при выполнении sh.exe.

Давайте введем некрасивый, жестко закодированный тест, является ли argv[0] "sh", и относится ли это к MSYS2 Bash, чтобы определить, нужно ли нам цитируйте аргументы иначе, чем обычно.

Это все еще не решает проблему полностью, но по крайней мере это что-то.

Кстати, это также устраняет проблему, когда git clone \\server\repo не удался из-за неправильной обработки обратных слеш при передаче пути к процессу git-upload-pack.

Кроме того, мы должны позаботиться о том, чтобы указывать не только пробел и обратную косую черту, но и фигурные скобки.
Поскольку псевдонимы часто проходят через MSYS2 Bash, и поскольку псевдонимы часто получают такие параметры, как [email protected]{yesterday}, это действительно важно.

Смотрите t/t5580-clone-push-unc.sh