Git의 기본 동작을 상세히 설명합니다. 분산버전관리시스템인 Git 의 내부가 어떻게 작동되고 운영되는지 알 수 있습니다.

1. $ git
On branch level 2
Your branch is up-to-date with ‘origin/ncsoft@ibare’.
Changes not staged for commit
modified: http://www.slideshare.net/ibare/dvcs-git
__ Learn DVCS for beginner
use "git add" and/or "git commit -a -m ‘Learn level 2’"

2. SOFTWARE
PROJECT
{ code }
소프트웨어 프로젝트는 코드를 중심으로 다양한 자원으로 구성된다

3. SOFTWARE PROJECT
{ code }
수 많은 파일과 중첩된 디렉토리의 집합
버전, 업무, 기능, 상황별로 다양한 상태를 가짐
Files
Files Directories Versions Patches more…

4. Directories
SOFTWARE PROJECT
{ code }
자원은 1명, 때론 수 백명이 각자 다른 상태를 유지하며 수시로 병합되고 분기됨
Files
Files
Versions
Patches
Directories
Files
Files
Versions
Patches
Directories
Files
Files
Versions
Patches

5. SOFTWARE PROJECT
{ code }
시간 순서대로 진행되는 상태 변화 뿐만 아니라 병렬적으로 n개 이상의
상태가 전개되는 경우도 비일비재

6. SOFTWARE PROJECT
{ code }
History Stage Strategy
소프트웨어 프로젝트에서 자원은 작업(변경) 이력과
작업 환경의 상태 그리고 진행 전략이 필요
?

7. git
Content tracker
Hash file system toolkit

8. Working
Directory
~/ncsoft $
프로젝트의 파일이 저장될 ROOT 폴더 ~/ncsoft 가 있다고 가정합니다.
~/ncsoft

9. Working
Directory
~/ncsoft $ git init
Staging area
(index)
git directory
(Repository)
init 명령은 프로젝트 디렉토리를 git이 추적하는 파일 시스템으로 만든다.
결과적으로 .git 디렉토리가 만들어지며 필요한 모든 정보는 이 디렉토리에서 관리된다.
~/ncsoft
~/ncsoft/.git/index
~/ncsoft/.git

10. Working
Directory
~/ncsoft $ git status
Staging area
(index)
git directory
(Repository)
README.txt
Untracked files
~/ncsoft
~/ncsoft/.git/index
~/ncsoft/.git
README.txt 파일이 새로 작업 디렉토리에 만들어졌다. git 은 추적하지 않는 파일이 있다는 것을 안다.
status 명령으로 확인하면 untracked files 이라고 표시된다.

11. Working
Directory
~/ncsoft $ git add README.txt
Staging area
(index)
git directory
(Repository)
README.txt
New file
README.txt
9e/d4614
~/ncsoft
~/ncsoft/.git/index
~/ncsoft/.git/objects
추적해야할 파일이라는 것을 add 명령으로 알려준다. git 저장소에 README.txt 파일이 저장되고
이후부터 git 은 README.txt 파일의 추적을 시작한다.

12. Working
Directory
~/ncsoft $ git commit -m “first commit”
Staging area
(index)
git directory
(Repository)
README.txt
c6/8a958
9e/d4614
db/d45f1
blob
commit
tree
~/ncsoft
~/ncsoft/.git/index
~/ncsoft/.git/objects
변경 작업이 끝났다는 것을 알려주기 위한 명령으로 commit 이 제공된다.
commit 은 복수개의 변경 이력을 관리하는 git 의 기본 단위가 된다.

13. Working
Directory
~/ncsoft $ git status
Staging area
(index)
git directory
(Repository)
README.txt
c6/8a958
9e/d4614
db/d45f1
modified
README.txt
~/ncsoft
~/ncsoft/.git/index
~/ncsoft/.git/objects
추적중인 파일에 변경 사항이 발생하면 git 은 변경이 발생했다는 것을 알려준다.

14. Working
Directory
~/ncsoft $ git add README.txt
Staging area
(index)
git directory
(Repository)
README.txt
c6/8a958
9e/d4614
db/d45f1
modified
README.txt
98/12a4b blob
~/ncsoft
~/ncsoft/.git/index
~/ncsoft/.git/objects
변경이 완료되면 add 명령으로 저장소에 저장한다.
이때 변경된 파일은 새로운 스냅샷으로 저장소에 저장된다.

15. Working
Directory
~/ncsoft $ git commit -m “edit commit”
Staging area
(index)
git directory
(Repository)
README.txt
c6/8a958
9e/d4614
db/d45f1
98/12a4b
a5/eb117
f9/a6deb
blob
commit
tree
~/ncsoft
~/ncsoft/.git/index
~/ncsoft/.git/objects
변경을 완료하기 위해 commit 한다.

16. add
git repository

17. Working
Directory
~/ncsoft $ git init
Initialized empty Git repository in ~/ncsoft/.git/
1. 상태 추적을 위한 저장소 생성
2. 저장소는 .git 디렉토리
3. 상태 추적 대상을 지정한 순간 부터 추적 시작
git repository
~/ncsoft

18. ~/ncsoft $ git status
On branch master
Initial commit
nothing to commit (create/copy files and use "git add" to track)
1. 작업 디렉토리의 추적 상태 표시
2. 추적중인 파일에 변화가 있는 경우 표시 Working
Directory
git repository
~/ncsoft

19. ~/ncsoft
Working
Directory
~/ncsoft $ git add readme.txt
{ }
readme.txt
git repository
1d93fd8
{ }
* SHA-1 해싱 후
내용 압축하여 저장
1. 새로운 파일이 작업 디렉토리에 나타남
2. 새로운 파일이란 추적한 적이 없는 파일
3. add 명령으로 추적을 시작
4. 파일 내용을 기반으로 SHA-1 해시값을 반환한다
5. 해시값을 파일명으로 git 저장소에 파일을 압축하여 저장한다

20. { }
readme.txt
{ }
readme.txt
add 한 후 파일 내용을 변경하면?
“readme text” “git tutorial”
EDIT

21. ~/ncsoft
Working
Directory
~/ncsoft $ git status
On branch master
Initial commit
Changes to be committed:
(use "git rm --cached <file>..." to unstage)
new file: README.txt
Changes not staged for commit:
modified: README.txt
{ }
readme.txt
git repository
1d93fd8
{ }
1. 새로운 파일 README.txt 가 있고
2. 수정된 파일 README.txt 가 있다고 표시
3. 저장된 내용과 현재 작업중인 파일의 내용 불일치 발생

22. ~/ncsoft
Working
Directory
~/ncsoft $ git diff
diff --git a/readme.txt b/readme.txt
index 1d93fd8…
--- a/README.txt
+++ b/README.txt
@@ -1 +1 @@
-readme text
+git tutorial
{ }
readme.txt
git repository
1d93fd8
{ }
1. 저장소에 저장된 파일 내용과 현재 작업 파일 차이점 표시
2. 삭제된 내용(- 붉게 표시된) 표시
3. 추가된 내용 표시 (+ 초록색 표시)
4. 비교 대상 파일의 해시값이 일치하는 것을 알 수 있음

23. ~/ncsoft
1d93fd
{ }
Working
Directory
~/ncsoft $ git add readme.txt
{ }
readme.txt
git repository
bd0134f
{ }
1. 변경 내용으로 다시 저장하기 위해 add 명령 실행
2. git 은 다시 현재 내용 기반으로 저장소에 저장
3. 새로운 db0134f 파일명으로 저장소에 저장
이전 파일은 어디로?
변경전 내용을 보고 싶다면?

24. .git/
objects/
93fd8ced…f9e36
0134f2e0…9d4ae
bd/
1d/
{ }
{ }
1. git은 저장소에 변경 내용을 기록(add)할 때 마다 파일 내용을
(Snapshot) 압축하여 .git/objects 디렉토리에 저장
2. 내용 기반의 SHA-1 해시값을 생성 파일명으로 사용. 내용이 동일
한 복수개의 파일이 만들어지지 않음.
3. 해시 값 앞 두 자리를 디렉토리로 생성, 파일 분산 효과를 가짐
git repository

25. Q1
두 가지 의문
내용 기반으로 파일을 저장한다면
파일명과 디렉토리 정보는 어디에
있는가?
내용이 변경될 때 add로 git 저장
소에 기록하는데 변경 이전 내용은
어떻게 접근하는가?
Q2

26. Index
git repository
1 2 3 4 5 n…

27. .git/index
1 2 3
1. git 저장소 내 index 파일에는 add 명령으로 저장된 파일 목록이 기록된다.
2. index 파일은 저장된 파일의 SHA-1 해시값과 디렉토리를 포함한 생성, 수정 시간 등
몇 가지 추가 정보로 구성된다.
1d93fd8
{ }
bd0134f
{ } { }
a3bf014

28. .git/index
1 2 3
1. index 파일은 파일 정보와 저장된 내용 파일이 1:1 관계로 연결되어있다.
2. 즉, index 파일은 변경 내역(히스토리) 을 관리하지 않는다.
3. 마지막으로 add 한 파일을 빠르게 접근하기 위한 색인 역할을 위해 존재한다.
4. 히스토리 관리를 위한 구조가 필요
readme.txt
objects/
93fd8ced…f9e36
0134f2e0…9d4ae
bd/
1d/
{ }
git repository readme.txt 파일의 이전 내용.
내용이 변경되면 index 파일과
연결은 유실된다.
.git/

29. Commit
git repository

30. git repository
{ } { } { } { }
index 기준
변경(CRUD) 정보의 묶음
~/ncsoft $ git commit -a -m “bug fixed”
1. index 파일을 기준으로 변경된 정보의 묶음 단위 기록을 commit 이라 한다.
2. git 은 commit 단위로 변경 이력을 추적, 관리한다.
3. commit 은 다음과 같은 정보로 구성된다.
commit
tree daf493
parent 560c00
author ibare <ibare@ncsoft.com>
committer ibare <ibare@ncsoft.com>
bug fixed
[ ]
objects/
commit 정보도 일반 파일과 마찮가지로
취급되고 같은 방식으로 objects
디렉토리에 저장된다.

31. Commit W/F
git commit
-a
tree
object 생성
commit
object 생성
이전 commit
{ } { } { } { }
objects/
파일 목록
저장
저장
git add <file>
1. 변경 내역을 저장소에 저장
2. 복수의 변경 내역 정보를 담은 트리 개체
를 생성 후 저장.
3. 이전 커밋 개체 정보를 참조
4. 2, 3의 결과(SHA-1) 그리고 사용자 정보
와 함께 커밋 개체 생성 후 저장

32. ~/ncsoft $ git commit -a -m “bug fixed”
1. 커밋 개체는 이전 커밋 개체의 참조를 가짐으로서 히스토리를 유지
2. 디렉토리를 추상화한 트리 개체가 존재하며 파일 목록은 트리 객체로 관리된다
3. 트리 개체는 디렉토리와 1:1 관계를 가지나 비어있는 디렉토리는 관리하지 않는다
4. 커밋 개체에 root 트리 개체의 참조를 저장
commit history
git repository
{ } { } { } { }
C2 C3
두 번째 커밋 새롭게 추가될
예정인 커밋
C1
첫 번째 커밋
저장된 스냅샷과 비교하여
수정된 묶음을 기록한다
objects/

33. git 개체의 종류
{ } C
파일 디렉토리 커밋
blob tree commit
git add 명령으로 추가될 때 생성
디렉토리내 파일 변경이 일어난 커밋 발생시 마다 재생성
커밋 할 때 마다 생성
생
성
시
점

34. 작업 디렉토리와 커밋 개체 생성 방식
작업 디렉토리 상태
1. 파일 a, b 가 추가되고 파일이 없는 data 디렉토리를 커밋한다.
2. 커밋 개체 C1은 root 를 추상화한 트리 개체를 가진다.
3. 트리 개체는 파일 a, b의 blob 개체 정보를 가진다.
4. 빈 디렉토리인 data 의 트리 개체는 만들어지지 않는다.
{ }
root
data
{ }
a
b
root C1
{ } { }
root
a b
daf493
cc33a a983c
077f38a

35. 작업 디렉토리와 커밋 개체 생성 방식
C2
{ }
{ }
{ }
{ }
root
data
root
data
{ }
1. 비어있던 data 디렉토리에 새로운 파일 c가 추가되어 커밋된다
2. 새로운 커밋 C2 가 만들어지며 data 디렉토리의 트리 개체가 만들어진다
3. 하위 요소를 참조하는 방식으로 인해 상위 트리 개체 모두 새로 만들어진다
4. 트리 개체는 새로 만들어 지는 반면 변경 내용이 없는 blob 개체들은 그대로 유지된다
a
b
c
C1
{ } { }
root
a b
daf493
cc33a a983c
root
11cafa
{ }
b
a983c
a
cc33a
ec63ca
c
781a3c
077f38a 5b8d85d
작업 디렉토리 상태

36. 작업 디렉토리와 커밋 개체 생성 방식
C2
{ }
{ }
{ }
{ }
root
data
root
data
{ }
1. data/c 파일 내용이 변경되어 커밋된다.
2. 새로운 커밋 C3 가 만들어지며 c 파일이 변경되며 이를 참조하고 있는 트리 개체도 새로 만들어 진다.
3. 서브 디렉토리의 변경사항은 언제나 최상위 루트 디렉토리까지 새로운 트리 개체 생성을 발생시킨다.
a
b
c
C1
{ } { }
root
a b
daf493
cc33a a983c
root
11cafa
{ }
b
a983c
a
cc33a
ec63ca
c
781a3c
077f38a 5b8d85d
C3
{ }
{ }
root
data
5a66ae9
{ }
b
a983c
a
cc33a
bef3442
c
d4bfd7c
f6ff14d
작업 디렉토리 상태

37. Working
Directory
git repository
~/ncsoft

38. git repo
Working Directory란?
1. git init 명령으로 .git 디렉토리가 루트에 존재하는 디렉토리
2. git이 추적하지 않는 파일과 git 저장소로부터 복사된 파일이 공존하는 디렉토리
3. git은 branch 라는 가상의 상태를 가진다.
4. Working directory는 branch의 상태를 복원한 임시 저장소이다.
~/ncsoft

39. 처음으로 돌아가서 확인하기
~/ncsoft $ git init
Initialized empty Git repository in ~/ncsoft/.git/
~/ncsoft $ git status
On branch master
Initial commit
nothing to commit (create/copy files and use "git add" to track)
1. init 명령으로 저장소를 만들면 기본 상태인 master 브랜
치를 만든다.

40. master 브랜치는 어디에 있나?
.git/HEAD
“ref: refs/heads/master”
1. HEAD 파일은 현재 상태(branch)의 위치값
을 가진 텍스트 파일
2. HEAD 파일에 기록된 경로가 현재 작업중인
브랜치다

41. master 브랜치는 어디에 있나?
.git/HEAD
refs
heads
master
참조

42. .git/HEAD
r
heads
master
참조
“252dbe34fcde59e0fdf35b3315078eccabad18dc”
master 파일에는 어떤 정보가?
1. master 파일도 평범한 텍스트 파일이며 커밋 개체의 해시
값을 담고 있다.
2. 브랜치는 특정 commit의 참조다.

43. git commit의 구성
master
HEAD
commitcommitcommit
tree tree
blob blob tree
blob
tree
blob tree
blob blob

44. create branch
git repository

45. ~/ncsoft $ git branch develop
master
HEAD
develop
1. branch 명령은 브랜치 목록 보기, 생성, 삭제를 지원한다.
2. 새로운 “develop” 브랜치를 생성한다.
3. 작업 디렉토리는 여전히 master 브랜치 상태다.
4. develop 브랜치 또한 master 브랜치와 동일한 커밋을 참조한다.
tree
blob tree
blob blob
C1 C2 C3

46. ~/ncsoft $ git checkout develop
1. checkout 명령으로 특정 브랜치 (커밋 트리) 로 이동할 수 있다.
2. 상태의 변경은 HEAD가 참조하는 브랜치를 이동시킨다. 변경된 커밋의 상태로
작업 디렉토리를 갱신한다.
master HEAD
develop
tree
blob tree
blob blob
C3C1 C2

47. ~/ncsoft $ git commit
1. develop 브랜치에서 변경이 발생하여 새롭게 커밋하여 커밋 C4 생성
2. develop 은 새로운 커밋 C4를 참조, HEAD 는 현재 작업 브랜치 develop을
따라 이동한다.
master
HEAD
develop
tree
blob tree
blob blob
tree
blob
C3 C4C1 C2

48. merge
git repository

49. ~/ncsoft $ git checkout master ; git merge develop
1. 현재 브랜치의 커밋 트리와 대상 브랜치의 커밋 트리를 비교하여 병합한다.
2. 병합 대상 브랜치의 부모 커밋과 (C3) 현재 브랜치의 커밋이 같다면 병합할 필요
가 없어 브랜치 참조의 이동만 발생한다. 이것을 참조만 변경하는 Fast-forward
라 한다.
master
HEAD
develop
tree
blob tree
blob blob
tree
blob
C3 C4C1 C2

50. ~/ncsoft $ git merge develop --no-ff
1. --no-ff 옵션은 Fast-forward 를 금지시킨다. 결과적으로 새로운 병합 커밋인
C4가 생성되며 develop 이 참조하는 커밋은 변하지 않는다.
2. 커밋 C5는 공통 조상이 2개인 (C3, C4) 병합 커밋이 된다.
master
HEAD
develop
C3
C4
C5
tree
blob tree
blob blob
tree
blob
C1 C2

51. ~/ncsoft $ git merge develop
1. 현재 브랜치의 커밋 트리와 대상 브랜치의 커밋 트리를 비교하여 같은 커밋 트리
가 아니라면 Fast-forward 하지 못하고 새로운 병합 커밋 (C6) 이 생성된다.
master
HEAD
develop
C3
C4
C5 C6C1 C2

52. merge conflict
git repository

53. ~/ncsoft $ git merge develop
Auto-merging main.c
CONFLICT (content): Merge conflict in main.c
Automatic merge failed; fix conflicts and then commit the result.
1. 커밋 C5와 C4의 병합을 시도한다. 동일한 파일이 같은 위치에 수정이 발생하여 충돌
이 발생했다. 이 경우 git 은 병합을 하지 못하며 새로운 병합 커밋도 생성되지 않는다.
2. 병합 커밋이 생성되지 않았기 때문에 HEAD 와 브랜치의 참조도 변경되지 않는다.
master
HEAD
develop
C3
C4
C5C1 C2

54. ~/ncsoft $ git status
On branch master
You have unmerged paths. (fix conflicts and run "git commit")
Unmerged paths:
(use "git add <file>..." to mark resolution)
both modified: main.c
no changes added to commit (use "git add" and/or "git commit -a")
1. 작업 디렉토리 상태를 확인하면 git 은 충돌이 main.c
파일에서 발생했다는 것을 알려준다.
2. 현재 작업 디렉토리에 있는 main.c 파일은 C4, C5
의 main.c 파일과 다른 git 이 병합 작업 중 만들어낸
main.c 파일이다.
master
HEAD
develop
C3
C4
C5

55. ~/ncsoft $ vi main.c
#include<stdio.h>
int main(int argc, char * argv[])
{
<<<<<<< HEAD
printf("Hello World!!!n");
=======
printf("Hello World~n");
>>>>>>> develop
return 0;
}
1. git 이 병합 작업중 만들어낸 main.c 파일의 내용을 편집한다.
2. 충돌이 발생한 파일의 출동 지점은 현재 HEAD 의 파일 내용과
병합 대상 파일의 파일 내용이 함께 표시된다.
3. 충돌이 발생한 내용을 편집기나 병합 도구로 직접 수정한 후 파
일을 저장한다.

56. ~/ncsoft $ git commit -a -m ‘fixed conflict’
1. 변경 내역을 커밋 한다. 새로운 병합 커밋 C6이 생성되고 병합이 완료된다.
2. 충돌 해결 후 왜 merge 명령이 아닌 commit 명령으로 병합 커밋이 생길까?
3. 병합 전 충돌로 발생한 main.c 파일은 어떤 커밋에 포함되어 있는걸까?
master
HEAD
develop
C3
C4
C5 C6
{ }
main.c
173d34
{ }
main.c
8e84a8
{ }
main.c
d96990

57. ~/ncsoft $ git ls-files -s
100644 1e8b314962144c26d5e0e50fd29d2ca327864913 0 main.h
100644 f599e28b8ab0d8c9c57a486c89c4a5132dcbd3b2 0 main.c
100644 5dcd71da1ab96274cb72b23a1edaf144abc1a0a9 0 data/config.xml
1. ls-files 명령은 git 이 제공하는 저수준 명령으로 현재 index(Staging Area)에 등록된
파일 목록을 표시한다.
2. 만약 충돌이 발생하면 출돌이 발생된 파일은 아래와 같이 표시된다.
모드 비트 SHA-1 해시 Slot No 파일명(경로 포함)
~/ncsoft $ git ls-files -s
100644 8e84a811941d10a363b9107e26fceec2c36b6a99 1 main.c
100644 173d34be1d1c2b2967d4f34095889f452c3c840b 2 main.c
100644 d969903bca8dc0e571a89b9aa4a0ef6aa606925f 3 main.c
100644 f599e28b8ab0d8c9c57a486c89c4a5132dcbd3b2 0 main.h
100644 5dcd71da1ab96274cb72b23a1edaf144abc1a0a9 0 data/config.xml

58. files -s
363b9107e26fceec2c36b6a99 1 main.c
967d4f34095889f452c3c840b 2 main.c
571a89b9aa4a0ef6aa606925f 3 main.c
9c57a486c89c4a5132dcbd3b2 0 main.h
4cb72b23a1edaf144abc1a0a9 0 data/config.xml
공통 조상
C3
C4
C5
{ }
main.c
173d34
{ }
main.c
8e84a8
{ }
main.c
0cfbf0
병합 대상
병합 재료
{ }
main.c
f7fa9e2
1. git이 만들어낸 충돌 파일. 신규 파일이
기 때문에 add 후 commit 한다.
2. slot 의 상태로 새로운 커밋이 병합 커밋
이 되어야 한다는 것을 인식한다.

59. rebase
git repository

60. ~/ncsoft $ git merge fb-login
1. facebook login 기능 개발을 새로운 브랜치 fb-login를
만들어 에서 개발 완료했다.
2. master 브랜치에 새로운 fb-login 브랜치를 병합하면
Fast-forward 된다.
C3
C2
C4
master
fb-login
C3C2 C4
master
HEAD
fb-login
C3
C2
C5
master
HEAD
fb-login
C4
C3
C2
C5
C4 C6
master
HEAD
fb-login
1. facebook login 기능 개발을 새로운 브랜치 fb-login를 만들어
에서 개발 완료했다.
2. fb-login 브랜치가 master 브랜치에 변경 사항 커밋 C4가 있기
때문에 Fast-forward 되지 않고 새로운 병합 커밋 이 생성된다.
HEAD
Fast-forward
3Way merge
병합 커밋 없이
Fast-forward
할 순 없을까?

61. ~/ncsoft $ git rebase master
C3
C2
C5
master
HEAD
fb-login
C4
C3’C2 C5’C4
master
HEAD
fb-login
C3’C2 C5’C4
master
HEAD
fb-login
~/ncsoft $ git merge fb-login
1. rebase 명령으로 fb-login 브랜치의 부모 커밋을 rebase할 브랜치의 마지막
커밋인 C4 뒤에 차례로 병합하며 연결한다.
2. 병합을 처리하기 위해 fb-login 커밋 하나 하나 순서 대로 C2 부터 병합을 처리
하여 C3, C5 커밋을 기반으로 C3’, C5’ 커밋을 생성해 C4 커밋 이후로 병합을
진행한다.
3. rebase 가 완료되면 master 와 fb-login 의 커밋 그래프는 직선 형태가 된다.
4. master 브랜치로 이동 후 fb-login 을 병합하면 순차적으
로 커밋이 발생한 것과 같기 때문에 Fast-forward 된다.
5. **주의** C3와 C5 커밋은 새로 만들어지기 때문에 rebase 이후 커밋 로그에
서 사라진다. reflog 명령으로 C3, C5 의 해시값 추적이 가능하다.
Rebase
Fast-forward
C3 C5

62. rebase conflict
git repository

63. ~/ncsoft $ git rebase master
C3
C2
C5
master
HEAD
fb-login
C4
C2
C5
C4
master
fb-login
~/ncsoft $ git rebase --continue
1. rebase 명령으로 fb-login 브랜치의 C3, C5 커밋이 차례로 master 에 병합된다.
2. 커밋 C4와 C3의 병합 중 충돌이 발생하여 병합이 중단된다.
3. 충돌의 결과는 merge 명령과 동일하다. 충돌의 처리 방법 또한 동일하다.
4. 충돌을 해결한 후 merge 명령의 경우 commit 하여 병합을 완료한 반면 rebase
는 아직 병합이 진행중이다. 남은 커밋 C5 를 병합해야 한다.
5. rebase --continue 옵션으로 병합을 계속 진행한다.
6. 충돌이 발생하면 동일한 방법으로 해결한 후 다 시 rebase 를 진행한다.
Rebase
C3
C3’C2 C5’C4
master
HEAD
fb-login

64. remote
ibare git repo
…
…
smith git repo

65. ~/ncsoft $ git clone <remote-git-repo-uri>
1. 리모트 git 저장소를 클론 명령으로 로컬에 복사할 수 있다.
2. 리모트 저장소의 참조가 로컬 저장소에 생성된다. 기본 참조 명은 origin 이다.
3. 리모트 저장소는 git 저장소 호스팅을 제공하는 서비스일 수도 있고 자체 구축한 git 서버일수도 있다.
로컬 디스크의 다른 디렉토리일 수 도 있다.
4. git 은 통신을 위해 http, https, ssh, smart-protocol 등을 지원한다.
remote repo
local repo
clone
https://github.com/your/project.git
host

66. remote repo local repo
clone
C1 C2
HEAD
C1 C2
master
origin/master
master
HEAD
C1 C2
origin/master master
C3
pushC1 C2
master
C3
C1 C2 C3
HEAD
origin/master
master
new local commit
success
clone 이후 로컬 저장소의 변경 내용 전송 동작
git clone https://remote.git
git push origin master
clone 명령은 리모트 저장소의
모든 내용을 완전하게 복사한다

67. remote repo local repo
fetch
HEAD
C1 C2
origin/master
master
리모트 저장소의 변경 내용 적용하기
git fetch origin master
fetch 명령은 리모트의 새로운 변경
내역을 로컬 저장소로 다운로드 한다
C1 C2
master
C3
C3
FETCH_HEAD
HEAD
C1 C2
master
origin/master
fetch
C1 C2 C3
HEAD
master
origin/master
merge
git merge origin/master

68. remote repo local repo
pull
간단하게 리모트 변경 내용 적용하기
git pull origin master
pull 명령은 리모트의 새로운 변경 내역을
로컬 저장소로 fetch 한 후 즉시 merge 를
수행한다. 결과적으로 merge 할 목적이라
면 작업을 단축시킬 수 있다.
C1 C2
master
C3
HEAD
C1 C2
master
origin/master
pull
C1 C2 C3
HEAD
master
origin/master

69. Operations
git repository

70. 원하는 커밋 트리로 이동하기
52e84ad
commit
tree tree
blob blob tree
blob
tree
blob tree
blob blob
C1 C2 C3
22d73ee
commit
f5e7dc8
commit
HEAD
master
W-Dir Stage Repo
1. Working Directory가 HEAD 의 위치인 C3
커밋 트리의 내용과 동일하게 구성되어있다.
2. 커밋 C3가 잘못되어 모든 상태를 C2 상태로
돌아가려 함.
clear

71. 원하는 커밋 트리로 이동하기
52e84ad
commit
tree tree
blob blob tree
blob
tree
blob tree
blob blob
C1 C2 C3
22d73ee
commit
f5e7dc8
commit
HEAD
master
W-Dir Stage Repo
1. Working Directory
커밋
2. 커밋
돌아가려
clear
$ git reset --hard HEAD~1
$ git reset --hard HEAD@{1}
$ git reset --hard 22d73ee
reset
--hard 옵션은 대상 커밋을 기준으로 모든 상태
(W-Dir, Stage, Repo)를 싱크시킨다.
HEAD~1 의 1은 단계를 의미한다. HARD~2 라
면 C1이 대상이 된다. HEAD@{n} 은 상대 위치
지정 방식. reflog 에서 단계를 확인할 수 있다. 커
밋의 해시값을 안다면 직접 지정해도 문제없다.

72. 원하는 커밋 트리로 이동하기
52e84ad
commit
tree tree
blob blob tree
blob
tree
blob tree
blob blob
C1 C2 C3
22d73ee
commit
f5e7dc8
commit
HEAD
master
W-Dir Stage Repo
1. Working Directory
커밋
2. 커밋
돌아가려
+new file
$ git reset --soft HEAD~1
$ git reset --soft HEAD@{1}
$ git reset --soft 22d73ee
reset
--soft 옵션은 HEAD와 master 의 참조만을 C2
로 변경한다. 결과적으로 커밋에 포함되지 않고
index 에만 추가됐던 (git add . 명령으로) C3 커
밋의 신규 파일이 아직 커밋 전 상태가 된다.

73. 원하는 커밋 트리로 이동하기
52e84ad
commit
tree tree
blob blob tree
blob
tree
blob tree
blob blob
C1 C2 C3
22d73ee
commit
f5e7dc8
commit
HEAD
master
W-Dir Stage Repo
1. Working Directory
커밋
2. 커밋
돌아가려
untracked
files
$ git reset --mixed HEAD~1
$ git reset --mixed HEAD@{1}
$ git reset --mixed 22d73ee
reset
--mixed 옵션은 HEAD와 master 의 참조를 이
동시키고 Stage 정보도 C2로 변경한다. 결과적으
로 C3 에서 add 로 추가됐던 파일이 index 에서
삭제되어 untracked file 로 표시된다.

74. 브랜치 생성 및 삭제
C1 C2 C3
HEAD
master
C1 C2
C4
HEAD
master
C3
C5
topic
git branch topic
new branch
master
topic 브랜치 시작 지점
git checkout -b topic master
checkout 의 -b 옵션으로 신규 브랜치를
만들면서 바로 이동할 수 있다.
C1 C2 C4
HEAD
master
C3 C5
topic
merge
delete branch
C1 C2 C4
HEAD
master
C3 C5
git branch -d topic

75. 커밋 북마크 태그
HEAD
master
develop
v1.0 v1.1 v1.2 v2.0
$ git tag v1.0
tag 명령으로 간단
하게 만들 수 있다.
22d73ee
$ git tag v1.2 22d7eee
지난 커밋에도 커밋의
SHA-1 값만 알면 Tag
를 만들 수 있다.
1. 커밋의 참조로서 HEAD, FETCH_HEAD, branch 외에 git 은 태그를 제공한다.
2. 수 없이 많은 커밋 중 기억해야할 필요가 있는 커밋이 있을 경우 태그를 만들어 관리할 수 있다.
3. 태그는 단순한 커밋 참조인 Lightweight Tag 와 태그 생성자 정보 및 태그 생성 일자 등의 부가 정보도 함께 저장되는
Annotated Tag 가 있다. (-a 옵션으로 만들 수 있다)
4. 태그의 내용은 show <tag-name> 으로 조회할 수 있고 git tag 명령은 전체 태그의 리스트를 표시한다.

76. $ git
checkout level 3
error: pathspec 'level3' did not match
any file(s) known to git