Effective Git
넥슨 코리아 왓 스튜디오
김찬웅

소개

김찬웅
• 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

발표 동기

Git 초심자들을 관찰
• 이전에 사용하던 VCS의 개념대로 사용
• 이전 VCS와 대칭되는 명령어만 사용
• svn checkout → git clone
• svn update → git pull
• svn commit → git commit

• 나쁘다는 것이 아님
• 발표자도 같은 시행착오를 겪음
• Git의 좋은 점을 영업하고 싶다!
© http://d.hatena.ne.jp/gu_he_he/20120322/1332419643
나랑 Git 쓰지 않을래?

발표의 대상
Git 숙련도
초심자
push, commit 정도의 기본적인 명령어 숙지
중급자
고급 명령어와
동작 원리 파악
여기 쯤

이런 분들에겐 조금 어려울 수 있습니다
• git을 command line으로 쓰지 않는 분
• GUI 툴을 주로 이용
• Staging area 를 아직 모르시는 분

하지 않을 이야기
• 흔한 Git 입문서
• 태초에 Git이 있었고, Git은 분산 버전 관리 시스템이며 …
• Git 내부 구조
• blob, tree object, commit object, …
• 이건 다음에 기회가 된다면…

오늘 할 이야기
• Git 사용 전략
• Rebase
• 바로 써먹을 수 있는 16가지 기능 소개
• 3가지 파트로 나누어서 설명
• 유용할 도구 소개

오늘 할 이야기
• Git 사용 전략
• Rebase
• 바로 써먹을 수 있는 16가지 기능 소개
• 3가지 파트로 나누어서 설명
• 유용할 도구 소개
1. 생산성 높이기
2. 로그 탐색하기
3. 실수 만회하기

Git 사용 전략
git flow
Forward-porting

Branching, Merge가 정말 쉽고 빠르다
쉽다 == 남용 하기 쉽다

Git-flow
gitflow
Forwa

Git-flow 브랜칭 전략
• Vincent Driessen이 제안
• 목적에 따라 브랜치를 분리하는 모델
• master branch: 배포 버전
• develop branch: 개발 버전
• 배포와 연관 지었을 때 강력한 힘을 발휘
• Git-flow를 설치해서 쓰면, 브랜치 삭제/병합을 쉽게 해 줌

새 기능 개발
develop

새 기능 개발
develop
feature/awesome
$ git flow feature start awesome
$ git commit -a
$ git commit -a
$ git commit -a

새 기능 개발
develop
feature/awesome
$ git flow finish awesome

새 배포
develop

새 배포
develop
release/v1.0.0
$ git flow release start v1.0.0
$ git commit -a
$ git commit -a
$ git commit -a

새 배포
develop
$ git flow release finish v1.0.0
master
tag v1.0.0

핫 픽스
master
tag v1.0.0

핫 픽스
master
hotfix/fix1
$ git flow hotfix start fix1
$ git commit -a
$ git commit -a
$ git commit -a

핫 픽스
master
$ git flow hotfix finish fix1
develop
tag fix1
hotfix/fix1

큰 그림
develop
feature/awesome
release/v1.0.0
master
feature
release
hotfix
tag v1.0.0
hotfix/fix1
tag fix1

큰 그림
develop
feature/awesome
release/v1.0.0
master
feature
release
hotfix
tag v1.0.0
hotfix/fix1
tag fix1

큰 그림
develop
feature/awesome
release/v1.0.0
master
feature
release
hotfix
tag v1.0.0
hotfix/fix1
tag fix1

큰 그림
develop
feature/awesome
release/v1.0.0
master
feature
release
hotfix
tag v1.0.0
hotfix/fix1
tag fix1

장점
• 가독성 향상
• feature → develop 머지 커밋 == 새로운 기능이 있구나
• 작업 내용은 feature branch로 격리되어 다른 코드와 섞이지 않음
• 효율 향상
• 브랜치의 역할이 정해져 있기 때문에 Hook등을 걸기 쉬움
• hotfix 작업시 실수 방지

Forward-porting
Forward-p
gitf

feature/blahblah
master
Forward-porting

feature/blahblah
$ git pull --rebase origin/master
origin/master
Forward-porting
master

feature/b
origin/master
Forward-porting $ git pull --rebase origin/master
master

장점
• 머지 그래프가 예쁘게 유지
• 작업 도중에 최신 내용을 가져 와 머지하는 순간 무지개에 가까워 짐..
• 충돌 발생시 기능 작업자가 인지, 처리 가능
• 코드 리뷰 향상
• 긴 기능의 작업을 피하게 됨
• 오래 된 기능 브랜치 일수록 충돌 날 확률이 올라감
• 개별 기능은 짧게 쪼개어 작업하는 원칙에도 OK

왓 스튜디오에서는
• Git-flow
• release 브랜치에 Hook을 활용
• 커밋이 올라오면 자동 빌드, 테스트, 배포
• Forward-porting
• 로그 그래프로 작업된 기능을 한 눈에 파악 가능
• 머지 했을 때, 타인의 코드에 트롤링(?)할 여지 방지

Rebase
rebase 동작 원리
로그 정제하기

rebase 동작 원리
rebase동
로그정

Rebase
• Base를 재정의(Re-)하는 기능
• Forward-porting도 Rebase를 이용한 방법
• Rebase를 통해 base를 최신 커밋 으로 지정하는 전략

B C D
feature/abc
E FA
develop
HEAD

B C D
feature/abc
E FA
develop
$ git checkout feature/abc
$ git rebase develop
HEAD

B C D
feature/abc
E FA
develop
공통 조상을 찾음
HEAD

B C D
feature/abc
E FA
develop
내부적으로 각 커밋마다 패치를 만들어 둠
HEAD
B C D

B` C` D`
feature/abc
E FA
develop
대상 브랜치에 적용
HEAD
B C D
B C D

로그 정제하기
로그정제하
reba

나누고 붙이고 섞고 지우고
$ git rebase –i [<커밋 범위>]

나누고 붙이고 섞고 지우고
$ git rebase –i [<커밋 범위>]

Rebase를 통해 코드를 원격 저장소에 올리기 전에,
커밋을 깔끔하게 정제할 수 있다.

16가지 기능 소개
1. 생산성 높이기
2. 로그 탐색하기
3. 실수 만회하기

1. 생산성 높이기
stash
bisect
blame
worktree
Hunk 단위 작업하기
특정 버전의 파일 가져오기
alias
shallow clone
2. 로그 탐색하기
3. 실수 만회하기

$ git stash save
Pop
Apply
List
drop
stash
bise
bla
workt
Hunk
특정버
ali
shall

작업 물 끼어들기
• 다들 겪어봤을 일
• 기능 A를 작업 중인데, 기능 B를 지금 해 달라고요?
© ABC

stash는 현재 작업 디렉토리에 있는 작업 물을
stash stack에 쌓아 줍니다.
WIP
WIP
stash
Working Directory
git stash save
git stash pop

보통은
• 현재 작업 물을 백업 혹은 격리
• 새로운 작업을 마친 후
• 이전 작업 물을 되돌림

git stash
• 현재 작업 물을 백업 혹은 격리
• $ git stash save
• 새로운 작업을 마친 후
• 이전 작업 물을 되돌림
• $ git stash pop

수동 관리도 가능
• $ git stash list
• $ git stash apply [<stash>]
• $ git stash drop [<stash>]

$ git bisect start
good
bad
log
reset
bisect
sta
bla
workt
Hunk
특정버
ali
shall

어?
• 어느 순간 코드가 실패한다.
• 어디지?
• 뭐가 문제지?
• 너무 작업이 많이 쌓여서 감이 안 오는데?
간담이 서늘해 진다
© http://ff663.blogspot.kr/2010/05/201058-
in-english-i-feel-complete.html

bisect는 버그를 가진 커밋을 찾는데
도움을 주는 이진 검색 도구.

HEAD

$ git bisect start
HEAD

$ git bisect start
$ git bisect bad
HEAD

$ git bisect start
$ git bisect bad
$ git bisect good f794027
f794027
HEAD

f794027
HEAD

$ git bisect good
f794027
HEAD

f794027
HEAD

f794027
HEAD
$ git bisect bad

f794027
HEAD

f794027
HEAD
$ git bisect bad

f794027
HEAD
$ git bisect bad

그 외
• $ git bisect log
• $ git bisect reset

으.. 이것도 귀찮은데?
• 완전 자동화!
• 자동화 완전 좋아! (발표자는 자동화 덕후)

• $ git bisect start
• # test_error.sh는 문제가 있을 경우 1을 반환.
• $ git bisect run test_error.sh

$ git blame
-L <start,end>
-C
blame
sta
bise
workt
Hunk
특정버
ali
shall

blame
• bisect로 버그 커밋을 찾았다면
• 이제 담당자를 찾아 격려(?)해 줄 차례
© 한빛미디어

$ git blame -L 10,11 effective_git.md

$ git blame -L 10,11 effective_git.md
파일의 시작 라인 번호
끝 라인 번호
경로

$ git blame -L 10,11 effective_git.md
파일의 시작 라인 번호
끝 라인 번호
경로
-C
파일명 변경 추적

$ git worktree add
prune
list
worktree
sta
bla
bise
Hunk
특정버
ali
shall

작업 물 끼어들기 (데자뷰)
• 다들 겪어봤을 일
• 기능 A를 작업 중인데, 기능 B를 지금 해 달라고요?
© ABC

작업 물 끼어들기 (데자뷰)
• 다들 겪어봤을 일
• 기능 A를 작업 중인데, 기능 B를 지금 해 달라고요?
• 근데 기능이 좀 커
© ABC

다음 상황에 적절
• 작업 디렉토리를 통째로 바꿔야 하는 경우
• 브랜치를 바꿔야 한다거나, 브랜치를 바꿔야 한다거나…
• stash할 순 있는데, untracked 파일도 꽤 있고…
• 현재 작업 상태를 보존하고 싶을 경우

다음 상황에 적절
• 작업 디렉토리를 통째로 바꿔야 하는 경우
• 브랜치를 바꿔야 한다거나, 브랜치를 바꿔야 한다거나…
• stash할 순 있는데, untracked 파일도 꽤 있고…
• 현재 작업 상태를 보존하고 싶을 경우
worktree는 여러 개의 작업 트리를 관리할 수 있게 해 줌

$ git worktree add –b emergency-fix ../temp master

$ git worktree add –b emergency-fix ../temp master
새로 만들 브랜치
새 worktree 경로
새 worktree가 chekcout할 브랜치

$ git worktree add –b emergency-fix ../temp master
$ pushd ../temp
# ... 새 작업 ...
$ popd
경로로 이동해서
새 작업을 끝내고
다시 돌아온다

$ git worktree add –b emergency-fix ../temp master
$ pushd ../temp
# ... 새 작업 ...
$ popd
$ rm –rf ../temp
$ git worktree prune
Worktree를 정리

Hunk 단위로 작업 (‘-p’ 옵션 활용)
$ git add –p
$ git checkout –p
$ git stash -p
Hunk단위로
sta
bla
workt
특정버
ali
bise
shall

Atomic commit
• “(나눌 수 없는)최소한의 단위Atomic”로 커밋 하자
• 다른 VCS에서도 권장하는 방식
• 이점
• 코드 리뷰 하기 쉽다
• 롤백 하기 쉽다

이론과 현실
• 정말 항상 한 작업만 하나?
• 가끔 실수 할 수 있다.
• 작업하고 나서 바로 커밋하는 것을 깜빡 했다거나…

이론과 현실
• 정말 항상 한 작업만 하나?
• 가끔 실수 할 수 있다.
• 작업하고 나서 바로 커밋하는 것을 깜빡 했다거나…
• 이럴 때 유용한 “-p” 옵션.

•$ git add

•$ git add –p

•$ git add –p

•$ git add –p
•$ git reset –p
•$ git checkout –p
•$ git rm -p

특정 버전의 파일 가져오기
$ git checkout
$ git show
툭정버전의
sta
bla
workt
Hunk
ali
bise
shall

checkout
• 브랜치를 바꾸는 명령어
• 특정 버전의 트리로 업데이트 해 주는 명령어

$ git checkout master -- Readme.md
Readme.md를 master 브랜치의 파일로 checkout

show
• 1개 이상의 오브젝트(blob, tree, commit, …)를 보는 명령어

• $ git show fc1b357:Readme.md > master_Readme.md
fc1b367 커밋의 Readme.md를 master_Readme.md로 출력

alias
alias
sta
bla
workt
Hunk
특정버
bise
shall

나는 게으른 사람입니다
• 명령어 줄여 쓰기
• git status → git st
• 다른 곳에서도 많이 쓰이는 개념
• 그 alias가 맞습니다.

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

shallow clone
$ git clone –depth
$ git fetch --depth
$ git fetch --unshallow
sallowcl
sta
bla
workt
Hunk
특정버
ali
bise

마지막 N개 커밋만 필요할 때
• 배포 패키징, 리뷰, 빌드 머신 …
• 근데 저장소가 넘나 클 때

$ git clone

$ git clone --depth 1

depth 변경
$ git fetch --depth <N>

Q. Push가 안 돼요

Q. Push가 안 돼요
$ git fetch --unshallow

2. 로그 탐색하기
3. 실수 만회하기
git log
리비전 선택하기
git log -S
옮겨진 파일 찾기
git grep
git rev-list
1. 생산성 높이기

git log
gitlog
리비전
gitl
옮겨진
gitg
gitr

제일 간단
$ git log <sha1 hash>

git log 검색 기능
• ‘/’ 를 눌러서 검색
• n, N (search Next) 키로
검색 결과 탐색
• Vi 처럼 j, k로 위, 아래 탐색

리비전 선택하기
^, ~, .., ...
리비전선택
gitl
옮겨진
gitg
gitr
git

특정 커밋이나 범위를 잡고 싶을 때?
• 기계 라면?
• d206ec8 부터 727372a가 보고 싶구나

특정 커밋이나 범위를 잡고 싶을 때?
• 기계 라면?
• d206ec8 부터 727372a가 보고 싶구나
• 멍청한 나
• 음.. 전전전전 커밋 부터 전 커밋 까지가 보고 싶은데?

특정 커밋이나 범위를 잡고 싶을 때?
• 기계 라면?
• d206ec8 부터 727372a가 보고 싶구나
• 멍청한 나
• 음.. 전전전전 커밋 부터 전 커밋 까지가 보고 싶은데?

^ (Circumflex)
•^n
• n번째 부모 커밋을 가리킴
• n이 1일 경우 생략 가능 ( ^1 == ^ )

HEAD

HEAD
HEAD^
HEAD^1
HEAD^2

HEAD
HEAD^^

HEAD
HEAD^^
(HEAD^)^

~ (Tilde)
• ~n은 n번 째 상위 커밋

HEAD

HEAD
HEAD~
HEAD~1

HEAD
HEAD~
HEAD~1HEAD~2

HEAD
HEAD~
HEAD~1HEAD~2
HEAD~3

.. (double dot)
• 범위를 나타 냄
• start..end : end는 포함, start는 안 포함 하는 범위

HEAD~3..HEAD

참 쉽죠?

B C D
JIHGFE
A
develop..master의 범위를 구하시오 (3점)
develop
master

B C D
JIHGFE
A
develop..master의 범위를 구하시오 (3점)
develop
master

.. (double dot)
• 커밋의 범위를 나타 냄
• start..end : end는 포함, start는 안 포함 하는 범위

.. (double dot)
• 커밋의 범위를 나타 냄
• start..end : end는 포함, start는 안 포함 하는 범위
end에는 도달할 수 있고, start에선 도달할 수 없는 범위
end – start 의 차집합

B C D
JIHGFE
A
develop
master
develop..master
master에는 도달할 수 있고, develop에선 도달할 수 없는 범위
master – develop 의 차집합

... (Triple dot)
• 공통으로 가지는 것을 제외하고 서로 다른 커밋의 범위
• 대칭차집합
A-B B-A
$ git log A...B

B C D
JIHGFE
A
develop
master
develop...master

B C D
JIHGFE
A
develop
master
develop...master

git log –S<string>
gitlog-
옮겨진
gitg
gitr
git
리비전

git log –S<string> # pickaxe
• 파일의 Diff 히스토리에서 문자열을 탐색
• 실제의 코드 블럭을 찾는데 용의
• -M 옵션을 곁들이면, rename까지도 탐색할 수 있음.

옮겨진 파일 찾기
git log --follow
옮겨진파
gitg
gitr
git
리비전
gitl

기억이 안 난다
• 파일명이 바뀐 것 까지는 기억이 나는데…
• 바뀐게 뭐 였지?

컴퓨터를 끈다

$ git log –follow -- filepath

$ git grep
gitgrep
gitr
git
리비전
gitl
옮겨진

$ git grep
• 평소에 많이 쓰는 그 grep과 유사
• blob object 검색이라고 생각하면 쉽다.
• 파일과 위치를 알 수 있음
• $ git grep blahblah
• -- 구분 기호로 경로를 제한할 수 있음
• $ git grep blahblah -- Document

$ git grep hello
# -- 구분 기호로 경로를 제한할 수 있음
$ git grep hello -- subdirectory

$ git rev-list
gitrev-l
git
리비전
gitl
옮겨진
gitg

rev-list
• commit object의 역순 리스트를 보는 명령
• 파일 경로와 같이 사용할 수 있다
• 파일 중심적인 로그를 볼 때 유용
• 파일의 변경을 추적하기 좋다

$ git rev-list master -- Readme.md

rev-list
$ git rev-list master -- Readme.md
727372ac234645eeb891272b3fc73c940ea5f52f
c38dc4e678d40dd48072489fda6b8f933cdea0c2
1064cea4cfbf8bd94dff3cc3175d5de2ff5c110c
19424a1bff2223c25905c2e732a857911a0d7c54
189952e05d7cc97a7e408480d00c39c8ab754489

rev-list
$ git rev-list –n 1 master -- Readme.md
727372ac234645eeb891272b3fc73c940ea5f52f

3. 실수 만회하기
1. 생산성 높이기
2. 로그 탐색하기
git reflog
git fsck

Reflog
gitreflo
gitf

History log를 망쳤을 때
• 머지를 잘못 했다거나
• 커밋을 실수로 덮어 쓰거나
• ( $ git commit –amend )
• 뭘 했는진 모르겠지만, 그래프를 보니 도망가고 싶을 때
© 이말년

Commit object는 불변
• $ git commit --amend
• 사실 새 커밋을 만드는 것. (sha1 hash 값이 다르다)

B C DA

B C DA
$ git commit --amend
D`

$ git commit --amend
B C DA
D`
기존 커밋은 dangling commit이 되어서 보이지 않는 것
GC가 돌기 전까지 살아 있다

아직 Push를 안 했다면 희망이 있다
• Reflog엔 사용한 명령어들이 기록이 됨

아직 Push를 안 했다면 희망이 있다
• Reflog엔 사용한 명령어들이 기록이 됨
잦은 push –f 는 권장하지 않는 행동입니다.

1. 자신이 일을 저지른(?) 커밋을 찾는다
2. hash 나 HEAD@{1} 같은 ref로 HEAD를 리셋해 준다
$ git reset HEAD@{2}
복원

참 쉽죠?

fsck
gitfsck
gitr

dangling commit
• 지정된 ref가 없어서 도달할 수 없는 커밋
B C DA
D`
HEAD

dangling commit 찾기
$ git fsck

도구 소개
Gitlab
Sourcetree
Git kraken

참고
• 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/

감사합니다.
cwkim@nexon.co.kr