01
같은 이름을 두 모드에서 비교
모드를 바꾸어도 원문은 유지됩니다. main과 refs/heads/main을 비교하고, 참조 모드에서 단일 계층 허용이 필요한지 판단하세요. 이 옵션은 슬래시 요구 조건만 바꿉니다.
- 단독 @, 끝의 점, 연속된 슬래시까지 허용하는 옵션은 아닙니다.
Git & Version Control
Git 브랜치 이름 검사규칙과 권고를 구분해서
브랜치, 참조 이름 또는 객체 해시 하나를 검사하고 위치별 진단을 확인하세요.
Git 브랜치 이름 검사
이름 또는 해시 입력
검사 보고서
이름 또는 해시를 입력하세요.
현재 브라우저에서 검사합니다. 입력을 업로드하거나 저장소에 접속하지 않습니다.
검사 옵션
값 하나, 최대 4,096 UTF-16 코드 단위. 진단은 50개씩 표시합니다.
이름 또는 해시를 입력하세요.
Git 브랜치 이름 검사는 명령이 이름을 거부했는데 이유를 알기 어려울 때 사용합니다. 붙여 넣은 공백이나 경로 요소 앞의 점은 눈으로 찾기 어렵고, 평범해 보이는 접미사도 오류의 원인이 됩니다.
입력한 값이 무엇을 나타내는지 먼저 선택하세요. main은 브랜치 이름으로 유효하지만 엄격한 참조 이름 검사에서는 슬래시가 필요합니다. 같은 40자리 문자열도 해시 알고리즘에 따라 완전한 ID 또는 축약형으로 분류됩니다.
Git 브랜치 이름 검사가 알려 주는 차이
수정하기 전에 오류 위치 확인
Git 브랜치 이름 검사는 입력 문자를 그대로 두고 문제의 행과 열을 보여 줍니다. ASCII 후보 이름은 별도로 제공하므로 진단 과정에서 원래 이름이 바뀌지 않습니다. 한글이나 대문자에 담긴 의미를 보존할지는 직접 판단할 수 있습니다.
표시용 접두사와 고유성 구분
릴리스 노트에서는 짧은 커밋 해시가 읽기 편합니다. 하지만 앞부분을 잘랐다고 그 값이 유일해지는 것은 아닙니다. 도구는 이미 있는 문자만 표시하며, 없는 뒷부분을 추측하거나 다른 객체와의 충돌을 확인했다고 말하지 않습니다.
입력의 의미부터 선택하세요
02
완전한 해시와 축약형 구분
SHA-1은 40자리, SHA-256은 64자리가 완전한 형식입니다. 축약 허용을 켜면 4자리부터 완전한 길이보다 한 자리 짧은 값까지 축약형으로 검사합니다.
- 표시 길이 기본값은 7이지만 입력이 4자리라면 4자리만 표시합니다.
03
현재 입력의 보고서인지 확인
자동 검사는 편집 후 350ms 기다립니다. 끄면 수동 버튼이 나타나며 Ctrl/Cmd + Enter로도 실행할 수 있습니다. 진단을 누르면 해당 행과 열로 이동합니다.
- 입력이나 옵션이 바뀌면 복사가 즉시 잠깁니다. 완료된 오류 보고서는 검토용으로 저장할 수 있습니다.
이름 규칙부터 객체 ID 형식까지
브랜치 이름 유효성 검사
브랜치 명명 규칙에는 HEAD와 맨 앞 하이픈 금지가 추가됩니다. 참조 모드는 단일 계층을 명시적으로 허용할 수 있습니다. git check-ref-format의 리터럴 규칙을 따르며 이전 체크아웃 기록을 해석하지 않습니다.
특수 문자와 보이지 않는 공백 진단
ASCII 제어 문자, 공백, 금지된 기호, ..와 @{ 같은 연속 문자를 찾습니다. 각 경로 요소의 시작 점과 .lock 접미사도 확인합니다. 행과 열은 1부터, 열과 JSON 오프셋은 UTF-16 코드 단위로 계산합니다.
별도로 검토하는 이름 후보
ASCII 문자를 소문자로 바꾸고 영숫자와 ._-/ 밖의 문자를 하이픈으로 대체합니다. 금지 구조를 정리한 뒤 다시 검사합니다. 한글은 로마자로 음역하지 않으며 남길 영숫자가 없으면 branch를 제안합니다.
알고리즘을 기록하는 해시 보고서
알고리즘, 입력 길이, 완전형 또는 축약형, 표시 접두사를 함께 제공합니다. 대문자 16진수는 보존됩니다. 파일 내용으로 해시를 계산하거나 SHA-1 ID를 SHA-256 ID로 변환하는 기능은 아닙니다.
문자열만으로 판단할 수 없는 사항
- 저장소 상태는 확인하지 않음
- 커밋 존재 여부, 객체 유형, 접두사 고유성, 브랜치 생성 권한은 실제 저장소에서 확인해야 합니다. foo가 이미 있어 foo/bar를 만들 수 없는 충돌, 보호 정책, 파일시스템 제약도 이 페이지에서는 알 수 없습니다.
- 원문을 하나의 값으로 처리
- 앞뒤 공백을 자동 제거하지 않습니다. 줄바꿈은 일괄 입력 구분자가 아닌 금지 문자입니다. HEAD~1, main^, @{-1} 같은 리비전 표현식과 와일드카드 refspec은 지원하지 않습니다. 파일 업로드나 URL 가져오기도 없습니다.
- 권고와 문법 오류는 별개
- Git이 허용하는 문자라도 셸에서는 따옴표 처리가 필요할 수 있습니다. ASCII 권고와 GitHub의 refs/ 접두사 및 40자리 16진수 이름 제한은 별도 안내입니다. 팀별 정규식이나 보호 브랜치 목록은 검사하지 않습니다.
- 도구의 입력 한도
- 최대 4,096개의 UTF-16 코드 단위를 처리합니다. 이는 Git 자체의 이름 길이 제한이 아닙니다. 진단은 50개씩 표시되지만 JSON 복사와 다운로드에는 완료된 전체 결과가 포함됩니다. 오류가 있다는 이유로 보고서가 잘리지는 않습니다.
- 교체 전 미리 보기와 한 번 되돌리기
- 예제와 지우기는 교체 내용 및 전후 문자 수를 먼저 표시합니다. 적용 후 한 번 되돌리면 입력, 옵션, 결과 상태가 복원됩니다. 후보는 복사만 가능하고 의미 보존을 보장하지 않습니다. 한도 안에서 안전하게 만들 수 없다면 제안하지 않습니다.
Git 브랜치 이름 검사 자주 묻는 질문
Git 브랜치 이름이 유효한지 어떻게 확인하나요?
리터럴 이름은 브랜치 모드로 검사하세요. 로컬에서는 git check-ref-format --branch에 따옴표로 처리한 이름을 전달할 수 있습니다. main이나 master를 보호하는 팀이 있어도 그 이름이 Git 문법상 금지된 것은 아닙니다. 문법 통과는 생성 성공을 뜻하지 않습니다.
브랜치 이름에 사용할 수 없는 문자는 무엇인가요?
ASCII 제어 문자와 공백, ~, ^, :, ?, *, [, 역슬래시 등이 금지됩니다. ..와 @{ 같은 조합에도 규칙이 있습니다. 닫는 대괄호 ]와 달러 기호 $는 그 자체로 문법 오류가 아니지만 셸에서 별도 인용이 필요할 수 있습니다.
브랜치 이름에 공백을 사용할 수 없는 이유는 무엇인가요?
일반 공백은 Git의 금지 문자 목록에 포함됩니다. 파일 경로 및 리비전 표기를 사용하는 도구들이 이름을 구분할 때 생길 혼동을 피하기 위한 규칙입니다. 이 페이지는 공백을 조용히 지우지 않고 위치를 표시하며, 후보 이름만 별도로 제안합니다.
짧은 커밋 해시의 길이는 어떻게 정해지나요?
Git은 해당 저장소의 객체들 사이에서 유일한 접두사를 찾습니다. 요청 가능한 최소 길이는 4이고 기본값은 core.abbrev 설정의 영향을 받습니다. 여기의 7자리는 표시 기본값일 뿐이며, 새로운 객체가 추가된 저장소에서도 고유하다고 보장하지 않습니다.
SHA-1로 커밋이 저장소에 존재하는지 확인할 수 있나요?
그 저장소를 직접 조회해야 합니다. git cat-file -e 등으로 객체가 존재하는지 확인하고 필요하면 커밋 유형인지도 검사하세요. 길이가 맞는 16진수 문자열을 가지고 있다는 사실만으로 실제 객체나 커밋이 있다고 판단할 수 없습니다.
더 궁금한 점이 있나요?