Your SlideShare is downloading. ×
Git from google techtalks by Randal
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Saving this for later?

Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime - even offline.

Text the download link to your phone

Standard text messaging rates apply

Git from google techtalks by Randal

1,415
views

Published on

Published in: Technology

0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
1,415
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
0
Comments
0
Likes
2
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Git from  Google TechTalks
      • Randal Schwatz 의 Google TechTalks slides * 일부의역
      • 내용이나 번역 ( 의역 ) 이 맘에 안드시는분은 연락주시면 감사히 반영하겠습니다 .
      • 일부 길어질수있는 추가 설명은 블로그 하단에 위치 합니다 .
      • 이미 git 을 좀 사용하신분은 도움이 되지 않을수도 있습니다 .
  • 2. Disclaimer
      • git 의 시작과 함께함 ( 리누스 토발즈가 운좋게  Randal  근처로 이사옴 ㄷㄷ )
      • 작은 프로젝트에 사용
      • 오랜 경력동안 다른 시스템도 사용해보았음
      • git 에 관련된 mailing-list 주시함
      • git 에 patch 를 기여 , UI 변화 제의
      • 작은 팀과 함께 GIT 사용경험
      • 큰팀과 GIT 사용경험은 전무
  • 3. What is git?    
      • file tree 에 가해진 변경을 관리
      • Git 의 최적화 :
        • 분산 개발 ( 리눅스 커널은 여러국가에서 동시에 개발됨 )
        • 많은 파일 집합 관리 ( 리눅스 커널은 35000 개 이상 )
        • 복잡한 병합 Merge
        • 시험적 분기 Branch 만들기 ( 분기가 쉽다는것은 시험적으로 무엇인가 개발하는것을 독려하게 된다 . )
        • 빠름 ( 예 > diff, merge )
        • 견고함 ( 큰 프로젝트에서 견고함이 없으면 ... )
      • Git 이 고려하지 않은 최적화 :
        • 파일 권한과 소유권
        • 각 파일의 역사
  • 4. Why git?
      • 리눅스 커널 개발에 매우 중요
      • BitKeeper 의 대안
      • 아무나 반영 commit 함 ( 분산적 특성 : 배포에 반영되는것은 선택적 )
      • 아무나 가능 :
        • 트리 복제
        • 로컬 개발과 테스트
        • 변경 패치를 EMAIL 로 보내거나 마스터 저장소에 병합을 위한 별도 서버를 띄움
        • 좀더 개발된 버젼에 변경사항의 병합 merge 을 도움
        • 공개 접근
  • 5. How does git do it?
      • 보편적 공개 식별자 Universal Public Identifier ( SHA-1 40 char 문자열을 통해 파일 , 디렉토리등 가리지 않고 객체에 일관적인 접근을 가능케 함 )
        • SVK 같은것과 다름 ( 예 > 내 @245 가 너의 @992 이다 )
        • SVK 는 분산형 VCS( perl 로 만듬 )
      • 다중프로토콜 전송 지원 ( HTTP, SSH, GIT )
      • 효율적 오브젝트 저장소
      • 모두가 저장소 전체 소유 ( 효율적 공간을 사용함 , 모든 변경 기록을 가지고 있음 )
      • 쉬운 분기 branching 과 병합 merge ( 장점 )
        • 반영이나 병합이 발생해도 공통분모를 추적할수있음
      • 바이너리 패치 지원 ( jpeg 같은 이미지 다됨 ) 
  • 6. The SHA1 is King <1>
      • 모든 객체는 식별용 고유 SHA1 을 갖고 있다 .
      • 오브젝트 ( object ) 구성 :
        • Blobs( 파일의 내용 )
        • 트리 (Blobs 의 트리 , 이외의 트리 )
          • 트리의 위치변경만으로는 식별자가 변경되지 않으며 , 내용을 복사하지 않고 원본을 유지한다 . 복사본도 똑같음
        • 반영 (Commit):
          • A Tree
          • 부모가 없거나 , 여러 부모가 있는 Tree( 주로 선형이며 , 여러 부모를 통해 병합 merge 할 수도 있다 . )
          • Why( 커밋 이유 남길수있다 )
  • 7. The SHA1 is King <2>
      • Tags:
        • 오브젝트 ( 보통 commit 임 )
        • 주제를 포함 ( 식별자 , 예 > Kernel 2.6.18-194)
        • 부가적인것은 통상적 Tag 를 생각하면 된다 .
  • 8. Objects live in the repo
      • Git 은 새 오브젝트를 효율적으로 생성한다 .
      • 오브젝트는 일반적으로 추가되며 , 삭제되지 않는다 .
      • 참조되지 않는 오브젝트 ( 예 > 지워진 branch, 추가됐지만 commit 되지 않을 것들 , etc ) 들은 garbage collect 될수 있다 .
      • 오브젝트들은 참조되지 않을수 있다 . 파일시스템의 효율을 위해 pack 될수 있다 (git-gc 를 통해 청소할수있다 . packing 해서 다른곳에 저장 . 저장소를 일관적으로 최소 공간 유지 )
      • Packs 는 공간 효율을 위해 deltas( 오브젝트 ) 로 표현될수있다 .( 큰 파일하나에 작은 변화가 있을시 , 전부 저장하는 것이 아닌 변화만을 효율적으로 저장 )
      • Packs 는 저장소간의 정보 전송을 위해 사용될수 있다 .
  • 9. Commits rule the repo
      • 오브젝트 연결체의 최신 head 을 반영 commit 이 만들어낸다 .
      • 그 최신 head 들중 특징적으로 &quot;master&quot; 라는 것이 있다 .( 처음 repo  만들때 생기는 최초의 분기 branch )
      • 다른 분기 branch 는 사용자의 의지에 의해 만들어짐 ( 예 > ' 버그 고침 A' 브랜치로 분기해서 문제를 수정한 연쇄적 반영 commits 의 최신 Head 을 통해 다시 master 로 병합 merge 한다 . )
      • 접근 가능한 모든 저장소 오브젝트들은 이 반영 commits 들의 최신 Head 으로부터 접근한다 .
        • 특정 반영 시점으로 부터 트리 오브젝트를 추적해 디렉토리와 파일에 접근한다 .
        • 부모 오브젝트를 추적하면 예전 반영 commit 들과 그들 각각의 트리를 접근할수 있다 .
  • 10. Mapping objects to a file tree
      • &quot; 작업중인 트리 &quot; 는 &quot;.git&quot; 디렉토리를 최상위 경로에 가지고 있다 .
      • CVS, SVN 과는 달리 디렉토리 경로가 깊어져도 귀찮은 것 ( 예 > .svn ) 들이 없다 . ( &quot;grep -r&quot; 사용에도 편리 )
      • .git 디렉토리의 구성 :
        • config - configuration 파일 ( .ini 스타일 )
        • objects/* - 오브젝트 저장소
        • refs/heads/* - 분기들 branches ( 예 > &quot;master&quot; )
        • refs/tags/* - tags
        • logs/* - logs
        • refs/remotes/* - 다른이들의 작업 추적
        • index - the &quot;index cache&quot; ( 후에 설명 )
        • HEAD - 분기중 하나를 가르킴 ( &quot; 현재 사용중인 반영될 분기 &quot; )
  • 11. The index (or &quot;cache&quot;)
      • blob 오브젝트들의 디렉토리
      • &quot; 다음 반영 commit &quot; 을 뜻함 ( 반영을 한다는것은 index 를 다음 반영 next commit 으로 변형하는것을 말함 )
      • &quot; 파일 추가 adding files &quot; 는 대상을 인덱스에 넣는것을 말한다 .( 그러므로 익덱싱 하지 않는 대상의 변경사항은 추적되지 않는다 . )
      • 반영 commit 은 현제 index 를 실제 반영 오브젝트 real commit object 로 만든다 .
      • HEAD 와 index 의 차이 Diff 는 반영 commit 하지 않은 변경사항
      • index 와 working dir 의 차이 Diff 는 추가 add 되지 않은 변경사항
      • index 는 병합 merge 중 충돌 conflict 사항 정보를 비포함한다
  • 12. The great renaming controversy
      • Git 은 명시적 이름변경 explicit renaming 을 사용하지 않으며 사용자가 하기를 기대하지 않는다 .
      • 이름변경은 SHA1 비교를 통해 판단할수있다 .
      • Copy-paste-edits 는 로그 logs 에 임시 유사성 법칙 ad-hoc similarity rules 을 적용해 검출가능
      • 일반적으로 사람보다 컴퓨터가 유사성 찾기에 능하다
      • 사용자가 명시적으로 접근시 잘못 될수 있다 . 이것은 병합 merge 를 방해한다 . 옳은 명시적 접근도 방해가 될수있다 .
      • 결론 : 내용을 추적하는것이 , 내용을 담는 컨테이너를 추적하는것보다 유연하고 정확하다 .
  • 13. 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 도 포함한다 . 
  • 14. 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 는 매우 안정적
  • 15. Git commands
      • 모든 git 명령은 &quot;git-&quot; 으로 시작
      • &quot;git-MUMBLE-FOO bar&quot; = &quot;git MUMBLE-FOO bar&quot;
      • 위와 같으므로 &quot;git&quot; 하나만 /usr/local/bin 에 추가해서     실행 가능
      • 내부 호출 internal call 도 잘동작
      • 도움말 manpages 은 &quot;git-MUMBLE-FOO&quot; 형태로 존재 . 그러므로 위 방식도 알아야한다 .
        • 다른 방법으로 git help MUMBLE-FOO 도 가능
  • 16. &quot;The internet is just a series of tubes&quot;
      • 저수준 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
  • 17. Creating a repo   
      • git-init
        • 현재 경로에 .git 을 만든다 .
        • Optional: .gitignore 을 편집해서 무시할 파일 지정
        • &quot;git-add .&quot; 로 경로로부터 모든 파일 추가 (.git 제외 )
        • 그러면 &quot;master&quot; 란 분기 branch 가 만들어진다 .
        • 최신 Head 은 &quot;master&quot; 를 가르키게 된다 .
      • git-clone REMOTESPEC 
        • git 저장소 repo 를 다른 저장소로부터 복제
        • 일반적으로 하위디렉토리를 만든다 .
        • 작업할 파일들 working copy 와 .git 이 그곳에 위치
        • 원격지의 모든 분기 remote branch 들은 추적 tracked 된다 .
        • 원격지의 최종 분기 Head Branch 가 사용자의 초기 master 분기로 지정된다 .
  • 18. 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 이다 .
  • 19. Typical work flow
      • 편집
      • git-add files ( 사용자의 변경사항 )
        • file 을 index 에 추가함
        • &quot;git-add .&quot; 이 무시 ignore 하는 것들을 제외한것들을 추가
      • git-status
        • 최신 Head 과 인덱스 index , 작업경로간의 차이점 diff 을 알림
      • git-commit  ( 사용자 반영 commit 이 준비됐을때 )
        • 로그 log 를 기록할수 있는 텍스트 편집기뜬다
        • 첫행은 &quot; 짧은 로그 log &quot; 를 기록하는곳
      • 현재 분기 current branch 의 개발 일보 전진됨
      • 이제 사용자는 개발을 위해 좀더 편집
  • 20. But which branch? <1>
      • 이전 언급처럼 Git 은 분기 branch 를 독려
        •   분기 branch 는 40 바이트 짜리 문자열과 'n' : 적은비용
      • 전형적인 진행방식 :
        • 무엇을 할지 정한다 .
        • 새 분기를 만든다 : git-checkout -b topic-name master
        • 개발 , 개발 , 개발 , 그리고 topic-name 에 반영 commit
      • 분기 개발이 끝나면 :
        • git-checkout master : master 분기로 돌아간다
        • git-merge topic-name : 개발완료된 분기 병합
        • git-branch -d topic-name
          • 분기가 HEAD 로부터 나올때만 영구삭제 허용 &quot; 더이상 추적 안함 &quot; 을 포함하는 의미
  • 21. But which branch? <2>
      • 각각의 반영 commit 을 표시함
      • 모든 작업 commits 을 하나의 반영 a   commit 으로 압축 flatten 하고 싶을때 :
        •   git-merge --squash --no-commit t; git-commit
          •   ( 예 > 17 번의 반영을 모아 커다란 한번의 반영으로 )
  • 22. 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 앞으로 연결되어 선형화
  • 23. The merge <1>
      • git-checkout master
      • git-merge topic1; git-branch -d topic1
        • 이런 사소한 병합 trivial   merge 은 &quot;fast forward&quot; merge 라 함
          • 이런 경우는 보통 사소한 변경 , 그저 병합하면 끝
      • git-merge topic2
        • 현재 master 에 없는 추가 변경사항이 들어있는 경우
      • 이런 경우 충돌 conflicts 가 날수 있다 :
        • 변경사항이 겹칠수 있다 .
        • 파일 이름을 분기간에 서로 다르게 변경하였을때
  • 24. The merge <2>
      • 사용자가 충돌을 해결하고 진행 :
        • git-add 사용자가 변경한것들
          • 혹은 git-add .
        • git-commit ( 병합 충돌을 어떻게 해결했는지 기술 )
      • 병합 중단 ( 다른 옵션이다 ): 병합을 undo 할수있음을 뜻함
        • git-reset --hard HEAD
  • 25. The rebase <1>
      • 특정 분기의 반영들을 다른 분기 branch 로 옮긴다 .
      • SHA1 을 깨트린다 : 대상 반영 commit 들은 추적불가
        • 반영 commit 을 옮기면 그 반영을 다시 작성 rewrite 함으로서 새로운 반영이 되는것이다 . SHA1 이 다름 .
        • 공개 혹은 원격 저장소 repo 에 반영 commits 을 밀어 ( push or published) 넣었을 경우 기반 - 재설정 rebase 을 하지 말것
          • 이것은 주로 로컬에서 유용한 기능이란 소리
      • git-rebase master topic
        • master 를 제외한 topic 의 변경사항이 master 에 기반하여 재작성된다 . 
          • 추가설명은 Blog 하단에
  • 26. The rebase <2>
      • 기반 - 재설정 rebase 는 병합 충돌 merge conflict 할 가능성이 있음 .
        • 재설정시 기반이 바꾸고 그 위에 분기의 변경을 다시 적용하기때문에 가능성이있다 .
        • git-rebase --continue or --abort or --skip
        • 위의 명령으로 수정하고 진행하던지 중단하던지 건너 띌수 있다 .
      • git-rebase -i ( 상호작용 interactive ) 유용하다 .
        • 텍스트 에디터를 띄워 여러가지 작업을 도와준다 .
      • 기반 - 재설정 rebase 이 되었을때 병합은 &quot;fast forward&quot; 이다
        • git-checkout master; git-merge topic
  • 27. Read the history
      • git-log
        • 변경들을 출력해준다
      • git-log -p
        • 변경들을 리비전 revisions   사이의 diff 를 포함해 출력
      • git-log --stat
        • diffstat 을 생성해 변경사항을 요약 출력
      • git-log file1 file2 file3
        • 나열된 파일이나 경로들의 변경을 보여준다 .
    •  
  • 28. What's the difference?
      • git-diff
        • index 와 작업공간 working tree 사이의 차이
        • 여기 나오는것들이 &quot;git-add&quot; 해야할 대상
        • &quot;git-commit -a&quot; 이 목록을 비운다 .
      • git-diff head
        • 최신 HEAD 과 작업공간 working tree 사이의 차이
        • &quot;git-commit -a&quot; 이 목록을 비운다 .
      • git-diff --cached
        • HEAD 와 index 사이의 차이
        • &quot;git-commit -a&quot; 이 목록을 비운다 . 
      • git-diff BRANCH_A : 분기 A 최신 Head 과 작업공간의 차이
      • git-diff BRANCH_A BRANCH_B : 분기 A,B 최신간 차이
  • 29. Barking up the tree
      • 많은 명령들이 &quot;tree-ish&quot; 라 불리우는것을 인자로 받는다 .
      • SHA1 은 절대적인 오브젝트를 가져온다 .
        • SHA1 전체가 아닌 첫 8~9 자만인 줄임 표현으로도 애매하지 않고 , 고유한 것이라면 가능
      • 목록 A : HEAD, 분기이름 , 태그이름 , origin 이름
      • 목록 A 뒤에 아래 표기법을 적용할수있다 .
        • ^n - &quot; 아이템의 n 번째 부모 &quot; ( 기본 1)
        • ~n 은 n^1 의 횟수 (~3 은 ^1^1^1 이 된다 .)
        • :path - tree 로부터 오브젝트를 선택
      • 예 > git-diff HEAD^ HEAD
        • 최신 반영 commit 과 이전 반영 commit 의 차이
      • 예 >git-dff HEAD~3 HEAD : 마지막 세 반영이 뭘했나 ?
  • 30. 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 가 존재
  • 31. Playing well with others <1>
      • git-clone 추적지 tracking 혹은 원격지 remote 분기 branch 생성
      • 보통 이 분기는 &quot;origin/master&quot; 라고 이름지어진다
      • 사용자 작업을 공유하기 위해 일단 원본을 최신 유지 :
        • git-fetch ( 원격지로부터 사용자의 origin 분기 갱신 )
      • 사용자의 변경에 상위작업공간 upstream 을 기반 - 재설정 rebase:
        • 모두 기반 base 이 다르게 분기하면 복잡해진다 .
        • git-checkout master # 혹은 분기명
        • git-rebase origin/master
  • 32. Playing well with others <2>
      • 상위 작업공간 Upstream 에 넣기 push:
        • git-push
      • 상위 작업공간에 넣기 push  권한이 없을경우 :
        • git-format-patch origin/master
        • 그리고 현재 경로에 생긴 패치를 전자메일로 보낸다 .
  • 33. Keeping things clean
      • git-gc
        • 참조하지 않는 오브젝트를 위한 garbage-collector 
        • 저장소의 오브젝트들이 유효한지 확인
        • 오브젝트를 모아 큰 공간 container 에 다시 담는다 : R epack
          • 이유 : 접근성과 공간사용의 효율성
      • git-gc --prune
        • 접근불가한 오브젝트를 삭제
        • 위험한 작업이다 .
        • 다른 것과 연관있을때 절대 하지말것 .
  • 34. 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 에 있는 복구대상을 가져온다 .
  • 35. Pay no attention to the man behind the curtain
      • 모든 경로가 .gitignore 를 지닐수 있다 .
        • 행의 시작 문자가 &quot;!&quot; 이면 , 부정 연산자 역활을 한다 .
        • 행이 &quot;/&quot; 를 제외하고 있다면 basename 으로 확인함
          • basename 은 unix program 이다 . [ 링크 ]
        • 이외엔 fnmatch(3) 를 통해 shell 이 패턴매칭을 함
        • &quot;/&quot; 로 시작하면 현재 경로를 뜻함
      • 저장소 repo 에 저장되고 추적됨
      •   .git/info/exclude 를 통해 .gitignore 와 비슷한 동작을 할수있는데 이는 사용자 저장소 repo 에만 해당한다 .
      • 두개다 같이 동작하지만 , 후자는 복제 clone 되지 않는다 .
  • 36. Configuration
      • 많은 명령은 환경설정 configurations 를 가질수있다 .
      • git-config name value
        • name 에 값 value 을 대입
        • name 에 &quot;.&quot; 을 붙여 종속된 속성 을 지닐수 있다 .
          • 예 > git config core. filemode  true
        • 원한다면 수동으로 편집가능
      • git-config name
        • 현재 값 value 을 보임
      • git-config -l
        • 설정값들을 나열
      • 최소한 user.email 과 user.name 을 반영 commit 을 위해 설정
  • 37. 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 : 누가 작성한것인지 
  • 38. For further info
      • &quot;Git (softwware)&quot; 를 Wikipedia 에서 찾아볼것 [ 링크 ]
      • git homepage http://git.or.cz 
      • Git wiki https://git.wiki.kernel.org/index.php/Main_Page
      • mailing list 활용
        • 도움될만한 사람들이 있다 .
        • 사용자가 버그 리포트 , 패치 , 아이디어 제공 가능
        • git 사용자들과 만나보자
      • Freenode IRC 에 #git 채널이 있음