[깃&깃허브] 그림으로 알아보는 Git HEAD

Git의 비밀을 풀어보자: HEAD씨의 기묘한 모험

Git을 사용하다 보면 "HEAD"라는 것을 종종 보게 됩니다. 커밋 히스토리를 살펴보거나, 브랜치를 생성할 때 등장하는 HEAD. 도대체 뭘 의미하는건지 그 정체가 궁금하신 분도 계실겁니다. 이번 포스팅에서는 HEAD의 본질을 그림과 시나리오로 설명해보려고 합니다.😎

1. HEAD씨의 첫 걸음, main 브랜치

HEAD씨가 Git 세상에 첫 발을 내디뎠습니다. 어쩌다보니 물 위에서 스폰된 HEAD씨를 위해, 발판을 만들어줍시다. 발판은 커밋을 통해 만들 수 있습니다.
 

첫 번째 커밋

 
새로운 커밋이 생성될 때마다 HEAD 씨가 있는 브랜치에 발판이 추가됩니다. 

💡정리
브랜치만 있으면 아무것도 할 수 없습니다. commit을 통해 브랜치에 새로운 정보를 입력할 수 있습니다.

---

2. 전진본능: HEAD씨는 멈추지 않아🚒

커밋을 한번 더 해볼까요. 새로운 발판이 생기면 앞으로 가는 것을 참을 수 없는 HEAD씨입니다.  발판이 하나 더 생겼으니 한 칸 전진하는 HEAD씨입니다. 
 

두 번째 커밋

💡정리
HEAD는 현재 작업 중인 브랜치와 최신 커밋을 가리키는 포인터입니다. 

---

3. 새로운 길: 브랜치 생성

저 멀리 이쁜 연꽃을 발견한 HEAD씨입니다. 하지만 꽃은 지금 가는 길로만 직진한다면 영원히 도달할 수 없는 위치에 있습니다.
HEAD씨를 위해 새로운 길을 만들어줍시다.
 

git branch feature/#1
git checkout feature/#1

 
이제 HEAD씨는 새로운 길(feature/#1) 위에 서 있게 됩니다.
하지만 길을 만든 것 만으로는 새로운 발판이 만들어지지 않습니다. HEAD씨가 서 있는 위치는 여전히 main 브랜치와 같은 공통 발판입니다.

새로운 브랜치 생성

 

💡정리
새로운 브랜치를 생성하면 현재 브랜치의 마지막 커밋을 기준으로 새로운 작업 경로가 생성됩니다. 하지만 새로운 커밋이 없다면 HEAD는 기존 브랜치와 동일한 지점에 위치합니다. 

---

4. 새로운 길, 새로운 발판

이제 새로운 브랜치에서 커밋 해볼까요. 커밋을 하면, main 브랜치와는 다른 길로 가는 새로운 발판이 만들어집니다.

새로운 브랜치에서 커밋 추가

 
발판을 뒤로 만들 수는 없습니다. 어느 브랜치이든 커밋을 추가하면, 가장 최근 생성된 발판의 진행 방향에 이어서 만들어집니다.
 
물론 이미 만들어진 경로 위에서 이동하는 것은 자유입니다. 지나온 경로로 돌아가서 해당 발판에서 이어지는 새로운 발판을 만들 수도 있습니다. 이런 경우 기존에 만들어진 발판은 그대로 유지됩니다.
 
하지만 main 브랜치로 돌아간다면, HEAD씨는 새로운 길을 기억하지 못합니다(다시 feature/#1으로 이동하면 마지막 커밋 상태를 그대로 반영하긴함). 길은 없어지지 않지만, HEAD씨의 시야에서는 확인할 수 없는 것이죠.
 
일단은 계속해서 발판을 만들어줍시다. 꽃에 다다른 헤드씨😎

💡정리
브랜치에 커밋을생성하면 해당 브랜치의 고유한 히스토리가 시작됩니다. 

💡정리
 Git에서 커밋은 항상 이전 커밋 기반으로 생성되며 시간순으로 앞으로만 나아갑니다,

💡정리
꽃을 보기 위해 새로운 길을 만든 것처럼, 브랜치 분기는 특정한 목적(기능 개발, 버그 픽스, 배포 등)을 위해 사용합니다.

---

5. 더 많은 갈림길 

새로운 길은 얼마든지 만들 수 있습니다.

main에서 feature/#2 브랜치 생성

 
HEAD씨는 어디로든 자유자재로 이동할 수 있지만,  "지나온 경로"에 한정됩니다. feature/#1과 feature/#2는 main을 기준으로 갈림길이기 때문에, feature/#2 로 간 HEAD씨는 feature/#1을 알지 못하고 feature/#1으로 가도 feature/#2 는 알 수 없습니다.

💡정리
각 브랜치는 독립적이며, 다른 브랜치의 내용을 직접 알 수 없습니다.

---

6. 갈림길 합치기: Merge

꽃을 따고 목표를 달성한 HEAD씨. 이제 다시 가던길 가야합니다. 
 
main의 마지막 발판으로 이동한 HEAD씨는 다른 길의 내용을 알 수 없다고 했는데요, feature/#1의 길을 기억하고도 main에 있을 수 있는 방법, 당연히 있습니다.

git merge feature/#1

 
merge를 하면 feature/#1 브랜치에서 지나온 길이 main 브랜치에 통합됩니다. 이제 main 브랜치의 마지막 발판은 feature #1 경로를 포함한, 통합된 길이 됩니다. HEAD 씨는 main 브랜치에서 feature/#1의 꽃길을 기억하며 여행을 계속할수 있습니다. 
 
main을 feature/#2로 merge 한다면, feature/#1과 main의 기억을 가진 feature/#2가 되겠죠.

feature/#1 -> main으로 merge

💡정리
merge는 두 개의 브랜치 히스토리를 하나로 통합하는 작업입니다.

💡정리
merge 후 main 브랜치의 마지막 커밋은 feature/#1의 모든 작업 내용을 포함합니다.

 

---

정리: HEAD는 언제나 현재 위치를 가리킨다

그림으로 간단하게 HEAD의 동작을 그려보았습니다. 정리해보자면, HEAD는 본질적으로 현재 작업 중인 브랜치와 최신 커밋을 가리키는 포인터입니다. 이 포인터는 브랜치의 흐름에 따라 계속해서 이동하며, 새로운 커밋이 생성될 때마다 업데이트 됩니다. 그 결과,  HEAD는 언제나 "현재 상태"를 가리키게 되며, 개발자에게 작업 중인 위치를 명확하게 알려주는 역할을 하는 것이죠. 
 

추가: Detached HEAD

HEAD가 브랜치에 연결되지 않고, 특정 커밋을 가리키는 경우가 있는데, 이 상태를 Detached HEAD라고 합니다. 일반적으로 HEAD는 특정 브랜치의 최신 커밋을 가리키지만 특정 브랜치가 아닌 직접적인 커밋을 가리키는 경우입니다.
 
발생 경우는 
1. 특정 커밋으로 체크아웃 할 때: git checkout <commit-hash> 명령어로 특정 커밋을 직접 체크아웃하면 Detached HEAD 상태가 됩니다.
2. 특정 태그를 체크아웃 할 때도 Detached HEAD 상태가 될 수 있습니다.
 
이 때 HEAD는 특정 커밋만을 가리키기 때문에 새로운 커밋을 생성하면 그 커밋은 브랜치가 없어서 고립된 상태가 됩니다. 나중에 다른 브랜치로 이동하면 해당 커밋은 참조하기 어려워집니다.
 
특정 상황에서 고의적으로 사용하기도 하지만, 중요한 작업을 할 때는 손실이 나지 않게 항상 브랜치를 생성하여 작업하기!

---

지금까지 HEAD를 알아보았습니다. 사실 지금껏 Git을 사용하면서도 HEAD를 볼 때마다 흐린 눈 하곤 했는데, 그림으로 보니 이해가 쉬웠던 것 같습니다. Git을 이해하고 활용하는데 많은 도움이 되었으면 좋겠습니다.!
 
https://www.yes24.com/Product/Goods/133290567

그림과 실습으로 배우는 깃 & 깃허브 입문 - 예스24