[Git_12] Git 개념 잡기 - 워킹 디렉토리, 스테이지, 저장소

Git 개념 잡기 - 워킹디렉토리, 스테이지, 저장소

앞서 Git을 구성하는 영역에 대해 살펴봤습니다.

[Git_11] Git 개념 잡기 - Git 영역 살펴보기

아래 그림과 같이 평범했던 폴더(디렉토리)가 $ git init 명령을 통해

Git 영역이 되고, Git 내부적으로 어떻게 논리적으로 구성이 되는지 확인했습니다.

Git 영역이 되는 개념도

---

워킹 디렉토리(Working Directory)

Git이 버전을 관리하기 위해 구성하는 영역 중에

워킹 디렉토리(Working Directory)를 살펴보겠습니다.

 

워킹 디렉토리는 워킹 트리(working tree)라고도 합니다.

워킹 디렉토리는 쉽게 얘기하면 현재 자신이 작업하고 있는 공간입니다.

 

앞서, firstrepo라는 디렉터리를 만들고

이 폴더를 git init 명령을 통해 저장소를 만드니 [. git]이라는 디렉토리가 생겼습니다.

[. git]이라는 디렉토리를 제외한 나머지 영역이 워킹 디렉토리가 됩니다.

 

firstrepo라는 디렉토리 아래에 개발 소스를 생성하고 수정하는 등의 작업을 하게 될 텐데,

그렇기 때문에 작업하는 공간이 되는 firstrepo 디렉토리가 Working Directory 가 된다고 이해해도 되겠습니다.

 

따라서 워킹 디렉토리는 실제 파일을 수정하거나 생성하는 공간입니다.

이 워킹 디렉토리내의 파일들은 Git에서 2가지의 상태를 가질 수 있으며,

그 2가지 상태는 추적(tracked) 상태와 비추적(untracted) 상태입니다.

 

firstrepo 디렉토리를 Git영역으로 만들었다고 해서 Git이 firstrepo 디렉토리 내에 존재하는 모든 파일을 자동으로 버전 관리하지 않습니다. Git의 입장에서 어떤 파일을 버전 관리하느냐 하지 않느냐는 다르게 얘기하면 Git이 파일의 변화를 감시하느냐, 하지 않느냐로 표현할 수 있고, 이것을 Git에서는 추적(tracked) 상태이냐, 추적되지 않는(untracked) 상태냐로 구분합니다.

 

다시 요약하면, Git은 자동으로 모든 파일을 추적하지 않습니다.

수많은 파일을 모두 자동으로 처리해야 한다면 시스템에 엄청난 부하가 발생하게 됩니다.

그래서 Git은 추적해 달라고 요청을 받은 파일만 추적하고 관리합니다.

 

Git에 추적을 요청하는 명령어가 add입니다.

$ git add 파일명이라고 요청할 수 있습니다.

이 add 명령어는 최초 추적을 요청하기도 하지만 그러면서 스테이지 영역에 올리는(등록하는) 명령어입니다.

add 명령어와의 연관성

add를 통해 추적을 요청하면 위 그림과 같이 스테이지 영역에 파일이 등록되고, Git은 추적을 시작합니다.

이때, 파일은 비추적(untracted)상태에서 추적(tracted) 상태로 변경되는 것입니다.

 

---

스테이지(Stage)

다음은 스테이지 영역입니다.

스테이지(stage)는 워킹 디렉토리에서 등록된 파일들을 임시로 저장하는 공간입니다.

 

스테이지 영역에는 파일의 전체 내용을 가지고 있는 것은 아니며,

추적 상태에 대한 정보만을 가지고 있습니다.

 

스테이지는 저장소에 기록하기 위해 기록할 내용을 정리하는 공간이라고 이해해도 되겠습니다.

 

Git은 이렇게 저장소에 기록할 내용들을 한번 정리하기 때문에

저장소에 기록할 때에도 빠르게 처리가 가능합니다.

Git영역 구성요소

위 그림에서 실제 저장해 기록되는 공간은

워킹 디렉토리(Working Directory) 와 저장소(Repository)입니다.

 

그 사이에 있는 스테이지(Stage)는 임시로 저장하는 영역이고,

스테이지 영역에 추가하는 명령어가 add 인 것입니다.

 

저장소에 실제 저장을 하기 위해서는 반드시 스테이지에 임시로 저장해야 합니다.

워킹 디렉토리에서 저장소까지의 흐름을 그림으로 나타내면 다음과 같습니다.

워킹 디렉토리에서 저장소까지의 흐름도

이 스테이지 영역의 존재는 SVN과 같은 버전 관리 시스템에서는 없는 개념입니다

SVN을 사용할 때는 파일을 수정하고 바로 커밋을 하면 되었는데,

Git은 커밋을 하기 전에 반드시 add를 해서 스테이지 영역에 올려야 합니다.

 

그리고, Git에서는 이 스테이지 영역(Stage Area)을 인덱스(Index)라고도 부릅니다.

인덱스(Index)는 색인 또는 목록이라는 의미입니다.

이 의미를 생각해 본다면 스테이지 영역의 역할도 좀 더 쉽게 이해할 수 있을 것입니다.

스테이지 영역은 커밋을 하기 위한 색인(목록)을 만드는 것이기 때문입니다.

 

Git은 파일의 상태를 스테이지 입장에서도 구분하고 있습니다.

워킹 디렉토리 입장에서는

파일이 추적(tracked)되느냐, 추적 되지 않느냐(untracked)로 구분할 수 있습니다만

스테이지 영역 입장에서는

파일이 스테이지 되었느냐 아니냐로 구분할 수 있는 것입니다.

즉, 스테이지 된 상태를 stage 상태 그렇지 않은 상태를 unstage 상태로 구분하게 됩니다.

 

파일의 상태에 대해서는 다시 한번 이야기할 수 있도록 하겠습니다.

지금은 이러한 영역들로 구분되어진다는 것만 알아 두기 바랍니다.

---

저장소(Repository)

다음으로 저장소(Repository)를 살펴보겠습니다.

저장소는 Git이 관리하는 파일들의 메타데이터와 객체 데이터베이스를 저장하는 곳입니다.

저장소에 변경된 이력을 저장(기록) 하기 위해서는 커밋(commit)을 하게 됩니다.

 

커밋은 변화된 내용을 영구적으로 저장소(Repository)에 기록하는 것입니다.

커밋을 통해 저장소에 기록하기 위해서는

기록할 내용을 임시 공간이 스테이지(stage)에 등록하는 것이 선행되어야만 합니다.

다음과 같이 나타낼 수 있습니다.

스테이지(Stage)와 저장소(Repository)의 관계

이렇게 저장소에 저장된 상태를 커밋된(committed) 상태가 됩니다.

 

저장소는 로컬 저장소와 서버 저장소로 구분될 수 있습니다.

서버 저장소는 원격(remote) 저장소라고도 합니다.

 

여기까지 Git을 구성하는 3가지 영역을 살펴봤습니다.

중간중간 '파일 상태'라는 얘기가 있었는데요.

Git에서는 파일의 상태를 구분하고 있습니다.

다음엔 파일의 상태에 대해 얘기하겠습니다.