Más contenido relacionado La actualidad más candente (20) Similar a [NDC16] Effective Git (20) [NDC16] Effective Git3. 김찬웅
• 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
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 쓰지 않을래?
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. 실수 만회하기
16. Git-flow 브랜칭 전략
• Vincent Driessen이 제안
• 목적에 따라 브랜치를 분리하는 모델
• master branch: 배포 버전
• develop branch: 개발 버전
• 배포와 연관 지었을 때 강력한 힘을 발휘
• Git-flow를 설치해서 쓰면, 브랜치 삭제/병합을 쉽게 해 줌
30. 장점
• 가독성 향상
• feature → develop 머지 커밋 == 새로운 기능이 있구나
• 작업 내용은 feature branch로 격리되어 다른 코드와 섞이지 않음
• 효율 향상
• 브랜치의 역할이 정해져 있기 때문에 Hook등을 걸기 쉬움
• hotfix 작업시 실수 방지
35. 장점
• 머지 그래프가 예쁘게 유지
• 작업 도중에 최신 내용을 가져 와 머지하는 순간 무지개에 가까워 짐..
• 충돌 발생시 기능 작업자가 인지, 처리 가능
• 코드 리뷰 향상
• 긴 기능의 작업을 피하게 됨
• 오래 된 기능 브랜치 일수록 충돌 날 확률이 올라감
• 개별 기능은 짧게 쪼개어 작업하는 원칙에도 OK
36. 왓 스튜디오에서는
• Git-flow
• release 브랜치에 Hook을 활용
• 커밋이 올라오면 자동 빌드, 테스트, 배포
• Forward-porting
• 로그 그래프로 작업된 기능을 한 눈에 파악 가능
• 머지 했을 때, 타인의 코드에 트롤링(?)할 여지 방지
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
64. $ git bisect start
$ git bisect bad
$ git bisect good f794027
f794027
HEAD
72. 그 외
• $ git bisect log
• $ git bisect reset
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
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는 여러 개의 작업 트리를 관리할 수 있게 해 줌
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” 옵션.
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
100. $ git checkout master -- Readme.md
Readme.md를 master 브랜치의 파일로 checkout
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개 커밋만 필요할 때
• 배포 패키징, 리뷰, 빌드 머신 …
• 근데 저장소가 넘나 클 때
116. 2. 로그 탐색하기
3. 실수 만회하기
git log
리비전 선택하기
git log -S
옮겨진 파일 찾기
git grep
git rev-list
1. 생산성 높이기
119. git log 검색 기능
• ‘/’ 를 눌러서 검색
• n, N (search Next) 키로
검색 결과 탐색
• Vi 처럼 j, k로 위, 아래 탐색
122. 특정 커밋이나 범위를 잡고 싶을 때?
• 기계 라면?
• d206ec8 부터 727372a가 보고 싶구나
123. 특정 커밋이나 범위를 잡고 싶을 때?
• 기계 라면?
• d206ec8 부터 727372a가 보고 싶구나
• 멍청한 나
• 음.. 전전전전 커밋 부터 전 커밋 까지가 보고 싶은데?
124. 특정 커밋이나 범위를 잡고 싶을 때?
• 기계 라면?
• d206ec8 부터 727372a가 보고 싶구나
• 멍청한 나
• 음.. 전전전전 커밋 부터 전 커밋 까지가 보고 싶은데?
142. .. (double dot)
• 커밋의 범위를 나타 냄
• start..end : end는 포함, start는 안 포함 하는 범위
end에는 도달할 수 있고, start에선 도달할 수 없는 범위
end – start 의 차집합
148. git log –S<string> # pickaxe
• 파일의 Diff 히스토리에서 문자열을 탐색
• 실제의 코드 블럭을 찾는데 용의
• -M 옵션을 곁들이면, rename까지도 탐색할 수 있음.
150. 기억이 안 난다
• 파일명이 바뀐 것 까지는 기억이 나는데…
• 바뀐게 뭐 였지?
154. $ git grep
• 평소에 많이 쓰는 그 grep과 유사
• blob object 검색이라고 생각하면 쉽다.
• 파일과 위치를 알 수 있음
• $ git grep blahblah
• -- 구분 기호로 경로를 제한할 수 있음
• $ git grep blahblah -- Document
155. $ git grep hello
# -- 구분 기호로 경로를 제한할 수 있음
$ git grep hello -- subdirectory
159. rev-list
$ git rev-list master -- Readme.md
727372ac234645eeb891272b3fc73c940ea5f52f
c38dc4e678d40dd48072489fda6b8f933cdea0c2
1064cea4cfbf8bd94dff3cc3175d5de2ff5c110c
19424a1bff2223c25905c2e732a857911a0d7c54
189952e05d7cc97a7e408480d00c39c8ab754489
163. History log를 망쳤을 때
• 머지를 잘못 했다거나
• 커밋을 실수로 덮어 쓰거나
• ( $ git commit –amend )
• 뭘 했는진 모르겠지만, 그래프를 보니 도망가고 싶을 때
© 이말년
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}
복원