�ݺ�ߣ

Git from Google TechTalks Randal Schwatz 의 Google TechTalks slides * 일부의역 내용이나 번역 ( 의역 ) 이 맘에 안드시는분은 연락주시면 감사히 반영하겠습니다 . 일부 길어질수있는 추가 설명은 블로그 하단에 위치 합니다 . 이미 git 을 좀 사용하신분은 도움이 되지 않을수도 있습니다 .

Disclaimer git 의 시작과 함께함 ( 리누스 토발즈가 운좋게 Randal 근처로 이사옴 ㄷㄷ ) 작은 프로젝트에 사용 오랜 경력동안 다른 시스템도 사용해보았음 git 에 관련된 mailing-list 주시함 git 에 patch 를 기여 , UI 변화 제의 작은 팀과 함께 GIT 사용경험 큰팀과 GIT 사용경험은 전무

What is git? file tree 에 가해진 변경을 관리 Git 의 최적화 : 분산 개발 ( 리눅스 커널은 여러국가에서 동시에 개발됨 ) 많은 파일 집합 관리 ( 리눅스 커널은 35000 개 이상 ) 복잡한 병합 Merge 시험적 분기 Branch 만들기 ( 분기가 쉽다는것은 시험적으로 무엇인가 개발하는것을 독려하게 된다 . ) 빠름 ( 예 > diff, merge ) 견고함 ( 큰 프로젝트에서 견고함이 없으면 ... ) Git 이 고려하지 않은 최적화 : 파일 권한과 소유권 각 파일의 역사

Why git? 리눅스 커널 개발에 매우 중요 BitKeeper 의 대안 아무나 반영 commit 함 ( 분산적 특성 : 배포에 반영되는것은 선택적 ) 아무나 가능 : 트리 복제 로컬 개발과 테스트 변경 패치를 EMAIL 로 보내거나 마스터 저장소에 병합을 위한 별도 서버를 띄움 좀더 개발된 버젼에 변경사항의 병합 merge 을 도움 공개 접근

How does git do it? 보편적 공개 식별자 Universal Public Identifier ( SHA-1 40 char 문자열을 통해 파일 , 디렉토리등 가리지 않고 객체에 일관적인 접근을 가능케 함 ) SVK 같은것과 다름 ( 예 > 내 @245 가 너의 @992 이다 ) SVK 는 분산형 VCS( perl 로 만듬 ) 다중프로토콜 전송 지원 ( HTTP, SSH, GIT ) 효율적 오브젝트 저장소 모두가 저장소 전체 소유 ( 효율적 공간을 사용함 , 모든 변경 기록을 가지고 있음 ) 쉬운 분기 branching 과 병합 merge ( 장점 ) 반영이나 병합이 발생해도 공통분모를 추적할수있음 바이너리 패치 지원 ( jpeg 같은 이미지 다됨 )

The SHA1 is King <1> 모든 객체는 식별용 고유 SHA1 을 갖고 있다 . 오브젝트 ( object ) 구성 : Blobs( 파일의 내용 ) 트리 (Blobs 의 트리 , 이외의 트리 ) 트리의 위치변경만으로는 식별자가 변경되지 않으며 , 내용을 복사하지 않고 원본을 유지한다 . 복사본도 똑같음 반영 (Commit): A Tree 부모가 없거나 , 여러 부모가 있는 Tree( 주로 선형이며 , 여러 부모를 통해 병합 merge 할 수도 있다 . ) Why( 커밋 이유 남길수있다 )

The SHA1 is King <2> Tags: 오브젝트 ( 보통 commit 임 ) 주제를 포함 ( 식별자 , 예 > Kernel 2.6.18-194) 부가적인것은 통상적 Tag 를 생각하면 된다 .

Objects live in the repo Git 은 새 오브젝트를 효율적으로 생성한다 . 오브젝트는 일반적으로 추가되며 , 삭제되지 않는다 . 참조되지 않는 오브젝트 ( 예 > 지워진 branch, 추가됐지만 commit 되지 않을 것들 , etc ) 들은 garbage collect 될수 있다 . 오브젝트들은 참조되지 않을수 있다 . 파일시스템의 효율을 위해 pack 될수 있다 (git-gc 를 통해 청소할수있다 . packing 해서 다른곳에 저장 . 저장소를 일관적으로 최소 공간 유지 ) Packs 는 공간 효율을 위해 deltas( 오브젝트 ) 로 표현될수있다 .( 큰 파일하나에 작은 변화가 있을시 , 전부 저장하는 것이 아닌 변화만을 효율적으로 저장 ) Packs 는 저장소간의 정보 전송을 위해 사용될수 있다 .

Commits rule the repo 오브젝트 연결체의 최신 head 을 반영 commit 이 만들어낸다 . 그 최신 head 들중 특징적으로 "master" 라는 것이 있다 .( 처음 repo 만들때 생기는 최초의 분기 branch ) 다른 분기 branch 는 사용자의 의지에 의해 만들어짐 ( 예 > ' 버그 고침 A' 브랜치로 분기해서 문제를 수정한 연쇄적 반영 commits 의 최신 Head 을 통해 다시 master 로 병합 merge 한다 . ) 접근 가능한 모든 저장소 오브젝트들은 이 반영 commits 들의 최신 Head 으로부터 접근한다 . 특정 반영 시점으로 부터 트리 오브젝트를 추적해 디렉토리와 파일에 접근한다 . 부모 오브젝트를 추적하면 예전 반영 commit 들과 그들 각각의 트리를 접근할수 있다 .

Mapping objects to a file tree " 작업중인 트리 " 는 ".git" 디렉토리를 최상위 경로에 가지고 있다 . CVS, SVN 과는 달리 디렉토리 경로가 깊어져도 귀찮은 것 ( 예 > .svn ) 들이 없다 . ( "grep -r" 사용에도 편리 ) .git 디렉토리의 구성 : config - configuration 파일 ( .ini 스타일 ) objects/* - 오브젝트 저장소 refs/heads/* - 분기들 branches ( 예 > "master" ) refs/tags/* - tags logs/* - logs refs/remotes/* - 다른이들의 작업 추적 index - the "index cache" ( 후에 설명 ) HEAD - 분기중 하나를 가르킴 ( " 현재 사용중인 반영될 분기 " )

The index (or "cache") blob 오브젝트들의 디렉토리 " 다음 반영 commit " 을 뜻함 ( 반영을 한다는것은 index 를 다음 반영 next commit 으로 변형하는것을 말함 ) " 파일 추가 adding files " 는 대상을 인덱스에 넣는것을 말한다 .( 그러므로 익덱싱 하지 않는 대상의 변경사항은 추적되지 않는다 . ) 반영 commit 은 현제 index 를 실제 반영 오브젝트 real commit object 로 만든다 . HEAD 와 index 의 차이 Diff 는 반영 commit 하지 않은 변경사항 index 와 working dir 의 차이 Diff 는 추가 add 되지 않은 변경사항 index 는 병합 merge 중 충돌 conflict 사항 정보를 비포함한다

The great renaming controversy Git 은 명시적 이름변경 explicit renaming 을 사용하지 않으며 사용자가 하기를 기대하지 않는다 . 이름변경은 SHA1 비교를 통해 판단할수있다 . Copy-paste-edits 는 로그 logs 에 임시 유사성 법칙 ad-hoc similarity rules 을 적용해 검출가능 일반적으로 사람보다 컴퓨터가 유사성 찾기에 능하다 사용자가 명시적으로 접근시 잘못 될수 있다 . 이것은 병합 merge 를 방해한다 . 옳은 명시적 접근도 방해가 될수있다 . 결론 : 내용을 추적하는것이 , 내용을 담는 컨테이너를 추적하는것보다 유연하고 정확하다 .

Git speaks and listens 저장소 repo 간 많은 프로토콜을 통해 git data 를 전송 rsync, http, https, git, ssh, local files Git Core 가 포함 : CVS 를 import/export SVN 을 import/export Arch 를 import CVS/SVN import 를 통해 프로젝트의 전체 history 를 어디서든 offline 으로 접근가능 써드파트 솔루션들이 또한 존재 ( 예 > Perforce) 레거시를 고집하는 사람을 위한 CVS server 도 포함한다 .

Getting Git http://www.kernel.org/pub/software/scm/git/ 에서 최신 git-*.tar.gz 을 통해 RPMs 과 Debian 패키지 git 을 부트스트랩했을 경우 , git-developer archive 를 git-clone ! - git-clone git://git.kernel.org/pub/scm/git/git.git 한주에 한번정도 리빌드 ( 별문제 없다 ) Maintenance Release 는 매우 안정적

Git commands 모든 git 명령은 "git-" 으로 시작 "git-MUMBLE-FOO bar" = "git MUMBLE-FOO bar" 위와 같으므로 "git" 하나만 /usr/local/bin 에 추가해서 실행 가능 내부 호출 internal call 도 잘동작 도움말 manpages 은 "git-MUMBLE-FOO" 형태로 존재 . 그러므로 위 방식도 알아야한다 . 다른 방법으로 git help MUMBLE-FOO 도 가능

"The internet is just a series of tubes" 저수준 git 작업 low-level git operation 은 배관 plumbing 이라 한다 . 고수준 git 작업 higher level action 은 자기 porcelain 이라 한다 . 곁다리는 Blog 하단에 설명 git 배포판은 git 배관 plumbing 과 자기 porcelain 를 둘다 포함 나머지 슬라이드는 따로 언급하지 않는 이상 git 자기 porcelain 를 통해 이야기 다른 자기 porcelain 가 존재 : StGit : stacked git guilt tig(curses-based viewer) qgit

Creating a repo git-init 현재 경로에 .git 을 만든다 . Optional: .gitignore 을 편집해서 무시할 파일 지정 "git-add ." 로 경로로부터 모든 파일 추가 (.git 제외 ) 그러면 "master" 란 분기 branch 가 만들어진다 . 최신 Head 은 "master" 를 가르키게 된다 . git-clone REMOTESPEC git 저장소 repo 를 다른 저장소로부터 복제 일반적으로 하위디렉토리를 만든다 . 작업할 파일들 working copy 와 .git 이 그곳에 위치 원격지의 모든 분기 remote branch 들은 추적 tracked 된다 . 원격지의 최종 분기 Head Branch 가 사용자의 초기 master 분기로 지정된다 .

Think globally, work locally 일반적으로 사용자의 결과물은 추가 반영 commits 들이다 . 반영 commits 들은 항상 분기 branch 에 속해있다 . 분기 branch 는 이름지어진 반영 commit 이다 . 사용자가 반영 commit 하게 되면 이전 분기의 최신 head 은 부모 parent 가 됩니다 . 새 반영의 부모가 된다는 의미 분기의 최신 branch head 은 새 반영 new commit 을 가르키게 됩니다 . 사용자는 분기 최신 Branch Head 을 루트 root 로 하는 DAG( Directed acyclic graph ) 를 만드는 셈이다 . 병합 merge 은 다중부모 multiple parent 를 둔 반영 commit 이다 .

Typical work flow 편집 git-add files ( 사용자의 변경사항 ) file 을 index 에 추가함 "git-add ." 이 무시 ignore 하는 것들을 제외한것들을 추가 git-status 최신 Head 과 인덱스 index , 작업경로간의 차이점 diff 을 알림 git-commit ( 사용자 반영 commit 이 준비됐을때 ) 로그 log 를 기록할수 있는 텍스트 편집기뜬다 첫행은 " 짧은 로그 log " 를 기록하는곳 현재 분기 current branch 의 개발 일보 전진됨 이제 사용자는 개발을 위해 좀더 편집

But which branch? <1> 이전 언급처럼 Git 은 분기 branch 를 독려 분기 branch 는 40 바이트 짜리 문자열과 '' : 적은비용 전형적인 진행방식 : 무엇을 할지 정한다 . 새 분기를 만든다 : git-checkout -b topic-name master 개발 , 개발 , 개발 , 그리고 topic-name 에 반영 commit 분기 개발이 끝나면 : git-checkout master : master 분기로 돌아간다 git-merge topic-name : 개발완료된 분기 병합 git-branch -d topic-name 분기가 HEAD 로부터 나올때만 영구삭제 허용 " 더이상 추적 안함 " 을 포함하는 의미

But which branch? <2> 각각의 반영 commit 을 표시함 모든 작업 commits 을 하나의 반영 a commit 으로 압축 flatten 하고 싶을때 : git-merge --squash --no-commit t; git-commit ( 예 > 17 번의 반영을 모아 커다란 한번의 반영으로 )

Working in parallel 여러가지 목표를 동시에 개발가능 : 아래는 동시다발적 예시 git-checkout -b topic1 master 개발 , 개발 ; 반영 commit ; 개발 , 개발 ; 반영 commit git-checkout -b topic2 master 개발 , 개발 ; 반영 commit ; git-checkout topic1 ; 개발 개발 ; 반영 commit 이제 이 작업들을 어떻게 최종 제품에 반영할것인가 병합 merge : 병행 히스토리 parallel history 그래프도 여러 갈래가 하나로 병합됨 기반 - 재설정 rebase : 순차적 히스토리 serial history 기반이 분기 최신 head 앞으로 연결되어 선형화

The merge <1> git-checkout master git-merge topic1; git-branch -d topic1 이런 사소한 병합 trivial merge 은 "fast forward" merge 라 함 이런 경우는 보통 사소한 변경 , 그저 병합하면 끝 git-merge topic2 현재 master 에 없는 추가 변경사항이 들어있는 경우 이런 경우 충돌 conflicts 가 날수 있다 : 변경사항이 겹칠수 있다 . 파일 이름을 분기간에 서로 다르게 변경하였을때

The merge <2> 사용자가 충돌을 해결하고 진행 : git-add 사용자가 변경한것들 혹은 git-add . git-commit ( 병합 충돌을 어떻게 해결했는지 기술 ) 병합 중단 ( 다른 옵션이다 ): 병합을 undo 할수있음을 뜻함 git-reset --hard HEAD

The rebase <1> 특정 분기의 반영들을 다른 분기 branch 로 옮긴다 . SHA1 을 깨트린다 : 대상 반영 commit 들은 추적불가 반영 commit 을 옮기면 그 반영을 다시 작성 rewrite 함으로서 새로운 반영이 되는것이다 . SHA1 이 다름 . 공개 혹은 원격 저장소 repo 에 반영 commits 을 밀어 ( push or published) 넣었을 경우 기반 - 재설정 rebase 을 하지 말것 이것은 주로 로컬에서 유용한 기능이란 소리 git-rebase master topic master 를 제외한 topic 의 변경사항이 master 에 기반하여 재작성된다 . 추가설명은 Blog 하단에

The rebase <2> 기반 - 재설정 rebase 는 병합 충돌 merge conflict 할 가능성이 있음 . 재설정시 기반이 바꾸고 그 위에 분기의 변경을 다시 적용하기때문에 가능성이있다 . git-rebase --continue or --abort or --skip 위의 명령으로 수정하고 진행하던지 중단하던지 건너 띌수 있다 . git-rebase -i ( 상호작용 interactive ) 유용하다 . 텍스트 에디터를 띄워 여러가지 작업을 도와준다 . 기반 - 재설정 rebase 이 되었을때 병합은 "fast forward" 이다 git-checkout master; git-merge topic

Read the history git-log 변경들을 출력해준다 git-log -p 변경들을 리비전 revisions 사이의 diff 를 포함해 출력 git-log --stat diffstat 을 생성해 변경사항을 요약 출력 git-log file1 file2 file3 나열된 파일이나 경로들의 변경을 보여준다 .

What's the difference? git-diff index 와 작업공간 working tree 사이의 차이 여기 나오는것들이 "git-add" 해야할 대상 "git-commit -a" 이 목록을 비운다 . git-diff head 최신 HEAD 과 작업공간 working tree 사이의 차이 "git-commit -a" 이 목록을 비운다 . git-diff --cached HEAD 와 index 사이의 차이 "git-commit -a" 이 목록을 비운다 . git-diff BRANCH_A : 분기 A 최신 Head 과 작업공간의 차이 git-diff BRANCH_A BRANCH_B : 분기 A,B 최신간 차이

Barking up the tree 많은 명령들이 "tree-ish" 라 불리우는것을 인자로 받는다 . SHA1 은 절대적인 오브젝트를 가져온다 . SHA1 전체가 아닌 첫 8~9 자만인 줄임 표현으로도 애매하지 않고 , 고유한 것이라면 가능 목록 A : HEAD, 분기이름 , 태그이름 , origin 이름 목록 A 뒤에 아래 표기법을 적용할수있다 . ^n - " 아이템의 n 번째 부모 " ( 기본 1) ~n 은 n^1 의 횟수 (~3 은 ^1^1^1 이 된다 .) :path - tree 로부터 오브젝트를 선택 예 > git-diff HEAD^ HEAD 최신 반영 commit 과 이전 반영 commit 의 차이 예 >git-dff HEAD~3 HEAD : 마지막 세 반영이 뭘했나 ?

Seeing the changes side by side gitk mytopic origin History 를 Tk widget 으로 표시 (graphical) 사용자가 원하는 차이점을 GUI 를 통해 보여줌 gitk -all 모든 정보를 다 보임 gitk from..to from 에 없는 to 에 있는 변경사항을 보임 git-show-branch myTopic...origin Tk 가 했던것과 같음 qgit 도 한번 봐볼것은 권함 발표때와 달리 지금은 상당히 많은 front-end 가 존재

Playing well with others <1> git-clone 추적지 tracking 혹은 원격지 remote 분기 branch 생성 보통 이 분기는 "origin/master" 라고 이름지어진다 사용자 작업을 공유하기 위해 일단 원본을 최신 유지 : git-fetch ( 원격지로부터 사용자의 origin 분기 갱신 ) 사용자의 변경에 상위작업공간 upstream 을 기반 - 재설정 rebase: 모두 기반 base 이 다르게 분기하면 복잡해진다 . git-checkout master # 혹은 분기명 git-rebase origin/master

Playing well with others <2> 상위 작업공간 Upstream 에 넣기 push: git-push 상위 작업공간에 넣기 push 권한이 없을경우 : git-format-patch origin/master 그리고 현재 경로에 생긴 패치를 전자메일로 보낸다 .

Keeping things clean git-gc 참조하지 않는 오브젝트를 위한 garbage-collector 저장소의 오브젝트들이 유효한지 확인 오브젝트를 모아 큰 공간 container 에 다시 담는다 : R epack 이유 : 접근성과 공간사용의 효율성 git-gc --prune 접근불가한 오브젝트를 삭제 위험한 작업이다 . 다른 것과 연관있을때 절대 하지말것 .

Resetting git-reset --soft 목표 인덱스 , 작업공간은 건드리지 않고 최신 HEAD 만 목표로 git-reset --hard # 위험 작업공간 working dir 을 마지막 반영 commit 으로 되돌린다 . git-reset --hard HEAD~3 가장 최근 세 반영 commit 을 취소하고 작업공간 working dir 을 그에 맞춰 바꿔준다 . 이미 분기를 배포했다면 , git-revert 를 사용하자 . git-checkout HEAD 복구대상 마지막 반영 commit 에 있는 복구대상을 가져온다 .

Pay no attention to the man behind the curtain 모든 경로가 .gitignore 를 지닐수 있다 . 행의 시작 문자가 "!" 이면 , 부정 연산자 역활을 한다 . 행이 "/" 를 제외하고 있다면 basename 으로 확인함 basename 은 unix program 이다 . [ 링크 ] 이외엔 fnmatch(3) 를 통해 shell 이 패턴매칭을 함 "/" 로 시작하면 현재 경로를 뜻함 저장소 repo 에 저장되고 추적됨 .git/info/exclude 를 통해 .gitignore 와 비슷한 동작을 할수있는데 이는 사용자 저장소 repo 에만 해당한다 . 두개다 같이 동작하지만 , 후자는 복제 clone 되지 않는다 .

Configuration 많은 명령은 환경설정 configurations 를 가질수있다 . git-config name value name 에 값 value 을 대입 name 에 "." 을 붙여 종속된 속성 을 지닐수 있다 . 예 > git config core. filemode true 원한다면 수동으로 편집가능 git-config name 현재 값 value 을 보임 git-config -l 설정값들을 나열 최소한 user.email 과 user.name 을 반영 commit 을 위해 설정

other useful porcelain git-archive : tar/zip 형태로 tree 를 내보냄 git-bisect : 문제있는 반영과 아닌것사이의 적정 반영찾기 git-cherry-pick : 선택적 병합 selective merging git-mv : file/dir 을 올바른 인덱스 조작으로 이름 바꿈 git-push : 상위 작업공간 upstream 에 넣기 git-revert : 이전 반영 commit 을 무효화하는 반영 commit git-blame : 누가 작성한것인지

For further info "Git (softwware)" 를 Wikipedia 에서 찾아볼것 [ 링크 ] git homepage http://git.or.cz Git wiki https://git.wiki.kernel.org/index.php/Main_Page mailing list 활용 도움될만한 사람들이 있다 . 사용자가 버그 리포트 , 패치 , 아이디어 제공 가능 git 사용자들과 만나보자 Freenode IRC 에 #git 채널이 있음

�ݺ�ߣ

Git from google techtalks by Randal

More Related Content

Git from google techtalks by Randal