먼저

무심결에 쓸 수 있는 기릿이지만 실제 구조는 심오하고 복잡하다.
이런 지트를 쓰기 시작했을 때 거의 모든 사람이 생각하는'HEAD'가 어떤 사람인지 설명하고 싶다.
또한 Branch, detached HEAD와 함께 설명합니다.
결론이 먼저라면

HEAD 소개

현재 자신이 일하고 있는 곳을 가리키는 지침

이른바 Branch

개발의 주류에서부터 지점을 나누어 본류의 개발을 방해하지 않고 계속 일하는 기능

detached HEAD

HEAD가 Branch를 가리키지 않는 상태를 나타냅니다.
그리고 내가 이전에 지점이 무엇인지 물었을 때 다음 그림의 인상을 받았다.
그리고 이것은 잘못된 인식이다.

이 글은 Make IT advent 달력 9일차 기사로 투고되었습니다!
내일 예정@wh1tecat 투고.
기대되네요(웃음)

이른바 Branch

우선 Giit에 관한 지점 시스템에 대해 말씀드리겠습니다.
분지라고 불리면 뭐가 생각나세요?
나는 그림으로 가지를 설명하고 싶다.
다음 그림의 Giit에서 왼쪽 상단은 최초의 제출을 표시하고 반복적으로 제출할 때마다 아래로 뻗는다.왼쪽 상단의 마스터 지점에서 시작하여 중도 개발자 지점에서 개발자 지점으로feat/a 지점으로 파생합니다.

이 Giit는 세 개의 지점을 관리하고 있다.
그리고 지금 너는 마스터 지점에서 일하고 있어.
그러면 이 나무를 보면'마스터','develop','feat/a'의 지점은 어디에 있습니까?이렇게 물었을 때, 나 자신도 이전에 아래 그림처럼 생각한 적이 있다.그리고 그것은 잘못된 인식이다.

나는 파란색 테두리로 둘러싸인 전체가 마스터 지점이라는 것을 깨달았다.
그리고 나는 항상 후술한 HEAD도 파란색의 테두리를 가리킨다고 생각한다.
그러나 실제 브랜치는 아래 그림과 같다

이 상황에 대한 결론을 내리자면.
Git의 분기는 제출한 경량 포인터를 가리킨다
세 갈래는 각각 특정한 제출을 지시하는 지침이다
나는 이전에 지점이 파생원에서 최신 역사까지의 전체 지점이나 문서군 같은 것을 가리킨다고 생각했지만 그것은 잘못된 것이다.
그렇다면 이 이외의 커미션은 어느 지점에 속합니까?
도대체 무엇이 커미션인가
Giit는 파일 기록을 어떻게 관리합니까
HEAD란 무엇인가?
이런 의문이 생기더라도 다음은 지트의 구조에 대해 조금 말씀드리고 싶습니다.

Giit의 파일 관리 메커니즘

Giit 제출에 필요한 명령은 대체로 다음과 같습니다.

1. /* ファイルを編集 */
2. git add -A
3. git commit -m "add my-files"

이때 Giit 내부 프로세스는 다음과 같습니다.

계산급 파일의 산열

트리 객체 만들기

레벨 코드의 바늘을 트리 대상에 저장

git commiit를 실행할 때 제출 대상을 만듭니다

제출 대상 저장소 트리 대상에 대한 지침, 아버지에게 제출한 지침, 창설자의 메타데이터 등

분기의 포인터를 최신 제출 대상

으로 이동
제출이 중복될 때마다 지점은 자동으로 다음 지점으로 이동합니다
동시에 HEAD를 이동합니다.

하위 파일의 바늘은blocb로 트리 대상에 저장됩니다.
포인터의 전면에 레벨 파일의 스냅샷이 저장되어 있습니다.
제출 대상을 만들 때마다 트리 대상의 바늘을 저장합니다
제출 대상에는 트리 대상을 가리키는 바늘 이외에 아버지가 제출한 바늘, 제출한 메타 정보, 제출한 메시지 등이 포함된다.
그리고 이 제출 대상들은 구슬 연결을 통해 Giit의 나무를 형성했다
이렇게 해서 Giit는 제출을 제작하고 관리하고 있습니다.
Giit의 지점은 단지 이러한 약속을 나타내는 경량 지침일 뿐이다.
새로운 지점을 만들면 새로운 지침만 만들어진다.
분지는 제출을 지시하는 지침이 아니라 문서의 역사군과 나뭇가지처럼 보이는 전체를 가리킨다.
Git는 제출한 부모마다 제출한 서류의 역사를 관리한다.
이 부모 수치에 따라 파일의 수정 기록을 확인합니다.
하나의 제출은 여러 개의 제출을 보류할 수 있습니다.합병의 상황 등.
또한 여러 개의 지점도 하나의 제출을 인용할 때가 있다.지느러미가 지침이기 때문에 지느러미가 끼어도 별다른 해가 없다.

HEAD 소개

기트가 현재 업무의 지점을 어떻게 파악하는지 아십니까?그때는 HEAD를 사용했습니다.
HEAD의 내용 이쪽도 포인터로 Git에서 특수하고 유일한 존재입니다.
HEAD가 브랜치를 가리키면 현재 브랜치가 무엇인지 확인할 수 있습니다.
즉, 제출 장소는 지점, 지점 위치는 HEAD로 기억하는 것을 기억한다.
바늘

새 커밋이 발생하면 분기 포인터도 자동으로 이동합니다.HEAD는 분기의 경우 HEAD 값도 함께 추가하여 추적하는 것을 의미합니다.
Giit는 HEAD와 같은 지점에서 자신이 일하고 있는 지점을 확인했다
그나저나 최근 자신이 이동한 HEAD의 위치를 확인하려면 다음 명령을 수행한다.

git reflog

분기의 트리 그림을 보려면 SourceTree와 GiitUP 등 GUI 도구와 tig 등을 사용해 확인하는 것이 좋다.

detached HEAD

마지막으로 detached HEAD가 무엇인지 설명합니다.
detached HEAD는 드물지만 rebase 등을 진행할 때 발생한다.
detached HEAD란 무엇인지, 결론부터 말하자면.
는 브랜치 이외의 커밋 포인터의 상태를 나타냅니다.

방금 HEAD가 지점을 표시한다고 말했는데 HEAD는 지점을 제외한 다른 어떤 약속도 표시할 수 있다.
이 상태를 detached HEAD라고 합니다.
예를 들어 특정 제출 시 파일 상태를 확인하고자 할 때 일부러 HEAD를 분기 이외의 곳으로 이동하는 등이다.
detached HEAD로 변한 상태에서 처리하지만, 임의의 지점(상)에서 HEAD를 체크아웃시키면 지점을 참조하기 때문에 detached HEAD가 아닙니다.

다음은 detached HEAD의 간단한 깨우는 방법을 소개합니다.

git log를 통해 제출을 확인하고 지점에 표시되지 않은 제출 산열을 제어한다

대기하는 산열 체크아웃

git branch를 통해 확인

git log
git checkout c215891f5b9b997ec4020c4539b773ef94c2449c
git branch
* (HEAD detached at c215891)
  develop
  feat/a
  master

후퇴 방식

git branch로 반환된 분기 이름 확인

확인된 지점에 체크아웃

git branch
* (HEAD detached at c215891)
  develop
  feat/a
  master

git checkout develop
git branch
* develop
  feat/a
  master

detached HEAD가 좋은 상태인지 나쁜 상태인지는 상황에 따라 정해지기 때문에 뭐라고 할 수는 없지만, 의식 없이 발생했다면 좋은 상태라고 할 수는 없겠죠.나는 상세한 사람에게 상황을 설명한 후에 처리하는 것이 비교적 좋다고 생각한다.

끝맺다

이 글의 동기는 원래 몇 달 전 퀵 스트라이커와 비퀵 스트라이커를 이해하기 위해 조사한 것으로, 브런치를 알아보는 계기가 됐다.그러나 정리할 정력이 없어서 다음에 다시 정리하고 싶었지만 이번 정리의 좋은 기회가 이 보도의 동기였다.
깃의 HEAD에 관해서는 제가 잘 설명해 드렸지만, 저 자신도 모르는 게 많아서 매일 공부하고 있습니다.
언젠가 기트 마스터가 되는 꿈을 꾸며 살고 싶어요.
더 잘하고 싶은 마음

참고 자료