... 특히 FAT32 또는 exFAT USB 플래시 드라이브를 통해 이동할 때?
작업 복사본에 권한 변경이 발생하고 기호 링크가 명백히 제거될 수도 있지만(사용하는 경우)... Git이 이를 잘 감지할 수 있는 변경 사항은 별개로,.git/한 운영 체제 및/또는 파일 시스템에서 다른 운영 체제 및/또는 파일 시스템으로 저장소를 이동할 수 있을 만큼 디렉터리 내용이 충분합니까 ?예: Windows, 일반 Linux 배포판, macOS, NTFS, ext FS,APFS...
필요한 경우 Git 버전 2+를 가정할 수 있습니다.
답변1
예, 저장소 데이터베이스는 다음과 같습니다.대개모든 최신 운영 체제에서 이식 가능포함윈도우. 확장된 속성에 의존하지 않으며 지금까지는 대소문자 구분에도 의존하지 않습니다. 데이터베이스 내부의 파일 이름은 최대 52자인 것 같습니다.
주요 요구 사항은 파일 이름이보존하다대소문자를 구분하지 않는 파일 시스템에서도 마찬가지입니다(예: .git/HEAD를 ext4에서 FAT32, APFS, HFS+, ext4로 복사하는 경우 .git/HEAD로 유지되어야 하며 .git/head가 되어서는 안 됩니다). 다행히 위에 나열된 모든 파일 시스템~이다대소 문자를 보존하므로 괜찮습니다.
한 가지 명심해야 할 점은 각 브랜치나 태그가 .git/refs 아래에 별도의 파일로 표시된다는 것입니다. Git은 모든 파일 시스템에서 작동하기 위해 엄격한 문자 세트 제한을 적용하지만 항상 충분하지는 않습니다. 대소문자를 구분하지 않는 파일 시스템(예: APFS 또는 NTFS)으로 이동하는 경우 저장소에 포함되지 않기를 바랍니다. 여러 개의 분기 또는 태그는 대소문자만 다릅니다. 마찬가지로 Git은 분기/태그 이름과 aux같은 기존 DOS 장치 이름의 사용을 금지하지 않습니다 .nul
(기술적으로 다른 파일 시스템에 걸쳐 저장소를 이동하면 a-w객체 blob의 "읽기 전용"( ) 상태와 같은 일부 파일 메타데이터가 손실될 수 있지만 이는 어쨌든 Git 자체에서 확인하는 내용은 아닙니다.)
FAT32를 임시 전송 용도로만 사용하는 경우 분기 이름 문제를 최대한 피하고 사용하는 것을 git pack-refs --all --prune고려 하십시오. rm -rf .git/logs또한 git repack -d; git prune느슨한 개체 파일의 수를 줄이려면 a를 실행하세요.
git bundle커밋 기록 전체 또는 일부를 포함하는 전송 친화적인 Blob을 만드는 데 사용할 수도 있습니다 .
답변2
디렉터리 복사는 .git대부분의 경우 작동하지만 주의가 필요한 몇 가지 주의 사항이 있습니다.
git-svn은 이름, 이메일 주소 등 복사하고 싶지 않은 일부 사용자 정보를 기억할 수 있습니다
.git/logs/refs/remotes/trunk.복제된 저장소에는 복사 명령으로 생성이 취소되지 않는 상위 저장소에 대한 링크가 포함됩니다. 을 사용하여 해당 링크를 제거할 수 있습니다
git remote remove origin.디렉토리 에 심볼릭 링크가 있는 경우
.git해당 링크를 역참조해야 합니다. 예를 들어:cp -r -L <source-repo-dir> <destination-repo-dir>외부 프로그램을 참조하는 사용자 정의 diff 드라이버 및 후크 스크립트와 같은 일부 구성 항목은 플랫폼에 따라 다를 수 있습니다. 서로 다른 플랫폼 간에 복사할 때는
core.ignorecase,core.autocrlf, 및 기타 항목과core.safecrlf같은 항목을 확인해야 합니다 .core.fileMode자식 클론 컴퓨터 간에 작동할 수 있는 안전한 작업입니다.
git clone ssh://[email protected]/path/to/my-project.git복제는 원래 저장소를 다시 가리키는 "원본"이라는 원격 연결을 자동으로 생성하므로 중앙 저장소와 쉽게 상호 작용할 수 있습니다.
git 디렉토리를 선택적으로 이동하는 방법에 대한 다음 튜토리얼을 읽어보면 흥미로울 것입니다.