GitHub 저장소 미러링
한눈에 보기
모든 브랜치와 태그를 다른 원격 저장소에 그대로 복제하는 미러링을 다룬다. git clone --mirror와 push --mirror 절차, 동기화 자동화, LFS와 메타데이터 관련 주의사항을 정리한다.
최종 업데이트 2026.09.17
저장소 미러링(repository mirroring)은 Git 저장소의 모든 브랜치, 태그, 참조를 다른 원격 저장소에 그대로 복제해서 두 저장소를 동일한 상태로 유지하는 작업이다. GitHub에서 GitLab으로 이전하거나, 사내 서버에 백업 사본을 두거나, 내부 저장소를 외부에 공개 미러로 제공할 때 사용한다. 핵심 도구는 git clone --mirror와 git push --mirror이며, 지속적인 동기화는 예약 작업으로 자동화한다.
미러링의 개념과 일반 클론과의 차이
일반적인 git clone은 기본 브랜치를 체크아웃하고 원격 브랜치를 원격 추적 참조로만 가져온다. 반면 미러 클론은 작업 디렉터리가 없는 베어 저장소(bare repository)로 만들어지며, 모든 브랜치와 태그를 포함한 원본의 참조(ref) 전체를 로컬 참조로 그대로 복사한다. 또한 원본에서 삭제된 참조는 미러에서도 삭제되도록 설정되므로, 미러는 원본의 완전한 거울이 된다.
git clone --bare와의 차이도 알아 두면 좋다. 베어 클론은 참조를 한 번 복사할 뿐이지만, 미러 클론은 remote 설정에 모든 참조를 갱신하는 fetch 규칙이 걸려 있어서 이후 git remote update 한 번으로 원본의 최신 상태를 통째로 따라갈 수 있다. 미러링은 이 성질을 이용해 원본에서 가져오고 대상에 밀어 넣는 두 단계로 이루어진다.
미러링 실제 절차
저장소를 다른 곳으로 옮기거나 복제하는 기본 절차는 다음과 같다. 먼저 대상 플랫폼에 빈 저장소를 만들어 두어야 한다.
# 1. 원본을 미러 클론한다 (모든 브랜치와 태그 포함)
git clone --mirror https://github.com/<원본계정>/<저장소>.git
cd <저장소>.git
# 2. 대상 저장소로 전체를 밀어 넣는다
git push --mirror https://github.com/<대상계정>/<저장소>.git
일회성 이전이 아니라 지속적인 동기화가 목적이라면 미러 클론을 유지한 채 주기적으로 갱신과 푸시를 반복한다.
# 원본의 최신 상태를 가져온다 (삭제된 참조도 반영)
git remote update --prune
# 대상에 다시 밀어 넣는다
git push --mirror https://github.com/<대상계정>/<저장소>.git
git push --mirror는 대상에만 있는 참조를 삭제하는 파괴적인 명령이므로, 대상 저장소에서 독자적인 커밋이 일어나는 상황과 함께 쓰면 안 된다. 미러 대상은 항상 읽기 전용으로 취급하는 것이 원칙이다. 브랜치와 태그만 밀고 싶다면 다음처럼 범위를 좁힐 수도 있다.
git push target-remote --all # 모든 브랜치
git push target-remote --tags # 모든 태그
동기화 자동화와 방식 비교
사람이 주기적으로 명령을 치는 방식은 오래가지 못하므로 자동화가 필수다. GitHub에서는 GitHub Actions의 예약 실행(schedule)으로 위 절차를 주기적으로 돌리는 방법이 널리 쓰이고, 원본 저장소의 push 이벤트를 트리거로 걸면 거의 실시간에 가까운 미러도 만들 수 있다. GitLab은 저장소 설정에 풀 미러링(pull mirroring)과 푸시 미러링(push mirroring)을 내장 기능으로 제공한다.
| 방식 | 동작 | 장점 | 한계 |
|---|---|---|---|
| 푸시 미러링 | 원본 쪽에서 변경이 생길 때 대상으로 밀어 넣는다 | 지연이 짧고 원본이 주도권을 가진다 | 원본 쪽에 자동화 설정과 대상 인증 정보가 필요하다 |
| 풀 미러링 | 대상 쪽에서 주기적으로 원본을 끌어온다 | 원본에 손대지 않아도 된다 | 주기만큼 지연이 생기고 GitLab 등 지원 플랫폼이 필요하다 |
| 일회성 이전 | clone --mirror 후 push --mirror 한 번 수행 | 가장 단순하고 이력이 완전하게 옮겨진다 | 이후 변경은 반영되지 않는다 |
GitHub Actions로 자동화할 때는 대상 저장소에 푸시할 수 있는 개인 접근 토큰(Personal Access Token)을 저장소 시크릿(secret)으로 등록하고, 워크플로 안에서 미러 클론과 미러 푸시를 실행하는 형태가 일반적이다.
미러링 시 주의사항
미러링은 Git 데이터만 복제한다는 점을 기억해야 한다. 이슈, 풀 리퀘스트, 위키, 릴리스 노트, 저장소 설정은 Git 객체가 아니므로 함께 옮겨지지 않으며, 이런 메타데이터까지 이전하려면 플랫폼의 가져오기 도구나 API를 별도로 써야 한다. Git LFS(Large File Storage)를 쓰는 저장소라면 포인터 파일만 복사되므로 git lfs fetch --all과 git lfs push --all로 대용량 객체를 따로 옮겨야 한다.
대상 저장소에 보호된 브랜치(protected branch)가 설정되어 있으면 미러 푸시가 거부될 수 있고, 코드 안에 하드코딩된 비밀값이 있다면 미러를 통해 그대로 유출된다는 점도 주의해야 한다. 미러를 백업 용도로 쓴다면, 미러가 원본의 잘못된 상태(예를 들어 강제 푸시로 이력이 날아간 상태)까지 충실히 복제한다는 한계도 알아야 한다. 미러는 복제본이지 시점별 백업이 아니므로, 진짜 백업이 필요하면 git bundle이나 스냅숏을 병행하는 것이 안전하다.
면접에서 이렇게 물어본다
- git clone, git clone --bare, git clone --mirror의 차이를 설명해 보라.
- 저장소를 GitHub에서 다른 플랫폼으로 이력 손실 없이 옮기는 절차를 명령 수준에서 설명해 보라.
- git push --mirror가 위험할 수 있는 이유와, 미러 대상을 읽기 전용으로 유지해야 하는 이유는 무엇인가.
- 미러링으로 옮겨지지 않는 것들(이슈, PR, LFS 객체 등)과 그 대응 방법을 말해 보라.
- 미러와 백업의 차이는 무엇이고, 백업 목적이라면 무엇을 추가로 고려해야 하는가.
Git과 협업에서 같이 읽기
- Node.js 프로젝트의 Git 협업node_modules와 .env는 제외하고 잠금 파일은 커밋하는 이유부터 npm ci, 기능 브랜치와 풀 리퀘스트 리뷰, 병합 전략까지 Node.js 팀의 표준 Git 협업 방식을 정리한다.
- Git 커밋 메시지 컨벤션커밋 메시지의 형식과 어휘를 통일하는 규칙을 다룬다. 제목, 본문, 꼬리말 구조와 컨벤셔널 커밋 타입 체계, commitlint와 husky로 컨벤션을 강제하는 방법까지 정리한다.
- Git Flow, GitHub Flow, GitLab Flow 비교릴리스 중심의 Git Flow, 지속 배포를 위한 GitHub Flow, 환경 브랜치로 배포 단계를 표현하는 GitLab Flow를 비교하고 배포 주기와 제품 형태에 따른 선택 기준을 정리한다.
- GitHub Fork로 협업하기원본 저장소에 쓰기 권한이 없어도 포크한 내 저장소에서 작업하고 풀 리퀘스트로 기여하는 오픈 소스 협업 방식을 다룬다. upstream 등록과 동기화, 공유 저장소 방식과의 비교까지 정리한다.
이 개념, 내 코드에서는 어떻게 물어볼까요
데브핏(DevFit)에 채용공고 URL을 붙여 넣고 레포지토리를 연결하면, 내가 쓴 커밋에서 예상 질문과 어필 포인트를 만듭니다. 하루 10회까지 무료입니다. 합불 판정이나 지원자 랭킹은 만들지 않고, 최종 판단은 사람이 합니다.
공고 넣고 시작하기