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

Я полный нуб, когда дело доходит до 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

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

Спасибо

Вы можете указать 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

$ 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подразумевается опция.

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

git clone file: ////home/git/repositories/MyProject.git/

Мне удалось это сделать с помощью file: //, но с одним дополнительным слешем для обозначения абсолютного пути.

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

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

Добавление пульта работает так же

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

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

git clone Z:\

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

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

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

$ 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-репо).

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

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

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

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

Следующее использует относительные пути:

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

Хотя путь 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 г.) от Johannes Schindelin (dscho ) . Помогает
: Ким Гайбелс ( Jeff-G) .
^{(Слиты Junio C Hamano - gitster- в фиксации f5dd919 , 05 Feb 2019)}

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

Симптом является то , что первый из этих двух обратных косых черт в 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] is» shи относится ли он к MSYS2 Bash, чтобы определить, нужно ли нам цитировать аргументы иначе, чем обычно.

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

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

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

Видеть t/t5580-clone-push-unc.sh

После клона пуш не работал.

Решение: в случае клонирования репозитория откройте папку .git и файл конфигурации.

Для удаленного источника URL установите значение:

[remote "origin"]
    url = file:///C:/Documentation/git_server/kurmisoftware