Pro Git Scott Chacon * 2012-04-09 * 지금 보시는 문서는 Pro Git 책에 대한 PDF 파일입니다. 본 문서는 Creative Commons 저작자표 시-비영리조건-동일조건변경허락 3.0(Creative Commons Attribution-Non Commercial-Share Alike 3.0) 라이센스를 따릅니다. 여러분이 Git을 이해하는데 도움이 되기를 희망합니다. 종이로 출판된 책을 Amazon 웹사이트 http://tinyurl.com/amazonprogit 에서 구입하여 저를 비롯한 Apress에도 도움을 주 시기를 기대하겠습니다. 한국어 번역은 박창우(pismute@gmail.com), 이성환(lethee@gmail.com)이 하였습니다. 오역 등의 개선 사항은 역자의 메일로 보내주시거나 한국어 번역 게시판에 https://github.com/dogfeet/progit/issues 남겨주시기 바랍니다. 직접 개선해서 패치나 Pull Request를 보내주셔도 됩니다.

목차 1 시작하기 1 1.1 버전 관리란?.................................... 1 1.1.1 로컬 버전 관리 시스템........................... 1 1.1.2 중앙집중식 버전 관리 시스템 (Centralized VCS)............. 2 1.1.3 분산형 버전 관리 시스템(Distributed VCS)................ 3 1.2 짧게 보는 Git의 역사................................ 3 1.3 Git 기초....................................... 4 1.3.1 차이점이 아니라 Snapshot......................... 4 1.3.2 거의 모든 명령을 로컬에서 실행...................... 5 1.3.3 Git의 무결성................................ 5 1.3.4 Git은 데이터를 추가할 뿐......................... 5 1.3.5 세 가지 상태................................. 6 1.4 Git 설치....................................... 7 1.4.1 소스코드로 설치하기............................ 7 1.4.2 리눅스에 설치................................ 7 1.4.3 Mac에 설치하기.............................. 8 1.4.4 윈도우에 설치................................ 8 1.5 Git 최초 설정.................................... 8 1.5.1 사용자 정보................................. 9 1.5.2 편집기.................................... 9 1.5.3 Diff 도구.................................. 9 1.5.4 설정 확인.................................. 10 1.6 도움말 보기..................................... 10 1.7 요약......................................... 10 2 Git의 기초 11 2.1 Git 저장소 만들기.................................. 11 2.1.1 이미 있는 디렉토리에서 새 저장소 만들기................. 11 2.1.2 이미 있는 저장소를 Clone하기....................... 12 2.2 수정하고 저장소에 저장하기............................ 12 2.2.1 파일의 상태 확인하기............................ 13 2.2.2 새 파일을 추적하기............................. 13 2.2.3 Modified 상태의 파일을 Stage하기.................... 14 2.2.4 파일 무시하기................................ 16 2.2.5 Staged와 Unstaged 상태의 변경 내용을 보기............... 16 2.2.6 변경사항 커밋하기............................. 19 iii

2.2.7 Staging Area 생략하기........................... 20 2.2.8 파일을 삭제하기.............................. 20 2.2.9 파일 이름 변경하기............................. 22 2.3 커밋 히스토리 조회하기............................... 22 2.3.1 조회 제한조건................................ 26 2.3.2 GUI 도구를 사용하여 히스토리를 시각화하기............... 27 2.4 되돌리기(Undo)................................... 27 2.4.1 커밋 수정하기................................ 28 2.4.2 파일 상태를 Unstage로 변경하기...................... 28 2.4.3 Modified 파일 되돌리기.......................... 29 2.5 리모트 저장소.................................... 30 2.5.1 리모트 저장소 확인하기.......................... 30 2.5.2 리모트 저장소 추가하기.......................... 31 2.5.3 리모트 저장소를 Pull 하거나 Fetch 하기.................. 32 2.5.4 리모트 저장소에 Push하기......................... 32 2.5.5 리모트 저장소 살펴보기.......................... 32 2.5.6 리모트 저장소 이름을 바꾸거나 리모트 저장소를 삭제하기........ 33 2.6 Tag(Tag)....................................... 34 2.6.1 Tag 조회하기................................ 34 2.6.2 Tag 붙이기................................. 34 2.6.3 Annotated Tag............................... 35 2.6.4 Tag에 서명하기............................... 35 2.6.5 Lightweight Tag.............................. 36 2.6.6 Tag 검증하기................................ 37 2.6.7 나중에 Tag하기............................... 37 2.6.8 Tag 공유하기................................ 38 2.7 팁과 트릭...................................... 39 2.7.1 자동완성................................... 39 2.7.2 Git Alias.................................. 40 2.8 요약......................................... 41 3 Git 브랜치 43 3.1 브랜치란 무엇인가?................................. 43 3.2 브랜치와 Merge의 기초............................... 47 3.2.1 브랜치의 기초................................ 48 3.2.2 Merge의 기초................................ 51 3.2.3 충돌(Conflict)의 기초........................... 52 3.3 브랜치 관리..................................... 54 3.4 브랜치 Workflow.................................. 55 3.4.1 긴 호흡(Long-Running) 브랜치...................... 55 3.4.2 토픽 브랜치................................. 56 3.5 리모트 브랜치.................................... 57 3.5.1 Push하기.................................. 60 3.5.2 브랜치 추적(Tracking)........................... 61 3.5.3 리모트 브랜치 삭제............................. 62 3.6 Rebase하기..................................... 62 iv

3.6.1 Rebase의 기초............................... 62 3.6.2 Rebase질.................................. 64 3.6.3 Rebase의 위험성.............................. 66 3.7 요약......................................... 68 4 Git 서버 69 4.1 프로토콜....................................... 69 4.1.1 로컬 프로토콜................................ 69 장점..................................... 70 단점..................................... 70 4.1.2 SSH 프로토콜................................ 71 장점..................................... 71 단점..................................... 71 4.1.3 Git 프로토콜................................ 71 장점..................................... 72 단점..................................... 72 4.1.4 HTTP/S 프로토콜............................. 72 장점..................................... 73 단점..................................... 73 4.2 서버에 Git 설치하기................................ 73 4.2.1 서버에 Bare 저장소 넣기.......................... 74 4.2.2 초 간단 뚝딱................................. 74 SSH 접근.................................. 74 4.3 SSH 공개키 만들기................................. 75 4.4 서버 설정하기.................................... 76 4.5 공개하기....................................... 78 4.6 GitWeb....................................... 79 4.7 Gitosis........................................ 81 4.8 Gitolite....................................... 85 4.8.1 설치하기................................... 85 4.8.2 자신에게 맞게 설치하기.......................... 86 4.8.3 설정 파일과 접근제어 규칙......................... 87 4.8.4 deny 규칙을 꼼꼼하게 제어하기..................... 88 4.8.5 파일 단위로 Push를 제어하기....................... 89 4.8.6 Personal 브랜치............................... 89 4.8.7 와일드카드 저장소............................ 89 4.8.8 그 밖의 기능들............................... 89 4.9 Git 데몬....................................... 90 4.10 Hosted Git..................................... 92 4.10.1 GitHub................................... 93 4.10.2 계정 설정하기................................ 93 4.10.3 저장소 만들기................................ 94 4.10.4 Subversion으로부터 코드 가져오기(Import)............... 95 4.10.5 동료 추가하기................................ 96 4.10.6 내 프로젝트................................. 96 4.10.7 프로젝트 Fork............................... 97 v

4.10.8 GitHub 요약................................ 98 4.11 요약......................................... 98 5 분산 환경에서의 Git 99 5.1 분산 환경에서의 Workflow............................. 99 5.1.1 중앙집중식 Workflow........................... 99 5.1.2 Integration-Manager Workflow..................... 100 5.1.3 Dictator and Lieutenants Workflow................... 101 5.2 프로젝트에 기여하기................................ 102 5.2.1 커밋 가이드라인.............................. 102 5.2.2 비공개 소규모 팀.............................. 103 5.2.3 비공개 대규모 팀.............................. 108 5.2.4 공개 소규모 팀............................... 112 5.2.5 대규모 공개 프로젝트............................ 116 5.2.6 요약..................................... 118 5.3 프로젝트 운영하기................................. 119 5.3.1 토픽 브랜치 작업.............................. 119 5.3.2 이메일로 받은 Patch를 적용하기...................... 119 apply 명령을 사용하는 방법........................ 119 am 명령을 사용하는 방법......................... 120 5.3.3 리모트 브랜치로부터 통합하기....................... 122 5.3.4 기여한 사항 확인하기............................ 123 5.3.5 기여물 통합하기.............................. 124 Merge Workflow.............................. 124 대규모 Merge Workflow.......................... 126 Rebase와 Cherry-Pick Workflow..................... 127 5.3.6 Release 버전에 Tag 달기.......................... 128 5.3.7 빌드넘버 만들기.............................. 129 5.3.8 Release 준비하기.............................. 130 5.3.9 Shortlog 보기................................ 130 5.4 요약......................................... 131 6 Git 도구 133 6.1 리비전 조회하기................................... 133 6.1.1 리비전 하나 가리키기............................ 133 6.1.2 SHA-1 줄여 쓰기.............................. 133 6.1.3 SHA-1 해시 값에 대한 단상........................ 134 6.1.4 브랜치로 가리키기............................. 135 6.1.5 RefLog로 가리키기............................. 135 6.1.6 계통 관계로 가리키기............................ 136 6.1.7 범위로 커밋 가리키기............................ 138 Double Dot................................. 138 세 개 이상의 레퍼런스........................... 139 Triple Dot.................................. 139 6.2 대화형 명령어.................................... 140 6.2.1 Staging Area에 파일 추가하고 추가 취소하기............... 140 vi

6.2.2 파일의 일부분만 Staging Area에 추가하기................ 142 6.3 Stashing....................................... 143 6.3.1 하던 일을 Stash하기............................ 144 6.3.2 Stash 되돌리기............................... 146 6.3.3 Stash를 적용한 브랜치 만들기....................... 146 6.4 히스토리 단장하기................................. 147 6.4.1 마지막 커밋을 수정하기.......................... 147 6.4.2 커밋 메시지를 여러 개 수정하기...................... 147 6.4.3 커밋 순서 바꾸기.............................. 149 6.4.4 커밋 합치기................................. 149 6.4.5 커밋 분리하기................................ 150 6.4.6 filter-branch는 포크레인.......................... 151 모든 커밋에서 파일을 제거하기...................... 151 하위 디렉토리를 루트 디렉토리로 만들기................. 152 모든 커밋의 이메일 주소를 수정하기................... 152 6.5 Git으로 버그 찾기.................................. 152 6.5.1 파일 어노테이션.............................. 153 6.5.2 이진 탐색.................................. 154 6.6 서브모듈....................................... 155 6.6.1 서브모듈 시작하기............................. 156 6.6.2 서브모듈이 있는 프로젝트 Clone하기................... 157 6.6.3 슈퍼프로젝트................................ 159 6.6.4 서브모듈 사용할 때 주의할 점들...................... 160 6.7 Subtree Merge................................... 161 6.8 요약......................................... 163 7 Customizing Git 165 7.1 Git 설정하기.................................... 165 7.1.1 클라이언트 설정.............................. 165 core.editor................................. 166 commit.template.............................. 166 core.pager.................................. 167 user.signingkey............................... 167 core.excludesfile.............................. 167 help.autocorrect.............................. 168 7.1.2 컬러 터미널................................. 168 color.ui................................... 168 color.*................................... 168 7.1.3 다른 Merge, Diff 도구 사용하기...................... 169 7.1.4 소스 포맷과 공백.............................. 171 core.autocrlf................................ 171 core.whitespace............................... 172 7.1.5 서버 설정.................................. 173 receive.fsckobjects............................. 173 receive.denynonfastforwards...................... 173 receive.denydeletes............................. 173 vii

7.2 Git Attribute.................................... 174 7.2.1 바이너리 파일................................ 174 바이너리 파일이라고 알려주기....................... 174 바이너리 파일 Diff하기........................... 174 MS Word 파일........................... 174 OpenDocument 파일........................ 176 이미지 파일............................. 177 7.2.2 키워드 치환................................. 178 7.2.3 저장소 익스포트하기............................ 180 export-ignore............................... 180 export-subst................................ 180 7.2.4 Merge 전략................................. 181 7.3 Git 훅........................................ 181 7.3.1 훅 설치하기................................. 181 7.3.2 클라이언트 훅................................ 182 커밋 Workflow 훅............................. 182 E-mail Workflow 훅............................ 182 기타 훅................................... 183 7.3.3 서버 훅................................... 183 pre-receive와 post-receive........................ 183 update.................................... 184 7.4 정책 구현하기.................................... 184 7.4.1 서버 훅................................... 184 커밋 메시지 규칙 만들기.......................... 184 ACL로 사용자마다 다른 규칙 적용하기.................. 186 Fast-Forward Push만 허용하기...................... 188 7.4.2 클라이언트 훅................................ 189 7.5 요약......................................... 192 8 Git과 다른 VCS 193 8.1 Git과 Subversion.................................. 193 8.1.1 git svn.................................... 193 8.1.2 설정하기................................... 194 8.1.3 시작하기................................... 194 8.1.4 Subversion 서버에 커밋하기........................ 196 8.1.5 새로운 변경사항 받아오기......................... 197 8.1.6 Git 브랜치 문제............................... 199 8.1.7 Subversion의 브랜치............................ 199 SVN 브랜치 만들기............................. 199 8.1.8 Subversion 브랜치 넘나들기........................ 200 8.1.9 Subversion 명령.............................. 200 SVN 형식의 히스토리........................... 200 SVN 어노테이션.............................. 201 SVN 서버 정보............................... 201 Subversion에서 무시하는것 무시하기................... 202 8.1.10 Git-Svn 요약................................ 202 viii

8.2 Git으로 옮기기................................... 202 8.2.1 가져오기................................... 203 8.2.2 Subversion................................. 203 8.2.3 Perforce................................... 204 8.2.4 직접 Importer 만들기............................ 206 8.3 요약......................................... 211 9 Git의 내부구조 213 9.1 Plumbing 명령과 Porcelain 명령.......................... 213 9.2 Git 개체....................................... 214 9.2.1 Tree 개체.................................. 216 9.2.2 Commit 개체................................ 219 9.2.3 개체 저장소................................. 220 9.3 Git 레퍼런스.................................... 222 9.3.1 HEAD.................................... 223 9.3.2 Tag..................................... 224 9.3.3 Remote 레퍼런스.............................. 225 9.4 Packfile....................................... 226 9.5 Refspec....................................... 229 9.5.1 Refspec Push하기.............................. 230 9.5.2 레퍼런스 삭제하기............................. 231 9.6 데이터 전송 프로토콜................................ 231 9.6.1 Dumb 프로토콜............................... 231 9.6.2 Smart 프로토콜............................... 234 데이터 업로드................................ 234 데이터 다운로드.............................. 235 9.7 운영 및 데이터 복구................................. 236 9.7.1 운영..................................... 236 9.7.2 데이터 복구................................. 237 9.7.3 개체 삭제.................................. 239 9.8 요약......................................... 242 10 번역 243 ix

1장 시작하기 이 장에서는 처음 접하는 사람들에게 Git을 설명한다. 먼저 버전 관리 도구에 대한 이해를, 그 리고 Git을 설치하는 방법을, 마지막으로 Git 서버를 설정하고 사용하는 방법을 설명한다. 이 장 을 다 읽고 나면 Git의 탄생 배경, Git을 사용하는 이유, Git을 설정하고 사용하는 방법을 터득할 것이다. 1.1 버전 관리란? 버전 관리는 무엇이고, 우리는 왜 이것을 알아야 할까? 버전 관리는 파일들의 변화를 시간에 따 라 기록하는 것이다. 이 책에 있는 모든 예제는 모두 버전 관리 시스템을 사용한다. 실제로 컴퓨 터에서 사용하는 거의 모든 파일의 버전을 관리할 수 있다. 그래픽 디자이너나 웹 디자이너도 이미지나 레이아웃의 모든 버전(변경 이력 혹은 수정 내용) 을 관리하기 위해 버전 관리 시스템 (VCS - Version Control System)을 사용하는 것이 현명하 다. VCS를 사용하면 각 파일을 이전 상태로 되돌릴 수 있고, 프로젝트를 통째로 이전 상태로 되 돌릴 수 있고, 시간에 따라 수정 내용을 비교해 볼 수 있고, 누가 문제를 일으켰는지도 추적할 수 있고, 누가 언제 만들어낸 이슈인지도 알 수 있다. VCS를 사용하면 파일을 잃어버리거나 잘못 고쳤을 때도 쉽게 복구할 수 있다. 이런 모든 장점을 큰 노력 없이 이용할 수 있다. 1.1.1 로컬 버전 관리 시스템 많은 사람은 버전을 관리하기 위해 Directory로 파일을 복사하는 방법을 쓴다(똑똑한 사람이라 면 Directory 이름으로 시간을 쓸 거다). 이 방법은 간단하므로 자주 사용한다. 그렇지만, 정말 뭔가가 잘못되기 쉽다. 작업하는 Directory를 지워버리거나, 실수로 파일을 잘못 고칠 수도 있 고, 잘못 복사할 수도 있다. 이런 이유로 프로그래머들은 오래전에 로컬 VCS를 만들었다. 그 VCS는 관리 중인 파일의 변 경 정보를 저장하려고 아주 간단한 데이터베이스를 사용했다. 많이 쓰는 VCS 도구 중에 rcs라고 부르는 것이 있는데 오늘날까지도 아직 많은 회사가 사용하 고 있다. Mac OS X 운영체제에서도 개발 도구를 설치하면 RCS가 함께 설치된다. RCS는 기 본적으로 Patch Set(파일에서 변경되는 부분)을 관리한다. 이 Patch Set은 특별한 형식의 파일 로 저장한다. 그리고 일련의 Patch Set을 적용해서 모든 파일을 특정 시점으로 되돌릴 수 있다. 1

1장 시작하기 Scott Chacon Pro Git 그림 1.1: 로컬 버전 관리 다이어그램. 1.1.2 중앙집중식 버전 관리 시스템 (Centralized VCS) 프로젝트를 진행하다 보면 다른 개발자와 함께 작업해야 하는 경우가 많다. 이럴 때 생기는 문제 를 해결하기 위해 CVCS(Centralized Version Control System)가 개발됐다. CVS, Subversion, Perforce 같은 시스템은 모든 파일을 관리하는 서버가 별도로 있고 많은 클라이언트가 중앙 서 버에서 파일을 받아서 사용(Checkout)한다. 수년 동안 이러한 시스템들이 많은 사랑을 받았다. 그림 1.2: 중앙집중식 버전 관리 (CVCS) 다이어그램. CVCS 환경은 로컬 VCS에 비해 장점이 많다. 프로젝트에 참여한 사람이면 누가 무엇을 하고 있는지 알 수 있다. 관리자는 누가 무엇을 할 수 있는지 꼼꼼하게 관리할 수 있다. 모든 클라이 언트의 로컬 데이터베이스를 관리하는 것보다 VCS 하나를 관리하기가 훨씬 쉽다. 그러나 CVCS 환경은 몇 가지 치명적인 결점이 있다. 가장 대표적인 것이 중앙 서버에 발생한 문제다. 만약 서버가 한 시간 동안 다운되면 그동안 아무도 다른 사람과 협업할 수 없고 사람들 이 하는 일을 백업할 방법도 없다. 그리고 중앙 데이터베이스가 있는 하드디스크에 문제가 생기 면 프로젝트의 모든 히스토리를 잃는다. 물론 사람마다 하나씩 가진 Snapshot은 괜찮다. 로컬 VCS 시스템도 이와 비슷한 결점이 있고 이런 문제가 발생하면 모든 것을 잃는다. 2

Scott Chacon Pro Git 1.2절 짧게 보는 Git의 역사 1.1.3 분산형 버전 관리 시스템(Distributed VCS) 분산형 버전 관리 시스템(DVCS)을 설명할 차례다. Git, Mecurial, Bazaar, Darcs 같은 DVCS 에서는 클라이언트가 파일의 마지막 Snapshot을 Checkout 하지 않는다. 그냥 저장소를 전부 복 제한다. 서버에 문제가 생기면 이 복제물로 다시 작업을 시작할 수 있다. 클라이언트 중에서 아 무거나 골라도 서버를 복원할 수 있다. 모든 Checkout은 모든 데이터를 가진 진정한 백업이다. 그림 1.3: 분산형 버전 관리 시스템(DVCS) 다이어그램. 게다가 대부분의 DVCS 환경에서는 리모트 저장소가 존재할 수 있다. 리모트 저장소가 많다고 해도 문제없다. 그래서 사람들은 동시에 다양한 그룹과 다양한 방법으로 협업할 수 있다. 계층 모델 같은 중앙집중식 시스템으로는 할 수 없는 몇 가지 워크플로우도 사용할 수 있다. 1.2 짧게 보는 Git의 역사 인생을 살다 보면 여러 가지 일들이 벌어지듯이 Git의 삶 또한 창조적인 파괴와 모순 속에서 시 작되었다. 리눅스 커널은 굉장히 규모가 큰 오픈소스 프로젝트다. 리눅스 커널의 일생에서 대 부분 시절은 패치와 단순 파일(Archived file)로만 관리했다. 2002년에 드디어 리눅스 커널은 BitKeeper라고 불리는 상용 DVCS를 사용하기 시작했다. 2005년에 커뮤니티가 만드는 리눅스 커널과 이익을 추구하는 회사가 개발한 BitKeeper의 관계 는 틀어졌다. BitKeeper의 무료 사용이 제고된 것이다. 이 사건은 리눅스 개발 커뮤니티(특히 리 눅스 창시자 리누스 토발즈)가 자체 도구를 만드는 계기가 됐다. Git은 BitKeeper를 사용하면서 배운 교훈을 기초로 다음과 같은 목표를 세웠다: 빠른 속도 단순한 구조 비선형적인 개발(수천 개의 동시 다발적인 브랜치) 완벽한 분산 3

1장 시작하기 Scott Chacon Pro Git 리눅스 커널 같은 대형 프로젝트에도 유용할 것(속도나 데이터 크기 면에서) Git은 2005년 탄생하고 나서 아직도 초기 목표를 그대로 유지하고 있으면서도 사용하기 쉽게 진화하고 성숙했다. Git은 미친 듯이 빨라서 대형 프로젝트에 사용하기도 좋다. Git은 동시다발 적인 브랜치에도 끄떡없는 슈퍼 울트라 브랜칭 시스템이다 (3장 참고). 1.3 Git 기초 Git의 핵심은 뭘까? 이 질문은 Git을 이해하는데 굉장히 중요하다. Git이 무엇이고 어떻게 동 작하는지 이해한다면 쉽게 Git을 효과적으로 사용할 수 있다. Git을 배우려면 Subversion이나 Perforce 같은 다른 VCS를 사용하던 경험을 지워버려야 한다. Git은 미묘하게 달라서 다른 VCS 에서 쓰던 개념으로는 헷갈릴 거다. 사용자 인터페이스는 매우 비슷하지만, 정보를 취급하는 방 식이 다르다. 이런 차이점들을 이해하면 Git을 사용하는 것이 어렵지 않다. 1.3.1 차이점이 아니라 Snapshot Subversion과 Subversion 비슷한 놈들과 Git의 가장 큰 차이점은 데이터를 다루는 방법에 있 다. 큰 틀에서 봤을 때 대부분의 VCS 시스템이 관리하는 정보는 파일들의 목록이다. CVS, Subversion, Perforce, Bazaar 등의 시스템은 파일의 집합으로 정보를 관리한다. 각 파일의 변화 를 그림1.4처럼 시간순으로 관리한다. 그림 1.4: 각 파일에 대한 변화(차이점)를 저장하는 시스템들. Git은 이런 식으로 데이터를 저장하지도 취급하지도 않는다. 대신 Git의 데이터는 파일 시스템 의 Snapshot이라 할 수 있으며 크기가 아주 작다. Git은 Commit 하거나 프로젝트의 상태를 저 장할 때마다 파일이 존재하는 그 순간을 중요하게 여긴다. 파일이 달라지지 않았으면 Git은 성 능을 위해서 파일을 저장하지 않는다. 단지 이전 상태의 파일에 대한 링크만 저장한다. Git은 그 림1.5처럼 동작한다. 그림 1.5: Git은 시간순으로 프로젝트의 Snapshot을 저장한다. 이것이 Git이 다른 VCS와 구분되는 점이다. 이점 때문에 Git는 다른 시스템들이 과거로부터 답습해왔던 버전 컨트롤의 개념의 많은 부분을 새로운 관점에서 바라본다. Git은 강력한 도구를 4

Scott Chacon Pro Git 1.3절 Git 기초 지원하는 작은 파일시스템이다. Git은 단순한 VCS가 아니다. 이제3장에서 설명할 Git 브랜치 를 사용하면 얻게 되는 이득이 무엇인지 설명한다. 1.3.2 거의 모든 명령을 로컬에서 실행 거의 모든 명령이 로컬 파일과 데이터만 사용하기 때문에 네트워크에 있는 다른 컴퓨터는 필요 없다. 대부분의 명령어가 네트워크의 속도에 영향을 받는 CVCS에 익숙하다면 Git이 매우 놀라 울 것이다. Git의 이런 특징에서 나오는 미칠듯한 속도는 오직 Git느님만이 구사할 수 있는 초 인적인 능력이다. 프로젝트의 모든 히스토리가 로컬 디스크에 있기 때문에 모든 명령을 순식간 에 실행된다. 예를 들어 프로젝트의 히스토리를 조회하려 할 때 Git은 서버가 필요 없다. 그냥 로컬 데이터베 이스에서 히스토리를 읽어서 보여 준다. 그래서 눈 깜짝할 사이에 히스토리를 조회할 수 있다. 어떤 파일의 현재 버전과 한 달 전의 상태를 비교해보고 싶을 때도 Git은 그냥 한 달 전의 파일 과 지금의 파일을 로컬에서 찾는다. 파일을 비교하기 위해 리모트에 있는 서버에 접근하고 나서 예전 버전을 가져올 필요가 없다. 즉 오프라인 상태에서도 비교할 수 있다. 비행기나 기차 등에서 작업하고 네트워크에 접속하고 있지 않아도 Commit 할 수 있다. 다른 VCS 시스템에서는 불가능한 일이다. Perforce는 서버에 연결할 수 없을 때 할 수 있는 일이 별로 없다. Subversion이나 CVS에서도 마찬가지다. 데이터 베이스에 접근할 수 없어서 파일을 편집할 수는 있지만, Commit 할 수 없다. 매우 사소해 보이 지만 실제로 이 상황에 부닥쳐보면 느껴지는 차이가 매우 크다. 1.3.3 Git의 무결성 Git은 모든 데이터를 저장하기 전에 체크섬(Checksum 또는 Hash)을 구하고 그 체크섬으로 데 이터를 관리한다. 체크섬 없이 어떠한 파일이나 Directory도 변경할 수 없다. 체크섬은 Git에서 사용하는 가장 기본적인(Atomic) 데이터 단위이자 Git의 기본 철학이다. Git 없이는 체크섬을 다룰 수 없어서 파일의 상태도 알 수 없고 데이터를 잃어버릴 수도 없다. Git은 SHA-1 Hash를 사용하여 체크섬을 만든다. 만든 체크섬은 40자 길이의 16진수 문자열 이다. 파일의 내용이나 Directory 구조를 이용하여 체크섬을 구한다. SHA-1은 아래처럼 생겼 다. 24b9da6552252987aa493b52f8696cd6d3b00373 Git은 모든 것을 Hash로 식별하기 때문에 이런 값은 여기저기서 보일 것이다. 실제로 Git은 파 일을 이름으로 저장하지 않고 해당 파일의 Hash로 저장한다. 1.3.4 Git은 데이터를 추가할 뿐 Git으로 무얼 하든 데이터가 추가된다. 되돌리거나 데이터를 삭제할 방법이 없다. 다른 VCS처 럼 Git도 Commit 하지 않으면 변경사항을 잃어버릴 수 있다. 하지만, 일단 Snapshot을 Commit 하고 나면 데이터를 잃어버리기 어렵다. Git을 사용하면 프로젝트가 심각하게 망가질 걱정 없이 매우 즐겁게 여러 가지 실험을 해 볼 수 있다. Git이 데이터를 어떻게 저장하고 손실을 복구할 수 있는지 좀 더 알아보려면9장 살펴본다. 5

1장 시작하기 Scott Chacon Pro Git 1.3.5 세 가지 상태 이 부분은 중요하기에 집중해서 읽어야 한다. Git을 공부하기 위해 반드시 짚고 넘어가야 할 부분이다. Git은 파일을 Commited, Modified, Staged 이렇게 세 가지 상태로 관리한다. Commited란 데이터가 로컬 데이터베이스에 안전하게 저장됐다는 것을 의미한다. Modified는 수정한 파일을 아직 로컬 데이터베이스에 Commit 하지 않은 것을 말한다. Staged란 현재 수정 한 파일을 곧 Commit 할 것이라고 표시한 상태를 의미한다. 이 세 가지 상태는 Git 프로젝트의 세 가지 단계와 연결돼 있다. Git Directory, Working Directory, Staging Area 이 세 가지 단계를 이해하고 넘어가자. 그림 1.6: Working Directory, Staging Area, Git Directory Git Directory는 Git이 프로젝트의 메타데이터와 객체 데이터베이스를 저장하는 곳을 말한다. Git Directory가 Git의 핵심이다. 다른 컴퓨터에 있는 저장소를 Clone 할 때 Git Directory가 만 들어진다. Working Directory는 프로젝트의 특정 버전을 Checkout 한 것이다. Git Directory는 지금 작 업하는 디스크에 있고 그 Directory에 압축된 데이터베이스에서 파일을 가져와서 Working Directory를 만든다. Staging Area는 Git Directory에 있다. 단순한 파일이고 곧 Commit 할 파일에 대한 정보를 저 장한다. 종종 인덱스라고 불리기도 하지만, Staging Area라는 명칭이 표준이 되어가고 있다. Git으로 하는 일은 기본적으로 다음과 같다: Working Directory에서 파일을 수정한다. Staging Area에 파일을 Stage 해서 Commit 할 Snapshot을 만든다. Staging Area에 있는 파일들을 Commit 해서 Git Directory에 영구적인 Snapshot으로 저 장한다. Git directory에 있는 파일들은 Committed 상태이다. 파일을 수정하고 Staging Area에 추가했 다면 Staged이다. 그리고 Checkout하고 나서 수정했지만, 아직 Staging Area에 추가하지 않았 으면 Modified이다.2장에서 이 상태에 대해 좀 더 자세히 배운다. 특히 Staging Area를 어떻게 이용하는지 혹은 아예 생략하는 방법도 설명한다. 6

Scott Chacon Pro Git 1.4절 Git 설치 1.4 Git 설치 Git을 사용해 보려면 우선 설치해야 한다. 다양한 방법으로 Git을 설치할 수 있지만 가장 일반 적인 방법은 두 가지가 있다. 하나는 소스코드로 컴파일하여 설치하는 방법이고 다른 하나는 각 운영체제(혹은 Platform)의 패키지를 사용하여 설치하는 방법이다. 1.4.1 소스코드로 설치하기 소스코드로 설치하면 Git의 가장 최신 버전을 설치할 수 있기 때문에 컴파일하여 설치할 시간 이 있으면 소스코드로 Git을 설치하는 것이 좋다. Git은 계속 UI를 개선하고 있기 때문에 최신 버전을 사용하면 좋은 기능을 빨리 사용할 수 있다. 리눅스 패키지는 보통 최신 버전이 아니고 예전 버전이다. 그래서 Backport를 사용하거나 소스코드로 설치하는 것도 좋은 대안이다. Git을 설치하려면 다음과 같은 라이브러리들이 필요하다. Git은 curl, zlib, openssl, expat, libiconv를 필요로 한다. 예를 들어 Fedora처럼 yum을 가지는 시스템을 사용하고 있거나 apt-get이 있는 데비안류 시스템을 사용하면 다음의 명령어를 실행하여 의존 패키지를 설치할 수 있다: $ yum install curl-devel expat-devel gettext-devel \ openssl-devel zlib-devel $ apt-get install libcurl4-gnutls-dev libexpat1-dev gettext \ libz-dev libssl-dev 필요한 라이브러리를 모두 설치하고 다음 단계를 진행한다. Git 웹 사이트에서 최신 Snapshot 을 가져온다: http://git-scm.com/download 그리고 컴파일하고 설치한다: $ tar -zxf git-1.7.2.2.tar.gz $ cd git-1.7.2.2 $ make prefix=/usr/local all $ sudo make prefix=/usr/local install 설치한 다음부터는 Git을 사용하여 Git 소스코드를 갱신할 수 있다: $ git clone git://git.kernel.org/pub/scm/git/git.git 1.4.2 리눅스에 설치 리눅스에서 패키지로 Git을 설치할 때에는 보통 각 배포판에서 사용하는 패키지 관리도구를 사 용하여 설치한다. Fedora에서는 다음과 같이 한다: $ yum install git-core 7

1장 시작하기 Scott Chacon Pro Git Ubuntu같은 데비안류 배포판에서는 apt-get을 사용한다: $ apt-get install git-core 1.4.3 Mac에 설치하기 Mac에 Git을 쉽게 설치하는 방법은 두 가지가 있다. GUI 인스톨러를 사용하기가 가장 쉽다. Google Code 페이지에서 내려받는다: http://code.google.com/p/git-osx-installer 그림 1.7: OS X Git 인스톨러. MacPorts(http://www.macports.org)를 사용하는 방법도 있다. MacPorts가 설치돼 있으면 다음과 같이 Git을 설치한다: $ sudo port install git-core +svn +doc +bash_completion +gitweb 이제 설치는 했다. 만약 Subversion 저장소를 Git과 함께 사용해야 하면 svn도 필요하다. 1.4.4 윈도우에 설치 Git을 윈도우에 설치하기도 쉽다. 그저 구글 코드 페이지에서 msysgit 인스톨러를 내려받고 실 행하면 된다: http://code.google.com/p/msysgit 설치가 완료되면 CLI 프로그램과 GUI 프로그램을 둘 다 사용할 수 있다. CLI 프로그램에는 SSH 클라이언트가 포함돼 있기 때문에 유용하다. 1.5 Git 최초 설정 Git을 설치하고 나면 Git의 사용 환경을 적절히 설정해 주어야 한다. 한 번만 설정하면 된다. 설 정한 내용은 Git을 업그레이드해도 유지된다. 또한, 명령어로 언제든지 다시 바꿀 수 있다. Git은 git config 라는 도구로 설정 내용을 확인하고 변경할 수 있다. Git은 이 설정에 따라 동 작한다. 이 설정 파일은 세 가지나 된다. 8

Scott Chacon Pro Git 1.5절 Git 최초 설정 /etc/gitconfig 파일: 시스템의 모든 사용자와 모든 저장소에 적용되는 설정이다. git config --system 옵션으로 이 파일을 읽고 쓸 수 있다. ~/.gitconfig 파일: 특정 사용자에게만 적용되는 설정이다. git config --global 옵션 으로 이 파일을 읽고 쓸 수 있다..git/config: 이 파일은 Git Directory에 있고 특정 저장소(혹은 현재 작업 중인 프로 젝트)에만 적용된다. 각 설정은 역순으로 우선시 된다. 그래서.git/config가 /etc/ gitconfig보다 우선한다. 윈도우에서 Git은 $HOME Directory(C:\Documents and Settings\$USER)에 있는.gitconfig 파일을 찾는다. 그리고 msysgit도 /etc/gitconfig를 가지고 있다. 경로는 MSys 루트에 따른 상 대 경로다. 인스톨러로 msysgit을 설치할 때 설치 경로를 선택할 수 있다. 1.5.1 사용자 정보 Git을 설치하고 나서 가장 먼저 해야 하는 것은 사용자 이름과 이메일 주소를 설정하는 것이다. Git은 Commit 할 때마다 이 정보를 사용한다. 한 번 Commit 한 후에는 정보를 변경할 수 없다. $ git config --global user.name "John Doe" $ git config --global user.email johndoe@example.com 다시 말하자면 --global 옵션으로 설정한 것은 딱 한 번만 하면 된다. 해당 시스템에서 해당 사 용자가 사용할 때에는 이 정보를 사용한다. 만약 프로젝트마다 다른 이름과 이메일 주소를 사용 하고 싶으면 --global 옵션을 빼고 명령을 실행한다. 1.5.2 편집기 사용자 정보를 설정하고 나면 Git에서 사용할 텍스트 편집기를 고른다. 기본적으로 Git은 시스 템의 기본 편집기를 사용하고 보통 이것은 Vi나 Vim이다. 하지만, Emacs 같은 다른 텍스트 편 집기를 사용하고 싶다면 다음과 같이 실행한다.: $ git config --global core.editor emacs 1.5.3 Diff 도구 Merge 충돌을 해결하기 위해 사용하는 Diff 도구를 설정할 수 있다. vimdiff를 사용하고 싶으 면 다음과 같이 실행한다: $ git config --global merge.tool vimdiff 이렇게 kdiff3, tkdiff, meld, xxdif, emerge, vimdiff, gvimdiff, ecmerge, opendiff를 사용할 수 있다. 물론 다른 도구도 사용할 수 있다. 자세한 내용은7장에서 다룬다. 9

1장 시작하기 Scott Chacon Pro Git 1.5.4 설정 확인 git config --list 명령을 실행하면 모든 설정 내용을 확인할 수 있다: $ git config --list user.name=scott Chacon user.email=schacon@gmail.com color.status=auto color.branch=auto color.interactive=auto color.diff=auto... Git은 같은 키를 여러 파일(/etc/gitconfig와 ~/.gitconfig같은)에서 읽기 때문에 같은 키가 하나 이상 나올 수도 있다. 이 경우에 Git은 나중 값을 사용한다. git config key 명령으로 Git이 특정 Key에 대해 어떤 값을 사용하는지 확인할 수 있다: $ git config user.name Scott Chacon 1.6 도움말 보기 명령어에 대한 도움말이 필요할 때 도움말을 보는 방법은 세 가지이다: $ git help <verb> $ git <verb> --help $ man git-<verb> 예를 들어 다음과 같이 실행하면 config 명령에 대한 도움말을 볼 수 있다: $ git help config 도움말은 언제 어디서나 볼 수 있다. 오프라인 상태에서도 가능하다. 도움말과 이 책으로 부 족하면 다른 사람의 도움을 받는 것이 필요하다. Freenode IRC 서버(irc.freenode.net)에 있는 #git이나 #github 채널로 찾아가라. 이 채널은 보통 수백 명의 사람이 접속해 있다. 이 사람들 은 모두 Git에 대해 잘 알고 있다. 기꺼이 도와줄 것이다. 1.7 요약 우리는 Git이 무엇이고 지금까지 사용해 왔던 다른 CVCS와 어떻게 다른지 배웠다. 시스템에 Git을 설치하고 사용자 정보도 설정했다. 다음 장에서는 Git의 사용법을 배운다. 10

2장 Git의 기초 Git을 사용하는 방법을 알고 싶은데 단 한 챕터밖에 읽을 시간이 없을 때2장이 딱 맞다. Git을 사용하면서 자주 사용하는 명령어들은 모두2장에 등장한다.2장을 다 읽으면 저장소를 만들고 설정하는 방법, 파일을 추적하거나(Track) 추적을 그만두는 방법, 변경 내용을 Stage하고 커밋 할 수 있는 방법을 알 수 있다. 우리는 또 특정 파일이나 파일의 패턴을 무시하도록 Git을 설정 하는 방법, 실수를 쉽고 빠르게 만회하는 방법, 프로젝트의 히스토리를 조회하고 커밋을 서로 비 교하는 방법, 리모트 저장소에 Push하고 Pull하는 방법을 살펴볼 것이다. 2.1 Git 저장소 만들기 보통 프로젝트의 Git 저장소를 만드는 방법은 두 가지다. 하나는 기존에 있는 프로젝트를 Git 저장소로 만드는 방법이고 하나는 다른 서버에 있는 저장소를 Clone하는 것이다. 2.1.1 이미 있는 디렉토리에서 새 저장소 만들기 이미 있는 프로젝트를 추적하고 싶을 때, 프로젝트의 디렉토리로 이동해서 다음과 같은 명령을 실행한다. $ git init 이 명령은.git이라는 하위디렉토리를 만든다..git 디렉토리에는 저장소를 이루는 뼈대가 되 는 파일(Skeleton)이 들어 있다(.git 디렉토리가 막 만들어진 직후 어떤 파일이 포함되는지에 대한 자세한 내용은9장에서 다룬다). 하지만, 위 명령만으로는 아직 Git은 프로젝트의 어떤 파 일도 추적하지 않는다. 그리고 파일들의 버전을 관리하려면 Git이 파일을 관리하도록 저장소에 추가하고 최초로 커밋 한다. git add 명령으로 여러 파일을 추가하고 커밋한다: $ git add *.c $ git add README $ git commit -m 'initial project version' 1분도 되지 않는 짧은 시간에 위의 명령어들을 실행하여 Git 저장소를 만들었고 파일을 추적하 게 하였다. 11

2장 Git의 기초 Scott Chacon Pro Git 2.1.2 이미 있는 저장소를 Clone하기 다른 프로젝트에 참여하거나(Contribute) Git 저장소를 복사하고 싶을 때 git clone 명령을 사 용한다. 이미 Subversion 같은 VCS에 익숙하면 checkout이 아니라 clone 이라는 점이 눈에 띌 것이다. Subversion과 git의 가장 큰 차이점은 서버에 있는 모든 데이터를 복사한다는 것이다. git clone을 실행하면 프로젝트 히스토리를 전부 받아온다. 실제로 서버의 디스크가 망가져도 클라이언트들의 저장소 중에서 아무거나 하나 가져다가 복구할 수 있다(서버에 특화된 설정은 복구하지 못하지만 모든 데이터는 복구된다 -4장에서 좀 더 자세히 다룬다). git clone [url]로 저장소를 Clone한다. 예를 들어, Ruby용 Git 라이브러리인 Grit을 Clone 하려면 다음과 같이 한다: $ git clone git://github.com/schacon/grit.git 이 명령은 grit 이라는 디렉토리를 만들고 그 안에.git 디렉토리를 만든다. 그리고 저장소의 데이터도 모두 가져오고 자동으로 가장 최신 버전을 Checkout한다. grit 디렉토리로 이동하면 Checkout으로 생성된 파일을 볼 수 있고 당장 하고자 하는 일을 바로 시작할 수 있다. 다음과 같은 명령을 사용하여 저장소를 Clone하면 grit 이 아니라 다른 이름으로 Clone할 수 있다: $ git clone git://github.com/schacon/grit.git mygrit 디렉토리 이름이 mygrit이라는 것만 빼면 이 명령의 결과와 앞선 명령의 결과는 같다. Git은 다양한 프로토콜을 지원한다. 이제까지는 git:// 프로토콜을 사용했지만 http(s)://를 사용할 수도 있고 user@server:/path.git처럼 SSH 프로토콜을 사용할 수도 있다. 자세한 내 용은4장에서 다룬다.4장에서는 각 프로토콜의 장단점도 알아보고 Git 저장소에 접근하는 방법 들을 알아본다. 2.2 수정하고 저장소에 저장하기 Git 저장소를 하나 만들고 일할 수 있도록 Checkout했다. 이제는 파일을 수정하고 파일의 Snapshot을 커밋해 보자. 파일들을 수정하다가 저장하고 싶으면 Snapshot을 커밋한다. 작업 디렉토리의 모든 파일은 크게 Tracked(관리대상임)와 Untracked(관리대상이 아님) 로 나눈다. Tracked 파일은 이미 Snapshot에 포함돼 있던 파일이다. Tracked 파일들은 또 Unmodified(수정하지 않음)와 Modified(수정함) 그리고 Staged(커밋을 하면 현재 수정 사항 을 저장소에 기록함) 상태 중 하나이다. 그리고 나머지 파일들은 모두 Untracked 파일이다. Untracked 파일은 작업 디렉토리에 있는 모든 파일이 Snapshot에 포함돼 있는 것은 아니고 Staging Area에 있는 것도 아니다. 처음 저장소를 Clone하고 나면 모든 파일은 Tracked이면서 Unmodified 상태이다. Git은 저장소를 Clone하면 자동으로 파일을 Checkout하고 아직 아무것 도 편집하지 않은 상태다. 마지막 커밋 이후 아직 아무것도 수정하지 않은 상태에서 어떤 파일이 수정되면 Git은 그 즉시 파일을 Modified 상태로 인식한다. 그리고 이 수정한 파일을 Stage하고 Staged 상태인 파일들 을 커밋한다. 이 라이프사이클을 그림2.1처럼 계속 반복한다. 12

Scott Chacon Pro Git 2.2절 수정하고 저장소에 저장하기 그림 2.1: 파일의 라이프사이클 2.2.1 파일의 상태 확인하기 파일의 상태를 확인하려면 보통 git status 명령을 사용한다. Clone한 후에 바로 이 명령을 실 행하면 다음과 같은 메시지를 볼 수 있다: $ git status # On branch master nothing to commit (working directory clean) 위의 내용은 파일을 하나도 수정하지 않았다는 것을 말해준다. 즉, Tracked와 Modified 상태 의 파일이 없다. Untracked 파일은 아직 없어서 목록에 나타나지 않는다. 그리고 현재 작업 중 인 브랜치를 알려준다. 기본 브랜치가 master이기 때문에 현재 master로 나오는 것이다. 브랜 치 관련 내용은 차차 알아가자. 다음 장에서 브랜치와 레퍼런스에 대해 자세히 다룬다. 프로젝트에 README 파일을 만들어보자. README 파일은 새로 만든 파일이기 때문에 git status를 실행하면 Untracked에 들어 있다: $ vim README $ git status # On branch master # Untracked files: # (use "git add <file>..." to include in what will be committed) # # README nothing added to commit but untracked files present (use "git add" to track) README 파일은 Untracked files 부분에 속해 있는데 이것은 README 파일이 Untracked 상태라는 것을 말한다. Git은 Untracked 파일을 이전 Snapshot(커밋)에는 없는 파일이라고 본 다. Git은 파일이 Tracked 상태가 되기 전까지는 절대 그 파일들을 커밋하지 않는다. 그래서 일 하는 동안 생성된 파일인 바이너리 파일 같은 것을 커밋하는 실수는 하지 않게 된다. README 파일을 포함해 직접 Tracked 상태로 만들어 보자. 2.2.2 새 파일을 추적하기 git add 명령을 사용하여 새로운 파일을 추적할 수 있다. 다음 명령을 실행하면 Git은 README 13

2장 Git의 기초 Scott Chacon Pro Git 파일을 추적한다: $ git add README git status 명령을 다시 실행하면 README 파일이 Tracked 상태이면서 Staged 상태라는 것 을 확인할 수 있다: $ git status # On branch master # Changes to be committed: # (use "git reset HEAD <file>..." to unstage) # # new file: README # Changes to be committed 에 들어 있는 파일은 Staged 상태라는 것을 의미한다. 커밋하면 git add를 실행한 시점의 파일이 커밋되어 저장소 히스토리에 남는다. 앞에서 git init 명령 을 실행했을 때, 그 다음 git add (files) 명령을 실행했던 걸 기억할 것이다. 이것은 작업 디 렉토리에 있는 파일들을 추적하기 시작하게 하였다. git add 명령은 파일 또는 디렉토리의 경 로명을 인자로 받는다; 만일 디렉토리를 인자로 줄 경우, 그 디렉토리 아래에 있는 모든 파일들 을 재귀적으로 추가한다. 2.2.3 Modified 상태의 파일을 Stage하기 이미 Tracked 상태인 파일을 수정하는 법을 알아보자. benchmarks.rb라는 파일을 수정하고 나 서 git status 명령을 다시 실행하면 결과는 다음과 같다: $ git status # On branch master # Changes to be committed: # (use "git reset HEAD <file>..." to unstage) # # new file: README # # Changed but not updated: # (use "git add <file>..." to update what will be committed) # # modified: benchmarks.rb # 이 benchmarks.rb 파일은 Changed but not updated에 있다. 이것은 수정한 파일이 Tracked 상태이지만 아직 Staged 상태는 아니라는 것이다. Staged 상태로 만들려면 git add 명령을 실 행해야 한다. git add는 파일을 새로 추적할 때도 사용하고 수정한 파일을 Staged 상태로 만 드는데에도 사용한다. git add를 실행하여 benchmarks.rb 파일을 Staged 상태로 만들고 git status 명령으로 결과를 확인해보자: 14

Scott Chacon Pro Git 2.2절 수정하고 저장소에 저장하기 $ git add benchmarks.rb $ git status # On branch master # Changes to be committed: # (use "git reset HEAD <file>..." to unstage) # # new file: README # modified: benchmarks.rb # 두 파일 모두 Staged 상태이므로 다음 커밋에 포함된다. 하지만, 아직 더 수정해야 한다는 것을 알게 되어 바로 커밋하지 못하는 상황이 되었다고 하자. 이 상황에서 benchmark.rb 파일을 열 고 수정한다. 이제 아마 당신은 커밋할 준비가 다 됐다고 생각할 것이다. 하지만, Git에게는 그 렇지 않다. git status 명령으로 파일의 상태를 다시 확인해보자: $ vim benchmarks.rb $ git status # On branch master # Changes to be committed: # (use "git reset HEAD <file>..." to unstage) # # new file: README # modified: benchmarks.rb # # Changed but not updated: # (use "git add <file>..." to update what will be committed) # # modified: benchmarks.rb # 헉! benchmarks.rb가 Staged 상태이면서 동시에 Unstaged 상태로 나온다. 어떻게 이런 일이 가능할까? git add 명령을 실행하면 Git은 파일을 바로 Staged 상태로 만든다. 지금 이 시점에 서 커밋을 하면 git commit 명령을 실행하는 시점의 버전이 커밋되는 것이 아니라 마지막으로 git add 명령을 실행했을 때의 버전이 커밋된다. 그러니까 git add 명령을 실행 후에 또 파일 을 수정하면 git add 명령을 다시 실행하여 최신 버전을 Staged 상태로 만들어야 한다: $ git add benchmarks.rb $ git status # On branch master # Changes to be committed: # (use "git reset HEAD <file>..." to unstage) # # new file: README # modified: benchmarks.rb # 15

2장 Git의 기초 Scott Chacon Pro Git 2.2.4 파일 무시하기 어떤 파일들은 Git이 자동으로 추가하지도 Untracked 파일이라고 보여줄 필요가 없다. 보 통 로그 파일이나 빌드 시스템이 자동으로 생성한 파일들이 그렇다. 그런 파일을 무시하려면.gitignore 파일을 만들고 그 안에 무시할 파일 패턴을 적는다. 다음은.gitignore 파일의 예 이다: $ cat.gitignore *.[oa] *~ 첫번째 줄은 확장자가.o 나.a인 파일을 Git이 무시하라는 것이고 둘째 줄은 ~로 끝나는 모 든 파일을 무시하라는 것이다..o와.a는 각각 빌드 시스템이 만들어내는 오브젝트와 아카이 브 파일이고 ~로 끝나는 파일은 Emacs나 VI 같은 텍스트 편집기들이 임시로 만들어내는 파일 이다. 또 log, tmp, pid 같은 디렉토리나, 자동으로 생성하는 문서 같은 것들도 추가할 수 있다..gitignore 파일은 보통 처음에 만들어 두는 것이 편리하다. 그래서 Git 저장소에 커밋하고 싶 지 않은 파일을 실수로 커밋하는 일을 방지한다..gitignore 파일에 입력하는 패턴은 다음의 규칙을 따른다: 아무것도 없는 줄이나, #로 시작하는 줄은 무시한다. 표준 Glob 패턴을 사용한다. 디렉토리는 슬래시(/)를 끝에 사용하는 것으로 표현한다. 느낌표(!)로 시작하는 패턴은 해당 패턴의 파일을 무시하지 않는다. Glob 패턴은 정규표현식을 단순하게 만든 것으로 생각하면 되고 보통 쉘에서 많이 사용한다. 애 스터리스크(*)는 문자가 하나도 없거나 하나 이상을 의미하고, [abc]는 중괄호 안에 있는 문자 중 하나를 의미한다(그러니까 이 경우에는 a, b, c). 물음표(?)는 문자 하나를 말하고, [0-9]처럼 중괄호 안의 캐릭터 사이에 하이픈(-)을 사용하면 그 캐릭터 사이에 있는 문자 하나를 말한다. 다음은.gitignore 파일의 예이다: # a comment - 이 줄은 무시한다. *.a # 확장자가.a인 파일 무시!lib.a # 윗 줄에서 확장자가.a인 파일은 무시하게 했지만 lib.a는 무시하지 않는다. /TODO # 루트 디렉토리에 있는 TODO파일은 무시하고 subdir/root처럼 하위디렉토리에 있는 파일은 무시 하지 않는다. build/ # build/ 디렉토리에 있는 모든 파일은 무시한다. doc/*.txt # `doc/notes.txt`같은 파일은 무시하고 doc/server/arch.txt같은 파일은 무시하지 않는다. 2.2.5 Staged와 Unstaged 상태의 변경 내용을 보기 단순히 파일이 변경됐다는 사실이 아니라 어떤 내용이 변경됐는지 살펴보기엔 git status 명 령은 부족해서 git diff 명령을 사용해야 한다. 일반적으로 우리는 수정했지만, 아직 Staged 파일이 아닌것? 과 어떤 파일이 Staged 상태인지? 가 궁금하기 때문에 git status 명령으로도 충분하다. git diff는 Patch처럼 어떤 라인을 추가했고 삭제했는지 알아야 할 때에 사용한다. git diff는 나중에 더 자세히 다룬다. 16

Scott Chacon Pro Git 2.2절 수정하고 저장소에 저장하기 README 파일을 수정하고 Staged 상태로 만들어 보자. benchmarks.rb 파일은 그냥 수정만 해둔다. 이 상태에서 git status 명령을 실행하면 다음과 같은 메시지를 볼 수 있다: $ git status # On branch master # Changes to be committed: # (use "git reset HEAD <file>..." to unstage) # # new file: README # # Changed but not updated: # (use "git add <file>..." to update what will be committed) # # modified: benchmarks.rb # git diff 명령을 실행하면 수정했지만 아직 staged 상태가 아닌 파일을 비교해 볼 수 있다: $ git diff diff --git a/benchmarks.rb b/benchmarks.rb index 3cb747f..da65585 100644 --- a/benchmarks.rb +++ b/benchmarks.rb @@ -36,6 +36,10 @@ def main @commit.parents[0].parents[0].parents[0] end + run_code(x, 'commits 1') do + git.commits.size + end + run_code(x, 'commits 2') do log = git.commits('master', 15) log.size 이 명령은 작업 디렉토리에 있는 것과 Staging Area에 있는 것을 비교한다. 그래서 수정하고 아 직 Staged 상태가 아닌 것들을 보여준다. 만약 커밋하려고 Staging Area에 넣은 파일의 변경 부분을 보고 싶으면 git diff --cached 옵 션을 사용한다(Git 버전 1.6.1부터는 좀 더 기억하기 쉽게 git diff --staged로도 사용할 수 있다). 이 명령은 Staging Area와 저장소에 커밋한 것을 비교한다: $ git diff --cached diff --git a/readme b/readme new file mode 100644 index 0000000..03902a1 --- /dev/null +++ b/readme2 @@ -0,0 +1,5 @@ +grit 17

2장 Git의 기초 Scott Chacon Pro Git + by Tom Preston-Werner, Chris Wanstrath + http://github.com/mojombo/grit + +Grit is a Ruby library for extracting information from a Git repository 꼭 잊지 말아야 할 것이 있는데 git diff 명령은 마지막으로 커밋한 후에 수정한 것을 보여주 지 않는다. git diff는 Unstaged 상태인 것들만 보여준다. 이 부분은 조금 헷갈릴 수도 있는데, 수정한 파일을 모두 Staging Area에 넣었다면 git diff 명령은 아무것도 출력하지 않는다. benchmarks.rb 파일을 Stage한 후 다시 수정해도 git diff 명령을 사용할 수 있다. 이 경우 Staged 상태인 것과 Unstaged 상태인 것을 비교한다: $ git add benchmarks.rb $ echo '# test line' >> benchmarks.rb $ git status # On branch master # # Changes to be committed: # # modified: benchmarks.rb # # Changed but not updated: # # modified: benchmarks.rb # git diff 명령으로 Unstaged 상태인 변경 부분을 확인해 볼 수 있다: $ git diff diff --git a/benchmarks.rb b/benchmarks.rb index e445e28..86b2f7c 100644 --- a/benchmarks.rb +++ b/benchmarks.rb @@ -127,3 +127,4 @@ end main() ##pp Grit::GitRuby.cache_client.stats +# test line Staged 상태인 파일은 git diff --cached 옵션으로 확인한다: $ git diff --cached diff --git a/benchmarks.rb b/benchmarks.rb index 3cb747f..e445e28 100644 --- a/benchmarks.rb +++ b/benchmarks.rb @@ -36,6 +36,10 @@ def main @commit.parents[0].parents[0].parents[0] 18

Scott Chacon Pro Git 2.2절 수정하고 저장소에 저장하기 end + run_code(x, 'commits 1') do + git.commits.size + end + run_code(x, 'commits 2') do log = git.commits('master', 15) log.size 2.2.6 변경사항 커밋하기 수정한 것을 커밋하기 위해 Staging Area에 파일을 정리했다. Unstaged 상태의 파일은 커밋되 지 않는다는 것을 기억해야 한다. Git은 생성하거나 수정하고 나서 git add 명령으로 추가하지 않은 파일은 커밋하지 않는다. 그 파일은 여전히 Modified 상태로 남아 있다. 커밋하기 전에 git status 명령으로 모든 것이 Staged 상태인지 확인할 수 있다. 그리고 git commit을 실행하여 커밋한다: $ git commit Git 설정에 지정된 편집기가 다음과 같이 실행되고, 다음과 같은 텍스트가 자동으로 포함된다 (아래 예제는 Vim 편집기의 화면이다). 이 편집기는 쉘의 $EDITOR 환경 변수에 등록된 편 집기이고 보통은 Vim이나 Emacs을 사용한다. 또1장에서 설명했듯이 git config --global core.editor 명령으로 어떤 편집기를 사용할지 설정할 수 있다: 편집기는 아래와 같은 내용을 표시한다(아래 예제는 Vim 편집기의 경우): # Please enter the commit message for your changes. Lines starting # with '#' will be ignored, and an empty message aborts the commit. # On branch master # Changes to be committed: # (use "git reset HEAD <file>..." to unstage) # # new file: README # modified: benchmarks.rb ~ ~ ~ ".git/commit_editmsg" 10L, 283C 자동으로 생성되는 커밋 메시지는 첫 줄은 비어 있고 둘째 줄부터 git status 명령의 결과가 채워진다. 커밋한 내용을 쉽게 기억할 수 있도록 이 메시지를 포함할 수도 있고 메시지를 전부 지우고 새로 작성할 수 있다(수정한 내용을 좀 더 구체적으로 남겨 둘 수 있다. git commit에 -v 옵션을 추가하면 편집기에 diff 메시지도 추가된다). 메시지를 인라인으로 첨부할 수도 있다. commit 명령을 실행할 때 다음과 같이 -m 옵션을 사용 한다: 19

2장 Git의 기초 Scott Chacon Pro Git $ git commit -m "Story 182: Fix benchmarks for speed" [master]: created 463dc4f: "Fix benchmarks for speed" 2 files changed, 3 insertions(+), 0 deletions(-) create mode 100644 README commit 명령은 몇 가지 정보를 출력하는데 위 예제는 master 브랜치에 커밋했고 체크섬은 463dc4f이라고 알려준다. 그리고 수정한 파일이 몇 개이고 삭제됐거나 추가된 줄이 몇 줄인지 알려준다. Git은 Staging Area에 속한 Snapshot을 커밋한다는 것을 기억해야 한다. 수정은 했지만, 아직 Staging Area에 넣지 않은 것들은 다음에 커밋할 수 있다. 커밋할 때마다 프로젝트의 Snapshot 을 기록하기 때문에 나중에 Snapshot끼리 비교하거나 예전 Snapshot으로 되돌릴 수 있다. 2.2.7 Staging Area 생략하기 Staging Area는 커밋할 파일들을 정리한다는 점에서 매우 유용하지만 복잡하기만 하고 필요하 지 않은 때도 있다. 아주 쉽게 Staging Area를 생략할 수 있다. git commit 명령을 실행할 때 -a 옵션을 추가하면 Git은 Tracked 상태의 파일이라면 자동으로 Staging Area에 넣는다. 그래서 git add 명령을 실행하는 수고를 덜 수 있다: $ git status # On branch master # # Changed but not updated: # # modified: benchmarks.rb # $ git commit -a -m 'added new benchmarks' [master 83e38c7] added new benchmarks 1 files changed, 5 insertions(+), 0 deletions(-) 이 예제에서는 커밋하기 전에 git add 명령으로 benchmarks.rb 파일을 추가하지 않았다는 점 을 눈여겨보자. 2.2.8 파일을 삭제하기 Git에서 파일을 제거하려면 git rm 명령으로 Tracked 상태의 파일을 삭제한 후에(정확하게는 Staging Area에서 삭제하는 것) 커밋해야 한다. 이 명령은 작업 디렉토리에 있는 파일도 삭제하 기 때문에 실제로 지워진다. 만약 Git없이 그냥 파일을 삭제하고 git status 명령으로 상태를 확인하면 Changed but not updated(즉, Unstaged) 에 속해 있는 것을 확인할 수 있다: $ rm grit.gemspec $ git status # On branch master # 20

Scott Chacon Pro Git 2.2절 수정하고 저장소에 저장하기 # Changed but not updated: # (use "git add/rm <file>..." to update what will be committed) # # deleted: grit.gemspec # 그리고 git rm 명령을 실행하면 삭제한 파일은 staged 상태가 된다: $ git rm grit.gemspec rm 'grit.gemspec' $ git status # On branch master # # Changes to be committed: # (use "git reset HEAD <file>..." to unstage) # # deleted: grit.gemspec # 커밋하면 파일은 삭제되고 Git은 이 파일을 더는 추적하지 않는다. 이미 파일을 수정했거나 Index에(역주, Staging Area을 Git Index라고도 부른다) 추가했다면 -f옵션을 주어 강제로 삭제 해야 한다. 이 점은 실수로 데이터를 삭제하지 못하도록 하는 안전장치다. 한 번도 커밋한적 없 는 데이터는 Git으로 복구할 수 없다. 또 Staging Area에서만 제거하고 작업 디렉토리에 있는 파일은 지우지 않고 남겨둘 수 있다. 다시 말해서 하드디스크에 있는 파일은 그대로 두고 Git만 더는 추적하지 않게 한다. 이것은.gitignore 파일에 추가하는 것을 빼먹었거나 대용량 로그 파일이나 컴파일된 파일인.a 파일 같은 것을 실수로 추가했을 때 쓴다. --cached 옵션을 사용하여 명령을 실행한다: $ git rm --cached readme.txt 여러 개의 파일이나 디렉토리를 한꺼번에 삭제할 수도 있다. 다음과 같이 git rm 명령에 file-glob 패턴을 사용한다: $ git rm log/\*.log *앞에 \을 사용한 것을 기억하자. 이것은 쉘의 파일명 확장에 더하여 Git 자체의 파일명 확장 기능을 사용하기 위해서이다. 이 명령은 log/ 디렉토리에 있는.log 파일을 모두 삭제한다. 다 음의 예제처럼 할 수도 있다: $ git rm \*~ 이 명령은 ~로 끝나는 파일을 모두 삭제한다. 21

2장 Git의 기초 Scott Chacon Pro Git 2.2.9 파일 이름 변경하기 Git은 다른 VCS 시스템과는 달리 파일 이름의 변경이나 파일의 이동을 명시적으로 관리하지 않는다. 다시 말해서 파일 이름이 변경됐다는 별도의 정보를 저장하지 않는다. Git은 똑똑해서 굳이 파일 이름이 변경되었다는 것을 추적하지 않아도 아는 방법이 있다. 이제 Git이 파일의 이 름이 변경된 것을 어떻게 알아내는지 살펴본다. 이렇게 말하고 Git에 mv 명령이 있는 게 좀 이상하겠지만, 다음과 같이 파일이름을 변경할 수 있다: $ git mv file_from file_to 잘 동작한다. 이 명령을 실행하고 Git의 상태를 확인해보면 Git은 이름이 바뀐 사실을 알고 있 다: $ git mv README.txt README $ git status # On branch master # Your branch is ahead of 'origin/master' by 1 commit. # # Changes to be committed: # (use "git reset HEAD <file>..." to unstage) # # renamed: README.txt -> README # 사실 git mv 명령은 다음의 명령어들을 수행한 것과 완전히 똑같다: $ mv README.txt README $ git rm README.txt $ git add README git mv는 일종의 단축 명령어이다. 이 명령으로 파일이름을 바꿔도 되고 mv 명령으로 파일이 름을 직접 바꿔도 된다. 단지 Git의 mv명령은 편리하게 명령을 세 번 실행해주는 것뿐이다. 어 떤 도구로 이름을 바꿔도 상관없다. 중요한 것은 이름을 변경하고 나서 꼭 rm/add 명령을 실행 해야 한다는 것뿐이다. 2.3 커밋 히스토리 조회하기 새로 저장소를 만들어서 몇 번 커밋을 했을 수도 있고, 커밋 히스토리가 있는 저장소를 Clone 했을 수도 있다. 어쨌든 가끔 저장소의 히스토리를 보고 싶을 때가 있다. Git에는 히스토리를 조 회하는 명령어인 git log가 있다. 이 예제에서는 simplegit 이라는 매우 단순한 프로젝트를 사용한다. simplegit은 Git을 설명하 는데 자주 사용하는 예제다. 다음과 같이 이 프로젝트를 Clone한다: 22

Scott Chacon Pro Git 2.3절 커밋 히스토리 조회하기 git clone git://github.com/schacon/simplegit-progit.git 이 프로젝트 디렉토리에서 git log 명령을 실행하면 다음과 같이 출력된다: $ git log commit ca82a6dff817ec66f44342007202690a93763949 Author: Scott Chacon <schacon@gee-mail.com> Date: Mon Mar 17 21:52:11 2008-0700 changed the version number commit 085bb3bcb608e1e8451d4b2432f8ecbe6306e7e7 Author: Scott Chacon <schacon@gee-mail.com> Date: Sat Mar 15 16:40:33 2008-0700 removed unnecessary test code commit a11bef06a3f659402fe7563abf99ad00de2209e6 Author: Scott Chacon <schacon@gee-mail.com> Date: Sat Mar 15 10:31:28 2008-0700 first commit 특별한 인자 없이 git log 명령을 실행하면 저장소의 커밋 히스토리를 시간순으로 보여준다. 즉, 가장 최근의 커밋이 가장 먼저 나온다. 그리고 이어서 각 커밋의 SHA-1 체크섬, 저자 이름, 저자 이메일, 커밋한 날짜, 커밋 메시지를 보여준다. 원하는 히스토리를 검색할 수 있도록 git log 명령은 매우 다양한 옵션을 지원한다. 여기에서 는 자주 사용하는 옵션을 설명한다. -p가 가장 유용한 옵션 중 하나다. -p는 각 커밋의 diff 결과를 보여준다. 게다가 -2는 최근 두 개의 결과만 보여주는 옵션이다: $ git log -p -2 commit ca82a6dff817ec66f44342007202690a93763949 Author: Scott Chacon <schacon@gee-mail.com> Date: Mon Mar 17 21:52:11 2008-0700 changed the version number diff --git a/rakefile b/rakefile index a874b73..8f94139 100644 --- a/rakefile +++ b/rakefile @@ -5,7 +5,7 @@ require 'rake/gempackagetask' spec = Gem::Specification.new do s - s.version = "0.1.0" + s.version = "0.1.1" s.author = "Scott Chacon" 23

2장 Git의 기초 Scott Chacon Pro Git commit 085bb3bcb608e1e8451d4b2432f8ecbe6306e7e7 Author: Scott Chacon <schacon@gee-mail.com> Date: Sat Mar 15 16:40:33 2008-0700 removed unnecessary test code diff --git a/lib/simplegit.rb b/lib/simplegit.rb index a0a60ae..47c6340 100644 --- a/lib/simplegit.rb +++ b/lib/simplegit.rb @@ -18,8 +18,3 @@ class SimpleGit end end - -if $0 == FILE - git = SimpleGit.new - puts git.show -end \ No newline at end of file 이 옵션은 직접 diff를 실행한 것과 같은 결과를 출력하기 때문에 동료가 무엇을 커밋했는지 리 뷰하고 빨리 조회하는데 유용하다. 또 git log 명령에는 히스토리의 통계를 보여주는 옵션도 있다. --stat 옵션으로 각 커밋의 통 계 정보를 조회할 수 있다: $ git log --stat commit ca82a6dff817ec66f44342007202690a93763949 Author: Scott Chacon <schacon@gee-mail.com> Date: Mon Mar 17 21:52:11 2008-0700 changed the version number Rakefile 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) commit 085bb3bcb608e1e8451d4b2432f8ecbe6306e7e7 Author: Scott Chacon <schacon@gee-mail.com> Date: Sat Mar 15 16:40:33 2008-0700 removed unnecessary test code lib/simplegit.rb 5 ----- 1 files changed, 0 insertions(+), 5 deletions(-) commit a11bef06a3f659402fe7563abf99ad00de2209e6 Author: Scott Chacon <schacon@gee-mail.com> Date: Sat Mar 15 10:31:28 2008-0700 first commit README 6 ++++++ Rakefile 23 +++++++++++++++++++++++ 24

Scott Chacon Pro Git 2.3절 커밋 히스토리 조회하기 lib/simplegit.rb 25 +++++++++++++++++++++++++ 3 files changed, 54 insertions(+), 0 deletions(-) 이 결과에서 --stat 옵션은 어떤 파일이 수정됐는지, 얼마나 많은 파일이 변경됐는지, 또 얼마 나 많은 줄을 추가하거나 삭제했는지 보여준다. 요약정보는 가장 뒤쪽에 보여준다. 다른 또 유용한 옵션은 --pretty 옵션이다. 이 옵션을 통해 log의 내용을 보여줄 때 기본 형식 이외에 여러 가지 중에 하나를 선택할 수 있다. oneline 옵션은 각 커밋을 한 줄로 보여준다. 이 옵션은 많은 커밋을 한 번에 조회할 때 유용하다. 추가로 short, full, fuller 옵션도 있는데 이 것들은 정보를 조금씩 가감해서 보여준다: $ git log --pretty=oneline ca82a6dff817ec66f44342007202690a93763949 changed the version number 085bb3bcb608e1e8451d4b2432f8ecbe6306e7e7 removed unnecessary test code a11bef06a3f659402fe7563abf99ad00de2209e6 first commit 가장 재밌는 옵션은 format 옵션이다. 나만의 형식으로 결과를 출력하고 싶을 때 사용한다. 특 히 결과를 다른 프로그램으로 파싱하고자 할 때 유용하다. 이 옵션을 사용하면 형식을 정확하게 일치시킬 수 있기 때문에 Git을 새 버전으로 바꿔도 결과의 형식이 바뀌지 않는다: $ git log --pretty=format:"%h - %an, %ar : %s" ca82a6d - Scott Chacon, 11 months ago : changed the version number 085bb3b - Scott Chacon, 11 months ago : removed unnecessary test code a11bef0 - Scott Chacon, 11 months ago : first commit 표2.1 형식에서 사용하는 유용한 옵션들. Option Description of Output %H Commit hash %h Abbreviated commit hash %T Tree hash %t Abbreviated tree hash %P Parent hashes %p Abbreviated parent hashes %an Author name %ae Author e-mail %ad Author date (format respects the date= option) %ar Author date, relative %cn Committer name %ce Committer email %cd Committer date %cr Committer date, relative %s Subject 저자(Author) 와 커미터(Committer) 를 구분하는 것이 조금 이상해 보일 수 있다. 저자는 원래 작업을 수행한 원작자이고 커밋터는 마지막으로 이 작업을 적용한 사람이다. 만약 당신이 어떤 25

2장 Git의 기초 Scott Chacon Pro Git 프로젝트에 패치를 보냈고 그 프로젝트의 담당자가 패치를 적용했다면 두 명의 정보를 모두 알 필요가 있다. 그래서 이 경우 당신이 저자고 그 담당자가 커미터다.5장에서 이 주제에 대해 자세 히 다룰 것이다. oneline과 format 옵션은 --graph 옵션과 함께 사용할 때 더 빛난다. 이 명령은 브랜치와 머지 히스토리를 보여주는 아스키 그래프를 출력한다. 이 명령을 Grit 프로젝트 저장소에서 사용해 보면 다음과 같다: $ git log --pretty=format:"%h %s" --graph * 2d3acf9 ignore errors from SIGCHLD on trap * 5e3ee11 Merge branch 'master' of git://github.com/dustin/grit \ * 420eac9 Added a method for getting the current branch. * 30e367c timeout code and tests * 5a09431 add timeout protection to grit * e1193f8 support for heads with slashes in them / * d6016bc require time for xmlschema * 11d191e Merge branch 'defunkt' into local git log 명령의 기본적인 옵션과 출력물의 형식에 관련된 옵션을 살펴보았다. git log 명령은 앞서 살펴본 것보다 더 많은 옵션을 지원한다. 표2.2 는 지금 설명한 것과 함께 유용하게 사용할 수 있는 옵션들이다. 각 옵션으로 어떻게 log 명령을 제어할 수 있는지 보여준다. 옵션 설명 -p 각 커밋에 적용된 패치를 보여준다. --stat 각 커밋에서 수정된 파일의 통계정보를 보여준다. --shortstat `--stat` 명령의 결과 중에서 수정한 파일, 추가된 줄, 삭제된 줄만 보여준다. --name-only 커밋 정보중에서 수정된 파일의 목록만 보여준다. --name-status 수정된 파일의 목록을 보여줄 뿐만 아니라 파일을 추가한 것인지, 수정한 것인지, 삭제한 것 인지도 보여준다. --abbrev-commit 40자 짜리 SHA-1 체크섬을 전부 보여주는 것이 아니라 처음 몇 자만 보여준다. --relative-date 정확한 시간을 보여주는 것이 아니라 `2 주전`처럼 상대적인 형식으로 보여준다. --graph 브랜치와 머지 히스토리 정보까지 아스키 그래프로 보여준다. --pretty 지정한 형식으로 보여준다. 이 옵션에는 oneline, short, full, fuller, format이 있다. format 은 원하는 형식으로 출력하고자 할 때 사용한다. 2.3.1 조회 제한조건 출력 형식과 관련된 옵션들을 살펴봤지만 git log 명령은 조회 범위를 제한하는 옵션들도 있 다. 히스토리 전부가 아니라 부분만 조회한다. 이미 최근 두 개만 조회하는 -2 옵션은 살펴봤다. 실제 사용법은 -<n>이고 n은 최근 n개의 커밋을 의미한다. 사실 이 옵션은 잘 쓰이지 않는데, Git가 기본적으로 출력을 pager류의 프로그램을 거쳐서 내보내므로 한 번에 한 페이지씩 볼 수 있기 때문이다. 반면 --since나 --until같은 시간을 기준으로 조회하는 옵션은 매우 유용하다. 지난 2주 동안 만들어진 커밋들만 조회하는 명령은 다음과 같다: 26

Scott Chacon Pro Git 2.4절 되돌리기(Undo) $ git log --since=2.weeks 이 옵션은 다양한 형식을 지원한다. 2008-01-15같이 정확한 날짜도 사용할 수 있고 2 years 1 day 3 minutes ago같이 상대적인 기간을 사용할 수도 있다. 또 다른 기준도 있다. --author 옵션으로 저자를 지정하여 검색할 수도 있고 --grep 옵션으로 커밋 메시지에서 키워드를 검색할 수도 있다(author와 grep 옵션을 나눠서 지정하고 싶지 않으 면 --all-match 옵션으로 한 번에 검색할 수 있다). 마지막으로 파일 경로로 검색하는 옵션이 있는데 이것도 정말 유용하다. 디렉토리나 파일 이름 을 사용하여 그 파일이 변경된 log의 결과를 검색할 수 있다. 이 옵션은 --와 함께 경로 이름들 을 사용하는데 명령어 끝 부분에 쓴다(역주, git log -- path1 path2). 표2.3은 조회 범위를 제한하는 옵션들이다. 옵션 설명 -(n) 최근 n 개의 커밋만 조회한다. --since, --after 명시한 날짜 이후의 커밋만 검색한다. --until, --before 명시한 날짜 이전의 커밋만 조회한다. --author 입력한 저자의 커밋만 보여준다. --committer 입력한 커미터의 커밋만 보여준다. 다음의 예제는 2008년 10월에 Junio Hamano가 커밋한 히스토리를 조회하는 것이다. 그 중에 서 테스트 파일을 수정한 커밋 중에서 머지 커밋이 아닌 것들만 조회한다: $ git log --pretty="%h - %s" --author=gitster --since="2008-10-01" \ --before="2008-11-01" --no-merges -- t/ 5610e3b - Fix testcase failure when extended attribute acd3b9e - Enhance hold_lock_file_for_{update,append}() f563754 - demonstrate breakage of detached checkout wi d1a43f2 - reset --hard/read-tree --reset -u: remove un 51a94af - Fix "checkout --track -b newbranch" on detac b0ad11e - pull: allow "git pull origin $something:$cur 총 2만여 개의 커밋 히스토리에서 이 명령의 검색 조건에 만족하는 것은 단 6개였다. 2.3.2 GUI 도구를 사용하여 히스토리를 시각화하기 GUI 도구로 커밋 히스토리를 시각화하고 싶다면 gitk를 사용할 수 있다. gitk는 Tcl/Tk 프로그 램이고 git log 명령을 시각화해주는 도구다. gitk는 git log 명령이 지원하는 필터링 옵션을 거의 모두 지원한다. 프로젝트 디렉토리에서 gitk를 실행하면 그림2.2처럼 보일 것이다. 위쪽 반을 차지하는 윈도우에서는 히스토리를 그래프로 예쁘게 보여준다. 아래쪽 반을 차지하 는 윈도우는 diff 결과를 보여주는데 위쪽 윈도우에서 선택한 커밋에 대한 diff 결과를 보여준다. 2.4 되돌리기(Undo) 일을 하다보면 모든 단계에서 어떤 것은 되돌리고 싶을 때가 있다. 이번에는 우리가 한 일을 되 돌리는 방법을 살펴볼 것이다. 한 번 되돌리면 복구할 수 없어서 주의해야 한다. Git을 사용하면 27

2장 Git의 기초 Scott Chacon Pro Git 그림 2.2: gitk의 히스토리 우리가 한 실수를 복구하지 못할 것은 거의 없지만 되돌리기는 복구할 수 없다. 2.4.1 커밋 수정하기 종종 완료한 커밋을 수정해야 할 때가 있다. 너무 일찍 커밋했거나 어떤 파일을 빼먹었을 때 그 리고 커밋 메시지를 잘못 적었을 때 하게 된다. 다시 커밋하고 싶으면 --amend 옵션을 사용한다: $ git commit --amend 이 명령은 Staging Area를 사용하여 커밋한다. 만약 마지막으로 커밋하고 나서 수정한 것이 없 다면(커밋하자마자 바로 이 명령을 실행하는 경우) 조금 전에 한 커밋과 모든 것이 같을 것이다. 이 경우는 커밋 메시지만 수정하게 된다. 편집기가 실행되면 이전 커밋 메시지가 이미 포함돼 있다. 메시지를 수정하지 않고 그대로 커 밋해도 기존의 커밋을 덮어쓴다. 예를 들어 커밋을 했는데 Stage하는 것을 깜빡하고 빠트린 파일이 있으면 다음과 같이 고칠 수 있다: $ git commit -m 'initial commit' $ git add forgotten_file $ git commit --amend 여기서 실행한 명령어 3개는 모두 하나의 커밋으로 기록된다. 두 번째 커밋은 첫 번째 커밋을 덮어쓴다. 2.4.2 파일 상태를 Unstage로 변경하기 다음은 Staging Area와 작업 디렉토리 사이를 넘나드는 방법을 설명한다. 멋진 부분은, 두 영역 의 상태를 확인하기 위해 명령할 때마다, 변경된 상태를 되돌리는 명령을 상기시켜 준다는 점이 다. 예를 들어 파일을 두 개 수정했는데 따로따로 커밋하려고 했지만, 실수로 git add * 라고 실 28

Scott Chacon Pro Git 2.4절 되돌리기(Undo) 행해 버렸다. 두 파일 모두 Staging Area에 들어 있다. 이제 둘 중 하나를 어떻게 꺼낼까? 우선 git status 명령으로 확인해보자: $ git add. $ git status # On branch master # Changes to be committed: # (use "git reset HEAD <file>..." to unstage) # # modified: README.txt # modified: benchmarks.rb # Changes to be commited 밑에 git reset HEAD <file>...이라는 문장을 볼 수 있다. 이 명령 으로 Unstage 상태로 변경할 수 있다. benchmarks.rb 파일을 Unstage 상태로 변경해보자: $ git reset HEAD benchmarks.rb benchmarks.rb: locally modified $ git status # On branch master # Changes to be committed: # (use "git reset HEAD <file>..." to unstage) # # modified: README.txt # # Changed but not updated: # (use "git add <file>..." to update what will be committed) # (use "git checkout -- <file>..." to discard changes in working directory) # # modified: benchmarks.rb # 이 명령이 조금 어색하긴 하지만 일단 동작은 잘 수행되었다. benchmarks.rb 파일은 Unstage 상태가 됐다. 2.4.3 Modified 파일 되돌리기 어떻게 해야 benchmarks.rb 파일을 수정하고 나서 다시 되돌릴 수 있을까? 그러니까 최근 커 밋된 버전으로(아니면 처음 Clone했을 때처럼 작업 디렉토리에 처음 Checkout 한 그 내용으 로) 되돌리는 방법이 무얼까? git status 명령이 친절하게 알려준다. 바로 위에 있는 예제에서 Unstaged 부분을 보자: # Changed but not updated: # (use "git add <file>..." to update what will be committed) # (use "git checkout -- <file>..." to discard changes in working directory) # # modified: benchmarks.rb # 29