깃 & 전달 더 많은 세부 정보 B · 공식 안내 플랫폼: 일반

Detached HEAD

분리된 HEAD

분리된 HEAD는 HEAD가 브랜치 이름 대신 하나의 커밋을 직접 가리키는 Git 상태입니다.

당신은 이것을 이렇게 부를 수 있습니다 Detached HEAD분리된 HEAD

작동 방식을 확인하세요

원본 작업 예제분리된 HEAD

다른 예시

조사관은 그 정확한 커밋에서 릴리스 문제를 재현하기 위해 태그 v2.8.0을 체크아웃합니다. 새 작업을 보관해야 하는 경우 먼저 브랜치를 생성합니다. 분리된 HEAD에 남겨진 커밋은 찾기 어려워질 수 있습니다.

주요 부분

  1. 01HEAD
  2. 02직접 커밋 대상
  3. 03누락된 분기 참조

사용할 때

HEAD가 검사, 빌드 또는 단기 작업을 위해 커밋을 직접 가리킬 때 이 용어를 사용하세요.

다음 경우에는 사용하지 마세요

브랜치나 다른 지속 참조를 만들기 전까지 중요한 작업을 계속하지 마세요.

코드에서 사용된 이름

HEAD → commit (no branch ref)

출시하기 전에

Before publishing, check the exact repository, branch, target, and diff. Keep unpublished work. Pass review and CI checks. Record conflict and data-loss risks, release order, traceability, recovery, and rollback.

복사 가능한 요청

Outcome:Complete the task with 분리된 HEAD (Detached HEAD)。 User context:조사관은 그 정확한 커밋에서 릴리스 문제를 재현하기 위해 태그 v2.8.0을 체크아웃합니다. 새 작업을 보관해야 하는 경우 먼저 브랜치를 생성합니다. 분리된 HEAD에 남겨진 커밋은 찾기 어려워질 수 있습니다. Delivery concept or operation:분리된 HEAD (Detached HEAD)。 Why it fits:HEAD가 검사, 빌드 또는 단기 작업을 위해 커밋을 직접 가리킬 때 이 용어를 사용하세요. Do not use it when:브랜치나 다른 지속 참조를 만들기 전까지 중요한 작업을 계속하지 마세요. Delivery requirements: Name the code repository and target. List preconditions, changes, review and CI checks, conflict and data-loss risks, release order, and the rollback or recovery command. Repository safeguards: Keep unpublished work and a clear history. Do not run destructive steps without an explicit backup. Check the exact code diff and remote target before publishing. Acceptance criteria: Review the intended diff and pass all required checks. Keep the target version traceable. Practice failure recovery and keep published history clear. Evidence and limits (evidence boundary):해당 출처에 대해 공식적인 것입니다. 다른 플랫폼이나 팀은 그 용어를 다른 방식으로 사용할 수 있습니다. Unknowns to confirm: Repository, branch, team activity, release environment, approval owner, protected checks, and rollback target.

이 요청을 확인하세요

Review how 분리된 HEAD (Detached HEAD) is used now. Definition: 분리된 HEAD는 HEAD가 브랜치 이름 대신 하나의 커밋을 직접 가리키는 Git 상태입니다. Release checks: Before publishing, check the exact repository, branch, target, and diff. Keep unpublished work. Pass review and CI checks. Record conflict and data-loss risks, release order, traceability, recovery, and rollback. Before changing code, list the evidence, gaps, severity, and the smallest safe fix.

B
이 용어는 얼마나 공식적인가요?

공식 안내

명명된 플랫폼, 프레임워크, 프로젝트 또는 전문가 그룹에는 이 용어에 대한 공식 가이드가 있습니다.

해당 출처에 대해 공식적인 것입니다. 다른 플랫폼이나 팀은 그 용어를 다른 방식으로 사용할 수 있습니다.

범위
소스가 포함하는 것만:정규 이름、정의、플랫폼 API、구현、사용 안내
문서 상태
안정적인
선택됨
2026-07-30

증거 출처 및 범위

권위 있는 출처 + 용어 참조 · Git · 안정적인 git-checkout 범위: 정규 이름、정의、플랫폼 API、구현、사용 안내 여기 역할: 직접 용어 참조 출처 범위: 정규 이름, 정의, 플랫폼 API, 구현, 사용 안내

직접 복사

브라우저가 이것을 복사할 수 없습니다. 아래 요청을 선택하고 직접 복사하세요.