Windows의 로컬 파일 시스템에서 GIT 복제 저장소

Windows의 로컬 파일 시스템에서 GIT 복제 저장소

---

GIT에 관해서는 완전한 Noob입니다. 지난 며칠 동안 첫 발걸음을 내딛었습니다. 랩톱에 저장소를 설정하고 SVN 프로젝트에서 트렁크를 가져 왔습니다 (분기에 문제가 있었지만 작동하지 않았습니다).

이제 랩탑에서 메인 데스크탑으로 당기거나 밀어 낼 수 있기를 원합니다. 노트북을 사용하는 이유는 하루 2 시간 씩 여행하면서 기차에서 편리하며 좋은 일을 할 수 있습니다. 그러나 집에있는 메인 머신은 개발하기에 좋습니다. 집에 도착했을 때 랩탑에서 메인 컴퓨터로 밀거나 당길 수 있기를 원합니다. 이 작업을 수행하는 가장 간단한 방법은 코드 폴더를 LAN을 통해 공유하고 수행하는 것입니다.

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 서버 등을 가져올 장소가있을 것입니다. 이것은 두 컴퓨터에서 동일한 리포지토리에서 작업 할 수 있도록하기위한 것입니다.

Sebastian의 제안에 따라 다음을 얻습니다.

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

이것은 훌륭하게 작동했습니다.

감사

---

파일 프로토콜에 UNC 경로를 적용하여 원격 URL을 지정할 수 있습니다 . 이를 위해서는 네 개의 슬래시를 사용해야합니다.

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

위의 명령은 git 저장소가있는 디렉토리에 POSIX 경로 표기법을 사용합니다. 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/

필자의 경우 Windows 용 Cygwin에서 Git을 사용하고 있습니다.이 경로는 / cygdrive / c 부분으로 인해 볼 수 있습니다. 경로를 약간 조정하면 모든 git 설치와 함께 작동해야합니다.

리모컨 추가는 같은 방식으로 작동합니다

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

---

공유를 네트워크 드라이브로 매핑 한 다음

git clone Z:\

대부분 추측 일뿐입니다. 나는 항상 ssh를 사용 하여이 일을합니다. 물론이 제안을 따르면 랩톱을 밀거나 당길 때마다 해당 드라이브를 매핑해야합니다. 창문 아래에서 작동하도록 ssh를 어떻게 조작하는지 잘 모르겠지만이 작업을 많이 수행하려면 조사해 볼 가치가 있습니다.

---

Not sure if it was because of my git version (1.7.2) or what, but the approaches listed above using machine name and IP options were not working for me. An additional detail that may/may not be important is that the repo was a bare repo that I had initialized and pushed to from a different machine.

I was trying to clone project1 as advised above with commands like:

$ 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

and

$ 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

What did work for me was something simpler:

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

Note - even though the repo being cloned from was bare, this did produce a 'normal' clone with all the actual code/image/resource files that I was hoping for (as opposed to the internals of the git repo).

---

Either enter absolute paths or relative paths.

For example the first one below uses absolute paths :

(this is from inside the folder which contains the repository and the backup as subfolders. also remember that the backup folder is not modified if it already contains anything. and if it is not present, a new folder will be created )

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

The following uses relative paths :

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

---

While UNC path is supported since Git 2.21 (Feb. 2019, see below), Git 2.24 (Q4 2019) will allow

git clone file://192.168.10.51/code

No more file:////xxx, 'file://' is enough to refer to an UNC path share.
See "Git Fetch Error with UNC".

---

Note, since 2016 and the MingW-64 git.exe packaged with Git for Windows, an UNC path is supported.
(See "How are msys, msys2, and MinGW-64 related to each other?")

And with Git 2.21 (Feb. 2019), this support extends even in in an msys2 shell (with quotes around the UNC path).

See commit 9e9da23, commit 5440df4 (17 Jan 2019) by Johannes Schindelin (dscho).
Helped-by: Kim Gybels (Jeff-G).
^{(Merged by Junio C Hamano -- gitster -- in commit f5dd919, 05 Feb 2019)}

Before Git 2.21, due to a quirk in Git's method to spawn git-upload-pack, there is a problem when passing paths with backslashes in them: Git will force the command-line through the shell, which has different quoting semantics in Git for Windows (being an MSYS2 program) than regular Win32 executables such as git.exe itself.

The symptom is that the first of the two backslashes in UNC paths of the form \\myserver\folder\repository.git is stripped off.

This is mitigated now:

mingw: special-case arguments to sh

The MSYS2 runtime does its best to emulate the command-line wildcard expansion and de-quoting which would be performed by the calling Unix shell on Unix systems.

Those Unix shell quoting rules differ from the quoting rules applying to Windows' cmd and Powershell, making it a little awkward to quote command-line parameters properly when spawning other processes.

In particular, git.exe passes arguments to subprocesses that are not intended to be interpreted as wildcards, and if they contain backslashes, those are not to be interpreted as escape characters, e.g. when passing Windows paths.

Note: this is only a problem when calling MSYS2 executables, not when calling MINGW executables such as git.exe. However, we do call MSYS2 executables frequently, most notably when setting the use_shell flag in the child_process structure.

There is no elegant way to determine whether the .exe file to be executed is an MSYS2 program or a MINGW one.
But since the use case of passing a command line through the shell is so prevalent, we need to work around this issue at least when executing sh.exe.

Let's introduce an ugly, hard-coded test whether argv[0] is "sh", and whether it refers to the MSYS2 Bash, to determine whether we need to quote the arguments differently than usual.

That still does not fix the issue completely, but at least it is something.

또한 프로세스 git clone \\server\repo경로를 전달할 때 백 슬래시를 잘못 처리하여 실패한 문제도 해결합니다 git-upload-pack.

또한 공백과 백 슬래시뿐만 아니라 중괄호도 인용해야합니다.
별명은 종종 MSYS2 Bash를 거치고 별명은과 같은 매개 변수를 얻는 경우가 많으므로 HEAD@{yesterday}실제로 중요합니다.

보다 t/t5580-clone-push-unc.sh

참고 URL : https://stackoverflow.com/questions/2519933/git-clone-repo-across-local-file-system-in-windows