(svn사용자인 내가 Git의 파일 관리 장소나 파일의 분류, 파일의 상태의 용어들이 정말 헷갈린다ㅠㅠ
그래서 본 포스팅에서 정리하고자 한다.)
Git Repository (= git 저장소)
- 'git이 관리하는 파일이나 폴더를 저장 장소'
- 파일을 수정, 커밋하고 프로젝트의 이력관리 및 공유 등 git의 기능 사용 가능 공간.
- 하위에 '.git' 디렉터리가 생성된 디렉터리
< Git Repository 두 종류 >
1. 원격 저장소(Remote Repository)
: 원격에 존재해 clone가능한 저장소 >> 주로 "(내가 clone해 가져오는) 협업 플젝 원본의 저장소"
2. 로컬 저장소(Local Repository)
: 내 PC에 위치한 git 설정된 디렉토리 (원격에 등록했으면 원격 저장소이기도 할듯!)
>> 내가 "git 저장소를 생성"했거나 / "원격 저장소를 clone해 와서 (작업할) 내 PC에 존재하는 git 저장소"
->추가 세부 사항 Git 저장소 관련 포스팅 참조
Git 관리 공간
(Working Directory = Work Tree | Staging Area = Index | (Git) Repository)
- Git 관리 공간? 장소? / Git 파일들이 동작하는 공간?? 뭐라 표현해야할지 모르겠다...
1. Working Directory = Work Tree (=작업공간 =워크 트리 =워킹 디렉토리 =워킹 디렉토리)
- 말그대로 "내가 작업할 프로젝트 디렉토리"
- 내가 작업해야하므로 내 로컬의 로컬 저장소(Local Repository)이다.
- Git 에서는 우리가 흔히 말하는 폴더를 '작업 트리'(Work Tree)'라고 한다는데 'Working Directory'와 무슨 차이인지 모르겠다.
- 로컬이므로 항상 현재 실제 존재하는 내 로컬의 실존재 공간이다.
2. Staging Area = Index
- git파일은 원격 저장소에 저장되기 전까지 ( '수정' -> '추가(=등록=stage=스테이징함)' -> '커밋' ) 의 상태를 거치는데
이떄 "수정 후 추가되었지만 커밋은 되지 않은 파일들이 존재하는 가상공간"이다.
- 커밋을 실행하기 전의 저장소와 작업 트리 사이에 존재하는 공간으로,
이 공간이 있어 Working Directory있지만 커밋하지 않을 파일(바이너리 파일 등)이 구분되어 실수의 위험이 줄어든다.
- Staging Area에 추가된 파일만 커밋가능하다.
- ※ 가상 공간이므로 "이 공간에 있어도 실제 존재하는 공간은 Working Directory"이다.
3. Git Repository (= (줄여서)Repository = git 저장소)
- 커밋한 파일들이 저장되는 공간
- 대부분 협업 프로젝트를 작업하거나 접근 가능의 용이를 위해 '원격 저장소(Remote Repository)'일 것이다.
- Git의 명령어(clone, pull, fetch 등)들로 Git Repository의 파일들을 Working Directory로 가져올 수 있다.
- 커밋(Commit)이란 과정이 실존재 공간인 Working Directory의 파일을 Git Repository에 저장하는 것이므로
이 두 공간에 함께 존재할 수 있다.
- ※ (로컬의 실존재 공간일 수도 있으나 보통 원격 저장소를 쓰므로) 원격지의 실존재 공간이다.
∴ 모든 파일은 원격 저장소에 저장되기까지
(Working Directory = Work Tree) -> (Staging Area = Index) -> (Git Repository) 순서대로 [Git 관리공간]에 위치한다.
하지만, 로컬에 실제 존재하는 저장소는 Working Directory이므로
Staging Area에서는 Working Directory에 존재하고, Git Repository에서는 Working Directory에도 있을 수 있다.
그림 하나 그려줘
Git 파일 구분 ( Tracked, Untracked )
- Git이 해당 파일을 알고 있느냐(=Git의 관리대상이냐)의 차이에 따라 구분되는 구분값이다.
- Working Directory의 모든 파일은 크게 Tracked(관리대상임)와 Untracked(관리대상이 아님)로 나뉜다.
1. Tracked(관리대상임)
: 이미 스냅샷(=Git Repository 특정 시점)에 포함돼 있던 파일
>> Unmodified(수정하지 않음)와 Modified(수정함) 그리고 Staged(커밋으로 저장소에 기록할) 상태 중 하나
>> 간단히 말하자면 Git이 알고 있는 파일
2. Untracked(관리대상이 아님)
: Working Directory에 있는 파일 중 스냅샷(=Git Repository 특정 시점)에도 Staging Area에도 포함되지 않은 파일
>> Tracked가 아닌 나머지 파일은 모두 Untracked 파일이다.
>> 간단히 말하자면 Git이 모르는(관리하지 않는) 있는 파일
>> Git은 Untracked 파일을 아직 스냅샷(커밋)에 넣어지지 않은 파일이라고 본다.
파일이 Tracked 상태가 되기 전까지는 Git은 절대 그 파일을 커밋하지 않는다. 그래서 빌드 시 생성하는
바이너리 파일 같은 것을 커밋하는 실수는 하지 않게 된다.
Git 파일 상태 (Unmodified, Modified, Staged )
- (Git파일 구분'값이)"Tracked(관리대상임)"인 파일만 Git파일 상태값을 가진다. (git이 모르는 파일의 상태를 알 수 없으니 당연한 말이다)
- (Tracked 파일은) Unmodified(수정하지 않음)와 Modified(수정함) 그리고 Staged(커밋으로 저장소에 기록할) 상태 중 하나이다. .
1. Unmodified 상태
: 마지막 커밋 이후 아직 아무것도 수정하지 않은 파일의 상태
>> 마지막 커밋할 때 Git Repository의 스냅샷의 파일과 동일한 상태인 파일 (수정하지 않았으니 커밋시점의 원격과 같은 건 당연)
2. Modified 상태
: Unmodified 상태의 파일을 수정하면 Modified 상태가 된다.
>> Modified 상태의 파일은 커밋할 수 없다.
3. Staged 상태
: Modified 상태의 파일을 Staging Area에 추가(=stage=스테이징=등록)하면 Staged 상태가 된다.
>> Staging Area에 추가된 파일만 커밋가능하다. 즉, Staged상태인 파일만 커밋가능하다.
Git 파일의 라이프사이클
- 하나의 파일이 Repository에 저장되기까지 [Git파일 상태]가 변화되는데 이 변화과정이 일종의 'Git파일의 라이프사이클'이 된다.
그림 하나 그려줘
[그림 8. 파일의 라이프사이클.] https://git-scm.com/book/en/v2/images/lifecycle.png
CASE 1) Git Repository 미존재 파일을 Git Repository에 저장하기까지의 라이프사이클
ⓐ (git 로컬 저장소에서 새로운 파일을 생성했거나 프로젝트를 처음 git 저장소로 설정 시) Git Repository에 미존재 파일이다.
>> Untracked파일이고 [파일 상태값이 없다].
ⓑ 파일을 Staging Area에 추가(=stage=스테이징=등록)한다. >> Tracked파일이고 [Staged상태]가 된다.
ⓒ 파일을 커밋하면 Git Repository에 저장되고 존재하는 파일이 된다. >> Tracked파일이고 [Unmodified상태]가 된다.
| CASE 1 | '(보통 원격 저장소인) Git Repository 미존재 파일을 Git Repository에 저장하기까지' | |||||
| 저장 과정 |
새 파일A를 생성 | (파일 A 수정해도 변화없음) |
파일 A를 추가 (=A를 Stage) |
추가된 A | 파일 A를 커밋 | Repository에 커밋된 A |
| 관리 공간 |
(Working Directory)에 존재 <<실존재 (로컬) 공간>> |
(Staging Area = Index)에 존재 <<가상공간>> |
(Git Repository)에 존재 <<실존재 공간>> |
|||
| 실존재 공간 | (Working Directory)에 존재 | (Git Repository)에 존재 & 로컬에서 삭제 안 했다면 (Working Directory)에도 존재 |
||||
| 파일 상태 (라이프사이클) |
X (git이 상태를 알 수 없음) | Staged | Unmodified | |||
| Git파일 구분 |
Untracked (관리대상이 아님) |
Tracked (관리대상임) |
||||
CASE 2) Git Repository 존재 파일을 Git Repository에 저장하기까지의 라이프사이클
ⓐ (Git Repository의 최신 스냅샷에 추가된 파일을 가져왔을 때 해당 파일이나 처음 저장소를 clone했을 때의 모든 파일들은)
Git Repository에 존재 파일이다. >> Tracked파일이고 Unmodified상태이다.
ⓑ 파일을 Staging Area에 추가(=stage=스테이징=등록)한다. >> Tracked파일이고 Staged상태가 된다.
ⓒ 파일을 커밋하면 Git Repository에 저장되고 존재하는 파일이 된다. >> Tracked파일이고 다시 Unmodified상태가 된다.
| CASE 2 | '(보통 원격 저장소인) Git Repository 존재 파일을 Git Repository에 저장하기까지' | |||||
| 저장 과정 |
git의 파일A | 파일 A를 수정 (='A1'이라 일컫자) |
파일 A1을 추가 (=A1을 Stage) |
추가된 A1 | 파일 A1를 커밋 | Repository에 커밋된 A1 |
| 관리 공간 |
(Working Directory)에 존재 <<실존재 (로컬) 공간>> |
(Staging Area = Index)에 존재 <<가상공간>> |
(Git Repository)에 존재 <<실존재 공간>> |
|||
| 실존재 공간 | (Working Directory)에 존재 | (Git Repository)에 존재 & 로컬에서 삭제 안 했다면 (Working Directory)에도 존재 |
||||
| 파일 상태 (라이프사이클) |
Unmodified | Modified | Staged | Unmodified | ||
| Git파일 구분 |
Tracked (∵ 파일A는 이미 기존에 git에 커밋된 파일이므로 항상 'Tracked(관리대상임)'이다) |
|||||
- ∴ 'CASE 1(Repository 미존재 파일이 저장과정)'과 'CASE 2 (Repository 존재 파일이 저장과정)' 에서는
[Git 관리공간]과 '실존재 공간'의 차이는 없으며, 최초 [파일의 상태]와 [Git파일 구분]이 차이날 뿐이다.
요약 정리
[Git 관리공간]
| 1. Working Directory = Work Tree 2. Staging Area = Index 3. (Git) Repository |
∴ 모든 파일은 원격 저장소에 저장되기까지
(Working Directory = Work Tree) -> (Staging Area = Index) -> (Git Repository) 순서대로 [Git 관리공간]에 위치한다.
하지만, 로컬에 실제 존재하는 저장소는 Working Directory이므로
Staging Area에서는 Working Directory에 존재하고, Git Repository에서는 Working Directory에도 있을 수 있다.
- Staging Area에 추가된 파일만 커밋가능하다. = Staged상태인 파일만 커밋가능하다.
- Staging Area에 파일을 추가하는 것을
"Staging Area에 추가한다.", "stage 한다.", "스테이징 한다.", "파일을 add한다.", "파일을 등록한다." 등으로 다양하게 표현한다.
(헷갈린다 -ㅠ-)
[Git파일 구분]은 항상 Git에 커밋되어 있는 파일이면 "Tracked", 그렇지 않은 경우는 "Untracked"이다.
[Git파일 상태]는
| 1. Unmodified상태 (수정하지 않음) 2. Modified 상태 (수정함) 3. Staged 상태 (커밋으로 저장소에 기록할)상태 |
- Tracked 파일에만 존재하며 (UnTracked 파일은 파일상태가 없다),
(커밋 후 미수정 시) Unmodified상태 (수정하지 않음) ---(수정 시)---> Modified상태 (수정함) --------(Staging Area)에 추가 시------------> Staged상태 (커밋으로 저장소에 기록할) 중 하나이다.
[Git파일의 라이프사이클]이란 하나의 파일이 Repository에 저장되기까지 [Git파일 상태]가 변화되는 과정이다.
END!
스터디 도움 참조 블로그 (References)
| - 버전 관리(VC) 위키백과 https://ko.wikipedia.org/wiki/%EB%B2%84%EC%A0%84_%EA%B4%80%EB%A6%AC - 누구나 쉽게 이해할 수 있는 Git 입문 https://backlog.com/git-tutorial/kr/ /입문편/Git의 기본/이력을 관리하는 저장소 https://backlog.com/git-tutorial/kr/intro/intro1_2.html /입문편/Git의 기본 개념 알기/작업 트리(Work tree)와 인덱스(Index) https://backlog.com/git-tutorial/kr/intro/intro1_4.html - git--distributed-even-if-your-workflow-isnt (Pro Git Book) https://git-scm.com/book/en/v2 - git--distributed-even-if-your-workflow-isnt (Pro Git Book) / ch2.1 https://git-scm.com/book/ko/v2/Git%EC%9D%98-%EA%B8%B0%EC%B4%88-Git-%EC%A0%80%EC%9E%A5%EC%86%8C-%EB%A7%8C%EB%93%A4%EA%B8%B0 - What is the difference between git clone and checkout? https://stackoverflow.com/a/7298621 - What is the difference between git checkout and git pull? - Quora https://www.quora.com/What-is-the-difference-between-git-checkout-and-git-pull |