[GitHub]Git 핵심 개념 한번에 이해하기: 3대 영역 + HEAD와 Branch

안녕하세요!

이번 글에서는 Git의 기초기초왕기초인!! Git의 3대 핵심 영역과 HEAD/ Branch에대해 알아보겠습니다!

---

들어가며..

막상 Git 명령어들을 습관처럼 사용하다 보니까, 제가 쓰는 명령어들이 실제로 어떤 흐름으로 작동하는지 깊게 생각해본 적은 많지 않았던 것 같아요.

사실 git reset, git checkout, git revert 같은 명령어들도 사용은 하는데, 어떤 게 뭘 되돌리는 건지 헷갈릴 때 많잖아요??

이럴 때 Git의 핵심 구조를 제대로 알고 있으면 명령어가 다르게 작동하는 이유도 자연스럽게 이해되더라구요.

즉, Git이 내부적으로 어떤 영역들을 기준으로 동작하는지, 지금 내가 Git 안에서 어느 위치에서 작업하고 있는지를 이해하는게 중요하다고 생각했습니다!

그래서 이번 기회에 Git을 좀 더 깊이 이해하고, 늘 헷갈리던 명령어들도 명확하게 구분할 수 있도록 Git의 3대 핵심 영역과 함께 HEAD, Branch 개념까지 정리해보려고 합니다!

우선, Git의 핵심 영역에는 Working Directory, Index (Staging Area), Repository가 있는데요?

각각 어떤 역할을 하는지, 그리고 HEAD와 Branch는 여기에 어떻게 연결되는지,

지금부터 하나씩 정리해봅시다 :)

---

🧑‍💻 대상 독자

• Git을 막 시작했거나, 아직 개념이 흐릿한 분
• 명령어는 익숙하지만 동작 흐름은 잘 모르는 분
• reset, checkout, commit이 늘 헷갈리는 분

---

Working Directory

Working Directory는 저희에게 가장 익숙한 영역인데요?

실제로 파일을 보고, 수정하고, 저장하는 공간을 말합니다!

즉, 저는 iOS 개발자니까 이미지와같이 Xcode에서 Swift 파일을 열고 작업하는 이 위치겠죠?

 

Working Directory는 개발자 눈에 보이는 공간이라서 수정도 자유롭고, 테스트도 마음껏 할 수 있어요.

단! 이곳에서 작업한 내용은 git add를 하지 않으면 Git이 관리하지 않습니다.

그러니까, 커밋하기 전까지는 Working Directory를 수정해도 Git이 "어? 뭐가 바뀌긴 했네" 하고 변경 상태만 인식하고 있을 뿐, 그 내용을 정식 히스토리로 기록하지는 않습니다.

---

Index = Staging Area

Index(Staging Area)는 말 그대로 머무는 공간인데요!

Git에게 “이 파일들 곧 커밋할 거야!”(= Repository에 올라갈꺼야) 하고 알려주는 중간 대기실 같은 곳이에요

git add hello.txt

예를 들어 hello.txt 파일을 수정한 뒤 git add를 하면

이미지처럼 해당 파일은 Working Directory에서 Index(Staging Area) 로 올라가게 됩니다.

 

직접 Index에 올라갔는지 확인하고 싶다면 status 명령어를 사용하면되는데요!

git status

 

status 명령어로 본 add명령어 실행 전후의 변화는 아래와 같습니다

// git add 하기 전
Changes not staged for commit:
  modified:   hello.txt

// git add 한 후
Changes to be committed:
  modified:   hello.txt

"to be committed"로 표시되면, 해당 파일이 Index에 올라간 상태라는 뜻입니다

이후 git commit까지 해야 Repository에 정식으로 기록되는데요!

즉, Staging Area는 커밋 직전의 준비 상태를 의미해요. "대기 중인 스냅샷"이라고 생각하면 좋습니다!

---

Repository

Repository는 Git의 본진이라고 생각하면 되는데요!

git commit -m "hello 파일 추가"

이렇게 git commit을 하면, Staging Area에 있던 파일 상태가 Repository에 스냅샷으로 저장됩니다.

 

이곳에는 커밋 기록이 누적되며, git log나 git diff 같은 명령어로 확인할 수 있어요!

요런 느낌으로?? 즉, Repository는 Git이 정식으로 기억하는 히스토리 공간이라고 생각하면되겠죠?

 

---

 

각각의 영역에서 하는 역할을 표로 정리해보았습니다!

영역	설명
Working Directory	실제 파일이 존재하는 작업 공간 (코딩, 수정, 저장 등)
Index / Staging Area	git add 후 커밋될 파일들을 준비하는 공간
Repository	git commit으로 기록되는 Git의 진짜 저장소 (히스토리 관리)

 

이제 어느정도 감이 잡히네요!!

그렇다면 제3대 핵심 영역들의 버전 관리 흐름은 어떻게 될까요??!

 

짜라란 쉽지요~~

---

지금까지 Git의 기본적인 흐름을 알아봤는데요?!

‘지금 내가 어디서 작업 중인지’를 판단하는 기준인 Branch와 HEAD에 대해알아봅시다!!!

Branch란?

브랜치는 특정 커밋을 가리키는 이름 있는 포인터입니다!

	
          HEAD
           ↓
          main
           ↓
커밋 A ──▶ 커밋 B

일반적으로는 해당 브랜치의 가장 마지막(최신) 커밋 을 가리키지만, 상황에 따라 특정 명령어(checkout)를 사용하면 앞선 커밋을 가리킬 수도 있습니다!

또한 기본적으로는 main 브랜치에서 작업하지만, 현업에서는 아래처럼 기능 개발이나 실험 작업은 보통 별도의 브랜치에서 진행하는 경우가 많습니다

* main
  feature/login
  fix/typo

 

 

직접 브랜치 목록을 보고 싶다면? 아래와 같은 명령어를 실행하면됩니다

이렇게 명령어를 실행했을때 * 표시가 있는 브랜치가 지금 HEAD가 가리키고 있는 브랜치입니다!

---

HEAD

HEAD는 지금 내 작업 디렉토리가 어느 커밋을 기준으로 만들어졌는지를 가리키는 일종의 포인터입니다!

내 위치를 보고 싶다면 아래와 같은 명령어를 실행하면 되는데요

git log --oneline

여기 로그를 보면, 맨 위에 있는 최신 커밋이 보통 HEAD가 가리키는 곳이에요!

즉, 지금 작업 중인 ‘기준점’이 되는 커밋이죠.

HEAD는 내 현재 위치! “나는 지금 이 커밋에서 작업을 시작하고 있어요” 라는 의미라고 생각하면 쉽겠죠?!

 

그런데 여기서 한 가지 더 알아두면 좋은 점!!!

보통은 HEAD가 브랜치를 가리키고 있어서, 커밋을 하면 해당 브랜치 위에 커밋이 쌓이게 돼요.

git checkout A  # 특정 커밋으로 이동하면 HEAD가 커밋을 직접 가리킴

그런데 만약 git checkout <커밋 해시>처럼 특정 커밋으로 이동하면, HEAD가 브랜치를 가리키지 않고 커밋 자체를 직접 가리키는 상태가 됩니다. 이를 Detached HEAD 상태라고 해요!

 HEAD
  ↓
커밋 A ──▶ 커밋 B

보면 HEAD는 main을 가리키지 않고, 커밋 A를 직접 가리키고 있죠?

이걸 Detached HEAD 상태라고 해요!

만약 이 상태에서 커밋을 해버리면, 브랜치와 연결되지 않은 참조되지 않는 커밋(= Dangling commit)이 생길 수 있어서 나중에 잃어버리기 쉬우니 주의해야 합니다!

---

정리

어느정도 이해가되셨나요?!

정리해보면 이렇게 HEAD → branch → commit 순서로 가리키고 있답니다!

개념부분은 따로 표로 정리해보았습니다!

요소	역할 / 의미	특징	예시 설명
branch	최신 커밋을 가리키는 이름 있는 포인터	mutable (커밋 추가 시 자동으로 이동)	main → 커밋 A → 커밋 B → 커밋 C
HEAD	현재 작업 중인 위치를 나타내는 포인터	브랜치를 가리키거나 직접 커밋을 가리킬 수 있음	HEAD → main 또는 HEAD → abc1234
커밋	스냅샷(상태)과 이전 커밋에 대한 참조를 가지는 단위	immutable (내용 불변)	커밋 C는 커밋 B를 부모로 가짐

 

---

마무리하며..

Git에서 우리가 자주 사용하는 대부분의 명령어는, 결국 세 가지 핵심 영역(Working Directory, Staging Area, Repository) 사이에서 무언가를 옮기거나 상태를 변경하는 작업입니다

저희가 이제부터는 명령어 하나를 입력할 때도 “지금 이 명령어는 어떤 영역에서 어떤 영역으로 이동시키고 있는 걸까?” 하는 구조적 관점으로 바라본다면, Git이 훨씬 덜 낯설게 느껴질 거라고 생각합니다!

 

다음 글에서는 오늘 배운 세 가지 영역을 바탕으로 reset, checkout, revert 같은 명령어들이 어떻게 동작하고, HEAD, Branch와는 어떤 방식으로 연결되어 있는지 흐름과 함께 정리해보겠습니다! 읽어주셔서 감사합니다!

 

 

참고 문헌

https://git-scm.com/book/ko/v2