ko/clone.txt

   1 == 클론 만들기 ==
   2
   3 구형 VCS에서는 체크아웃 명령어가 어딘가에 저장되어 있는 파일들을 가져오는 보편적인 방법이었습니다.
   4
   5 Git을 포함한 다른 분산 제어식 VCS에서는 클론만들기를 체크아웃을 대체하는 보편적인 방법으로 채택하고 있습니다. 어떤 저장된 파일을 얻기위해서는, 원하는 파일 원본들이 저장되어있는 저장소에서 내 컴퓨터로 끌고와 '클론'을 만들어야 합니다. 즉, 중앙관리서버를 미러링해오는 것과 같은 이치라고 설명할 수 있습니다. 클론을 본떠온다면 중앙관리서버가 할 수 있는 모든 것들을 당신이 이제 할 수 있는 것이죠.
   6
   7 === 컴퓨터 동기화 ===
   8
   9 기본적인 동기화 및 백업을 할 때 tarball을 만드는 것과 *rsync*명령어를 사용하는 것은 이해할 수 있는 행동입니다. 그러나 저는 가끔씩 노트북에서 편집을 할 때도 있고, 데스크탑에서 할 때도 있는데, 이 두 개의 컴퓨터는 *rsync*같은 명령어를 사용하면서 작업할때 잦은 동기화를 하지 않을지도 모릅니다.
  10
  11 한 컴퓨터에서 Git Repository를 초기화하고 파일들을 commit함으로써 이 문제를 해결할 수 있습니다. 그 후 다른 컴퓨터에서:
  12
  13  $ git clone other.computer:/path/to/files
  14
  15 위 명령어를 이용해서 두 번째 Git repository 사본을 만들 수 있습니다. 그 다음부터는,
  16
  17  $ git commit -a
  18  $ git pull other.computer:/path/to/files HEAD
  19
  20 을 이용하여 현재 작업중인 컴퓨터로 다른 컴퓨터에서 작업하던 파일들을 '당겨올 (pull)' 수 있습니다. 만약에 같은 파일에 대해서 전후가 맞지않는 작업을 했을 경우, Git은 당신에게 에러메세지로 먼저 이 모순을 해결 후 commit을 할 것을 알려줄 것입니다.
  21
  22 === 고전적인 소스 관리 ===
  23
  24 우선 Git 저장소를 초기화 해줍니다:
  25
  26  $ git init
  27  $ git add .
  28  $ git commit -m "Initial commit"
  29
  30 그리고 중앙 서버에서, 아무 디렉토리에서나 태초의(bare) repository를 초기화 해줍니다:
  31
  32  $ mkdir proj.git
  33  $ cd proj.git
  34  $ git --bare init
  35  $ touch proj.git/git-daemon-export-ok
  36
  37 필요하다면 Git daemon을 실행합니다:
  38
  39  $ git daemon --detach  # 아마 이미 daemon이 실행하고 있을지도 모릅니다.
  40
  41 Git 호스팅 서비스를 한다면 우선 빈 Git repository를 만들어야 합니다.
  42 대부분 웹페이지에서 어떠한 문서를 작성하곤 하죠.
  43
  44  다음 명령어를 사용해 당신의 프로젝트를 중앙서버로 '밀어넣기 (push)' 할 수 있습니다:
  45
  46  $ git push central.server/path/to/proj.git HEAD
  47
  48 소스를 확인하고 싶을 때에 개발자는 다음 명령어를 사용합니다:
  49
  50  $ git clone central.server/path/to/proj.git
  51
  52 편집작업이 끝난 후에 개발자는 다음명령어를 사용해 로컬드라이브에 각종 바뀐 사항들을 저장을 합니다:
  53
  54  $ git commit -a
  55
  56 가장 최신 버전으로 로컬파일들을 갱신하려면:
  57
  58  $ git pull
  59
  60 merge할때 일어날 수 있는 오류들은 수동으로 해결 후, commit 명령어를 사용하여 작업을 commit 해주셔야 합니다:
  61
  62  $ git commit -a
  63
  64 로컬에서 바뀐 사항들을 중앙 저장소로 저장하기 위해서는:
  65
  66  $ git push
  67
  68 중앙 서버가 다른 개발자들로 인하여 새로운 변경사항이 생겼을 경우에는, 당신의 '밀어넣기 (Push)'는 실패할 것입니다.
  69 그렇다면 당신은 '밀어넣기 (Push)' 하기 전에 최신 버전을 다시 당겨서 (pull) 오류를 수동으로 해결 후 다시 밀어넣기를 시도해야 하겠지요.
  70
  71 모든 개발자들은 특정 Git repository에 대한 SSH 접근권한이 있어야 push와 pull를 할 수 있습니다.
  72 그러나 개발소스는 대부분 모든 이들에게 개방된 것으로써 다음 명령어를 이용하면 조회 및 클로닝이  가능합니다:
  73
  74  $ git clone git://central.server/path/to/proj.git
  75
  76 Git 프로토콜은 HTTP와 비슷합니다: 증명서가 존재하지 않죠. 그래서 아무나 프로젝트를 조회할 수 있는겁니다.
  77 그런 이유에서 '밀어넣기 (push)'는 Git 프로토콜로는 할 수없게 디폴트 설정이 되어있지요.
  78
  79 === 숨겨진 소스 ===
  80
  81 개방되어 있지않은 소스의 프로젝트를 진행할 때에는 Git의 터치 (Touch) 명령어를 생략합니다. 그리고
  82 'git-daemong-export-ok'라는 이름의 파일을 절대 만들지 않도록 주의합니다. 이렇게하면 git 프로토콜을 사용해서
  83 원치않는 사람들이 당신의 저장소를 조회하거나 클로닝 할 수 있는 일은 없을 것입니다; 이제는 SSH 접근권이 있는 사람들만
  84 조회할 수 있게 될겁니다. 당신의 모든 repository가 개방되지 않은 경우에는 git daemon명령어는 필요없겠지요.
  85 모든 repository는 SSH 를 통해서만 허락된 개발자들에게만 공개될테니까요.
  86
  87 === 태초의 저장소 ===
  88
  89 이 괴상한 이름의 저장소 (bare repository)는 현재 작업중인 디렉토리가 아니기에 이렇게 이름이 붙여졌습니다; 이 저장소는 하위 '.git' 디렉토리에서 숨겨진 파일들만을 저장하는 저장소입니다. 풀어 설명하면, 이 저장소는 현 프로젝트의 과거를 관리하기만 하고, 아무런 버전도 저장하지 않는 저장소입니다.
  90
  91 헐벗은 저장소는 중앙서버관리식 VCS와 비슷한 기능을 담당하고 있고
  92 당신의 프로젝트가 저장되어 있는 집과같은 기능을 담당하고 있습니다. 개발자들은
  93 이 곳에서 부터 클론을 만들 수 있고, 작업한 내용을 '밀어넣기 (Push)' 할 수 있습니다. 보편적으로
  94 이 bare repository는 서버에서 상주하고 있다가 데이터를 퍼트리는 역할을 맡고있습니다. 개발은
  95 개발자 각자가 만들어 놓은 로컬컴퓨터에서의 클론에서 이루어짐으로써, 워킹 디렉토리없이 서버내에서 보호받는 저장소 역할을 할 수 있습니다.
  96
  97 많은 Git 명령어들은 'GIT_DIR' 환경 변수가 repository로 경로설정이 되어 있지않다면 이 bare repository에 인식되지 않을 것입니다. '--bare' 옵션을 이용한다면 모를까.
  98
  99 === 밀어넣기 (push) vs. 당기기 (pull) ===
 100
 101 '당기기 (pull)' 커맨드에만 의존하는 대신에 왜 제가 '밀어넣기 (push)'를 소개했을까요? 먼저, 당기기 (pull)는 아까 소개드린 bare repository에서는 실행이 되지 않는 명령어입니다: 물론 나중에 소개할 '물어오기 (fetch)'라는 명령어로 같은 일을 할 수 있지만요. 그러나 중앙서버에 저장 되어있는 보통 일반적인 repository에서도, 당기기 (pull)는 번거로울 수 밖에 없습니다. 서버에 로그인을 해야 될 것이고 그런 후에야 당기기 (pull)을 사용해야 하다는 말이지요. 파이어월이 이런 절차를 방해할 수도 있습니다. 그리고 쉘 접근 권한이 없다면 중앙 서버에 접속이나 가능할런지요?
 102
 103 그러나 이러한 특수상황들이 아니라면 밀어넣기 (push)를 사용하시는 것을 비추합니다. 목적지가 현재 작업중인 디렉토리가 있을 경우에는 굉장히 햇갈릴 수 있기 때문입니다.
 104
 105 줄여서, Git을 배울 때에는, bare repository일 경우에는 '밀어넣기 (push)'를 진행하시고 아니면 '당기기 (pull)'을 사용합시다.
 106
 107 === 프로젝트 포크질 (forking) 하기 ===
 108
 109 현재 프로젝트가 진행되고 있는 방식이 마음에 안 드신 다고요? 당신이 좀 더 잘할 수 있다고 생각하세요? 그렇다면 당신 서버에서:
 110
 111  $ git clone git://main.server/path/to/files
 112
 113 이 명령어를 쓴 후에, 다른 사람들에게 당신이 포크질 (fork)을 한 프로젝트에 대해 알리세요.
 114
 115 이후 작업이 끝난 후 아무때나 원래 프로젝트 파일에서 다음 명령어를 씀으로써 포크질 해놓은 프로젝트로부터 오리지널 프로젝트 파일로 병합을 실행할 수 있습니다:
 116
 117  $ git pull
 118
 119 === 궁극의 백업 ===
 120
 121 아무도 건들 수 없고 지리적으로 다양한 곳에 저장해놓고 싶은 기록 보관소를 소유하고 싶다고요? 만약 당신의 프로젝트에 많은 개발자들이 참여한다면 아무 것도 하지 마십시오. 그 수많은 개발자들이 각자 클론을 만들었다면 그 클론 자체가 아주 효율적인 프로젝트 백업이 될 것 입니다. 현 상태의 프로젝트 뿐만이 아니라, 그 프로젝트의 모든 과거 버전까지 말이죠. 만약이라도 어떤 개발자 분의 클론이 훼손 된다면 암호화 된 hashing 덕에 다른 모든 개발자들이 프로젝트 훼손여부에 관해 알 수 있게 될 것입니다.
 122
 123 만약 당신의 프로젝트에 그리 많은 개발자들이 참여하지 않는다면, 최대한 많은 서버를 확보해서 클론을 만들어 놓으십시오.
 124
 125 편집증이 걸린 개발자들은 언제나 프로젝트 HEAD의 20-바이트 SHA1 hash를 어딘가에는 안전하게 모셔놓죠. 안전하다는 말이 꼭 사적인 공간에 저장해놓는다는 말은 아닙니다. 예를 들면, 어떤 신문에 기사를 개제하는 것도 안전한 기록보관의 한 방법이 될 수 있지요. 그 정보를 훼손하고자하는 작자들이 세상에 발간된 모든 신문 카피를 바꿀 수는 없기 때문입니다.
 126
 127 === 광속의 멀티테스킹 ===
 128
 129 만약에 어떠한 프로젝트의 여러 부분을 동시에 작업하고 싶으실 때에는 우선 현재상태의 프로젝트를 한 번 commit 한 후 다음 명령어를 사용합니다:
 130
 131  $ git clone . /some/new/directory
 132
 133 http://en.wikipedia.org/wiki/Hard_link[hardlinking] 이라는 기능 덕분에 로컬시스템에 생성된 클론들은 일반 백업에 비해 비교적 적은 시간과 공간만 필요로 합니다.
 134
 135 이렇게 하면 두개의 독립적인 작업을 동시진행 할 수 있습니다. 예로, 한 클론이 컴파일 중일때 다른 클론에서 또 다른 작업을 진행하고 있을 수 있습니다. 그리고 다른 클론으로 부터 아무 때나 commit과 당기기 (pull)도 사용할 수 있습니다.
 136
 137  $ git pull /the/other/clone HEAD
 138
 139 === 게릴라 버전 관리 ===
 140
 141 당신은 현재 다른 VCS를 사용하고 있지만, Git을 그리워하고 있진 않습니까? 그렇다면 현재 작업중인 디렉토리에서 Git을 초기화 시켜주십시오:
 142
 143  $ git init
 144  $ git add .
 145  $ git commit -m "Initial commit"
 146
 147 그리고 클론을 만들고:
 148
 149  $ git clone . /some/new/directory
 150
 151 이제 방금 클론 된 디렉토리에서 작업을 진행하시면 됩니다. 가끔은 다른 개발자 분들과 동기화하고 싶으시겠죠. 그 개발자분들은 아직 Git을 사용하고 있지 않아도 우리 Git에서는:
 152
 153  $ git add .
 154  $ git commit -m "Sync with everyone else"
 155
 156 그리고는 새로운 디렉토리에서:
 157
 158  $ git commit -a -m "Description of my changes"
 159  $ git pull
 160
 161 다른 분들에게 당신의 작업을 공유하는 일은 그 쪽 분들이 쓰시는 VCS에 따라 다릅니다. 새로운 디렉토리는 이제 당신이 실행한 작업들이 포함되어 있겠죠. 위의 명령어를 쓰신 후에 다른 VCS에서 쓰는 명령어를 통해서 그들의 중앙 서버에 업로드 하실 수 있습니다.
 162
 163 Subversion은 가장좋은 중앙관리식 VCS로써 개발자들 사이에서 애용되고 있습니다. Git에서 *git svn*을 사용해서 위에서 언급한 일들은 Subversion 저장소를 대상으로 행할 수 있습니다.http://google-opensource.blogspot.com/2008/05/export-git-project-to-google-code.html[Git 프로젝트를 Subversion 저장소로 보내기].
 164
 165 === Mercurial ===
 166
 167 Mercurial 역시 비슷한 VCS으로써 Git과 쉽게 연동될 수 있습니다. 'hg-git'플러그인을 통해서 Mercurial 유저들은 Git 저장소에 쉽게 '밀어넣기 (push)'와 '당기기 (pull)'을 사용할 수 있죠.
 168
 169 Git으로 'hg-git' 플러그인을 구하는 방법:
 170
 171  $ git clone git://github.com/schacon/hg-git.git
 172
 173 Mercurial로 'hg-git'플러그인을 구하는 방법:
 174
 175  $ hg clone http://bitbucket.org/durin42/hg-git/
 176
 177 유감스럽지만 다른 VCS에선 Git과 비슷한 플러그인이 있는지는 모르겠습니다. 그렇기 때문에 Mercurial보다는 Git을 주 저장소를 쓰길 선호합니다. Mercurial로 프로젝트를 진행할 경우에는 대부분 한 개발자가 Git 저장소를 같이 병행관리하는 업무를 떠맡곤 합니다. 그러나 Git으로 Mercurial 프로젝트를 진행할 경우에는 'hg-git'플러그인의 도움으로 그러한 번거로움이 필요없겠죠.
 178
 179 Mercurial에 있는 repository를 Git repository로 '밀어넣기 (push)'를 사용하여 쉽게 바꿀 수 있으나, 'hg-fast-export.sh'스크립트를 사용해 이 작업을 더 쉽게 끝낼 수 있습니다. 다음 저장소에서 이 스크립트를 구할 수 있습니다:
 180
 181  $ git clone git://repo.or.cz/fast-export.git
 182
 183 빈 저장소에서 이 작업을 한번 해봅시다:
 184
 185  $ git init
 186  $ hg-fast-export.sh -r /hg/repo
 187
 188 위 명령어는 스크립트를 '$PATH'에 넣은 후에 실행합니다.
 189
 190 === Bazaar ===
 191
 192 Bazaar는 Git과 Mercurial 다음으로 많이 알려진 VCS입니다.
 193
 194 Bazaar는 만들어진지 별로 되지않은 시스템이기에 엄청난 가능성이 잠재하고 있지요; Bazaar 개발자들은 다른 VCS의 단점을 배우고 고쳐나가는 중입니다. 그리고 Bazaar 개발자들은 Bazaar VCS가 다른 VCS들과 연동하는 문제에 많은 노력을 기울이고 있습니다.
 195
 196 'bzr-git'플러그인은 Bazaar 이용자들이 Git과 함께 연동해 작업할 수 있도록 해줍니다. 'tailor' 프로그램은 Bazaar repository를 Git repository로 바꿔줍니다. 'bzr-fast-export'도 한 번 검색해보세요.
 197
 198 === 내가 Git을 사용하는 이유 ===
 199
 200 제가 Git을 처음에 사용했던 이유는 제가 듣기에 Git은 Linux kernel source 관리에 용이하다고 들었기 때문입니다. Git을 사용한 이후로는 다른 VCS로 바꿔야겠다는 생각은 들지도 않았지요. Git은 저에게 매우 유용했고 저는 아직 Git으로 인한 어떠한 심각한 오류를 겪어보지도 않았습니다.저는 Linux를 주로 이용하기 때문에 다른 플랫폼에서 발생할 수 있는 문제는 생략하겠습니다.
 201
 202 그리고 저는 C, bash scripts, Python을 이용하는 사람이고 프로그램 런타임에 목숨을 거는 사람 중 하나입니다.
 203
 204 Git이 어떻게 좀 더 발전할 수 있을지, 또 Git과 비슷한 프로그램도 직접 짜보기도 했지만 학교 프로젝트 정도로만 썻었을 뿐입니다. 그러나 제가 직접 저만의 VCS를 만들었더라도 저는 Git을 계속 이용했을 겁니다. 제 프로그램을 써도 별로 투자한 것에 비해 얻을 것이 적어보였기 때문이지요.
 205
 206 자연스레 여러분들이 필요로하고 원하는 프로그램은 계속해서 바뀝니다. 그러나 Git과는 그럴 가능성이 매우 적지요.