CI나 새 복제본에서 과거 커밋이 보이지 않으면 먼저 shallow clone 여부를 확인하세요. 이력을 일부만 내려받은 상황은 커밋을 잃어버린 상황과 다르므로, 복구 명령보다 저장소와 조회 범위를 먼저 구분해야 합니다.
적용 환경: Git의 --is-shallow-repository 옵션을 지원하는 로컬 저장소 또는 CI 체크아웃; 명령은 그 저장소 디렉터리에서 실행. 자료 확인일: 2026-10-28. 공식 문서와 별도 임시 저장소 시험을 구분해 안내합니다. 실제 운영·외부 원격 저장소에서 실행한 결과가 아닙니다.
1. 원인: clone 깊이가 이력 탐색을 제한한다
git clone --depth는 지정한 커밋 수로 이력을 제한하는 얕은 복제를 만듭니다. 기본적으로 단일 브랜치 복제를 함께 뜻하므로, 서버에 존재하는 과거 이력이나 다른 브랜치가 로컬 로그에 모두 보인다고 가정하면 안 됩니다.
반대로 일반 저장소에서 브랜치나 경로 필터를 좁혀 본 경우도 있습니다. 로그가 짧다는 증상 하나로 shallow 상태를 단정하지 않고, CI 체크아웃 설정과 실제 저장소 조회를 함께 봅니다.
2. 해결: 저장소·얕은 복제·로그 범위를 조회
다음은 로컬 상태를 읽는 명령입니다. 저장소 안에서 실행하며 출력 경로와 커밋 메시지에 사내 정보가 있으면 공유 전 가립니다.
git --version
git rev-parse --show-toplevel
git rev-parse --is-shallow-repository
git log --oneline -n 10
git branch --all| 결과 | 읽을 의미 |
| shallow 조회 true | 깊이 제한을 먼저 조사 |
| shallow 조회 false | 브랜치·경로·참조 범위 조사 |
| 로컬 브랜치만 적음 | 원격 추적 범위와 CI 설정 대조 |
| 로컬에서 만든 커밋을 잃음 | 별도 reflog 보존 절차 검토 |
격리된 로컬 시험에서 확인한 결과
2026-10-28 06:59 KST, macOS의 Git 2.50.1(Apple Git-155)로 별도 임시 저장소에 직접 만든 커밋 세 개를 저장했습니다. 이를 file:// 전송과 --depth 1로 새 폴더에 복제했을 때 --is-shallow-repository는 true, git rev-list --count HEAD는 1을 출력했고 git log --oneline에는 마지막 example-3 커밋 하나만 나타났습니다.
이는 깊이를 제한한 복제본에서 로컬 조회 이력이 짧아지는 현상을 확인한 시험입니다. 외부 저장소·운영 파일은 변경하지 않았으며 추가 fetch로 깊이를 늘리는 시험은 수행하지 않았습니다. 실제 CI의 인증·refspec·체크아웃 동작은 해당 환경에서 별도로 확인해야 합니다.
3. 확인: 필요한 이력을 명시하고 취득 범위를 정한다
원하는 것이 직전 몇 커밋의 변경 비교인지, 특정 릴리스 태그인지, 모든 과거 이력인지 먼저 적으세요. CI 설정에 depth·branch·tag 제한이 있는지 확인하고 필요한 참조와 깊이를 담당자에게 전달합니다. 이력이 부족하다는 이유만으로 모든 작업에 전체 복제를 강제할 필요는 없습니다.
추가 fetch는 네트워크 사용과 로컬 참조 갱신을 수반합니다. 실제 원격과 권한을 확인한 후 필요한 범위만 취득하고, 다시 shallow 상태 및 대상 커밋의 조회 가능 여부를 확인하세요. 이 글의 조회 명령만으로 원격 이력을 추가로 받거나 복구를 완료하지는 않습니다.
4. 주의와 FAQ
reflog로 서버의 옛 커밋을 모두 볼 수 있나요? reflog는 로컬 참조 이동 기록을 조사하는 용도입니다. 애초 받지 않은 원격 이력을 자동으로 제공하지 않습니다. 직접 만든 커밋을 잃은 경우와 구분하세요.
shallow가 false면 서버와 완전히 같은가요? 아닙니다. 브랜치·태그·refspec·조회한 경로의 범위가 다를 수 있습니다. false는 얕은 저장소가 아니라는 상태이며 모든 참조의 최신 동기화를 보장하지 않습니다.
공식 출처와 관련 글
Git clone의 depth와 single-branch 조건
Git 커밋을 잃어버렸을 때: reflog 확인 후 복구 브랜치부터 만드는 순서
reset이나 rebase 뒤 커밋이 보이지 않으면 먼저 로컬 reflog에서 후보를 찾고 내용을 확인하세요. 바로 reset --hard를 실행하기보다 새 복구 브랜치를 만들어 후보 커밋을 보존하는 편이 현재 작업을
papa-titipo.com
'소프트웨어개발' 카테고리의 다른 글
| S3 Inventory에 최근 파일이 없을 때: 첫 보고서와 현재 상태 구분 (0) | 2026.10.29 |
|---|---|
| EC2를 중지했는데 비용이 남을 때: EBS와 Elastic IP를 따로 확인 (0) | 2026.10.29 |
| Compose 재생성 후 접속 포트가 바뀔 때: 동적 호스트 포트 확인 (0) | 2026.10.28 |
