모든 분기 및 태그를 포함하여 전체 자식 저장소를 백업하는 간단한 방법이 있습니까?

복제본을 만드는 방법은 무엇입니까?

git clone --mirror other/repo.git

모든 저장소는 원격의 백업입니다.

git bundle

나는 그 방법을 좋아하는데, 하나의 파일 만으로 복사하기가 더 쉽습니다. ProGit : 작은 기쁨의 묶음을
참조하십시오 . " 어떻게 누군가에게 git 저장소를 이메일로 보낼 수 있습니까? "를 참조하십시오.

git bundle create /tmp/foo-all --all

상세하다 :

git bundlegit show-ref 로 표시되는 참조 만 패키지 합니다. 여기에는 헤드, 태그 및 원격 헤드가 포함됩니다.
사용 된 기초가 목적지에 의해 유지되는 것이 매우 중요합니다.
번들 파일에 대상에 이미있는 오브젝트가 포함되어 있으므로 대상에서 압축을 풀 때 무시되기 때문에주의를 기울여야합니다.

해당 번들을 사용하기 위해 존재하지 않는 폴더를 지정하여 복제 할 수 있습니다 (git repo 외부).

git clone /tmp/foo-all newFolder

다른 답변을 확장하면 이것이 내가하는 일입니다.

저장소를 설정하십시오. git clone --mirror user@server:/url-to-repo.git

그런 다음 git remote update복제 위치에서 백업을 새로 고치려고 할 때 .

이렇게하면 나중에 추가되는 새 항목을 포함하여 모든 지점과 태그가 백업되지만, 삭제 된 지점은 복제본에서 삭제되지 않습니다 (백업의 경우 좋을 수도 있음).

이것은 원자 적이므로 간단한 사본으로 인한 문제는 없습니다.

http://www.garron.me/en/bits/backup-git-bare-repo.html을 참조 하십시오

KingCrunch 및 VonC 의 훌륭한 답변 확대

나는 둘 다 결합했다.

git clone --mirror git@some.origin/reponame reponame.git
cd reponame.git
git bundle create reponame.bundle --all

그 후에는 reponame.bundle쉽게 복사 할 수 있는 파일 이 있습니다. 그런 다음을 사용하여 새로운 일반 git 저장소를 만들 수 있습니다 git clone reponame.bundle reponame.

참고 git bundle저장소에 일부 참조 (지점 또는 태그)로 이어질에만 복사 커밋. 따라서 엉킴 커밋은 번들에 저장되지 않습니다.

모든 것이 .git디렉토리에 포함되어 있습니다. 파일과 마찬가지로 프로젝트와 함께 백업하십시오.

자식 번들을 사용하거나 복제

git 디렉토리를 복사하는 것은 원자 적이 지 않기 때문에 좋은 해결책이 아닙니다. 복사하는 데 시간이 오래 걸리고 누군가가 저장소로 푸시하는 큰 저장소가있는 경우 백업에 영향을줍니다. 번들을 복제하거나 만들면이 문제가 발생하지 않습니다.

최소 저장소 크기에서 git-copy 를 사용하여 git repo를 백업 할 수 있습니다 .

git copy /path/to/project /backup/project.repo.backup

그런 다음 프로젝트를 복원 할 수 있습니다 git clone

git clone /backup/project.repo.backup project

정답 IMO는 git clone --mirror 입니다. 리포지토리가 완전히 백업됩니다.

Git 복제 미러는 전체 리포지토리, 메모, 헤드, 참조 등을 복제하며 일반적으로 전체 리포지토리를 새 git 서버에 복사하는 데 사용됩니다. 이것은 모든 지점과 모든,은 An 아래로 끌어 전체 저장소를.

git clone --mirror git@example.com/your-repo.git

• 일반적으로 리포지토리 복제에는 모든 분기가 포함되지 않으며 마스터 만 포함됩니다.

• repo 폴더를 복사하면 가져온 분기 만 "복사"됩니다. 기본적으로 마스터 분기 만 또는 이전에 체크 아웃 한 다른 분기입니다.

• Git bundle 명령은 또한 원하는 것이 아닙니다. "bundle 명령은 일반적으로 git push 명령을 사용하여 와이어를 통해 푸시되는 모든 것을 바이너리 파일로 패키지하여 누군가에게 이메일로 보내거나 플래시 드라이브에 넣을 수 있습니다. 다른 저장소로 묶지 마십시오. " ( git clone --mirror와 git clone --bare의 차이점은 무엇입니까? )

이 스레드는 git repos의 백업을 수행하는 방법에 대한 통찰력을 얻는 데 매우 도움이되었습니다. 나는 아직도 자신에게 "올바른 방법"(tm)을 찾는 힌트, 정보 또는 결론이 부족하다고 생각합니다. 그러므로 내 생각을 여기에 공유하여 다른 사람들을 돕고 토론을 위해 향상시킬 수 있습니다. 감사.

따라서 원래 질문을 선택하는 것으로 시작하십시오.

• 목표는 git 저장소의 "전체"백업에 최대한 가깝게하는 것입니다.

그런 다음 일반적인 요구 사항으로 풍부하게하고 사전 설정을 지정하십시오.

• 서비스 중단 시간을 피하려면 "핫 카피"를 통한 백업이 선호됩니다.
• git의 단점은 추가 명령으로 해결할 수 있습니다.
• 스크립트는 단일 백업을위한 여러 단계를 결합하고 사람의 실수 (오타 등)를 피하기 위해 백업을 수행해야합니다.
• 또한 스크립트는 덤프를 대상 머신에 적용하기 위해 복원을 수행해야합니다. 예를 들어 백업 이후 원래 머신의 구성도 변경되었을 수 있습니다.
• 환경은 하드 링크를 지원하는 파일 시스템이있는 Linux 시스템의 git 서버입니다.

1. "전체"git repo 백업이란 무엇입니까?

"100 %"백업의 관점에서 관점이 다릅니다. 다음은 일반적인 두 가지입니다.

# 1 개발자의 관점

• 함유량
• 참고 문헌

자식은 개발자 도구입니다 통해 이러한 관점을 지원 git clone --mirror하고 git bundle --all.

# 2 관리자의 관점

• 컨텐츠 파일
  • 특수한 경우 "packfile": git은 가비지 수집 중에 객체를 팩 파일로 결합하고 압축합니다 (참조 git gc)
• 자식 구성
  • 참조 https://git-scm.com/book/en/v2/Git-Internals-Plumbing-and-Porcelain를
  • docs : man git-config, man gitignore
  • .git / config
  • .git / description (후크 및 툴, 예 : 이메일 수신 후 후크, gitolite, GitWeb 등)
  • .git / hooks /
  • .git / info / (리포지토리 제외 파일 등)
• 선택 사항 : OS 구성 (파일 시스템 권한 등)

git는 개발자 도구이며 관리자에게 맡깁니다. git 구성 및 OS 구성의 백업은 내용의 백업과 분리 된 것으로 보여야합니다.

2. 기술

• "콜드 카피"
  • 파일에 독점적으로 액세스 할 수 있도록 서비스를 중지하십시오. 중단 시간!
• "핫 카피"
  • 서비스는 백업 목적으로 고정 상태를 제공합니다. 진행중인 변경 사항은 해당 상태에 영향을 미치지 않습니다.

3. 다른 주제

대부분 백업에 일반적입니다.

• 전체 백업을 저장할 공간이 충분합니까? 몇 세대가 저장됩니까?
• 증분 방식이 필요합니까? 몇 세대가 저장되며 언제 전체 백업을 다시 작성해야합니까?
• 생성 후 또는 시간이 지남에 따라 백업이 손상되지 않았는지 확인하는 방법은 무엇입니까?
• 파일 시스템이 하드 링크를 지원합니까?
• 단일 아카이브 파일에 백업을 넣거나 디렉토리 구조를 사용 하시겠습니까?

4. git이 콘텐츠를 백업하기 위해 제공하는 것

• git gc --auto

  • 문서 : man git-gc
  • 리포지토리를 정리하고 압축합니다.

• git bundle --all

  • docs : man git-bundle, man git-rev-list
  • 원자 = "핫 카피"
  • 번들은 덤프 파일이며 git (확인, 복제 등)과 함께 직접 사용할 수 있습니다.
  • 증분 추출을 지원합니다.
  • 를 통해 확인할 수 git bundle verify있습니다.

• git clone --mirror

  • docs : man git-clone, man git-fsck, git clone --mirror와 git clone --bare의 차이점은 무엇입니까?
  • 원자 = "핫 카피"
  • 미러는 실제 자식 리포지토리입니다.
  • 이 명령의 주요 목적은 원래 저장소에서 정기적으로 업데이트를 가져 오는 전체 활성 미러를 작성하는 것입니다.
  • 공간 낭비를 피하기 위해 동일한 파일 시스템에서 미러에 대한 하드 링크를 지원합니다.
  • 를 통해 확인할 수 git fsck있습니다.
  • 미러는 전체 파일 백업 스크립트의 기초로 사용될 수 있습니다.

5. 콜드 카피

콜드 복사 백업은 항상 전체 파일 백업을 수행 할 수 있습니다 . git repos에 대한 모든 액세스를 거부 하고 백업을 수행하고 다시 액세스를 허용하십시오.

• 가능한 문제
  • 파일 시스템을 통한 공유 액세스와 같은 모든 액세스를 거부하기가 쉽지 않을 수도 있습니다.
  • 리포지토리가 단일 사용자가있는 클라이언트 전용 시스템에 있어도 사용자는 자동화 된 백업 실행 중에 무언가를 커밋 할 수 있습니다. (
  • 서버에서 가동 중지 시간이 허용되지 않을 수 있으며 여러 대규모 저장소를 백업하는 데 시간이 오래 걸릴 수 있습니다.
• 완화를위한 아이디어 :
  • 클라이언트가 동일한 시스템에 있더라도 일반적으로 파일 시스템을 통한 직접 repo 액세스를 방지하십시오.
  • SSH / HTTP 액세스의 경우 git 권한 부여 관리자 (예 : gitolite)를 사용하여 스크립트 방식으로 액세스를 동적으로 관리하거나 인증 파일을 수정하십시오.
  • 백업을 하나씩 리포 지하여 각 리포지토리의 다운 타임을 줄입니다. 하나의 리포지를 거부하고 백업을 수행 한 후 다시 액세스를 허용 한 후 다음 리포지토리를 계속하십시오.
  • 개발자의 혼란을 피하기 위해 유지 관리 일정을 계획하십시오.
  • 저장소가 변경된 경우에만 백업하십시오. 구현하기가 매우 어려울 수 있습니다 (예 : 객체 목록과 팩 파일을 염두에두고 구성 및 후크 체크섬 등).

6. 핫 카피

진행중인 커밋으로 인해 데이터가 손상 될 위험 때문에 활성 저장소로 파일 백업을 수행 할 수 없습니다. 핫 카피는 백업 목적으로 고정 된 활성 저장소 상태를 제공합니다. 진행중인 커밋은 해당 복사본에 영향을 미치지 않습니다. 위에 나열된 것처럼 git의 클론 및 번들 기능은이를 지원하지만 "100 % 관리자"백업의 경우 추가 명령을 통해 몇 가지 작업을 수행해야합니다.

"100 % 관리자"핫 카피 백업

• 옵션 1 : 사용 git bundle --all 컨텐츠의 전체 / 증분 덤프 파일을 작성하고 구성 파일을 별도로 복사 / 백업하는 데 사용합니다.
• 옵션 2 : 사용 git clone --mirror 구성을 개별적으로 , 처리 및 복사 한 다음 미러의 전체 파일 백업을 수행하십시오.
  • 노트:
  • 미러는 새로운 리포지토리이며 생성시 현재 자식 템플릿으로 채워집니다.
  • 구성 파일 및 디렉토리를 정리 한 다음 원래 소스 저장소에서 구성 파일을 복사하십시오.
  • 백업 스크립트는 미러에 대한 파일 권한과 같은 OS 구성을 적용 할 수도 있습니다.
  • 하드 링크를 지원하는 파일 시스템을 사용하고 소스 리포지토리와 동일한 파일 시스템에 미러를 만들어 백업하는 동안 속도를 높이고 공간 소비를 줄입니다.

7. 복원

• 머신을 목표로하는 최신 git 구성과 최신 "작업 방식"철학을 확인하고 채택하십시오.
• OS 구성을 확인하고 채택하여 머신과 최신 "작업 방식"철학을 목표로합니다.

cd /path/to/backupdir/
git clone /path/to/repo
cd /path/to/repo
git remote add backup /path/to/backupdir
git push --set-upstream backup master

이렇게하면 백업이 생성되고 설정이 완료되므로 git push를 사용하여 백업을 업데이트 할 수 있습니다. / path / to / backupdir과 / path / to / repo가 ​​최소한 다른 하드 드라이브인지 확인하십시오. 그렇지 않으면 그렇게하는 것이 그다지 의미가 없습니다.

두 가지 옵션이 있습니다.

1. git repo 디렉토리 의 tar 는 서버에 repo의 전체 내용이 있으므로 직접 tar 를 사용할 수 있습니다 . 백업하는 동안 누군가 repo 작업을하고있을 가능성이 약간 있습니다.

2. 다음 명령은 서버에있는 것처럼 레포의 베어 클론을 제공하며 문제없이 복제 한 위치의 tar를 취할 수 있습니다.

   git clone --bare {your backup local repo} {new location where you want to clone}
   

Github에있는 경우 bitbucket으로 이동하여 "저장소 가져 오기"방법을 사용하여 github 저장소를 개인 저장소로 가져옵니다.

비트 버킷에있는 경우 다른 방법으로 수행하십시오.

전체 백업이지만 클라우드에 머무르는 것이 이상적입니다.

내가 아는 한 리포지토리가있는 디렉토리의 사본을 만들 수 있습니다.

cp -r project project-backup