브랜치 push가 성공했다고 로컬 태그도 모두 원격에 전송됐다고 가정하지 마세요. 로컬 태그의 존재와 대상 커밋을 확인하고, 실제 push 옵션·설정이 태그를 포함했는지 나누어 확인해야 합니다.
적용 환경: Git 명령행 저장소와 원격 태그 목록 조회 권한; 실제 저장소 폴더에서 실행, 아래 명령은 로컬 조회 예시이며 원격 push는 실행하지 않음. 자료 확인일: 2026-10-29. 공식 문서 기반 안내이며 실제 계정·운영 환경에서 실행한 시험 결과가 아닙니다.
1. 원인: 브랜치와 태그는 별도의 참조다
Git Book은 기본 git push가 태그를 자동 전송하지 않는다고 설명합니다. 다만 실제 동작은 명령의 refspec과 push.followTags 같은 설정의 영향을 받습니다. 성공 메시지 하나로 무엇이 전송됐는지 생략하지 말고 명령과 출력에 나타난 참조를 대조하세요.
로컬에 붙인 릴리스 이름과 원격 호스팅 서비스의 태그 화면은 같은 저장 위치가 아닙니다. 다른 원격으로 보냈거나 태그 생성 전에 브랜치만 push했다면 결과가 달라질 수 있습니다. 태그를 다시 만들기 전에 현재 참조부터 조사합니다.
2. 해결: 로컬 태그와 태그 종류 확인
아래 예시의 v1.2.3은 실제 존재하는 태그로 바꾸세요. 해당 저장소 안에서 실행하며 태그가 없으면 오류가 날 수 있습니다. 조회 결과의 커밋 ID나 저장소 경로에 민감한 정보가 있으면 공유 전 가립니다.
git tag --list
git cat-file -t refs/tags/v1.2.3
git rev-parse v1.2.3^{}태그 참조가 가리키는 객체 종류가 tag라면 주석 태그인지 조사할 수 있습니다. commit을 바로 가리키는 경량 태그와 구분하고, 역참조한 커밋이 의도한 릴리스인지 확인합니다. 태그 이름만 같다는 이유로 같은 소스를 가리킨다고 단정하지 않습니다.
| 전송 범위 | 태그에 관한 의미 |
| 이름을 지정한 태그 | 승인한 특정 태그 전송 범위 검토 |
| --tags | 로컬 태그 전체가 대상이 될 수 있음 |
| --follow-tags | 보내는 참조에서 도달 가능한 누락 주석 태그 |
| --all | 브랜치 전체 옵션을 태그 전체로 오해하지 않기 |
3. 확인: 대상 원격의 실제 태그를 대조
승인된 원격 호스팅 화면에서 정확한 태그 이름과 커밋을 확인합니다. 원격 조회 명령을 사용할 때도 현재 원격 주소와 읽기 권한을 확인하고, 다른 저장소의 태그를 비교하지 마세요. push 설정에 followTags가 켜졌어도 경량 태그까지 같은 조건으로 포함된다고 생각하면 안 됩니다.
정말 전송이 빠졌다면 공유 범위와 릴리스 자동화 영향을 검토한 뒤 특정 태그만 보내는 방법을 선택합니다. 진단을 위해 --tags로 관련 없는 태그까지 일괄 전송하거나, 이미 공유한 태그를 강제로 이동시키지 않습니다.
4. 주의와 FAQ
태그가 원격에 있으면 배포도 끝났나요? 태그 전송과 CI 실행·릴리스 생성·배포 성공은 각각 확인해야 합니다. 원격 참조 생성만으로 배포 완료를 보고하지 마세요.
--follow-tags면 모든 태그가 올라가나요? 아닙니다. Git 문서는 누락된 주석 태그 중 전송하는 참조에서 도달 가능한 대상을 설명합니다. 경량 태그나 별도 이력의 태그가 같은 방식으로 포함된다고 보장하지 않습니다.
공식 출처와 관련 글
'소프트웨어개발' 카테고리의 다른 글
| S3 Batch Operations가 Complete인데 실패 객체가 남을 때: 완료 보고서 확인 (0) | 2026.10.30 |
|---|---|
| RDS 자동 확장 후 용량이 줄지 않을 때: 할당량과 여유 공간 구분 (0) | 2026.10.30 |
| curl에서 301·302만 보일 때: Location과 최종 URL 확인 (0) | 2026.10.29 |
