Recommandé
Contenu connexe
Tendances
Tendances (20)
Similaire à [NDC16] Effective Git
Similaire à [NDC16] Effective Git (20)
[NDC16] Effective Git
- 1. Effective Git 넥슨 코리아 왓 스튜디오 김찬웅
- 2. 소개
- 3. 김찬웅 • 2010-2014.3 <삼한제국기> • 2014.3-2014.11 <Project N> • 2014.12- <야생의 땅: 듀랑고> • KGC14 <삼한제국기 포스트모템> • NDC15 <그룹웨어에 새 에너지를> • NDC16 <Find My AndPhone> • NDC16 <Effective Git> kexplo http://chanwoong.kim cwkim@nexon.co.kr kexplo
- 4. 발표 동기
- 5. Git 초심자들을 관찰 • 이전에 사용하던 VCS의 개념대로 사용 • 이전 VCS와 대칭되는 명령어만 사용 • svn checkout → git clone • svn update → git pull • svn commit → git commit
- 6. • 나쁘다는 것이 아님 • 발표자도 같은 시행착오를 겪음 • Git의 좋은 점을 영업하고 싶다! © http://d.hatena.ne.jp/gu_he_he/20120322/1332419643 나랑 Git 쓰지 않을래?
- 7. 발표의 대상 Git 숙련도 초심자 push, commit 정도의 기본적인 명령어 숙지 중급자 고급 명령어와 동작 원리 파악 여기 쯤
- 8. 이런 분들에겐 조금 어려울 수 있습니다 • git을 command line으로 쓰지 않는 분 • GUI 툴을 주로 이용 • Staging area 를 아직 모르시는 분
- 9. 하지 않을 이야기 • 흔한 Git 입문서 • 태초에 Git이 있었고, Git은 분산 버전 관리 시스템이며 … • Git 내부 구조 • blob, tree object, commit object, … • 이건 다음에 기회가 된다면…
- 10. 오늘 할 이야기 • Git 사용 전략 • Rebase • 바로 써먹을 수 있는 16가지 기능 소개 • 3가지 파트로 나누어서 설명 • 유용할 도구 소개
- 11. 오늘 할 이야기 • Git 사용 전략 • Rebase • 바로 써먹을 수 있는 16가지 기능 소개 • 3가지 파트로 나누어서 설명 • 유용할 도구 소개 1. 생산성 높이기 2. 로그 탐색하기 3. 실수 만회하기
- 12. Git 사용 전략 git flow Forward-porting
- 13. Branching, Merge가 정말 쉽고 빠르다 쉽다 == 남용 하기 쉽다
- 16. Git-flow 브랜칭 전략 • Vincent Driessen이 제안 • 목적에 따라 브랜치를 분리하는 모델 • master branch: 배포 버전 • develop branch: 개발 버전 • 배포와 연관 지었을 때 강력한 힘을 발휘 • Git-flow를 설치해서 쓰면, 브랜치 삭제/병합을 쉽게 해 줌
- 17. 새 기능 개발 develop
- 18. 새 기능 개발 develop feature/awesome $ git flow feature start awesome $ git commit -a $ git commit -a $ git commit -a
- 19. 새 기능 개발 develop feature/awesome $ git flow finish awesome
- 20. 새 배포 develop
- 21. 새 배포 develop release/v1.0.0 $ git flow release start v1.0.0 $ git commit -a $ git commit -a $ git commit -a
- 22. 새 배포 develop $ git flow release finish v1.0.0 master tag v1.0.0
- 24. 핫 픽스 master hotfix/fix1 $ git flow hotfix start fix1 $ git commit -a $ git commit -a $ git commit -a
- 25. 핫 픽스 master $ git flow hotfix finish fix1 develop tag fix1 hotfix/fix1
- 26. 큰 그림 develop feature/awesome release/v1.0.0 master feature release hotfix tag v1.0.0 hotfix/fix1 tag fix1
- 27. 큰 그림 develop feature/awesome release/v1.0.0 master feature release hotfix tag v1.0.0 hotfix/fix1 tag fix1
- 28. 큰 그림 develop feature/awesome release/v1.0.0 master feature release hotfix tag v1.0.0 hotfix/fix1 tag fix1
- 29. 큰 그림 develop feature/awesome release/v1.0.0 master feature release hotfix tag v1.0.0 hotfix/fix1 tag fix1
- 30. 장점 • 가독성 향상 • feature → develop 머지 커밋 == 새로운 기능이 있구나 • 작업 내용은 feature branch로 격리되어 다른 코드와 섞이지 않음 • 효율 향상 • 브랜치의 역할이 정해져 있기 때문에 Hook등을 걸기 쉬움 • hotfix 작업시 실수 방지
- 33. feature/blahblah $ git pull --rebase origin/master origin/master Forward-porting master
- 34. feature/b origin/master Forward-porting $ git pull --rebase origin/master master
- 35. 장점 • 머지 그래프가 예쁘게 유지 • 작업 도중에 최신 내용을 가져 와 머지하는 순간 무지개에 가까워 짐.. • 충돌 발생시 기능 작업자가 인지, 처리 가능 • 코드 리뷰 향상 • 긴 기능의 작업을 피하게 됨 • 오래 된 기능 브랜치 일수록 충돌 날 확률이 올라감 • 개별 기능은 짧게 쪼개어 작업하는 원칙에도 OK
- 36. 왓 스튜디오에서는 • Git-flow • release 브랜치에 Hook을 활용 • 커밋이 올라오면 자동 빌드, 테스트, 배포 • Forward-porting • 로그 그래프로 작업된 기능을 한 눈에 파악 가능 • 머지 했을 때, 타인의 코드에 트롤링(?)할 여지 방지
- 37. Rebase rebase 동작 원리 로그 정제하기
- 39. Rebase • Base를 재정의(Re-)하는 기능 • Forward-porting도 Rebase를 이용한 방법 • Rebase를 통해 base를 최신 커밋 으로 지정하는 전략
- 40. B C D feature/abc E FA develop HEAD
- 41. B C D feature/abc E FA develop $ git checkout feature/abc $ git rebase develop HEAD
- 42. B C D feature/abc E FA develop 공통 조상을 찾음 HEAD
- 43. B C D feature/abc E FA develop 내부적으로 각 커밋마다 패치를 만들어 둠 HEAD B C D
- 44. B` C` D` feature/abc E FA develop 대상 브랜치에 적용 HEAD B C D B C D
- 46. 나누고 붙이고 섞고 지우고 $ git rebase –i [<커밋 범위>]
- 47. 나누고 붙이고 섞고 지우고 $ git rebase –i [<커밋 범위>]
- 48. Rebase를 통해 코드를 원격 저장소에 올리기 전에, 커밋을 깔끔하게 정제할 수 있다.
- 49. 16가지 기능 소개 1. 생산성 높이기 2. 로그 탐색하기 3. 실수 만회하기
- 50. 1. 생산성 높이기 stash bisect blame worktree Hunk 단위 작업하기 특정 버전의 파일 가져오기 alias shallow clone 2. 로그 탐색하기 3. 실수 만회하기
- 51. $ git stash save Pop Apply List drop stash bise bla workt Hunk 특정버 ali shall
- 52. 작업 물 끼어들기 • 다들 겪어봤을 일 • 기능 A를 작업 중인데, 기능 B를 지금 해 달라고요? © ABC
- 53. stash는 현재 작업 디렉토리에 있는 작업 물을 stash stack에 쌓아 줍니다. WIP WIP stash Working Directory git stash save git stash pop
- 54. 보통은 • 현재 작업 물을 백업 혹은 격리 • 새로운 작업을 마친 후 • 이전 작업 물을 되돌림
- 55. git stash • 현재 작업 물을 백업 혹은 격리 • $ git stash save • 새로운 작업을 마친 후 • 이전 작업 물을 되돌림 • $ git stash pop
- 56. 수동 관리도 가능 • $ git stash list • $ git stash apply [<stash>] • $ git stash drop [<stash>]
- 57. $ git bisect start good bad log reset bisect sta bla workt Hunk 특정버 ali shall
- 58. 어? • 어느 순간 코드가 실패한다. • 어디지? • 뭐가 문제지? • 너무 작업이 많이 쌓여서 감이 안 오는데? 간담이 서늘해 진다 © http://ff663.blogspot.kr/2010/05/201058- in-english-i-feel-complete.html
- 60. bisect는 버그를 가진 커밋을 찾는데 도움을 주는 이진 검색 도구.
- 61. HEAD
- 62. $ git bisect start HEAD
- 63. $ git bisect start $ git bisect bad HEAD
- 64. $ git bisect start $ git bisect bad $ git bisect good f794027 f794027 HEAD
- 65. f794027 HEAD
- 66. $ git bisect good f794027 HEAD
- 67. f794027 HEAD
- 68. f794027 HEAD $ git bisect bad
- 69. f794027 HEAD
- 70. f794027 HEAD $ git bisect bad
- 71. f794027 HEAD $ git bisect bad
- 72. 그 외 • $ git bisect log • $ git bisect reset
- 73. 으.. 이것도 귀찮은데? • 완전 자동화! • 자동화 완전 좋아! (발표자는 자동화 덕후)
- 74. • $ git bisect start • # test_error.sh는 문제가 있을 경우 1을 반환. • $ git bisect run test_error.sh
- 75. $ git blame -L <start,end> -C blame sta bise workt Hunk 특정버 ali shall
- 76. blame • bisect로 버그 커밋을 찾았다면 • 이제 담당자를 찾아 격려(?)해 줄 차례 © 한빛미디어
- 77. $ git blame -L 10,11 effective_git.md
- 78. $ git blame -L 10,11 effective_git.md 파일의 시작 라인 번호 끝 라인 번호 경로
- 79. $ git blame -L 10,11 effective_git.md 파일의 시작 라인 번호 끝 라인 번호 경로 -C 파일명 변경 추적
- 80. $ git worktree add prune list worktree sta bla bise Hunk 특정버 ali shall
- 81. 작업 물 끼어들기 (데자뷰) • 다들 겪어봤을 일 • 기능 A를 작업 중인데, 기능 B를 지금 해 달라고요? © ABC
- 82. 작업 물 끼어들기 (데자뷰) • 다들 겪어봤을 일 • 기능 A를 작업 중인데, 기능 B를 지금 해 달라고요? • 근데 기능이 좀 커 © ABC
- 83. 다음 상황에 적절 • 작업 디렉토리를 통째로 바꿔야 하는 경우 • 브랜치를 바꿔야 한다거나, 브랜치를 바꿔야 한다거나… • stash할 순 있는데, untracked 파일도 꽤 있고… • 현재 작업 상태를 보존하고 싶을 경우
- 84. 다음 상황에 적절 • 작업 디렉토리를 통째로 바꿔야 하는 경우 • 브랜치를 바꿔야 한다거나, 브랜치를 바꿔야 한다거나… • stash할 순 있는데, untracked 파일도 꽤 있고… • 현재 작업 상태를 보존하고 싶을 경우 worktree는 여러 개의 작업 트리를 관리할 수 있게 해 줌
- 85. $ git worktree add –b emergency-fix ../temp master
- 86. $ git worktree add –b emergency-fix ../temp master 새로 만들 브랜치 새 worktree 경로 새 worktree가 chekcout할 브랜치
- 87. $ git worktree add –b emergency-fix ../temp master $ pushd ../temp # ... 새 작업 ... $ popd 경로로 이동해서 새 작업을 끝내고 다시 돌아온다
- 88. $ git worktree add –b emergency-fix ../temp master $ pushd ../temp # ... 새 작업 ... $ popd $ rm –rf ../temp $ git worktree prune Worktree를 정리
- 89. Hunk 단위로 작업 (‘-p’ 옵션 활용) $ git add –p $ git checkout –p $ git stash -p Hunk단위로 sta bla workt 특정버 ali bise shall
- 90. Atomic commit • “(나눌 수 없는)최소한의 단위Atomic”로 커밋 하자 • 다른 VCS에서도 권장하는 방식 • 이점 • 코드 리뷰 하기 쉽다 • 롤백 하기 쉽다
- 91. 이론과 현실 • 정말 항상 한 작업만 하나? • 가끔 실수 할 수 있다. • 작업하고 나서 바로 커밋하는 것을 깜빡 했다거나…
- 92. 이론과 현실 • 정말 항상 한 작업만 하나? • 가끔 실수 할 수 있다. • 작업하고 나서 바로 커밋하는 것을 깜빡 했다거나… • 이럴 때 유용한 “-p” 옵션.
- 93. •$ git add
- 94. •$ git add –p
- 95. •$ git add –p
- 96. •$ git add –p •$ git reset –p •$ git checkout –p •$ git rm -p
- 98. 특정 버전의 파일 가져오기 $ git checkout $ git show 툭정버전의 sta bla workt Hunk ali bise shall
- 99. checkout • 브랜치를 바꾸는 명령어 • 특정 버전의 트리로 업데이트 해 주는 명령어
- 100. $ git checkout master -- Readme.md Readme.md를 master 브랜치의 파일로 checkout
- 101. show • 1개 이상의 오브젝트(blob, tree, commit, …)를 보는 명령어
- 102. • $ git show fc1b357:Readme.md > master_Readme.md fc1b367 커밋의 Readme.md를 master_Readme.md로 출력
- 104. 나는 게으른 사람입니다 • 명령어 줄여 쓰기 • git status → git st • 다른 곳에서도 많이 쓰이는 개념 • 그 alias가 맞습니다.
- 107. git lg • 로그 그래프를 이쁘게 보여주는 alias [alias] lg = log --graph --abbrev-commit --decorate --date=relative --format=format:'%C(bold red)%h%C(reset) - %C(bold green)(%ar)%C(reset) %C(white)%s%C(reset) %C(cyan)<%an>%C(res et)%C(bold yellow)%d%C(reset)' --all
- 109. shallow clone $ git clone –depth $ git fetch --depth $ git fetch --unshallow sallowcl sta bla workt Hunk 특정버 ali bise
- 110. 마지막 N개 커밋만 필요할 때 • 배포 패키징, 리뷰, 빌드 머신 … • 근데 저장소가 넘나 클 때
- 111. $ git clone
- 112. $ git clone --depth 1
- 113. depth 변경 $ git fetch --depth <N>
- 114. Q. Push가 안 돼요
- 115. Q. Push가 안 돼요 $ git fetch --unshallow
- 116. 2. 로그 탐색하기 3. 실수 만회하기 git log 리비전 선택하기 git log -S 옮겨진 파일 찾기 git grep git rev-list 1. 생산성 높이기
- 118. 제일 간단 $ git log <sha1 hash>
- 119. git log 검색 기능 • ‘/’ 를 눌러서 검색 • n, N (search Next) 키로 검색 결과 탐색 • Vi 처럼 j, k로 위, 아래 탐색
- 121. 리비전 선택하기 ^, ~, .., ... 리비전선택 gitl 옮겨진 gitg gitr git
- 122. 특정 커밋이나 범위를 잡고 싶을 때? • 기계 라면? • d206ec8 부터 727372a가 보고 싶구나
- 123. 특정 커밋이나 범위를 잡고 싶을 때? • 기계 라면? • d206ec8 부터 727372a가 보고 싶구나 • 멍청한 나 • 음.. 전전전전 커밋 부터 전 커밋 까지가 보고 싶은데?
- 124. 특정 커밋이나 범위를 잡고 싶을 때? • 기계 라면? • d206ec8 부터 727372a가 보고 싶구나 • 멍청한 나 • 음.. 전전전전 커밋 부터 전 커밋 까지가 보고 싶은데?
- 125. ^ (Circumflex) •^n • n번째 부모 커밋을 가리킴 • n이 1일 경우 생략 가능 ( ^1 == ^ )
- 126. HEAD
- 128. HEAD HEAD^^
- 129. HEAD HEAD^^ (HEAD^)^
- 130. ~ (Tilde) • ~n은 n번 째 상위 커밋
- 131. HEAD
- 132. HEAD HEAD~ HEAD~1
- 135. .. (double dot) • 범위를 나타 냄 • start..end : end는 포함, start는 안 포함 하는 범위
- 137. HEAD~3..HEAD
- 138. 참 쉽죠?
- 139. B C D JIHGFE A develop..master의 범위를 구하시오 (3점) develop master
- 140. B C D JIHGFE A develop..master의 범위를 구하시오 (3점) develop master
- 141. .. (double dot) • 커밋의 범위를 나타 냄 • start..end : end는 포함, start는 안 포함 하는 범위
- 142. .. (double dot) • 커밋의 범위를 나타 냄 • start..end : end는 포함, start는 안 포함 하는 범위 end에는 도달할 수 있고, start에선 도달할 수 없는 범위 end – start 의 차집합
- 143. B C D JIHGFE A develop master develop..master master에는 도달할 수 있고, develop에선 도달할 수 없는 범위 master – develop 의 차집합
- 144. ... (Triple dot) • 공통으로 가지는 것을 제외하고 서로 다른 커밋의 범위 • 대칭차집합 A-B B-A $ git log A...B
- 148. git log –S<string> # pickaxe • 파일의 Diff 히스토리에서 문자열을 탐색 • 실제의 코드 블럭을 찾는데 용의 • -M 옵션을 곁들이면, rename까지도 탐색할 수 있음.
- 149. 옮겨진 파일 찾기 git log --follow 옮겨진파 gitg gitr git 리비전 gitl
- 150. 기억이 안 난다 • 파일명이 바뀐 것 까지는 기억이 나는데… • 바뀐게 뭐 였지?
- 151. 컴퓨터를 끈다
- 152. $ git log –follow -- filepath
- 154. $ git grep • 평소에 많이 쓰는 그 grep과 유사 • blob object 검색이라고 생각하면 쉽다. • 파일과 위치를 알 수 있음 • $ git grep blahblah • -- 구분 기호로 경로를 제한할 수 있음 • $ git grep blahblah -- Document
- 155. $ git grep hello # -- 구분 기호로 경로를 제한할 수 있음 $ git grep hello -- subdirectory
- 157. rev-list • commit object의 역순 리스트를 보는 명령 • 파일 경로와 같이 사용할 수 있다 • 파일 중심적인 로그를 볼 때 유용 • 파일의 변경을 추적하기 좋다
- 158. $ git rev-list master -- Readme.md
- 159. rev-list $ git rev-list master -- Readme.md 727372ac234645eeb891272b3fc73c940ea5f52f c38dc4e678d40dd48072489fda6b8f933cdea0c2 1064cea4cfbf8bd94dff3cc3175d5de2ff5c110c 19424a1bff2223c25905c2e732a857911a0d7c54 189952e05d7cc97a7e408480d00c39c8ab754489
- 160. rev-list $ git rev-list –n 1 master -- Readme.md 727372ac234645eeb891272b3fc73c940ea5f52f
- 161. 3. 실수 만회하기 1. 생산성 높이기 2. 로그 탐색하기 git reflog git fsck
- 162. Reflog gitreflo gitf
- 163. History log를 망쳤을 때 • 머지를 잘못 했다거나 • 커밋을 실수로 덮어 쓰거나 • ( $ git commit –amend ) • 뭘 했는진 모르겠지만, 그래프를 보니 도망가고 싶을 때 © 이말년
- 164. Commit object는 불변 • $ git commit --amend • 사실 새 커밋을 만드는 것. (sha1 hash 값이 다르다)
- 165. B C DA
- 166. B C DA $ git commit --amend D`
- 167. $ git commit --amend B C DA D` 기존 커밋은 dangling commit이 되어서 보이지 않는 것 GC가 돌기 전까지 살아 있다
- 168. 아직 Push를 안 했다면 희망이 있다 • Reflog엔 사용한 명령어들이 기록이 됨
- 169. 아직 Push를 안 했다면 희망이 있다 • Reflog엔 사용한 명령어들이 기록이 됨 잦은 push –f 는 권장하지 않는 행동입니다.
- 170. 1. 자신이 일을 저지른(?) 커밋을 찾는다 2. hash 나 HEAD@{1} 같은 ref로 HEAD를 리셋해 준다 $ git reset HEAD@{2} 복원
- 171. 참 쉽죠?
- 172. fsck gitfsck gitr
- 173. dangling commit • 지정된 ref가 없어서 도달할 수 없는 커밋 B C DA D` HEAD
- 174. dangling commit 찾기 $ git fsck
- 179. 참고 • https://git-scm.com/doc • http://danielkummer.github.io/git-flow-cheatsheet/index.html • https://www.sourcetreeapp.com/ • https://www.gitkraken.com/ • https://about.gitlab.com/