ko/multiplayer.txt

   1 == Git은 멀티플레이어 ==
   2
   3 제가 과거에 단독 개발자였던 시절부터 Git을 사용해 오고있었습니다.
   4 그 당시엔 여태까지 소개했던 많은 명령어들 중 *pull*과 *clone*정도만 사용하여
   5 같은 프로젝트를 여러 디렉토리에 저장하는데 사용하였습니다.
   6
   7 시간이 지난 후 Git에 제가 만든 코드를 올리고 싶었고 다른 개발자들이
   8 한 작업도 반영하고 싶었습니다. 저는 전 세계의 많은 개발자들을
   9 관리하는 방법을 배워야 했습니다. 다행히도 이런 일을 도와주는 것은  Git의 가장 큰 힘입니다.
  10 Git이 존재하는 이유이기도 하지요.
  11
  12 === 난 누굴까? ===
  13
  14 각 commit은 작성자의 이름과 작성자의 이메일주소를 저장합니다. 이 목록은 *git log*를 사용해 조회할 수 있습니다.
  15 기본설정 상 Git은 시스템에 이미 기본으로 세팅이 되어있는 정보를 이용해 작성자의 이름과 이메일주소를 저장합니다.
  16 그러나 수동으로 이름과 이메일주소를 설정하려면:
  17
  18   $ git config --global user.name "John Doe"
  19   $ git config --global user.email johndoe@example.com
  20
  21 를 사용하여 지정해 주십시오.
  22
  23 현재 사용중인 repository에만 한정적으로 사용할 수 있는 이름이나 이메일을 설정하려면 위 명령어에서 *--global*을 사용하지마세요.
  24
  25 === SSH, HTTP를 통한 Git 사용 ===
  26
  27 웹 서버에 관한 SSH 접근권한을 보유하고 있다고 합니다. 그러나 Git은 아직 설치되어 있지않다고 가정합니다. 기존 프로토콜만큼 효율적이진 않겠지만, Git은 HTTP를 통해 데이터 교환이 가능합니다.
  28
  29 우선 기본적으로 컴퓨터에 Git을 다운받아서 설치합니다. 그리고 웹 디렉토리에 저장소를 만듭니다:
  30
  31  $ GIT_DIR=proj.git git init
  32  $ cd proj.git
  33  $ git --bare update-server-info
  34  $ cp hooks/post-update.sample hooks/post-update
  35
  36 Git의 예전 버전에선 복사를 지시하는 명령어가 안 들을 수 있습니다. 그렇다면:
  37
  38  $ chmod a+x hooks/post-update
  39
  40 이제 아무 클론에서 SSH를 통해 당신의 작업을 업로드할 수 있습니다:
  41
  42  $ git push web.server:/path/to/proj.git master
  43
  44 다른 사람들은 당신의 작업을 다운받으려면 다음 명령어를 쓰면 될겁니다:
  45
  46  $ git clone http://web.server/proj.git
  47
  48 === 모든 것은 Git을 통한다 ===
  49
  50 서버나 인터넷 연결없이 저장소를 동기화시키고 싶다고요?
  51 긴급하게 수정할 것이 발견되었다고요? <<makinghistory, *git
  52 fast-export* 그리고 *git fast-import* 명령어들은 repository를 하나의 파일로
  53 묶어주거나 그 하나의 파일을 repository로 되돌려 줄 수 있는 것을 배웠습니다>>.
  54 다양한 매개체를 통해서 repository의 파일들을 옮길 수 있지만, 정말 효율적인
  55 방법은 *git bundle* 명령어를 쓰는 것입니다.
  56
  57 보내는 이가 '묶음 (bundle)'을 만듭니다:
  58
  59  $ git bundle create somefile HEAD
  60
  61  그리고 다른 장소로 그 묶음, +somefile+을 어떻게든 옮겨야한다고 가정합시다: 이메일로 보내야할수도 있고, USB드라이브로 보내거나, *xxd* 프린트로 뽑아서 전송하던지, OCR 스캐너로 전송하던지, 전화로 직접 이야기하던지, 연기로 신호를 보내던지 등 어떻게든 보내야합니다. 파일을 받을 사람들은 이 묶음으로부터의 commit을 다음 명령어를 이용하여 간단히 받을 수 있습니다:
  62
  63  $ git pull somefile
  64
  65  파일을 받는 사람들은 빈 repository에서도 이 명령어를 사용할 수 있습니다. 파일의
  66  사이즈가 작아 보임에도 불구하고 +somefile+ 은 저장소의 본 모습을 담고 있습니다.
  67
  68 큰 프로젝트에서는 묶음만들기를 좀 더 효율적으로 하기위해서 버전차이만을
  69 묶어줍니다. 예를 들어서 "1b6d"의 hash가 달린 commit 이 가장 최근에 보내는 이와 받는 이 사이에 공유된 commit이라고 가정해 봅니다:
  70
  71  $ git bundle create somefile HEAD ^1b6d
  72
  73 너무 자주 이렇게 한다면, 어떤 commit이 가장 최근 것인지 기억하지 못할 수 있습니다. 도움말에서는 태그를 이용해 이런 문제점들을 피하라 명시합니다. 풀어서 말하자면 어떤 묶음을 보낸 후에는:
  74
  75  $ git tag -f lastbundle HEAD
  76
  77 그리고 새로운 묶음을 만들어 줍니다:
  78
  79  $ git bundle create newbundle HEAD ^lastbundle
  80
  81 === 패치: 세계적 통화 ===
  82
  83 패치는 컴퓨터와 인간이 쉽게 알아들을 수 있는 언어로 파일의 변화를
  84 텍스트로 표현할 수 있는 방법입니다. 전 세계 어떤 개발 공간에서나 이런 식으로 파일의 변화를 시도합니다.
  85 어떠한 VCS를 쓰던간에 개발자들에게 패치를 이메일로 보낼 수도 있습니다. 그 개발자들이
  86 그 이메일을 읽을 수만 있다면 그들은 당신이 편집을 한 작업기록을 손쉽게 볼 수 있을겁니다. 즉, 온라인용 Git repository를 만들 필요가 없다는 말이지요.
  87
  88 첫 장에서 본 명령어를 다시 한번 해봅시다:
  89
  90  $ git diff 1b6d > my.patch
  91
  92 위 명령어는 간단한 패치를 생성하여 이메일로 보낼수 있게 도와줍니다. Git 저장소에서 다음을 따라해보세요:
  93
  94  $ git apply < my.patch
  95
  96 위 명령어를 사용하여 패치를 적용시킵니다.
  97
  98 작성자의 이름과 싸인이 기록되어야하는 좀 더 공식적인 환경에서는
  99 그에 상응하는 패치 (1b6d 이후의 작업)를 만들기위해 다음 명령어를 사용합니다:
 100
 101  $ git format-patch 1b6d
 102
 103 이렇게 만든 파일묶음은 *git-send-email*을 사용하여 보낼 수 있습니다. 보내고싶은 commit 묶음을 수동으로 지정해줄 수도 있습니다:
 104
 105  $ git format-patch 1b6d..HEAD^^
 106
 107 받는 쪽에서는 이메일을 받을 때는 받은 txt형태의 패치 파일을 저장한 후:
 108
 109  $ git am < email.txt
 110
 111  이 명령어는 새로받은 패치를 적용시키고 작성자의 정보가 포함된 새로운 commit을 만듭니다.
 112
 113 브라우저 상으로 이메일을 수신한다면, 당신의 이메일 클라이언트에서 첨부된 패치의 본 코드의 형태를 확인해야 할수도 있습니다.
 114
 115 mbox-를 기반으로하는 이메일 클라이언트는 약간의 문제점들이 있습니다. 그러나
 116 이런 방식의 클라이언트를 쓸만한 사람이라면 손쉽게 튜토리얼을 읽지않고도
 117 해결할 수 있을것입니다.
 118
 119 === 죄송합니다. 주소를 옮겼습니다 ===
 120
 121 Repository를 클로닝한 후 *git push*나 *git pull*을 사용하면 원래의 URL에서 해당
 122 명령어를 실행합니다. Git은 어떤 원리로 이렇게 하는 것일까요? 그 비밀은
 123 클론을 만들때 생선된 config 옵션에서 찾을 수 있습니다. 한번 볼까요?:
 124
 125  $ git config --list
 126
 127 +remote.origin.url+ 옵션은 URL 소스를 통제합니다; "origin"은 원래 repository에
 128 붙여진 별명이라고 보면됩니다. Branch에 "master"라고 이름이 붙듯이 말이죠. 그말은
 129 이 이름을 바꾸거나 지울 수 있는데 할 필요는 없다는 것입니다.
 130
 131 제일 처음 사용하던 repository가 옮겨지면, URL을 수정해 주어야 합니다:
 132
 133  $ git config remote.origin.url git://new.url/proj.git
 134
 135 +brach.master.merge+ 옵션은 *git pull*로 당겨올 수 있는 branch를
 136 설정하여 줍니다. 처음으로 클론을 생성하였을때, 그 클론의 branch는
 137 그 클론을 만들어온 repository의 현재 사용중인 repository와 같게 설정이 되어있습니다. 그렇기 때문에 현재 작업 헤드가 다른 branch로 옮겨갔었다고 하더라도, 추후의 당겨오기는 본래의 branch를 따를 수 있게 해줄 것 입니다.
 138
 139 본 옵션은 처음에 +branch.master.remote+옵션에 기록되어 있는 클론의 대상 repository에만 적용됩니다.
 140 다른 저장소에서 당겨오기를 실행한다면, 구체적으로 어떤 나뭇가지에서 당겨오길 원하는지
 141 설정해주어야 합니다:
 142
 143  $ git pull git://example.com/other.git master
 144
 145 이 것은 왜 전에 보여드렸던 *push*와 *pull* 예제에 다른 argument가 붙지 않았었는지
 146 설명하여 줍니다.
 147
 148 === 원격 branch들 ===
 149
 150 어떠한 repository를 클론할 때에는 그 클론의 모든 branch를 클론하게 됩니다. Git은 이 사실을 은폐하기에
 151 당신은 클론을 하면서 몰랐을지도 모릅니다: 그러니 당신은 직접 Git에게 물어보아야 합니다. 이 설정은 원격 repository에 있는 branch들은 당신의 branch들과 꼬이게하는 일을 없게 해줍니다. 그래서 초보자들이 Git을 사용할 수 있는 것이고요.
 152
 153 다음 명령어를 이용하여 숨겨진 branch들을 포함해서 모두 나열합니다:
 154
 155  $ git branch -r
 156
 157 당신은 다음과 비슷한 결과물들을 보게될 것입니다:
 158
 159  origin/HEAD
 160  origin/master
 161  origin/experimental
 162
 163 이 결과는 각 행마다 원격 repository의 HEAD와 branch를 보여주며, 다른 Git 명령어들과
 164 함께 사용될 수 있습니다. 예를 들면, 당신은 지금 많은 commit을 하였다고 먼저 가정합니다. 그러고는 가장 최근에 가져온 버젼과 비교를 하고싶다고 생각해봅니다. SHA1 해쉬를 찾아서 확인할 수도 있지만 다음 명령어로 더 간단히 비교할 수 있습니다:
 165
 166  $ git diff origin/HEAD
 167
 168 아니면 "experimental" 나뭇가지가 지금 어떠한 상태인지 알아낼 수도 있습니다.
 169
 170  $ git log origin/experimental
 171
 172 === 다수의 원격 repository ===
 173
 174 당신 외의 두명의 개발자가 프로젝트를 공동으로 진행하고 있다고 가정합니다. 그리고 그 둘의
 175 작업상황을 주시하고 싶습니다. 당신은 다음 명령어를 사용함으로써 하나 이상의 repository를
 176 추적할 수 있습니다:
 177
 178  $ git remote add other git://example.com/some_repo.git
 179  $ git pull other some_branch
 180
 181 이제 두번째 repository의 branch로 병합을 시도하였으며 모든 repository의 모든 branch에
 182 대한 접근권한이 생겼습니다.
 183
 184  $ git diff origin/experimental^ other/some_branch~5
 185
 186 그러나 내 작업과 관련없이 버전의 변화를 비교해내는 방법은 무엇일까요? 풀어말하자면
 187 그들의 branch를 보는 동시에 그들의 작업이 내 작업에 영향받지않게 하고싶다는 것입니다. 그렇다면
 188 간단하게 당겨오기 보다는:
 189
 190  $ git fetch        # 태초의 repository로부터 물어옵니다. 디폴트 명령어.
 191  $ git fetch other  # 다른 개발자의 repository를 물어옵니다.
 192
 193 작업기록들만을 가져오는 명령어들입니다. 현재 작업중인 디렉토리는 영향을 받지않을 것이지만, 로컬 사본을
 194 가지고 있기에 우리는 이제 어느 repository의 어떤 branch라도 Git 명령어를 사용하여 활용할 수 있습니다.
 195
 196 Pull은 간단히 풀어서 설명하면 *fetch(물어오기)* 후 *merge(병합하기)*를 합친 하나의
 197 고급명령어라고 말할 수 있습니다. 우리는 마지막 으로 한 commit을 현재 작업에 병합하길 원하기 때문에
 198 주로 *pull(당겨오기)*를 사용하게 될 것입니다; 위에 설명한 상황은 특수상황이지요.
 199
 200 *git help remote*에는 원격 repository를 삭제하는 방법, 특정 branch를 무시하는 방법 외에
 201 많은 것을 볼 수 있습니다.
 202
 203 === 나만의 취향 ===
 204
 205 저는 작업을 할때 다른 개발자들이 제가 당겨오기를 실행할 수 있게 항시 준비해두는 것을 선호합니다.
 206 어떠한 Git 호스팅 서비스는 클릭 한 번만으로도 쉽게 이를 행할 수 있게 도와주는 것도 있습니다.
 207
 208 어떤 파일꾸러미를 물어온 후에는 Git 명령어들을 사용하여 프로젝트가 잘 정리되어 있길 빌며
 209 변화 기록을 조회합니다. 그러고는 저의 작업을 병합합니다. 그 후 제 작업이 맘에 들 경우
 210 메인 저장소에 밀어넣기 합니다.
 211
 212 제가 다른 사람들로부터 많은 도움을 받는 스타일은 아니지만, 이러한 제 작업방식을
 213 추천드리고 싶습니다. 다음 링크를 한 번보세요.
 214 http://torvalds-family.blogspot.com/2009/06/happiness-is-warm-scm.html[Linus Torvalds의
 215 블로그 포스팅].
 216
 217 Git의 세상에 거주하는 것은 패치 파일들을 만들어 배포하는 것보다 더 효율적입니다. Git은 단순한 버전관리 외에도 작업을 행한 사람의 이름, 이메일주소, 작업날짜를 같이 기록하여줍니다.