Git - Level 2

12,569 views

Published on

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

Published in: Technology
7 Comments
331 Likes
Statistics
Notes
No Downloads
Views
Total views
12,569
On SlideShare
0
From Embeds
0
Number of Embeds
1,316
Actions
Shares
0
Downloads
0
Comments
7
Likes
331
Embeds 0
No embeds

No notes for slide

Git - Level 2

  1. 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. 2. SOFTWARE PROJECT { code } 소프트웨어 프로젝트는 코드를 중심으로 다양한 자원으로 구성된다
  3. 3. SOFTWARE PROJECT { code } 수 많은 파일과 중첩된 디렉토리의 집합 버전, 업무, 기능, 상황별로 다양한 상태를 가짐 Files Files Directories Versions Patches more…
  4. 4. Directories SOFTWARE PROJECT { code } 자원은 1명, 때론 수 백명이 각자 다른 상태를 유지하며 수시로 병합되고 분기됨 Files Files Versions Patches Directories Files Files Versions Patches Directories Files Files Versions Patches
  5. 5. SOFTWARE PROJECT { code } 시간 순서대로 진행되는 상태 변화 뿐만 아니라 병렬적으로 n개 이상의 상태가 전개되는 경우도 비일비재
  6. 6. SOFTWARE PROJECT { code } History Stage Strategy 소프트웨어 프로젝트에서 자원은 작업(변경) 이력과 작업 환경의 상태 그리고 진행 전략이 필요 ?
  7. 7. git Content tracker Hash file system toolkit
  8. 8. Working Directory ~/ncsoft $ 프로젝트의 파일이 저장될 ROOT 폴더 ~/ncsoft 가 있다고 가정합니다. ~/ncsoft
  9. 9. Working Directory ~/ncsoft $ git init Staging area (index) git directory (Repository) init 명령은 프로젝트 디렉토리를 git이 추적하는 파일 시스템으로 만든다. 결과적으로 .git 디렉토리가 만들어지며 필요한 모든 정보는 이 디렉토리에서 관리된다. ~/ncsoft ~/ncsoft/.git/index ~/ncsoft/.git
  10. 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. 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. 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. 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. 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. 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. 16. add git repository
  17. 17. Working Directory ~/ncsoft $ git init
 Initialized empty Git repository in ~/ncsoft/.git/ 1. 상태 추적을 위한 저장소 생성 2. 저장소는 .git 디렉토리 3. 상태 추적 대상을 지정한 순간 부터 추적 시작 git repository ~/ncsoft
  18. 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. 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. 20. { } readme.txt { } readme.txt add 한 후 파일 내용을 변경하면? “readme text” “git tutorial” EDIT
  21. 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. 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. 23. ~/ncsoft 1d93fd { } Working Directory ~/ncsoft $ git add readme.txt { } readme.txt git repository bd0134f { } 1. 변경 내용으로 다시 저장하기 위해 add 명령 실행 2. git 은 다시 현재 내용 기반으로 저장소에 저장 3. 새로운 db0134f 파일명으로 저장소에 저장 이전 파일은 어디로? 변경전 내용을 보고 싶다면?
  24. 24. .git/ objects/ 93fd8ced…f9e36 0134f2e0…9d4ae bd/ 1d/ { } { } 1. git은 저장소에 변경 내용을 기록(add)할 때 마다 파일 내용을 (Snapshot) 압축하여 .git/objects 디렉토리에 저장 2. 내용 기반의 SHA-1 해시값을 생성 파일명으로 사용. 내용이 동일 한 복수개의 파일이 만들어지지 않음. 3. 해시 값 앞 두 자리를 디렉토리로 생성, 파일 분산 효과를 가짐 git repository
  25. 25. Q1 두 가지 의문 내용 기반으로 파일을 저장한다면 파일명과 디렉토리 정보는 어디에 있는가? 내용이 변경될 때 add로 git 저장 소에 기록하는데 변경 이전 내용은 어떻게 접근하는가? Q2
  26. 26. Index git repository 1 2 3 4 5 n…
  27. 27. .git/index 1 2 3 1. git 저장소 내 index 파일에는 add 명령으로 저장된 파일 목록이 기록된다. 2. index 파일은 저장된 파일의 SHA-1 해시값과 디렉토리를 포함한 생성, 수정 시간 등 몇 가지 추가 정보로 구성된다. 1d93fd8 { } bd0134f { } { } a3bf014
  28. 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. 29. Commit git repository
  30. 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. 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. 32. ~/ncsoft $ git commit -a -m “bug fixed” 1. 커밋 개체는 이전 커밋 개체의 참조를 가짐으로서 히스토리를 유지 2. 디렉토리를 추상화한 트리 개체가 존재하며 파일 목록은 트리 객체로 관리된다 3. 트리 개체는 디렉토리와 1:1 관계를 가지나 비어있는 디렉토리는 관리하지 않는다 4. 커밋 개체에 root 트리 개체의 참조를 저장 commit history git repository { } { } { } { } C2 C3 두 번째 커밋 새롭게 추가될 예정인 커밋 C1 첫 번째 커밋 저장된 스냅샷과 비교하여 수정된 묶음을 기록한다 objects/
  33. 33. git 개체의 종류 { } C 파일 디렉토리 커밋 blob tree commit git add 명령으로 추가될 때 생성 디렉토리내 파일 변경이 일어난 커밋 발생시 마다 재생성 커밋 할 때 마다 생성 생 성 시 점
  34. 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. 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. 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. 37. Working Directory git repository ~/ncsoft
  38. 38. git repo Working Directory란? 1. git init 명령으로 .git 디렉토리가 루트에 존재하는 디렉토리 2. git이 추적하지 않는 파일과 git 저장소로부터 복사된 파일이 공존하는 디렉토리 3. git은 branch 라는 가상의 상태를 가진다. 4. Working directory는 branch의 상태를 복원한 임시 저장소이다. ~/ncsoft
  39. 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. 40. master 브랜치는 어디에 있나? .git/HEAD “ref: refs/heads/master” 1. HEAD 파일은 현재 상태(branch)의 위치값 을 가진 텍스트 파일 2. HEAD 파일에 기록된 경로가 현재 작업중인 브랜치다
  41. 41. master 브랜치는 어디에 있나? .git/HEAD refs heads master 참조
  42. 42. .git/HEAD r heads master 참조 “252dbe34fcde59e0fdf35b3315078eccabad18dc” master 파일에는 어떤 정보가? 1. master 파일도 평범한 텍스트 파일이며 커밋 개체의 해시 값을 담고 있다. 2. 브랜치는 특정 commit의 참조다.
  43. 43. git commit의 구성 master HEAD commitcommitcommit tree tree blob blob tree blob tree blob tree blob blob
  44. 44. create branch git repository
  45. 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. 46. ~/ncsoft $ git checkout develop 1. checkout 명령으로 특정 브랜치 (커밋 트리) 로 이동할 수 있다. 2. 상태의 변경은 HEAD가 참조하는 브랜치를 이동시킨다. 변경된 커밋의 상태로 작업 디렉토리를 갱신한다. master HEAD develop tree blob tree blob blob C3C1 C2
  47. 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. 48. merge git repository
  49. 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. 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. 51. ~/ncsoft $ git merge develop 1. 현재 브랜치의 커밋 트리와 대상 브랜치의 커밋 트리를 비교하여 같은 커밋 트리 가 아니라면 Fast-forward 하지 못하고 새로운 병합 커밋 (C6) 이 생성된다. master HEAD develop C3 C4 C5 C6C1 C2
  52. 52. merge conflict git repository
  53. 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. 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. 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. 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. 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. 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. 59. rebase git repository
  60. 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. 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. 62. rebase conflict git repository
  63. 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. 64. remote ibare git repo … … smith git repo
  65. 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. 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. 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. 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. 69. Operations git repository
  70. 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. 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. 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. 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. 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. 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. 76. $ git checkout level 3 error: pathspec 'level3' did not match any file(s) known to git

×