diff --git a/.gitignore b/.gitignore index 94edaae9..85385187 100644 --- a/.gitignore +++ b/.gitignore @@ -2,6 +2,7 @@ output .DS_Store # build artifacts +Gemfile.lock progit.html progit.pdf progit.pdfmarks diff --git a/Gemfile.lock b/Gemfile.lock deleted file mode 100644 index ea981171..00000000 --- a/Gemfile.lock +++ /dev/null @@ -1,93 +0,0 @@ -GEM - remote: https://rubygems.org/ - specs: - Ascii85 (1.0.2) - addressable (2.4.0) - afm (0.2.2) - asciidoctor (1.5.4) - asciidoctor-epub3 (1.5.0.alpha.6) - asciidoctor (~> 1.5.0) - gepub (~> 0.6.9.2) - thread_safe (~> 0.3.5) - asciidoctor-pdf (1.5.0.alpha.11) - asciidoctor (~> 1.5.0) - prawn (>= 1.3.0, < 3.0.0) - prawn-icon (= 1.0.0) - prawn-svg (= 0.21.0) - prawn-table (= 0.2.2) - prawn-templates (= 0.0.3) - safe_yaml (~> 1.0.4) - thread_safe (~> 0.3.5) - treetop (= 1.5.3) - asciidoctor-pdf-cjk (0.1.2) - asciidoctor-pdf (~> 1.5.0.alpha.8) - asciidoctor-pdf-cjk-kai_gen_gothic (0.1.1) - asciidoctor-pdf-cjk (~> 0.1.2) - awesome_print (1.6.1) - coderay (1.1.1) - css_parser (1.3.7) - addressable - epubcheck (3.0.1) - gepub (0.6.9.2) - nokogiri (~> 1.6.1) - rubyzip (>= 1.1.1) - hashery (2.1.1) - json (1.8.3) - kindlegen (2.9.7) - mini_portile2 (2.0.0) - nokogiri (1.6.7.2) - mini_portile2 (~> 2.0.0.rc2) - pdf-core (0.6.1) - pdf-reader (1.4.0) - Ascii85 (~> 1.0.0) - afm (~> 0.2.1) - hashery (~> 2.0) - ruby-rc4 - ttfunk - polyglot (0.3.5) - posix-spawn (0.3.11) - prawn (2.1.0) - pdf-core (~> 0.6.1) - ttfunk (~> 1.4.0) - prawn-icon (1.0.0) - prawn (>= 1.1.0, < 3.0.0) - prawn-svg (0.21.0) - css_parser (~> 1.3) - prawn (>= 0.8.4, < 3) - prawn-table (0.2.2) - prawn (>= 1.3.0, < 3.0.0) - prawn-templates (0.0.3) - pdf-reader (~> 1.3) - prawn (>= 0.15.0) - pygments.rb (0.6.3) - posix-spawn (~> 0.3.6) - yajl-ruby (~> 1.2.0) - rake (10.5.0) - ruby-rc4 (0.1.5) - rubyzip (1.2.0) - safe_yaml (1.0.4) - thread_safe (0.3.5) - treetop (1.5.3) - polyglot (~> 0.3) - ttfunk (1.4.0) - yajl-ruby (1.2.1) - -PLATFORMS - ruby - -DEPENDENCIES - asciidoctor (= 1.5.4) - asciidoctor-epub3 (= 1.5.0.alpha.6) - asciidoctor-pdf (= 1.5.0.alpha.11) - asciidoctor-pdf-cjk-kai_gen_gothic (= 0.1.1) - awesome_print - coderay - epubcheck - json - kindlegen - pygments.rb - rake - thread_safe - -BUNDLED WITH - 1.10.6 diff --git a/book/01-introduction/sections/basics.asc b/book/01-introduction/sections/basics.asc index ac466f90..ed2cbda7 100644 --- a/book/01-introduction/sections/basics.asc +++ b/book/01-introduction/sections/basics.asc @@ -182,16 +182,16 @@ Modified는 수정한 파일을 아직 로컬 데이터베이스에 커밋하지 Staged란 현재 수정한 파일을 곧 커밋할 것이라고 표시한 상태를 의미한다. ////////////////////////// -This leads us to the three main sections of a Git project: the Git directory, the working directory, and the staging area. +This leads us to the three main sections of a Git project: the Git directory, the working tree, and the staging area. ////////////////////////// -이 세 가지 상태는 Git 프로젝트의 세 가지 단계와 연결돼 있다. Git 디렉토리, 워킹 디렉토리, Staging Area 이렇게 세 가지 단계를 이해하고 넘어가자. +이 세 가지 상태는 Git 프로젝트의 세 가지 단계와 연결돼 있다. Git 디렉토리, 워킹 트리, Staging Area 이렇게 세 가지 단계를 이해하고 넘어가자. ////////////////////////// -.Working directory, staging area, and Git directory. -image::images/areas.png["Working directory, staging area, and Git directory."] +.Working tree, staging area, and Git directory. +image::images/areas.png["Working tree, staging area, and Git directory."] ////////////////////////// -.워킹 디렉토리, Staging Area, Git 디렉토리. -image::images/areas.png["Working directory, staging area, and Git directory."] +.워킹 트리, Staging Area, Git 디렉토리. +image::images/areas.png["Working tree, staging area, and Git directory."] ////////////////////////// The Git directory is where Git stores the metadata and object database for your project. @@ -201,11 +201,11 @@ Git 디렉토리는 Git이 프로젝트의 메타데이터와 객체 데이터 이 Git 디렉토리가 Git의 핵심이다. 다른 컴퓨터에 있는 저장소를 Clone 할 때 Git 디렉토리가 만들어진다. ////////////////////////// -The working directory is a single checkout of one version of the project. +The working tree is a single checkout of one version of the project. These files are pulled out of the compressed database in the Git directory and placed on disk for you to use or modify. ////////////////////////// -워킹 디렉토리는 프로젝트의 특정 버전을 Checkout 한 것이다. -Git 디렉토리는 지금 작업하는 디스크에 있고 그 디렉토리 안에 압축된 데이터베이스에서 파일을 가져와서 워킹 디렉토리를 만든다. +워킹 트리는 프로젝트의 특정 버전을 Checkout 한 것이다. +Git 디렉토리는 지금 작업하는 디스크에 있고 그 디렉토리 안에 압축된 데이터베이스에서 파일을 가져와서 워킹 트리를 만든다. ////////////////////////// The staging area is a file, generally contained in your Git directory, that stores information about what will go into your next commit. @@ -220,11 +220,11 @@ The basic Git workflow goes something like this: Git으로 하는 일은 기본적으로 아래와 같다. ////////////////////////// -1. You modify files in your working directory. +1. You modify files in your working tree. 2. You stage the files, adding snapshots of them to your staging area. 3. You do a commit, which takes the files as they are in the staging area and stores that snapshot permanently to your Git directory. ////////////////////////// -1. 워킹 디렉토리에서 파일을 수정한다. +1. 워킹 트리에서 파일을 수정한다. 2. Staging Area에 파일을 Stage 해서 커밋할 스냅샷을 만든다. 3. Staging Area에 있는 파일들을 커밋해서 Git 디렉토리에 영구적인 스냅샷으로 저장한다. diff --git a/book/01-introduction/sections/first-time-setup.asc b/book/01-introduction/sections/first-time-setup.asc index e93027bf..5eac4375 100644 --- a/book/01-introduction/sections/first-time-setup.asc +++ b/book/01-introduction/sections/first-time-setup.asc @@ -59,7 +59,7 @@ Windows에서도 `/etc/gitconfig` 파일은 그 경로에서 찾는다. 이 경 The first thing you should do when you install Git is to set your user name and email address. This is important because every Git commit uses this information, and it's immutably baked into the commits you start creating: ////////////////////////// -Git을 설치하고 나서 가장 먼저 해야 하는 것은 사용자 이름과 이메일 주소를 설정하는 것이다. +Git을 설치하고 나서 가장 먼저 해야 하는 것은 사용자이름과 이메일 주소를 설정하는 것이다. Git은 커밋할 때마다 이 정보를 사용한다. 한 번 커밋한 후에는 정보를 변경할 수 없다. [source,console] diff --git a/book/01-introduction/sections/installing.asc b/book/01-introduction/sections/installing.asc index f1666671..db4fd7ef 100644 --- a/book/01-introduction/sections/installing.asc +++ b/book/01-introduction/sections/installing.asc @@ -183,7 +183,7 @@ due to binary name differences. ////////////////////////// When you have all the necessary dependencies, you can go ahead and grab the latest tagged release tarball from several places. -You can get it via the Kernel.org site, at https://www.kernel.org/pub/software/scm/git[], or the mirror on the GitHub web site, at https://github.com/git/git/releases[]. +You can get it via the Kernel.org site, at https://www.kernel.org/pub/software/scm/git[], or the mirror on the GitHub website, at https://github.com/git/git/releases[]. It's generally a little clearer what the latest version is on the GitHub page, but the kernel.org page also has release signatures if you want to verify your download. ////////////////////////// 모든 준비가 완료되면, 최신 배포 버전을 가져와야 한다. diff --git a/book/02-git-basics/sections/getting-a-repository.asc b/book/02-git-basics/sections/getting-a-repository.asc index 86fe4168..cfca86d0 100644 --- a/book/02-git-basics/sections/getting-a-repository.asc +++ b/book/02-git-basics/sections/getting-a-repository.asc @@ -19,9 +19,44 @@ Git 저장소를 만드는 방법은 두 가지다. ==== 기존 디렉토리를 Git 저장소로 만들기 ////////////////////////// -If you're starting to track an existing project in Git, you need to go to the project's directory and type: +If you're starting to track an existing project in Git, you need to go to the project's directory. If you've never done this, it looks a little different depending on which system you're running: ////////////////////////// -기존 프로젝트를 Git으로 관리하고 싶을 때, 프로젝트의 디렉토리로 이동해서 아래과 같은 명령을 실행한다. +기존 프로젝트를 Git으로 관리하고 싶을 때, 프로젝트의 디렉토리로 이동한다. 처음이라면 시스템마다 조금 다른 점을 주의하자. + +////////////////////////// +for Linux: +////////////////////////// +Linux: + +[source,console] +---- +$ cd /home/user/your_repository +---- + +////////////////////////// +for Mac: +////////////////////////// +Mac: + +[source,console] +---- +$ cd /Users/user/your_repository +---- + +////////////////////////// +for Windows: +////////////////////////// +Windows: + +[source,console] +---- +$ cd /c/user/your_repository +---- + +////////////////////////// +and type: +////////////////////////// +그리고 아래와 같은 명령을 실행한다: [source,console] ---- diff --git a/book/02-git-basics/sections/recording-changes.asc b/book/02-git-basics/sections/recording-changes.asc index 80166e90..0528a235 100644 --- a/book/02-git-basics/sections/recording-changes.asc +++ b/book/02-git-basics/sections/recording-changes.asc @@ -57,13 +57,13 @@ nothing to commit, working directory clean ---- ////////////////////////// -This means you have a clean working directory – in other words, there are no tracked and modified files. +This means you have a clean working directory – in other words, none of your tracked files are modified. Git also doesn't see any untracked files, or they would be listed here. Finally, the command tells you which branch you're on and informs you that it has not diverged from the same branch on the server. For now, that branch is always ``master'', which is the default; you won't worry about it here. <<_git_branching>> will go over branches and references in detail. ////////////////////////// -위의 내용은 파일을 하나도 수정하지 않았다는 것을 말해준다. Tracked나 Modified 상태인 파일이 없다는 의미다. +위의 내용은 파일을 하나도 수정하지 않았다는 것을 말해준다. Tracked 파일은 하나도 수정되지 않았다는 의미다. Untracked 파일은 아직 없어서 목록에 나타나지 않는다. 그리고 현재 작업 중인 브랜치를 알려주며 서버의 같은 브랜치로부터 진행된 작업이 없는 것을 나타낸다. 기본 브랜치가 master이기 때문에 현재 브랜치 이름이 ``master''로 나온다. 브랜치 관련 내용은 차차 알아가자. diff --git a/book/02-git-basics/sections/remotes.asc b/book/02-git-basics/sections/remotes.asc index 82718a8d..1904873d 100644 --- a/book/02-git-basics/sections/remotes.asc +++ b/book/02-git-basics/sections/remotes.asc @@ -323,13 +323,13 @@ What used to be referenced at `pb/master` is now at `paul/master`. 여태까지 `pb/master`로 리모트 저장소 브랜치를 사용했으면 이제는 `paul/master`라고 사용해야 한다. ////////////////////////// -If you want to remove a remote for some reason – you've moved the server or are no longer using a particular mirror, or perhaps a contributor isn't contributing anymore – you can use `git remote rm`: +If you want to remove a remote for some reason – you've moved the server or are no longer using a particular mirror, or perhaps a contributor isn't contributing anymore – you can either use `git remote remove` or `git remote rm`: ////////////////////////// -리모트 저장소를 삭제해야 한다면 `git remote rm` 명령을 사용한다. 서버 정보가 바뀌었을 때, 더는 별도의 미러가 필요하지 않을 때, 더는 기여자가 활동하지 않을 때 필요하다. +리모트 저장소를 삭제해야 한다면 `git remote remove`나 `git remote rm` 명령을 사용한다. 서버 정보가 바뀌었을 때, 더는 별도의 미러가 필요하지 않을 때, 더는 기여자가 활동하지 않을 때 필요하다. [source,console] ---- -$ git remote rm paul +$ git remote remove paul $ git remote origin ---- diff --git a/book/02-git-basics/sections/undoing.asc b/book/02-git-basics/sections/undoing.asc index ddc76e2e..06cc7e31 100644 --- a/book/02-git-basics/sections/undoing.asc +++ b/book/02-git-basics/sections/undoing.asc @@ -65,7 +65,7 @@ You end up with a single commit – the second commit replaces the results of th ==== 파일 상태를 Unstage로 변경하기 ////////////////////////// -The next two sections demonstrate how to wrangle your staging area and working directory changes. +The next two sections demonstrate how to work with your staging area and working directory changes. The nice part is that the command you use to determine the state of those two areas also reminds you how to undo changes to them. For example, let's say you've changed two files and want to commit them as two separate changes, but you accidentally type `git add *` and stage them both. How can you unstage one of the two? @@ -125,11 +125,12 @@ The `CONTRIBUTING.md` file is modified but once again unstaged. [NOTE] ////////////////////////// ===== -While `git reset` _can_ be a dangerous command if you call it with `--hard`, in this instance the file in your working directory is not touched. Calling `git reset` without an option is not dangerous - it only touches your staging area. +It's true that `git reset` can be a dangerous command, especially if you provide the `--hard` flag. +However, in the scenario described above, the file in your working directory is not touched, so it's relatively safe. ===== ////////////////////////// ===== -`git reset` 명령을 `--hard` 옵션과 함께 사용하면 워킹 디렉토리의 파일까지 수정돼서 조심해야 한다. `--hard` 옵션만 사용하지 않는다면 `git reset` 명령은 Staging Area의 파일만 조작하기 때문에 위험하지 않다. +`git reset` 명령은 매우 위험하다. `--hard` 옵션과 함께 사용하면 더욱 위험하다. 하지만 위에서 처럼 옵션 없이 사용하면 워킹 디렉토리의 파일은 건드리지 않는다. ===== ////////////////////////// diff --git a/book/02-git-basics/sections/viewing-history.asc b/book/02-git-basics/sections/viewing-history.asc index ad592814..28ed77c8 100644 --- a/book/02-git-basics/sections/viewing-history.asc +++ b/book/02-git-basics/sections/viewing-history.asc @@ -426,9 +426,9 @@ In <> we'll list these and a few other common options for your re |================================ ////////////////////////// -For example, if you want to see which commits modifying test files in the Git source code history are merged and were committed by Junio Hamano in the month of October 2008, you can run something like this:(((log filtering))) +For example, if you want to see which commits modifying test files in the Git source code history were committed by Junio Hamano in the month of October 2008 and are not merge commits, you can run something like this:(((log filtering))) ////////////////////////// -이제 살펴볼 예제는 Git 소스코드 저장소에서 2008년 10월에 Junio Hamano가 테스트 파일을 수정한 커밋 중 Merge 커밋을 제외한 순수한 커밋을 확인해보는 명령이다.(((log filtering))) +이제 살펴볼 예제는 Merge 커밋을 제외한 순수한 커밋을 확인해보는 명령이다. Junio Hamano가 2008년 10월에 Git 소스코드 저장소에서 테스트 파일을 수정한 커밋들이다.(((log filtering))) [source,console] ---- diff --git a/book/03-git-branching/sections/basic-branching-and-merging.asc b/book/03-git-branching/sections/basic-branching-and-merging.asc index 68288a85..80ad75a9 100644 --- a/book/03-git-branching/sections/basic-branching-and-merging.asc +++ b/book/03-git-branching/sections/basic-branching-and-merging.asc @@ -11,7 +11,7 @@ You'll follow these steps: 브랜치와 Merge는 보통 이런 식으로 진행한다. ////////////////////////// -. Do work on a web site. +. Do work on a website. . Create a branch for a new story you're working on. . Do some work in that branch. ////////////////////////// @@ -88,7 +88,7 @@ image::images/basic-branching-2.png[Creating a new branch pointer.] image::images/basic-branching-2.png[브랜치 포인터를 새로 만듦] ////////////////////////// -You work on your web site and do some commits. +You work on your website and do some commits. Doing so moves the `iss53` branch forward, because you have it checked out (that is, your `HEAD` is pointing to it): ////////////////////////// `iss53` 브랜치를 Checkout 했기 때문에(즉, `HEAD`는 `iss53` 브랜치를 가리킨다) @@ -101,14 +101,14 @@ $ git commit -a -m 'added a new footer [issue 53]' ---- ////////////////////////// -.The iss53 branch has moved forward with your work -image::images/basic-branching-3.png[The iss53 branch has moved forward with your work.] +.The `iss53` branch has moved forward with your work +image::images/basic-branching-3.png[The `iss53` branch has moved forward with your work.] ////////////////////////// -.진행 중인 iss53 브랜치 -image::images/basic-branching-3.png[진행 중인 iss53 브랜치] +.진행 중인 `iss53` 브랜치 +image::images/basic-branching-3.png[진행 중인 `iss53` 브랜치] ////////////////////////// -Now you get the call that there is an issue with the web site, and you need to fix it immediately. +Now you get the call that there is an issue with the website, and you need to fix it immediately. With Git, you don't have to deploy your fix along with the `iss53` changes you've made, and you don't have to put a lot of effort into reverting those changes before you can work on applying your fix to what is in production. All you have to do is switch back to your `master` branch. ////////////////////////// @@ -509,6 +509,6 @@ Conflicts: ---- ////////////////////////// -You can modify that message with details about how you resolved the merge if you think it would be helpful to others looking at this merge in the future – why you did what you did, if it's not obvious. +If you think it would be helpful to others looking at this merge in the future, you can modify this commit message with details about how you resolved the merge and explain why you did the changes you made if these are not obvious. ////////////////////////// 어떻게 충돌을 해결했고 좀 더 확인해야 하는 부분은 무엇이고 왜 그렇게 해결했는지에 대해서 자세하게 기록한다. 자세한 기록은 나중에 이 Merge 커밋을 이해하는데 도움을 준다. diff --git a/book/03-git-branching/sections/nutshell.asc b/book/03-git-branching/sections/nutshell.asc index b77690a4..0338b7f7 100644 --- a/book/03-git-branching/sections/nutshell.asc +++ b/book/03-git-branching/sections/nutshell.asc @@ -23,7 +23,7 @@ This object also contains the author's name and email, the message that you type ////////////////////////// To visualize this, let's assume that you have a directory containing three files, and you stage them all and commit. -Staging the files checksums each one (the SHA-1 hash we mentioned in <<_getting_started>>), stores that version of the file in the Git repository (Git refers to them as blobs), and adds that checksum to the staging area: +Staging the files computes a checksum for each one (the SHA-1 hash we mentioned in <<_getting_started>>), stores that version of the file in the Git repository (Git refers to them as blobs), and adds that checksum to the staging area: ////////////////////////// 파일이 3개 있는 디렉토리가 하나 있고 이 파일을 Staging Area에 저장하고 커밋하는 예제를 살펴 보자. 파일을 Stage 하면 Git 저장소에 파일을 저장하고(Git은 이것을 Blob이라고 부른다) Staging Area에 해당 파일의 체크섬을 저장한다(<<_getting_started>> 에서 살펴본 SHA-1을 사용한다). @@ -319,7 +319,7 @@ $ git log --oneline --decorate --graph --all ---- ////////////////////////// -Because a branch in Git is in actuality a simple file that contains the 40 character SHA-1 checksum of the commit it points to, branches are cheap to create and destroy. +Because a branch in Git is actually a simple file that contains the 40 character SHA-1 checksum of the commit it points to, branches are cheap to create and destroy. Creating a new branch is as quick and simple as writing 41 bytes to a file (40 characters and a newline). ////////////////////////// 실제로 Git의 브랜치는 어떤 한 커밋을 가리키는 40글자의 SHA-1 체크섬 파일에 불과하기 때문에 만들기도 쉽고 지우기도 쉽다. diff --git a/book/03-git-branching/sections/rebasing.asc b/book/03-git-branching/sections/rebasing.asc index 504025e3..189798b8 100644 --- a/book/03-git-branching/sections/rebasing.asc +++ b/book/03-git-branching/sections/rebasing.asc @@ -159,10 +159,10 @@ $ git rebase --onto master server client ---- ////////////////////////// -This basically says, ``Check out the client branch, figure out the patches from the common ancestor of the `client` and `server` branches, and then replay them onto `master`.'' +This basically says, ``Take the `client` branch, figure out the patches since it diverged from the `master` branch, and replay these patches in the `client` branch as if it was based directly off the `master` branch instead.'' It's a bit complex, but the result is pretty cool. ////////////////////////// -이 명령은 `client` 브랜치를 Checkout 하고 `server`와 `client`의 공통조상 이후의 Patch를 만들어 `master`에 적용한다. +이 명령은 `master` 브랜치부터 `server` 브랜치와 `client` 브랜치의 공통 조상까지의 커밋을 `client` 브랜치에서 없애고 싶을 때 사용한다. `client` 브랜치에서만 변경된 패치를 만들어 `master` 브랜치에서 `client` 브랜치를 기반으로 새로 만들어 적용한다. 조금 복잡하긴 해도 꽤 쓸모 있다. ////////////////////////// diff --git a/book/03-git-branching/sections/remote-branches.asc b/book/03-git-branching/sections/remote-branches.asc index 90374df0..a4b7f63c 100644 --- a/book/03-git-branching/sections/remote-branches.asc +++ b/book/03-git-branching/sections/remote-branches.asc @@ -189,13 +189,13 @@ The simplest is just to keep it in memory for a few mintues, which you can easil For more information on the various credential caching options available, see <<_credential_caching>>. ==== ////////////////////////// -.비밀번호를 매번 입력하지 않아도 된다 +.암호를 매번 입력하지 않아도 된다 ==== -HTTPS URL로 시작하는 리모트 저장소를 사용한다면 아마도 Push 나 Pull을 할 때 인증을 위한 사용자 이름이나 비밀번호를 묻는 것을 볼 수 있다. -보통 터미널에서 작업하는 경우 Git이 이 정보를 사용자로부터 받기 위해 사용자 이름이나 비밀번호를 입력받아 서버로 전달해서 권한을 확인한다. +HTTPS URL로 시작하는 리모트 저장소를 사용한다면 아마도 Push 나 Pull을 할 때 인증을 위한 사용자이름이나 암호를 묻는 것을 볼 수 있다. +보통 터미널에서 작업하는 경우 Git이 이 정보를 사용자로부터 받기 위해 사용자이름이나 암호를 입력받아 서버로 전달해서 권한을 확인한다. -이 리모트에 접근할 때마다 매번 ID나 비밀번호를 입력하지 않도록 ``credential cache'' 기능을 이용할 수 있다. -이 기능을 활성화하면 Git은 몇 분 동안 입력한 ID나 비밀번호를 저장해둔다. 이 기능을 활성화하려면 `git config --global credential.helper cache` 명령을 실행하여 환경설정을 추가한다. +이 리모트에 접근할 때마다 매번 사용자이름나 암호를 입력하지 않도록 ``credential cache'' 기능을 이용할 수 있다. +이 기능을 활성화하면 Git은 몇 분 동안 입력한 사용자이름이나 암호를 저장해둔다. 이 기능을 활성화하려면 `git config --global credential.helper cache` 명령을 실행하여 환경설정을 추가한다. 이 기능이 제공하는 다른 옵션에 대한 자세한 설명은 <<_credential_caching>>를 참고한다. ==== @@ -262,7 +262,7 @@ If you're on a tracking branch and type `git pull`, Git automatically knows whic When you clone a repository, it generally automatically creates a `master` branch that tracks `origin/master`. However, you can set up other tracking branches if you wish – ones that track branches on other remotes, or don't track the `master` branch. The simple case is the example you just saw, running `git checkout -b [branch] [remotename]/[branch]`. -This is a common enough operation that git provides the `--track` shorthand: +This is a common enough operation that Git provides the `--track` shorthand: ////////////////////////// 서버로부터 저장소를 Clone을 하면 Git은 자동으로 `master` 브랜치를 `origin/master` 브랜치의 트래킹 브랜치로 만든다. 트래킹 브랜치를 직접 만들 수 있는데 리모트를 `origin`이 아닌 다른 리모트로 할 수도 있고, 브랜치도 `master`가 아닌 다른 브랜치로 추적하게 할 수 있다. @@ -361,12 +361,17 @@ Finally we can see that our `testing` branch is not tracking any remote branch. It's important to note that these numbers are only since the last time you fetched from each server. This command does not reach out to the servers, it's telling you about what it has cached from these servers locally. If you want totally up to date ahead and behind numbers, you'll need to fetch from all your remotes right before running this. -You could do that like this: `git fetch --all; git branch -vv` +You could do that like this: ////////////////////////// 여기서 중요한 점은 명령을 실행했을 때 나타나는 결과는 모두 마지막으로 서버에서 데이터를 가져온(fetch) 시점을 바탕으로 계산한다는 점이다. 단순히 이 명령만으로는 서버의 최신 데이터를 반영하지는 않으며 로컬에 저장된 서버의 캐시 데이터를 사용한다. 현재 시점에서 진짜 최신 데이터로 추적 상황을 알아보려면 먼저 서버로부터 최신 데이터를 받아온 후에 추적 상황을 확인해야 한다. -`git fetch --all; git branch -vv` 처럼 두 명령을 이어서 사용하는 것이 적당하다 하겠다. +아래처럼 두 명령을 이어서 사용하는 것이 적당하다 하겠다. + +[source,console] +---- +$ git fetch --all; git branch -vv +---- ////////////////////////// ==== Pulling diff --git a/book/04-git-server/sections/git-daemon.asc b/book/04-git-server/sections/git-daemon.asc index 0fa84266..0580c42d 100644 --- a/book/04-git-server/sections/git-daemon.asc +++ b/book/04-git-server/sections/git-daemon.asc @@ -29,7 +29,7 @@ Basically, you need to run this command in a daemonized manner:(((git commands, [source,console] ---- -$ git daemon --reuseaddr --base-path=/opt/git/ /opt/git/ +$ git daemon --reuseaddr --base-path=/srv/git/ /srv/git/ ---- ////////////////////////// @@ -65,8 +65,8 @@ stop on shutdown exec /usr/bin/git daemon \ --user=git --group=git \ --reuseaddr \ - --base-path=/opt/git/ \ - /opt/git/ + --base-path=/srv/git/ \ + /srv/git/ respawn ---- diff --git a/book/04-git-server/sections/gitlab.asc b/book/04-git-server/sections/gitlab.asc index 20e465fa..64a5c51f 100644 --- a/book/04-git-server/sections/gitlab.asc +++ b/book/04-git-server/sections/gitlab.asc @@ -21,7 +21,7 @@ GitLab은 기능이 많은 만큼 설정도 복잡하고 유지보수를 위해 ==== 설치 ////////////////////////// -GitLab is a database-backed web application, so its installation is a bit more involved than some other git servers. Fortunately, this process is very well-documented and supported. +GitLab is a database-backed web application, so its installation is a bit more involved than some other Git servers. Fortunately, this process is very well-documented and supported. ////////////////////////// GitLab은 데이터베이스와 따로 연동해야하는 웹 애플리케이션이라 다른 Git 서버들보다 설치하기에 복잡하지만, 문서화가 잘 되어있으므로 이를 참고한다. @@ -32,7 +32,7 @@ One nice touch Bitnami has included is the login screen (accessed by typing alt- ////////////////////////// 설치 방법은 여러 가지가 있다. 가상 머신 이미지나 원클릭 인스톨러를 내려받아 빨리 설치하고 환경에 맞게 후다닥 설정해서 사용할 수 있다. https://bitnami.com/stack/gitlab[]에서 내려받을 수 있다.(((bitnami))) -Bitnami의 로그인 화면은 아래와 같다(alt-→ 를 눌러서 들어간다). 로그인 화면에 설치된 GitLab의 IP와 기본 사용자 이름, 비밀번호가 써있다. +Bitnami의 로그인 화면은 아래와 같다(alt-→ 를 눌러서 들어간다). 로그인 화면에 설치된 GitLab의 IP와 기본 사용자이름, 암호가 써있다. [[bitnami]] ////////////////////////// @@ -64,7 +64,7 @@ Once logged in, click the ``Admin area'' icon in the menu at the top right. ////////////////////////// GitLab의 관리자 도구는 웹 페이지로 되어있다. 웹 브라우저로 GitLab이 설치된 곳의 주소에 들어가면 그냥 보인다. 그리고 관리자로 로그인하자. -기본 사용자 이름은 `admin@local.host`, 비밀번호는 `5iveL!fe`이다(이건 로그인 후에 바꿀 수 있다). +기본 사용자이름은 `admin@local.host`, 암호는 `5iveL!fe`이다(이건 로그인 후에 바꿀 수 있다). 로그인하고 나서 메뉴 오른쪽 위에 있는 ``Admin area''를 클릭한다. [[gitlab_menu]] @@ -151,7 +151,7 @@ The types of permissions are too numerous to list here, but GitLab has a helpful ===== 프로젝트 ////////////////////////// -A GitLab project roughly corresponds to a single git repository. +A GitLab project roughly corresponds to a single Git repository. Every project belongs to a single namespace, either a user or a group. If the project belongs to a user, the owner of the project has direct control over who has access to the project; if the project belongs to a group, the group's user-level permissions will also take effect. ////////////////////////// @@ -163,12 +163,12 @@ GitLab의 프로젝트는 간단히 이야기하면 하나의 Git 저장소다. Every project also has a visibility level, which controls who has read access to that project's pages and repository. If a project is _Private_, the project's owner must explicitly grant access to specific users. An _Internal_ project is visible to any logged-in user, and a _Public_ project is visible to anyone. -Note that this controls both git ``fetch'' access as well as access to the web UI for that project. +Note that this controls both `git fetch` access as well as access to the web UI for that project. ////////////////////////// 프로젝트마다 공개 수준을 지정할 수 있어서 사람마다 프로젝트 페이지와 저장소가 보이거나 안 보이게 할 수 있다. 프로젝트가 _Private_이면 프로젝트 소유자가 허락한 사람들만 프로젝트에 접근할 수 있다. _Internal_은 로그인한 사용자에게만 보인다. 그리고 _Public_ 프로젝트는 모든 사람이 볼 수 있다. -이런 공개 수준은 git ``fetch''같은 접근이나 웹 UI 접근에 다 적용된다. +이런 공개 수준은 `git fetch` 같은 접근이나 웹 UI 접근에 다 적용된다. ////////////////////////// ===== Hooks @@ -178,7 +178,7 @@ _Internal_은 로그인한 사용자에게만 보인다. 그리고 _Public_ 프 ////////////////////////// GitLab includes support for hooks, both at a project or system level. For either of these, the GitLab server will perform an HTTP POST with some descriptive JSON whenever relevant events occur. -This is a great way to connect your git repositories and GitLab instance to the rest of your development automation, such as CI servers, chat rooms, or deployment tools. +This is a great way to connect your Git repositories and GitLab instance to the rest of your development automation, such as CI servers, chat rooms, or deployment tools. ////////////////////////// GitLab은 훅도 지원하는데 프로젝트 훅이나 시스템 훅을 사용할 수 있다. 훅은 어떤 이벤트가 발생하면 해당 이벤트 정보가 담긴 JSON 데이터를 HTTP POST로 보낸다. @@ -241,7 +241,7 @@ Each project's home page shows recent activity, and links along the top will lea ==== 함께 일하기 ////////////////////////// -The simplest way of working together on a GitLab project is by giving another user direct push access to the git repository. +The simplest way of working together on a GitLab project is by giving another user direct push access to the Git repository. You can add a user to a project by going to the ``Members'' section of that project's settings, and associating the new user with an access level (the different access levels are discussed a bit in <<_gitlab_groups_section>>). By giving a user an access level of ``Developer'' or above, that user can push commits and branches directly to the repository with impunity. ////////////////////////// diff --git a/book/04-git-server/sections/gitweb.asc b/book/04-git-server/sections/gitweb.asc index 0354c230..818670b6 100644 --- a/book/04-git-server/sections/gitweb.asc +++ b/book/04-git-server/sections/gitweb.asc @@ -66,7 +66,7 @@ First, you need to get the Git source code, which GitWeb comes with, and generat ---- $ git clone git://git.kernel.org/pub/scm/git/git.git $ cd git/ -$ make GITWEB_PROJECTROOT="/opt/git" prefix=/usr gitweb +$ make GITWEB_PROJECTROOT="/srv/git" prefix=/usr gitweb SUBDIR gitweb SUBDIR ../ make[2]: `GIT-VERSION-FILE' is up to date. diff --git a/book/04-git-server/sections/protocols.asc b/book/04-git-server/sections/protocols.asc index 8c0b9344..67452381 100644 --- a/book/04-git-server/sections/protocols.asc +++ b/book/04-git-server/sections/protocols.asc @@ -36,17 +36,17 @@ For example, to clone a local repository, you can run something like this: [source,console] ---- -$ git clone /opt/git/project.git +$ git clone /srv/git/project.git ---- ////////////////////////// Or you can do this: ////////////////////////// -아래 처럼도 가능하다: +아래처럼도 가능하다: [source,console] ---- -$ git clone file:///opt/git/project.git +$ git clone file:///srv/git/project.git ---- ////////////////////////// @@ -71,7 +71,7 @@ To add a local repository to an existing Git project, you can run something like [source,console] ---- -$ git remote add local_proj /opt/git/project.git +$ git remote add local_proj /srv/git/project.git ---- ////////////////////////// @@ -158,9 +158,9 @@ Git은 HTTP로 통신할 때, 서로 다른 두 방법으로 HTTP를 사용할 (((protocols, smart HTTP))) ////////////////////////// -The ``smart'' HTTP protocol operates very similarly to the SSH or Git protocols but runs over standard HTTP/S ports and can use various HTTP authentication mechanisms, meaning it's often easier on the user than something like SSH, since you can use things like username/password basic authentication rather than having to set up SSH keys. +The ``smart'' HTTP protocol operates very similarly to the SSH or Git protocols but runs over standard HTTP/S ports and can use various HTTP authentication mechanisms, meaning it's often easier on the user than something like SSH, since you can use things like username/password authentication rather than having to set up SSH keys. ////////////////////////// -스마트 HTTP 프로토콜은 SSH나 Git 프로토콜처럼 통신한다. 다만 HTTP나 HTTPS 포트를 이용해 통신하고 다양한 HTTP 인증 방식을 사용한다는 것이 다르다. SSH는 키를 발급하고 관리해야 하는 번거로움이 있지만, HTTP는 익숙한 사용자 이름과 비밀번호방식을 사용하기 때문에 더 편리하게 사용할 수 있다. +스마트 HTTP 프로토콜은 SSH나 Git 프로토콜처럼 통신한다. 다만 HTTP나 HTTPS 포트를 이용해 통신하고 다양한 HTTP 인증 방식을 사용한다는 것이 다르다. SSH는 키를 발급하고 관리해야 하는 번거로움이 있지만, HTTP는 사용자이름과 암호만으로 인증할 수 있기 때문에 더 편리하게 사용할 수 있다. ////////////////////////// It has probably become the most popular way to use Git now, since it can be set up to both serve anonymously like the `git://` protocol, and can also be pushed over with authentication and encryption like the SSH protocol. @@ -169,7 +169,7 @@ If you try to push and the repository requires authentication (which it normally ////////////////////////// 아마 지금은 Git에서 가장 많이 사용하는 프로토콜일 것이다. `git://` 프로토콜처럼 익명으로 사용할 수도 있고, SSH처럼 인증을 거쳐 Push 할 수도 있기 때문이다. 이 두 가지 동작을 다른 URL로 나눌 필요없이 하나의 URL로 통합해서 사용할 수 있다. -그냥 인증기능을 켜놓은 저장소에 Push를 하면 서버는 사용자 이름과 비밀번호를 물어본다. 그리고 Fetch나 Pull 같은 읽기 작업에서도 같은 URL을 사용한다. +그냥 인증기능을 켜놓은 저장소에 Push를 하면 서버는 사용자이름과 암호를 물어본다. 그리고 Fetch나 Pull 같은 읽기 작업에서도 같은 URL을 사용한다. ////////////////////////// In fact, for services like GitHub, the URL you use to view the repository online (for example, ``https://github.com/schacon/simplegit[]'') is the same URL you can use to clone and, if you have access, push over. @@ -250,8 +250,8 @@ Being able to authenticate with a username and password is also a big advantage For less sophisticated users, or users on systems where SSH is less common, this is a major advantage in usability. It is also a very fast and efficient protocol, similar to the SSH one. ////////////////////////// -읽기와 쓰기에 하나의 URL만 사용한다. 그리고 사용자에게 익숙한 아이디와 비밀번호 방식의 인증을 사용한다. -사용하기에 사용자 이름과 비밀번호 방식의 인증이 SSH에 비해 간단하다. SSH는 사용자가 알아서 키를 만들고 공개키를 서버에 올린 후에야 비로소 인증을 받을 수 있다. +읽기와 쓰기에 하나의 URL만 사용한다. 그리고 사용자에게 익숙한 사용자이름과 암호 방식의 인증을 사용한다. +사용자이름과 암호 방식의 인증이 SSH에 비해 사용하기 간단하다. SSH는 사용자가 알아서 키를 만들고 공개키를 서버에 올린 후에야 비로소 인증을 받을 수 있다. SSH에 대해 잘 모르거나 익숙지 않은 사용자를 생각하면 이런 사용성은 엄청난 장점이다. 게다가 SSH만큼이나 빠르고 효율적이기 까지 하다. @@ -284,7 +284,7 @@ Read <<_credential_caching>> to see how to set up secure HTTP password caching o ////////////////////////// Push 할 때 HTTP 인증을 사용하면 SSH 인증키를 사용하는 것보다 좀 더 복잡하다. 그래도 인증 캐싱 툴을 사용하면 좀 낫다. OSX에는 키체인(Keychain Access)이, Windows에는 인증서 관리자(Credential Manager)가 있다. -HTTP 비밀번호 캐싱 설정에 대한 더 자세한 사항은 <<_credential_caching>> 를 참고하길 바란다. +HTTP 암호 캐싱 설정에 대한 더 자세한 사항은 <<_credential_caching>> 를 참고하길 바란다. ////////////////////////// ==== The SSH Protocol diff --git a/book/04-git-server/sections/setting-up-server.asc b/book/04-git-server/sections/setting-up-server.asc index 5e2b26b3..5c8ef2cc 100644 --- a/book/04-git-server/sections/setting-up-server.asc +++ b/book/04-git-server/sections/setting-up-server.asc @@ -63,11 +63,11 @@ Now, you can set up an empty repository for them by running `git init` with the [source,console] ---- -$ cd /opt/git +$ cd /srv/git $ mkdir project.git $ cd project.git $ git init --bare -Initialized empty Git repository in /opt/git/project.git/ +Initialized empty Git repository in /srv/git/project.git/ ---- ////////////////////////// @@ -88,7 +88,7 @@ $ cd myproject $ git init $ git add . $ git commit -m 'initial commit' -$ git remote add origin git@gitserver:/opt/git/project.git +$ git remote add origin git@gitserver:/srv/git/project.git $ git push origin master ---- @@ -99,7 +99,7 @@ At this point, the others can clone it down and push changes back up just as eas [source,console] ---- -$ git clone git@gitserver:/opt/git/project.git +$ git clone git@gitserver:/srv/git/project.git $ cd project $ vim README $ git commit -am 'fix for the README file' diff --git a/book/04-git-server/sections/smart-http.asc b/book/04-git-server/sections/smart-http.asc index aea40bc8..9372fcff 100644 --- a/book/04-git-server/sections/smart-http.asc +++ b/book/04-git-server/sections/smart-http.asc @@ -5,7 +5,7 @@ (((serving repositories, HTTP))) ////////////////////////// -We now have authenticated access though SSH and unauthenticated access through `git://`, but there is also a protocol that can do both at the same time. +We now have authenticated access through SSH and unauthenticated access through `git://`, but there is also a protocol that can do both at the same time. Setting up Smart HTTP is basically just enabling a CGI script that is provided with Git called `git-http-backend` on the server.((git commands, "http-backend")) This CGI will read the path and headers sent by a `git fetch` or `git push` to an HTTP URL and determine if the client can communicate over HTTP (which is true for any client since version 1.6.6). If the CGI sees that the client is smart, it will communicate smartly with it, otherwise it will fall back to the dumb behavior (so it is backward compatible for reads with older clients). @@ -36,11 +36,11 @@ This also enables the `mod_cgi`, `mod_alias`, `mod_env`, and `mod_rewrite` modul ////////////////////////// You’ll also need to set the Unix user group of the `/opt/git` directories to `www-data` so your web server can read- and write-access the repositories, because the Apache instance running the CGI script will (by default) be running as that user: ////////////////////////// -`/opt/git` 디렉토리의 Unix 사용자 그룹도 `www-data`로 설정해야 한다. 그래야 웹 서버가 저장소를 읽고 쓸 수 있다. Apache 인스턴스는 CGI 스크립트를 이 사용자로 실행시킨다(기본 설정이다). +`/srv/git` 디렉토리의 Unix 사용자 그룹도 `www-data`로 설정해야 한다. 그래야 웹 서버가 저장소를 읽고 쓸 수 있다. Apache 인스턴스는 CGI 스크립트를 이 사용자로 실행시킨다(기본 설정이다). [source,console] ---- -$ chgrp -R www-data /opt/git +$ chgrp -R www-data /srv/git ---- ////////////////////////// @@ -50,7 +50,7 @@ Next we need to add some things to the Apache configuration to run the `git http [source,console] ---- -SetEnv GIT_PROJECT_ROOT /opt/git +SetEnv GIT_PROJECT_ROOT /srv/git SetEnv GIT_HTTP_EXPORT_ALL ScriptAlias /git/ /usr/lib/git-core/git-http-backend/ ---- @@ -75,7 +75,7 @@ RewriteRule ^/git/ - [E=AUTHREQUIRED] AuthType Basic AuthName "Git Access" - AuthUserFile /opt/git/.htpasswd + AuthUserFile /srv/git/.htpasswd Require valid-user Order deny,allow Deny from env=AUTHREQUIRED @@ -87,12 +87,12 @@ RewriteRule ^/git/ - [E=AUTHREQUIRED] That will require you to create a `.htpasswd` file containing the passwords of all the valid users. Here is an example of adding a ``schacon'' user to the file: ////////////////////////// -`.htpasswd` 파일에는 접근을 허가하려는 사용자의 비밀번호가 들어가 있어야 한다. +`.htpasswd` 파일에는 접근을 허가하려는 사용자의 암호가 들어가 있어야 한다. 아래는 ``schacon''이란 사용자를 추가하는 방법이다. [source,console] ---- -$ htpasswd -c /opt/git/.htpasswd schacon +$ htpasswd -c /srv/git/.htpasswd schacon ---- ////////////////////////// diff --git a/book/05-distributed-git/sections/contributing.asc b/book/05-distributed-git/sections/contributing.asc index 2318dc56..8396a8fc 100644 --- a/book/05-distributed-git/sections/contributing.asc +++ b/book/05-distributed-git/sections/contributing.asc @@ -45,7 +45,7 @@ Is a lieutenant system in place, and do you have to submit your work to them fir 중간 관리자가 있어서 그들에게 먼저 알려야 하는가? ////////////////////////// -The next issue is your commit access. +The next variable is your commit access. The workflow required in order to contribute to a project is much different if you have write access to the project than if you don't. If you don't have write access, how does the project prefer to accept contributed work? Does it even have a policy? @@ -126,7 +126,7 @@ The Git project requires that the more detailed explanation include your motivat It's also a good idea to use the imperative present tense in these messages. In other words, use commands. Instead of ``I added tests for'' or ``Adding tests for,'' use ``Add tests for.'' -Here is a template originally written by Tim Pope: +Here is a http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html[template originally written by Tim Pope]: ////////////////////////// 마지막으로 명심해야 할 점은 커밋 메시지 자체다. 좋은 커밋 메시지를 작성하는 습관은 Git을 사용하는 데 도움이 많이 된다. @@ -135,7 +135,7 @@ Here is a template originally written by Tim Pope: 그리고 현재형 표현을 사용하는 것이 좋다. 명령문으로 시작하는 것도 좋은 방법이다. 예를 들어 ``I added tests for (테스트를 추가함)'' 보다는 ``Add tests for (테스트 추가)'' 와 같은 메시지를 작성한다. -아래 내용은 Tim Pope가 작성한 커밋 메시지의 템플릿이다. +아래 내용은 http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html[Tim Pope가 작성한 커밋 메시지의 템플릿]이다. [source,text] ////////////////////////// @@ -186,10 +186,10 @@ The Git project has well-formatted commit messages – try running `git log --no Git 개발 프로젝트에는 잘 쓰인 커밋 메시지가 많으므로 프로젝트를 내려받아서 `git log --no-merges` 명령으로 꼭 살펴보기를 권한다. ////////////////////////// -In the following examples, and throughout most of this book, for the sake of brevity this book doesn't have nicely-formatted messages like this; instead, we use the `-m` option to `git commit`. +For the sake of brevity, the following examples, and most examples in other parts of this book, don't have nicely-formatted messages like this; instead, we use the `-m` option to `git commit`. Do as we say, not as we do. ////////////////////////// -이 책에서 설명하는 예제의 커밋 메시지는 시간 관계상 위와 같이 아주 멋지게 쓰지 않았다. `git commit` 명령에서 `-m` 옵션을 사용하여 간단하게 적는다. +시간 관계상, 이 책에서 설명하는 예제의 커밋 메시지는 위와 같이 아주 멋지게 쓰지 않았다. `git commit` 명령에서 `-m` 옵션을 사용하여 간단하게 적는다. 하지만! 저자처럼 하지 말고 시키는 대로 하는 것이 좋다. [[_private_team]] @@ -229,8 +229,8 @@ Cloning into 'simplegit'... ... $ cd simplegit/ $ vim lib/simplegit.rb -$ git commit -am 'removed invalid default value' -[master 738ee87] removed invalid default value +$ git commit -am 'remove invalid default value' +[master 738ee87] remove invalid default value 1 files changed, 1 insertions(+), 1 deletions(-) ---- @@ -419,7 +419,7 @@ commit 738ee872852dfaa9d6634e0dea7a324040193016 Author: John Smith Date: Fri May 29 16:01:27 2009 -0700 - removed invalid default value + remove invalid default value ---- ////////////////////////// @@ -480,7 +480,7 @@ Now Jessica merges in John's work (`origin/master`): ---- $ git merge origin/master Auto-merging lib/simplegit.rb -Merge made by recursive. +Merge made by the 'recursive' strategy. lib/simplegit.rb | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) ---- @@ -524,8 +524,8 @@ image::images/small-team-7.png[Jessica가 서버로 Push 하고 난 후의 저 ////////////////////////// That is one of the simplest workflows. -You work for a while, generally in a topic branch, and merge into your master branch when it's ready to be integrated. -When you want to share that work, you fetch and merge your master from `origin/master` if it has changed, and finally push to the `master` branch on the server. +You work for a while, generally in a topic branch, and merge into your `master` branch when it's ready to be integrated. +When you want to share that work, you fetch and merge your `master` from `origin/master` if it has changed, and finally push to the `master` branch on the server. The general sequence is something like this: ////////////////////////// 매우 간단한 상황의 예제를 살펴보았다. @@ -669,7 +669,7 @@ Fetch 해 온 브랜치를 `git merge` 명령으로 Merge 한다. ---- $ git merge origin/featureBee Auto-merging lib/simplegit.rb -Merge made by recursive. +Merge made by the 'recursive' strategy. lib/simplegit.rb | 4 ++++ 1 files changed, 4 insertions(+), 0 deletions(-) ---- @@ -813,13 +813,13 @@ image::images/managed-team-flow.png[Managed 팀의 워크플로.] Contributing to public projects is a bit different. Because you don't have the permissions to directly update branches on the project, you have to get the work to the maintainers some other way. This first example describes contributing via forking on Git hosts that support easy forking. -Many hosting sites support this (including GitHub, BitBucket, Google Code, repo.or.cz, and others), and many project maintainers expect this style of contribution. +Many hosting sites support this (including GitHub, BitBucket, repo.or.cz, and others), and many project maintainers expect this style of contribution. The next section deals with projects that prefer to accept contributed patches via email. ////////////////////////// 비공개 팀을 운영하는 것과 공개 팀을 운영하는 것은 약간 다르다. 공개 팀을 운영할 때는 모든 개발자가 프로젝트의 공유 저장소에 직접적으로 쓰기 권한을 가지지는 않는다. 그래서 프로젝트의 관리자는 몇 가지 일을 더 해줘야 한다. Fork를 지원하는 Git 호스팅에서 Fork를 통해 프로젝트에 기여하는 법을 예제를 통해 살펴본다. -Git 호스팅 사이트(GitHub, BitBucket, Google Code, repo.or.cz 등) 대부분은 Fork 기능을 지원하며 프로젝트 관리자는 보통 Fork 하는 것으로 프로젝트를 운영한다. +Git 호스팅 사이트(GitHub, BitBucket, repo.or.cz 등) 대부분은 Fork 기능을 지원하며 프로젝트 관리자는 보통 Fork 하는 것으로 프로젝트를 운영한다. 다른 방식으로 이메일과 Patch를 사용하는 방식도 있는데 뒤이어 살펴본다. ////////////////////////// @@ -864,14 +864,14 @@ $ git remote add myfork (url) ////////////////////////// Then you need to push your work up to it. -It's easiest to push the topic branch you're working on up to your repository, rather than merging into your master branch and pushing that up. -The reason is that if the work isn't accepted or is cherry picked, you don't have to rewind your master branch. -If the maintainers merge, rebase, or cherry-pick your work, you'll eventually get it back via pulling from their repository anyhow: +It's easiest to push the topic branch you're working on up to your repository, rather than merging into your `master` branch and pushing that up. +The reason is that if the work isn't accepted or is cherry-picked, you don't have to rewind your master branch. (`cherry-pick` is covered in more detail in <<_rebase_cherry_pick>>). +If the maintainers `merge`, `rebase`, or `cherry-pick` your work, you'll eventually get it back via pulling from their repository anyhow: ////////////////////////// 자 이제 등록한 리모트 저장소에 Push 한다. -작업하던 것을 로컬 저장소의 master 브랜치에 Merge 한 후 Push 하는 것보다 리모트 브랜치에 바로 Push를 하는 방식이 훨씬 간단하다. -이렇게 하는 이유는 관리자가 토픽 브랜치를 프로젝트에 포함시키고 싶지 않을 때 토픽 브랜치를 Merge 하기 이전 상태로 master 브랜치를 되돌릴 필요가 없기 때문이다. -관리자가 토픽 브랜치를 Merge 하든 Rebase 하든 cherry-pick 하든지 간에 결국 다시 관리자의 저장소를 Pull 할 때는 토픽 브랜치의 내용이 들어 있을 것이다. +작업하던 것을 로컬 저장소의 `master` 브랜치에 Merge 한 후 Push 하는 것보다 리모트 브랜치에 바로 Push를 하는 방식이 훨씬 간단하다. +이렇게 하는 이유는 관리자가 토픽 브랜치를 프로젝트에 포함시키고 싶지 않을 때 토픽 브랜치를 Merge 하기 이전 상태로 `master` 브랜치를 되돌릴 필요가 없기 때문이다. (`cherry-pick` 명령은 <<_rebase_cherry_pick>> 에서 자세히 다룬다). +관리자가 토픽 브랜치를 Merge 하든 Rebase 하든 Cherry-Pick 하든지 간에 결국 다시 관리자의 저장소를 Pull 할 때는 토픽 브랜치의 내용이 들어 있을 것이다. [source,console] ---- @@ -932,6 +932,7 @@ $ git checkout -b featureB origin/master # (work) $ git commit $ git push myfork featureB +$ git request-pull origin/master myfork # (email maintainer) $ git fetch origin ---- diff --git a/book/05-distributed-git/sections/distributed-workflows.asc b/book/05-distributed-git/sections/distributed-workflows.asc index d30c36f0..1657f75f 100644 --- a/book/05-distributed-git/sections/distributed-workflows.asc +++ b/book/05-distributed-git/sections/distributed-workflows.asc @@ -137,28 +137,28 @@ This is a variant of a multiple-repository workflow. It's generally used by huge projects with hundreds of collaborators; one famous example is the Linux kernel. Various integration managers are in charge of certain parts of the repository; they're called lieutenants. All the lieutenants have one integration manager known as the benevolent dictator. -The benevolent dictator's repository serves as the reference repository from which all the collaborators need to pull. +The benevolent dictator pushes from his directory to a reference repository from which all the collaborators need to pull. The process works like this (see <>): ////////////////////////// 이 방식은 저장소를 여러개 운영하는 방식을 변형한 구조이다. 보통 수백 명의 개발자가 참여하는 아주 큰 프로젝트를 운영할 때 이 방식을 사용한다. Linux 커널 프로젝트가 대표적이다. 여러 명의 Integration-Manager가 저장소에서 자신이 맡은 부분만을 담당하는데 이들을 Lieutenants라고 부른다. -모든 Lieutenant는 최종 관리자 아래에 있으며 이 최종 관리자를 Dictator라고 부른다. -최종 관리자가 관리하는 저장소를 공식 저장소로 하며 모든 프로젝트 참여자는 이 공식 저장소를 기준으로 작업한다. +모든 Lieutenant는 최종 관리자 아래에 있으며 이 최종 관리자를 Benevolent Dictator라고 부른다. +Benevolent Dictator는 Lieutenant의 저장소를 가져와 공식 저장소에 Push 하고 모든 프로젝트 참여자는 이 공식 저장소에서 반드시 Pull 해야 한다. 이러한 워크플로는 아래와 같다(<>). ////////////////////////// 1. Regular developers work on their topic branch and rebase their work on top of `master`. - The `master` branch is that of the dictator. + The `master` branch is that of the reference directory to which the dictator pushes. 2. Lieutenants merge the developers' topic branches into their `master` branch. -3. The dictator merges the lieutenants' `master` branches into the dictator's `master` branch. +3. The dictator merges the lieutenants' `master` branches into their `master` branch. 4. The dictator pushes their `master` to the reference repository so the other developers can rebase on it. ////////////////////////// 1. 개발자는 코드를 수정하고 master 브랜치를 기준으로 자신의 토픽 브랜치를 Rebase 한다. - 여기서 master 브랜치란 Dictator의 브랜치를 말한다. + 여기서 master 브랜치란 공식 저장소의 브랜치를 말한다. 2. Lieutenant들은 개발자들의 수정사항을 자신이 관리하는 master 브랜치에 Merge 한다. 3. Dictator는 Lieutenant의 master 브랜치를 자신의 master 브랜치로 Merge 한다. -4. Dictator는 Merge 한 자신의 master 브랜치를 Push 하며 다른 모든 개발자는 Dictator의 master 브랜치를 기준으로 Rebase 한다. +4. Dictator는 자신의 master 브랜치를 Push 하며 다른 모든 개발자는 Dictator의 master 브랜치를 기준으로 Rebase 한다. [[wfdiag_c]] ////////////////////////// diff --git a/book/05-distributed-git/sections/maintaining.asc b/book/05-distributed-git/sections/maintaining.asc index f0c47194..729d53fe 100644 --- a/book/05-distributed-git/sections/maintaining.asc +++ b/book/05-distributed-git/sections/maintaining.asc @@ -24,13 +24,13 @@ When you're thinking of integrating new work, it's generally a good idea to try This way, it's easy to tweak a patch individually and leave it if it's not working until you have time to come back to it. If you create a simple branch name based on the theme of the work you're going to try, such as `ruby_client` or something similarly descriptive, you can easily remember it if you have to abandon it for a while and come back later. The maintainer of the Git project tends to namespace these branches as well – such as `sc/ruby_client`, where `sc` is short for the person who contributed the work. -As you'll remember, you can create the branch based off your master branch like this: +As you'll remember, you can create the branch based off your `master` branch like this: ////////////////////////// 메인 브랜치에 통합하기 전에 임시로 토픽 브랜치를 하나 만들고 거기에 통합해 보고 나서 다시 메인 브랜치에 통합하는 것이 좋다. 이렇게 하면 Patch를 적용할 때 이리저리 수정해 보기도 하고 좀 더 고민해 봐야 하면 Patch를 적용해둔 채로 나중으로 미룰 수도 있다. 무슨 Patch인지 브랜치 이름에 간단히 적어주면 다른 작업을 하다가 나중에 이 브랜치로 돌아왔을 때 기억해내기 훨씬 수월하다. 프로젝트 관리자라면 이런 토픽 브랜치의 이름을 잘 지어야 한다. 예를 들어 `sc` 라는 사람이 작업한 Patch라면 `sc/ruby_client` 처럼 앞에 닉네임을 붙여서 브랜치를 만들 수 있다. -master 브랜치에서 새 토픽 브랜치를 아래와 같이 만든다. +`master` 브랜치에서 새 토픽 브랜치를 아래와 같이 만든다. [source,console] ---- @@ -48,9 +48,9 @@ $ git checkout -b sc/ruby_client master ---- ////////////////////////// -Now you're ready to add your contributed work into this topic branch and determine if you want to merge it into your longer-term branches. +Now you're ready to add your contributed work that you received into this topic branch and determine if you want to merge it into your longer-term branches. ////////////////////////// -이렇게 토픽 브랜치를 만들고 Patch를 적용해보고 적용한 내용을 다시 Long-Running 브랜치로 Merge 한다. +이렇게 토픽 브랜치를 만들고 받은 Patch를 적용해보고 적용한 내용을 다시 Long-Running 브랜치로 Merge 한다. [[_patches_from_email]] ////////////////////////// @@ -99,7 +99,7 @@ It won't create a commit for you – after running it, you must stage and commit `git apply`는 `patch` 명령보다 훨씬 보수적이다. 이 명령은 자동으로 커밋해 주지 않기 때문에 변경된 파일을 직접 Staging Area에 추가하고 커밋해야 한다. ////////////////////////// -You can also use git apply to see if a patch applies cleanly before you try actually applying it – you can run `git apply --check` with the patch: +You can also use `git apply` to see if a patch applies cleanly before you try actually applying it – you can run `git apply --check` with the patch: ////////////////////////// 실제로 Patch를 적용하기 전에 Patch가 잘 적용되는지 한 번 시험해보려면 `git apply --check` 명령을 사용한다. @@ -134,11 +134,11 @@ You should only have to use `git apply` for legacy patches and things like that. `git apply`는 기존 Patch 파일에만 사용한다. ////////////////////////// -To apply a patch generated by `format-patch`, you use `git am`. +To apply a patch generated by `format-patch`, you use `git am` (the command is named `am` as it is used to "apply a series of patches from a mailbox"). Technically, `git am` is built to read an mbox file, which is a simple, plain-text format for storing one or more email messages in one text file. It looks something like this: ////////////////////////// -`format-patch` 명령으로 생성한 Patch 파일은 `git am` 명령으로 적용한다. +`format-patch` 명령으로 생성한 Patch 파일은 `git am` 명령으로 적용한다(`am`은 "apply a series of patches from a mailbox"의 약자다). `git am`은 mbox 파일을 읽어 그 안에 이메일 메시지가 한 개가 있든 여러 개가 있든 처리할 수 있다. mbox 파일은 간단한 텍스트 파일이고 그 내용은 아래와 같다. @@ -153,12 +153,12 @@ Limit log functionality to the first 20 ---- ////////////////////////// -This is the beginning of the output of the format-patch command that you saw in the previous section. +This is the beginning of the output of the `format-patch` command that you saw in the previous section. This is also a valid mbox email format. -If someone has emailed you the patch properly using git send-email, and you download that into an mbox format, then you can point git am to that mbox file, and it will start applying all the patches it sees. -If you run a mail client that can save several emails out in mbox format, you can save entire patch series into a file and then use git am to apply them one at a time. +If someone has emailed you the patch properly using `git send-email`, and you download that into an mbox format, then you can point `git am` to that mbox file, and it will start applying all the patches it sees. +If you run a mail client that can save several emails out in mbox format, you can save entire patch series into a file and then use `git am` to apply them one at a time. ////////////////////////// -이 내용은 format-patch 명령으로 생성한 파일의 앞부분이다. +이 내용은 `format-patch` 명령으로 생성한 파일의 앞부분이다. 이 파일은 mbox 형식이다. 받은 메일이 `git send-email`로 만든 메일이라면 mbox 형식으로 저장하고 이 mbox 파일을 `git am` 명령으로 적용한다. 사용하는 메일 클라이언트가 여러 이메일을 mbox 파일 하나로 저장할 수 있다면 메일 여러 개를 한 번에 Patch 할 수 있다. @@ -261,11 +261,11 @@ No changes -- Patch already applied. ---- ////////////////////////// -In this case, this patch had already been applied. -Without the `-3` option, it looks like a conflict. +In this case, without the `-3` option the patch would have been considered as a conflict. +Since the `-3` option was used the patch applied cleanly. ////////////////////////// -위의 경우는 이미 Patch 한 것을 다시 Patch 하는 상황이다. -`-3` 옵션이 없었으면 충돌을 알아서 해결하지 못했을 것이다. +위의 경우에서 `-3` 옵션이 없었으면 충돌이 났을 것이다. +`-3` 옵션이 있어서 충돌 없이 깨끗하게 Patch가 적용됐다. ////////////////////////// If you're applying a number of patches from an mbox, you can also run the `am` command in interactive mode, which stops at each patch it finds and asks if you want to apply it: @@ -317,9 +317,9 @@ $ git checkout -b rubyclient jessica/ruby-client ---- ////////////////////////// -If she emails you again later with another branch containing another great feature, you can fetch and check out because you already have the remote setup. +If she emails you again later with another branch containing another great feature, you could directly `fetch` and `checkout` because you already have the remote setup. ////////////////////////// -나중에 Jessiaca가 이메일로 또 다른 엄청난 기능을 개발한 브랜치를 보내오면 이미 저장소를 등록했기 때문에 간단히 Fetch 하고 Checkout 할 수 있다. +나중에 Jessiaca가 이메일로 또 다른 엄청난 기능을 개발한 브랜치를 보내오면 이미 저장소를 등록했기 때문에 바로 Fetch 하고 Checkout 할 수 있다. ////////////////////////// This is most useful if you're working with a person consistently. @@ -351,7 +351,7 @@ This does a one-time pull and doesn't save the URL as a remote reference: $ git pull https://github.com/onetimeguy/project From https://github.com/onetimeguy/project * branch HEAD -> FETCH_HEAD -Merge made by recursive. +Merge made by the 'recursive' strategy. ---- [[_what_is_introduced]] @@ -371,13 +371,13 @@ This section revisits a couple of commands so you can see how you can use them t 주로 토픽 브랜치를 검토하는데 필요한 명령이다. ////////////////////////// -It's often helpful to get a review of all the commits that are in this branch but that aren't in your master branch. -You can exclude commits in the master branch by adding the `--not` option before the branch name. +It's often helpful to get a review of all the commits that are in this branch but that aren't in your `master` branch. +You can exclude commits in the `master` branch by adding the `--not` option before the branch name. This does the same thing as the `master..contrib` format that we used earlier. For example, if your contributor sends you two patches and you create a branch called `contrib` and applied those patches there, you can run this: ////////////////////////// -먼저 지금 작업하는 브랜치에서 master 브랜치에 속하지 않는 커밋만 살펴보는 것이 좋다. -`--not` 옵션으로 히스토리에서 master 브랜치에 속한 커밋은 제외하고 살펴본다. +먼저 지금 작업하는 브랜치에서 `master` 브랜치에 속하지 않는 커밋만 살펴보는 것이 좋다. +`--not` 옵션으로 히스토리에서 `master` 브랜치에 속한 커밋은 제외하고 살펴본다. 앞서 살펴본 `master..contrib` 형식을 사용하여 확인할 수도 있다. `contrib` 브랜치에 Patch를 두 개 Merge 했으면 아래와 같은 명령어로 그 결과를 살펴볼 수 있다. @@ -432,9 +432,9 @@ If `master` is a direct ancestor of your topic branch, this isn't a problem; but ////////////////////////// What you really want to see are the changes added to the topic branch – the work you'll introduce if you merge this branch with master. -You do that by having Git compare the last commit on your topic branch with the first common ancestor it has with the master branch. +You do that by having Git compare the last commit on your topic branch with the first common ancestor it has with the `master` branch. ////////////////////////// -정말 보고 싶은 것은 토픽 브랜치에 추가한 것이고 결국에는 이것을 master 브랜치에 추가하려는 것이다. +정말 보고 싶은 것은 토픽 브랜치에 추가한 것이고 결국에는 이것을 `master` 브랜치에 추가하려는 것이다. 그러니까 master 브랜치와 토픽 브랜치의 공통 조상인 커밋을 찾아서 토픽 브랜치가 현재 가리키는 커밋과 비교해야 한다. ////////////////////////// @@ -490,9 +490,9 @@ You have a number of choices, so we'll cover a few of them. (((workflows, merging))) ////////////////////////// -One simple workflow merges your work into your `master` branch. +One simple workflow is to merge the work into your `master` branch. In this scenario, you have a `master` branch that contains basically stable code. -When you have work in a topic branch that you've done or that someone has contributed and you've verified, you merge it into your master branch, delete the topic branch, and then continue the process. +When you have work in a topic branch that you've done or that someone has contributed and you've verified, you merge it into your `master` branch, delete the topic branch, and then continue the process. If we have a repository with work in two branches named `ruby_client` and `php_client` that looks like <> and merge `ruby_client` first and then `php_client` next, then your history will end up looking like <>. ////////////////////////// 바로 `master` 브랜치에 Merge 하는 것이 가장 간단하다. @@ -558,12 +558,12 @@ image::images/merging-workflows-5.png[토픽 브랜치를 릴리즈한 후.] ////////////////////////// This way, when people clone your project's repository, they can either check out master to build the latest stable version and keep up to date on that easily, or they can check out develop, which is the more cutting-edge stuff. -You can also continue this concept, having an integrate branch where all the work is merged together. -Then, when the codebase on that branch is stable and passes tests, you merge it into a develop branch; and when that has proven itself stable for a while, you fast-forward your master branch. +You can also extend this concept by having an `integrate` branch where all the work is merged together. +Then, when the codebase on that branch is stable and passes tests, you merge it into a develop branch; and when that has proven itself stable for a while, you fast-forward your `master` branch. ////////////////////////// 이 워크플로를 사용하면 프로젝트 저장소를 Clone 하고 나서 개발자가 안정 버전이 필요하면 master 브랜치를 빌드하고 안정적이지 않더라도 좀 더 최신 버전이 필요하면 develop 브랜치를 Checkout 하여 빌드한다. -이 개념을 좀 더 확장해서 사용할 수 있다. 토픽 브랜치를 검증하기 위한 integrate 브랜치를 만들어 Merge 하고 토픽 브랜치가 검증되면 develop 브랜치에 Merge 한다. -그리고 develop 브랜치에서 충분히 안정하다는 것이 증명되면 그때 master 브랜치에 Merge 한다. +이 개념을 좀 더 확장해서 사용할 수 있다. 토픽 브랜치를 검증하기 위한 `integrate` 브랜치를 만들어 Merge 하고 토픽 브랜치가 검증되면 develop 브랜치에 Merge 한다. +그리고 develop 브랜치에서 충분히 안정하다는 것이 증명되면 그때 `master` 브랜치에 Merge 한다. ////////////////////////// ===== Large-Merging Workflows @@ -592,11 +592,13 @@ image::images/large-merges-1.png[토픽 브랜치를 동시에 여러 개 관리 ////////////////////////// If the topics still need work, they're merged into `pu` instead. -When it's determined that they're totally stable, the topics are re-merged into `master` and are then rebuilt from the topics that were in `next` but didn't yet graduate to `master`. +When it's determined that they're totally stable, the topics are re-merged into `master`. +The `next` and `pu` branches are then rebuilt from the `master`. This means `master` almost always moves forward, `next` is rebased occasionally, and `pu` is rebased even more often: ////////////////////////// 토픽 브랜치가 좀 더 개선돼야 하면 `next`가 아니라 `pu`에 Merge 한다. -그 후에 충분히 검증을 마치면 `pu`에서 `next`로 옮기고 `next`를 기반으로 `pu`를 다시 만든다. `next`에는 아직 `master`에 넣기에 모자라 보이는 것들이 들어 있다. +충분히 검증을 했을 때에만 `master` 브랜치로 Merge 한다. +`master` 브랜치에 Merge하고 나면 `next` 브랜치와 `pu` 브랜치는 `master` 브랜치를 기반으로 다시 만든다. 즉 `next` 브랜치는 정말 가끔 Rebase 하고 `pu`는 자주 Rebase 하지만 `master`는 항상 Fast-forward 한다. ////////////////////////// @@ -610,25 +612,27 @@ image::images/large-merges-2.png[토픽 브랜치를 Long-Running 브랜치로 M When a topic branch has finally been merged into `master`, it's removed from the repository. The Git project also has a `maint` branch that is forked off from the last release to provide backported patches in case a maintenance release is required. Thus, when you clone the Git repository, you have four branches that you can check out to evaluate the project in different stages of development, depending on how cutting edge you want to be or how you want to contribute; and the maintainer has a structured workflow to help them vet new contributions. +The Git project's workflow is specialized. To clearly understand this you could check out the https://github.com/git/git/blob/master/Documentaion/howto/maintain-git.txt[Git Maintainer's guide]. ////////////////////////// 토픽 브랜치가 결국 `master` 브랜치로 Merge 되면 저장소에서 삭제한다. 그리고 이전 릴리즈 버전에 Patch가 필요하면 `maint` 브랜치를 이용해 대응한다. Git을 개발하는 프로젝트를 Clone 하면 브랜치가 4개 있고 각 브랜치를 이용하여 진행사항을 확인해볼 수 있다. 그래서 새로운 기능을 추가하려면 적당한 브랜치를 보고 고른다. 이 워크플로는 잘 구조화돼 있어서 코드가 새로 추가돼도 테스트하기 쉽다. +이 Git 프로젝트의 워크플로는 끝판왕이다. 완벽하게 이해하려면 https://github.com/git/git/blob/master/Documentaion/howto/maintain-git.txt[Git 관리자 가이드]를 봐야 한다. [[_rebase_cherry_pick]] ////////////////////////// -===== Rebasing and Cherry Picking Workflows +===== Rebasing and Cherry-Picking Workflows ////////////////////////// ===== Rebase와 Cherry-Pick 워크플로 (((workflows, rebasing and cherry-picking))) ////////////////////////// -Other maintainers prefer to rebase or cherry-pick contributed work on top of their master branch, rather than merging it in, to keep a mostly linear history. +Other maintainers prefer to rebase or cherry-pick contributed work on top of their `master` branch, rather than merging it in, to keep a mostly linear history. When you have work in a topic branch and have determined that you want to integrate it, you move to that branch and run the rebase command to rebuild the changes on top of your current master (or `develop`, and so on) branch. If that works well, you can fast-forward your `master` branch, and you'll end up with a linear project history. ////////////////////////// 히스토리를 한 줄로 관리하려고 Merge 보다 Rebase 나 Cherry-Pick을 더 선호하는 관리자들도 있다. -토픽 브랜치에서 작업을 마친 후 master에 통합할 때 master 브랜치를 기반으로 Rebase 한다. 그러면 커밋이 다시 만들어 진다. master 대신 `develop` 등의 브랜치에도 가능하다. +토픽 브랜치에서 작업을 마친 후 `master` 브랜치에 Merge 할 때 `master` 브랜치를 기반으로 Rebase 한다. 그러면 커밋이 다시 만들어 진다. `master` 대신 `develop` 등의 브랜치에도 가능하다. 문제가 없으면 `master` 브랜치를 Fast-forward시킨다. 이렇게 히스토리를 한 줄로 유지할 수 있다. (((git commands, cherry-pick))) @@ -653,7 +657,7 @@ image::images/rebasing-1.png[Example history before a cherry-pick.] image::images/rebasing-1.png[Cherry-pick을 실행하기 전의 저장소.] ////////////////////////// -If you want to pull commit `e43a6` into your master branch, you can run +If you want to pull commit `e43a6` into your `master` branch, you can run ////////////////////////// `e43a6` 커밋 하나만 현재 브랜치에 적용하려면 아래와 같은 명령을 실행한다. diff --git a/book/06-github/sections/1-setting-up-account.asc b/book/06-github/sections/1-setting-up-account.asc index 37014bee..7d86d87f 100644 --- a/book/06-github/sections/1-setting-up-account.asc +++ b/book/06-github/sections/1-setting-up-account.asc @@ -9,7 +9,7 @@ The first thing you need to do is set up a free user account. Simply visit https://github.com[], choose a user name that isn't already taken, provide an email address and a password, and click the big green ``Sign up for GitHub'' button. ////////////////////////// 가장 먼저 할 일은 무료 사용자 계정을 만드는 일이다. -https://github.com[]에 방문해서 사용자 이름과 이메일 주소, 암호를 입력하고 ``Sign up for GitHub''이라는 큰 녹색 버튼을 누른다. +https://github.com[]에 방문해서 사용자이름과 이메일 주소, 암호를 입력하고 ``Sign up for GitHub''이라는 큰 녹색 버튼을 누른다. ////////////////////////// .The GitHub sign-up form. @@ -56,7 +56,7 @@ You're now ready to use GitHub. As of right now, you're fully able to connect with Git repositories using the `https://` protocol, authenticating with the username and password you just set up. However, to simply clone public projects, you don't even need to sign up - the account we just created comes into play when we fork projects and push to our forks a bit later. ////////////////////////// -이제는 `https://` 프로토콜로도 Git 저장소를 사용하는 데 부족함이 없다. 간단히 사용자 이름과 암호로 인증만 하면 된다. +이제는 `https://` 프로토콜로도 Git 저장소를 사용하는 데 부족함이 없다. 간단히 사용자이름과 암호로 인증만 하면 된다. 공개 프로젝트를 Clone 하는 데는 인증도 필요 없다. 우리가 만든 계정은 프로젝트를 Fork 하고 그 프로젝트에 Push 할 때가 돼야 비로소 필요하다. ////////////////////////// @@ -139,7 +139,7 @@ image::images/avatar-crop.png[아바타 자르기.] ////////////////////////// Now anywhere you interact on the site, people will see your avatar next to your username. ////////////////////////// -이제부터 GitHub 사이트에서 어디에서든 사용자 이름 옆에 아바타가 보인다. +이제부터 GitHub 사이트에서 어디에서든 사용자이름 옆에 아바타가 보인다. ////////////////////////// If you happen to have uploaded an avatar to the popular Gravatar service (often used for Wordpress accounts), that avatar will be used by default and you don't need to do this step. @@ -208,7 +208,7 @@ image::images/2fa-1.png[Security 탭에 있는 2FA] ////////////////////////// If you click on the ``Set up two-factor authentication'' button, it will take you to a configuration page where you can choose to use a phone app to generate your secondary code (a ``time based one-time password''), or you can have GitHub send you a code via SMS each time you need to log in. ////////////////////////// -``Set up two-factor authentication'' 버튼을 클릭하면 2FA 설정 페이지로 이동한다. ``TOTP(Time based One-Time 비밀번호''를 생성하는 스마트폰 앱을 사용하는 방식을 고르거나 GitHub가 인증 코드를 SMS로 전송해주는 방식을 고를 수 있다. 설정하면 로그인할 때 TOTP나 인증코드가 필요하다. +``Set up two-factor authentication'' 버튼을 클릭하면 2FA 설정 페이지로 이동한다. ``TOTP(Time based One-Time 암호''를 생성하는 스마트폰 앱을 사용하는 방식을 고르거나 GitHub가 인증 코드를 SMS로 전송해주는 방식을 고를 수 있다. 설정하면 로그인할 때 TOTP나 인증코드가 필요하다. ////////////////////////// After you choose which method you prefer and follow the instructions for setting up 2FA, your account will then be a little more secure and you will have to provide a code in addition to your password whenever you log into GitHub. diff --git a/book/06-github/sections/3-maintaining.asc b/book/06-github/sections/3-maintaining.asc index 5beefe8e..4a6d9641 100644 --- a/book/06-github/sections/3-maintaining.asc +++ b/book/06-github/sections/3-maintaining.asc @@ -19,7 +19,7 @@ Let's create a new repository to share our project code with. Start by clicking the ``New repository'' button on the right-hand side of the dashboard, or from the `+` button in the top toolbar next to your username as seen in <<_new_repo_dropdown>>. ////////////////////////// 저장소를 새로 만들고 프로젝트 코드를 공유해 보자. -대시보드 오른쪽에 있는 ``New repository'' 버튼을 클릭하면 저장소를 만드는 폼으로 이동한다. 맨 위 툴바의 사용자 이름 옆에 있는 `+` 버튼을 클릭해도 된다. +대시보드 오른쪽에 있는 ``New repository'' 버튼을 클릭하면 저장소를 만드는 폼으로 이동한다. 맨 위 툴바의 사용자이름 옆에 있는 `+` 버튼을 클릭해도 된다. ////////////////////////// .The ``Your repositories'' area. @@ -34,7 +34,7 @@ image::images/newrepo.png[``Your repositories'' 박스.] image::images/new-repo.png[The ``new repository'' dropdown.] ////////////////////////// .사용자이름 옆 ``New repository'' 메뉴. -image::images/new-repo.png[사용자 이름 옆 ``new repository'' 메뉴.] +image::images/new-repo.png[``new repository'' 메뉴.] ////////////////////////// This takes you to the ``new repository'' form: @@ -118,7 +118,7 @@ You can repeat this as many times as you like to grant access to everyone you li If you need to revoke access, just click the ``X'' on the right-hand side of their row. ////////////////////////// 왼쪽 메뉴에서 ``Collaborators''를 선택한다. -텍스트 박스에 사용자 이름을 입력하고 ``Add collaborator''를 클릭한다. +텍스트 박스에 사용자이름을 입력하고 ``Add collaborator''를 클릭한다. 필요한 사람을 모두 추가할 때까지 반복한다. 그리고 오른쪽에 있는 ``X''를 클릭하면 권한이 회수된다. @@ -467,7 +467,7 @@ GitHub는 어떤 팀이나 사람에게 질문하거나 피드백을 받을 수 ////////////////////////// In any comment you can start typing a `@` character and it will begin to autocomplete with the names and usernames of people who are collaborators or contributors in the project. ////////////////////////// -GitHub 어디에서나 `@`만 입력해도 동료나 기여자의 사용자 이름이 자동완성 된다. +GitHub 어디에서나 `@`만 입력해도 동료나 기여자의 사용자이름이 자동완성 된다. ////////////////////////// .Start typing @ to mention someone. diff --git a/book/06-github/sections/5-scripting.asc b/book/06-github/sections/5-scripting.asc index 25711392..b31b4e86 100644 --- a/book/06-github/sections/5-scripting.asc +++ b/book/06-github/sections/5-scripting.asc @@ -212,9 +212,11 @@ For more information on how to write webhooks and all the different event types (((GitHub, API))) ////////////////////////// -Services and hooks give you a way to receive push notifications about events that happen on your repositories, but what if you need more information about these events? What if you need to automate something like adding collaborators or labeling issues? +Services and hooks give you a way to receive push notifications about events that happen on your repositories, but what if you need more information about these events? +What if you need to automate something like adding collaborators or labeling issues? ////////////////////////// -서비스와 훅은 저장소에서 발생한 이벤트의 알림을 받는 방법이다. 그런데 이벤트의 정보를 좀 더 자세히 알고 싶으면, 자동으로 동료를 추가하거나 이슈에 레이블을 달도록 하고 싶으면, 뭐 좋은 방법이 없을까? +서비스와 훅은 저장소에서 발생한 이벤트의 알림을 받는 방법이다. +그런데 이벤트의 정보를 좀 더 자세히 알고 싶으면, 자동으로 동료를 추가하거나 이슈에 레이블을 달도록 하고 싶으면, 뭐 좋은 방법이 없을까? ////////////////////////// This is where the GitHub API comes in handy. @@ -299,7 +301,7 @@ You can use basic authentication with just your username and password, but gener You can generate this from the ``Applications'' tab of your settings page. ////////////////////////// 몇 가지 방법으로 인증할 수 있다. -사용자 이름과 암호가 필요한 Basic 인증도 가능하지만, 개인 엑세스 토큰을 사용하는 게 낫다. +사용자이름과 암호가 필요한 Basic 인증도 가능하지만, 개인 엑세스 토큰을 사용하는 게 낫다. 설정 페이지의 ``Applications'' 탭에서 생성할 수 있다. [[_access_token]] @@ -323,7 +325,7 @@ You can now use this to authenticate in your script instead of using a username This is nice because you can limit the scope of what you want to do and the token is revokable. ////////////////////////// 토큰이 생성되면 복사해서 사용한다. -이제 스크립트에서 사용자 이름과 암호를 사용하지 않고 이 토큰을 사용할 수 있다. +이제 스크립트에서 사용자이름과 암호를 사용하지 않고 이 토큰을 사용할 수 있다. 토큰은 허용하는 범위가 제한돼 있고 언제든지 폐기할 수 있어서 좋다. ////////////////////////// diff --git a/book/07-git-tools/sections/credentials.asc b/book/07-git-tools/sections/credentials.asc index b21064de..2d834310 100644 --- a/book/07-git-tools/sections/credentials.asc +++ b/book/07-git-tools/sections/credentials.asc @@ -11,8 +11,8 @@ If you use the SSH transport for connecting to remotes, it's possible for you to However, this isn't possible with the HTTP protocols – every connection needs a username and password. This gets even harder for systems with two-factor authentication, where the token you use for a password is randomly generated and unpronounceable. //////////////////// -SSH 프로토콜을 사용하여 리모트 저장소에 접근할 때 Passphase 없이 생성한 SSH Key를 사용하면 사용자 이름과 비밀번호를 입력하지 않고도 안전하게 데이터를 주고받을 수 있다. -반면 HTTP 프로토콜을 사용하는 경우는 매번 사용자 이름과 비밀번호를 입력해야 한다. +SSH 프로토콜을 사용하여 리모트 저장소에 접근할 때 Passphase 없이 생성한 SSH Key를 사용하면 사용자이름과 암호를 입력하지 않고도 안전하게 데이터를 주고받을 수 있다. +반면 HTTP 프로토콜을 사용하는 경우는 매번 사용자이름과 암호를 입력해야 한다. //////////////////// Fortunately, Git has a credentials system that can help with this. @@ -34,14 +34,14 @@ Git Credential 기능이 제공하는 옵션은 아래와 같다. * If you're using Windows, you can install a helper called ``wincred.'' This is similar to the ``osxkeychain'' helper described above, but uses the Windows Credential Store to control sensitive information. //////////////////// -* 일단 기본적으로 아무런 설정도 하지 않으면 어떤 비밀번호도 저장하지 않는다. - 이 경우 인증이 필요한 때 매번 사용자 이름과 비밀번호를 입력해야 한다. -* ``cache'' 모드로 설정하면 일정 시간 동안 메모리에 사용자 이름과 비밀번호 같은 인증정보를 기억한다. +* 일단 기본적으로 아무런 설정도 하지 않으면 어떤 암호도 저장하지 않는다. + 이 경우 인증이 필요한 때 매번 사용자이름과 암호를 입력해야 한다. +* ``cache'' 모드로 설정하면 일정 시간 동안 메모리에 사용자이름과 암호 같은 인증정보를 기억한다. 이 정보를 Disk에 저장하지는 않으며 메모리에서도 15분 까지만 유지한다. * ``store'' 모드로 설정하면 인증정보를 Disk의 텍스트 파일로 저장하며 계속 유지한다. 계속 유지한다는 말은 리모트의 인증정보를 변경하지 않는 한 다시 인증정보를 입력하지 않아도 접근할 수 있다는 말이다. ``store'' 모드를 사용할 때 주의할 점은 인증정보가 사용자 홈 디렉토리 아래에 일반 텍스트 파일로 저장된다는 점이다. -* Mac에서 Git을 사용하는 경우 ``osxkeychain'' 모드를 사용하면 Mac에서 제공하는 Keychain 시스템에 사용자 이름과 비밀번호를 현재 로그인 계정에 속하게 저장한다. +* Mac에서 Git을 사용하는 경우 ``osxkeychain'' 모드를 사용하면 Mac에서 제공하는 Keychain 시스템에 사용자이름과 암호를 현재 로그인 계정에 속하게 저장한다. ``store'' 모드하면 인증정보를 Disk에 저장하고 인증정보가 만료되지 않는 점은 같지만, Safari 브라우저가 인증정보를 저장하는 것과 같은 수준으로 암호화해서 저장한다는 점이 다르다. * Windows 환경에서는 ``wincred'' 라는 Helper가 있다. ``osxkeychain'' Helper와 비슷하게 동작하며 Windows Credential Store를 사용하여 안전하게 인증정보를 저장한다. @@ -146,7 +146,7 @@ password=s3cre7 인증정보가 필요한 대상의 프로토콜과 호스트이름을 입력한다. <3> 빈 라인을 하나 입력하면 입력이 끝났다는 것을 의미한다. 이제 입력한 내용에 해당하는 인증정보를 응답해야 한다. <4> Git-credential 명령이 전달받은 내용으로 인증정보를 찾아보고 찾으면 표준출력으로 찾은 정보를 응답한다. -<5> 물론 요청에 대한 인증정보가 없을 수도 있다. 이렇게 되면 Git이 사용자 이름과 비밀번호를 사용자가 입력하도록 메시지를 띄우고 값도 입력받는다. 입력받은 값을 다시 표준출력으로 응답한다. +<5> 물론 요청에 대한 인증정보가 없을 수도 있다. 이렇게 되면 Git이 사용자이름과 암호를 사용자가 입력하도록 메시지를 띄우고 값도 입력받는다. 입력받은 값을 다시 표준출력으로 응답한다. //////////////////// The credential system is actually invoking a program that's separate from Git itself; which one and how depends on the `credential.helper` configuration value. @@ -185,7 +185,7 @@ The stdin/stdout protocol is the same as git-credential, but they use a slightly * `store` is a request to save a set of credentials in this helper's memory. * `erase` purge the credentials for the given properties from this helper's memory. //////////////////// -* `get` - 사용자 이름과 비밀번호를 요구하는 액션 +* `get` - 사용자이름과 암호를 요구하는 액션 * `store` - Helper에서 인증정보를 저장하는 액션 * `erase` - Helper에서 인증정보를 삭제하는 액션 @@ -226,10 +226,10 @@ password=s3cre7 We provide the parts of the connection we already know (`https://mygithost`), and an empty line. <3> `git-credential-store` replies with the username and password we stored above. //////////////////// -<1> `git-credential-store` Helper에게 인증정보를 저장하도록 한다. 저장할 인증정보는 사용자 이름은 ``bob'', 비밀번호는 ``s3cre7''를 저장하는데 프로토콜과 호스트가 `https://mygithost` 일 때 사용한다. +<1> `git-credential-store` Helper에게 인증정보를 저장하도록 한다. 저장할 인증정보는 사용자이름이 ``bob'', 암호가 ``s3cre7''이다. 프로토콜과 호스트가 `https://mygithost` 일 때 사용한다. <2> 저장한 인증정보를 가져온다. 이미 아는 `https://mygithost` 리모트 주소를 호스트와 프로토콜로 나누어 표준입력으로 전달하고 한 라인을 비운다. -<3> `git-credential-store` 명령은 <1>에서 저장한 사용자 이름과 비밀번호를 표준출력으로 응답한다. +<3> `git-credential-store` 명령은 <1>에서 저장한 사용자이름과 암호를 표준출력으로 응답한다. //////////////////// Here's what the `~/git.store` file looks like: @@ -302,7 +302,7 @@ include::../git-credential-read-only[] <3> 이후에는 빈 라인이 나타날 때까지 표준입력으로부터 한 줄 한 줄 읽는다. 각 라인을 파싱하여 `known` 해시에 저장하고 <4>의 응답에서 사용한다. <4> 이 루프에서 Credential 파일을 읽어서 <3>의 해시에 해당하는 정보를 찾는다. - `known` 해시에서 프로토콜과 호스트 정보가 일치하는 경우 사용자 이름과 비밀번호를 포함하여 결과를 출력한다. + `known` 해시에서 프로토콜과 호스트 정보가 일치하는 경우 사용자이름과 암호를 포함하여 결과를 출력한다. //////////////////// We'll save our helper as `git-credential-read-only`, put it somewhere in our `PATH` and mark it executable. diff --git a/book/07-git-tools/sections/submodules.asc b/book/07-git-tools/sections/submodules.asc index 9c515e44..e4b6ee00 100644 --- a/book/07-git-tools/sections/submodules.asc +++ b/book/07-git-tools/sections/submodules.asc @@ -15,17 +15,17 @@ A common issue arises in these scenarios: you want to be able to treat the two p ////////////////////////// Here’s an example. -Suppose you’re developing a web site and creating Atom feeds. +Suppose you’re developing a website and creating Atom feeds. Instead of writing your own Atom-generating code, you decide to use a library. You’re likely to have to either include this code from a shared library like a CPAN install or Ruby gem, or copy the source code into your own project tree. The issue with including the library is that it’s difficult to customize the library in any way and often more difficult to deploy it, because you need to make sure every client has that library available. -The issue with vendoring the code into your own project is that any custom changes you make are difficult to merge when upstream changes become available. +The issue with copying the code into your own project is that any custom changes you make are difficult to merge when upstream changes become available. ////////////////////////// Atom 피드를 제공하는 웹사이트를 만드는 것을 예로 들어보자. Atom 피드를 생성하는 코드는 직접 작성하지 않고 라이브러리를 가져다 쓰기로 한다. 라이브러리를 사용하려면 CPAN이나 Ruby gem 같은 라이브러리 관리 도구를 사용하여 Shared 라이브러리 형태로 쓰거나 직접 라이브러리의 소스코드를 프로젝트로 복사해서 사용할 수 있다. 우선 Shared 라이브러리를 사용하기에는 문제가 있다. 프로젝트를 사용하는 모든 환경에 라이브러리가 설치되어 있어야 하고 라이브러리를 프로젝트에 맞게 약간 수정해서 사용하고 배포하기가 어렵다. -또한, 라이브러리 소스코드를 직접 프로젝트에 포함해서 사용하고 배포하는 경우에는 라이브러리 Upstream 코드가 업데이트됐을 때 Merge 하기가 어렵다는 문제다. +또한, 라이브러리 소스코드를 직접 프로젝트에 포함시키는 경우에는 라이브러리 Upstream 코드가 업데이트됐을 때 Merge 하기가 어렵다. ////////////////////////// Git addresses this issue using submodules. @@ -200,6 +200,16 @@ That is a special mode in Git that basically means you’re recording a commit a `DbConnector` 디렉토리의 모드는 `160000`이다. Git에게 있어 160000 모드는 일반적인 파일이나 디렉토리가 아니라 특별하다는 의미다. +////////////////////////// +Lastly, push these changes: +////////////////////////// +끝으로, Push 한다. + +[source,console] +---- +$ git push origin master +---- + [[_cloning_submodules]] ////////////////////////// ==== Cloning a Project with Submodules @@ -530,11 +540,13 @@ So now let's go through an example of making changes to the submodule at the sam /////////// So far, when we've run the `git submodule update` command to fetch changes from the submodule repositories, Git would get the changes and update the files in the subdirectory but will leave the sub-repository in what's called a ``detached HEAD'' state. This means that there is no local working branch (like ``master'', for example) tracking changes. -With no working branch tracking changes, that means even if you commit changes to the submodule, those changes will quite possibly be lost the next time you run `git submodule update`. You have to do some extra steps if you want changes in a submodule to be tracked. +With no working branch tracking changes, that means even if you commit changes to the submodule, those changes will quite possibly be lost the next time you run `git submodule update`. +You have to do some extra steps if you want changes in a submodule to be tracked. /////////// 서브모듈 저장소에서 `git submodule update` 명령을 실행하면 Git은 서브모듈의 변경 사항을 업데이트한다. 하지만, 서브모듈 로컬 저장소는 ``Detached HEAD'' 상태로 남는다. 이 말은 변경 내용을 추적하는 로컬 브랜치(예를 들자면 ``master''같은)가 없다는 것이다. -변경 내용을 추적하는 브랜치 없이 서브모듈에서 수정 작업을 하게 되면 이후에 `git submodule update` 명령을 실행했을 때 수정한 내용을 잃어버릴 수 있다. 서브모듈 안에서 수정사항을 추적하려면 다른 작업이 좀 더 필요하다. +변경 내용을 추적하는 브랜치 없이 서브모듈에서 수정 작업을 하게 되면 이후에 `git submodule update` 명령을 실행했을 때 수정한 내용을 잃어버릴 수 있다. +서브모듈 안에서 수정사항을 추적하려면 다른 작업이 좀 더 필요하다. /////////// In order to set up your submodule to be easier to go in and hack on, you need do two things. @@ -730,9 +742,11 @@ to push them to a remote. /////////// As you can see, it also gives us some helpful advice on what we might want to do next. The simple option is to go into each submodule and manually push to the remotes to make sure they're externally available and then try this push again. +If you want the check behavior to happen for all pushes, you can make this behavior the default by doing `git config push.recurseSubmodules check`. /////////// 예제에서 볼 수 있는 대로 이러한 상황에서 다음으로 무엇을 해야 하는지 Git은 도움을 준다. 가장 단순한 방법은 각 서브모듈 디렉토리로 가서 직접 일일이 Push를 해서 외부로 공유하고 나서 메인 프로젝트를 Push 하는 것이다. +이 옵션이 항상 적용되도록 하고 싶으면 `git config push.recurseSubmodules check` 명령으로 설정한다. /////////// The other option is to use the ``on-demand'' value, which will try to do this for you. @@ -760,9 +774,13 @@ To https://github.com/chaconinc/MainProject ---- /////////// -As you can see there, Git went into the DbConnector module and pushed it before pushing the main project. If that submodule push fails for some reason, the main project push will also fail. +As you can see there, Git went into the DbConnector module and pushed it before pushing the main project. +If that submodule push fails for some reason, the main project push will also fail. +You can make this behavior the default by doing `git config push.recurseSubmodules on-demand`. /////////// -위에서 보듯이 Git이 메인 프로젝트를 Push 하기 전에 DbConnector 모듈로 들어가서 Push를 한다. 모종의 이유 덕분에 서브모듈 Push에 실패한다면 메인 프로젝트의 Push 또한 실패하게 된다. +위에서 보듯이 Git이 메인 프로젝트를 Push 하기 전에 DbConnector 모듈로 들어가서 Push를 한다. +모종의 이유로 서브모듈 Push에 실패한다면 메인 프로젝트의 Push 또한 실패하게 된다. +`git config push.recurseSubmodules on-demand` 명령으로 설정할 수 있다. /////////// ===== Merging Submodule Changes @@ -1156,7 +1174,7 @@ If you do remove it and then switch back to the branch that has that submodule, [source,console] ---- -$ git clean -fdx +$ git clean -ffdx Removing CryptoLibrary/ $ git checkout add-crypto diff --git a/book/08-customizing-git/sections/attributes.asc b/book/08-customizing-git/sections/attributes.asc index 5ad0c3cb..98e8f904 100644 --- a/book/08-customizing-git/sections/attributes.asc +++ b/book/08-customizing-git/sections/attributes.asc @@ -133,7 +133,7 @@ Create a file that's somewhere in your path called `docx2txt`, and add these con [source,console] ---- #!/bin/bash -docx2txt.pl $1 - +docx2txt.pl "$1" - ---- ////////////////////////// @@ -477,7 +477,7 @@ test/ export-ignore ---- ////////////////////////// -Now, when you run git archive to create a tarball of your project, that directory won't be included in the archive. +Now, when you run `git archive` to create a tarball of your project, that directory won't be included in the archive. ////////////////////////// `git archive` 명령으로 tar 파일을 만들면 test 디렉토리는 아카이브에 포함되지 않는다. @@ -527,9 +527,9 @@ The substitutions can include for example the commit message and any git notes, [source,console] ---- $ echo '$Format:Last commit: %h by %aN at %cd%n%+w(76,6,9)%B$' > LAST_COMMIT -$ git commit -am 'export-subst uses git log's custom formatter +$ git commit -am 'export-subst uses git log'\''s custom formatter -git archive uses git log's `pretty=format:` processor +git archive uses git log'\''s `pretty=format:` processor directly, and strips the surrounding `$Format:` and `$` markup from the output. ' diff --git a/book/08-customizing-git/sections/config.asc b/book/08-customizing-git/sections/config.asc index 31f9934e..59d2253a 100644 --- a/book/08-customizing-git/sections/config.asc +++ b/book/08-customizing-git/sections/config.asc @@ -455,7 +455,7 @@ Git config 파일에 이 스크립트를 모두 추가한다. 설정해야 하 ---- $ git config --global merge.tool extMerge $ git config --global mergetool.extMerge.cmd \ - 'extMerge \"$BASE\" \"$LOCAL\" \"$REMOTE\" \"$MERGED\"' + 'extMerge "$BASE" "$LOCAL" "$REMOTE" "$MERGED"' $ git config --global mergetool.extMerge.trustExitCode false $ git config --global diff.external extDiff ---- @@ -656,17 +656,17 @@ The three that are disabled by default but can be turned on are `indent-with-non ////////////////////////// You can tell Git which of these you want enabled by setting `core.whitespace` to the values you want on or off, separated by commas. -You can disable settings by either leaving them out of the setting string or prepending a `-` in front of the value. -For example, if you want all but `cr-at-eol` to be set, you can do this: +You can disable an option by prepending a `-` in front of its name, or use the default value by leaving it out of the setting string entirely. +For example, if you want all but `space-before-tab` to be set, you can do this (with `trailing-space` being a short-hand to cover both `blank-at-eol` and `blank-at-eof`): ////////////////////////// `core.whitespace` 옵션으로 이 네 가지 방법을 켜고 끌 수 있다. 설정에서 해당 옵션을 빼버리거나 이름이 `-`로 시작하면 기능이 꺼진다. -예를 들어, 다른 건 다 켜고 `cr-at-eol` 옵션만 끄려면 아래와 같이 설정한다. +예를 들어, 다른 건 다 켜고 `space-before-tab` 옵션만 끄려면 아래와 같이 설정한다. `trailing-space` 옵션은 `blank-at-eol` 옵션과 `blank-at-eof` 옵션을 의미한다. [source,console] ---- $ git config --global core.whitespace \ - trailing-space,space-before-tab,indent-with-non-tab + trailing-space,-space-before-tab,indent-with-non-tab,tab-in-indent,cr-at-eol ---- ////////////////////////// diff --git a/book/08-customizing-git/sections/hooks.asc b/book/08-customizing-git/sections/hooks.asc index c36b97d2..67138040 100644 --- a/book/08-customizing-git/sections/hooks.asc +++ b/book/08-customizing-git/sections/hooks.asc @@ -22,13 +22,13 @@ Git도 다른 버전 관리 시스템처럼 어떤 이벤트가 생겼을 때 The hooks are all stored in the `hooks` subdirectory of the Git directory. In most projects, that's `.git/hooks`. When you initialize a new repository with `git init`, Git populates the hooks directory with a bunch of example scripts, many of which are useful by themselves; but they also document the input values of each script. -All the examples are written as shell scripts, with some Perl thrown in, but any properly named executable scripts will work fine – you can write them in Ruby or Python or what have you. +All the examples are written as shell scripts, with some Perl thrown in, but any properly named executable scripts will work fine – you can write them in Ruby or Python or whatever language you are familiar with. If you want to use the bundled hook scripts, you'll have to rename them; their file names all end with `.sample`. ////////////////////////// 훅은 Git 디렉토리 밑에 `hooks`라는 디렉토리에 저장한다. 기본 훅 디렉토리는 `.git/hooks`이다. 이 디렉토리에 가보면 Git이 자동으로 넣어준 매우 유용한 스크립트 예제가 몇 개 있다. 그리고 스크립트가 입력받는 값이 어떤 값인지 파일 안에 자세히 설명돼 있다. -모든 예제는 쉘과 Perl 스크립트로 작성돼 있지만 실행할 수만 있으면 되고 Ruby나 Python같은 다른 스크립트 언어로 만들어도 된다. +모든 예제는 쉘과 Perl 스크립트로 작성돼 있지만 실행할 수만 있으면 되고 Ruby나 Python같은 익숙한 언어로 만들어도 된다. 예제 스크립트의 파일 이름에는 `.sample`이라는 확장자가 붙어 있다. 그래서 이름만 바꿔주면 그 훅을 바로 사용할 수 있다. ////////////////////////// diff --git a/book/08-customizing-git/sections/policy.asc b/book/08-customizing-git/sections/policy.asc index 546912bd..3e4bbc79 100644 --- a/book/08-customizing-git/sections/policy.asc +++ b/book/08-customizing-git/sections/policy.asc @@ -261,11 +261,9 @@ Now that you have the permissions sorted out, you need to determine what paths t 이렇게 사용할 권한 정보를 만들었다. 이제 Push 하는 파일을 그 사용자가 Push 할 수 있는지 없는지 알아내야 한다. ////////////////////////// -You can pretty easily see what files have been modified in a single commit with the `--name-only` option to the `git log` command -(mentioned briefly in <<_git_basics_chapter>>) +You can pretty easily see what files have been modified in a single commit with the `--name-only` option to the `git log` command (mentioned briefly in <<_git_basics_chapter>>): ////////////////////////// -`git log` 명령에 `--name-only` 옵션을 주면 해당 커밋에서 수정된 파일이 뭔지 알려준다. -(`git log` 명령은 <<_git_basics_chapter>>에서 다루었다) +`git log` 명령에 `--name-only` 옵션을 주면 해당 커밋에서 수정된 파일이 뭔지 알려준다(`git log` 명령은 <<_git_basics_chapter>>에서 다루었다). [source,console] ---- @@ -630,9 +628,11 @@ end ---- ////////////////////////// -This script uses a syntax that wasn't covered in <<_revision_selection>>. You get a list of commits that have already been pushed up by running this: +This script uses a syntax that wasn't covered in <<_revision_selection>>. +You get a list of commits that have already been pushed up by running this: ////////////////////////// -이 스크립트는 <<_revision_selection>> 절에서 설명하지 않은 표현을 사용했다. 아래의 표현은 이미 Push 한 커밋 목록을 얻어오는 부분이다. +이 스크립트는 <<_revision_selection>> 절에서 설명하지 않은 표현을 사용했다. +아래의 표현은 이미 Push 한 커밋 목록을 얻어오는 부분이다. [source,ruby] ---- diff --git a/book/09-git-and-other-scms/sections/client-p4.asc b/book/09-git-and-other-scms/sections/client-p4.asc index 84e1118b..ccbe81f6 100644 --- a/book/09-git-and-other-scms/sections/client-p4.asc +++ b/book/09-git-and-other-scms/sections/client-p4.asc @@ -51,7 +51,7 @@ Perforce 데몬과 Git Fusion이 포함된 가상 머신 이미지를 내려받 Upon first starting the machine, it asks you to customize the password for three Linux users (`root`, `perforce`, and `git`), and provide an instance name, which can be used to distinguish this installation from others on the same network. When that has all completed, you'll see this: ////////////////////////// -가상머신을 처음 부팅시키면 `root`, `perforce`, `git` 세 Linux 계정의 비밀번호를 입력하라는 화면과 가상머신 인스턴스 이름을 입력하라는 화면이 나타난다. 인스턴스 이름은 같은 네트워크 안에서 인스턴스를 구분하고 접근하기 위해 사용하는 이름이다. +가상머신을 처음 부팅시키면 `root`, `perforce`, `git` 세 Linux 계정의 암호를 입력하라는 화면과 가상머신 인스턴스 이름을 입력하라는 화면이 나타난다. 인스턴스 이름은 같은 네트워크 안에서 인스턴스를 구분하고 접근하기 위해 사용하는 이름이다. 이러한 과정을 마치고 나면 아래와 같은 화면을 볼 수 있다. ////////////////////////// @@ -85,7 +85,7 @@ The second one will prompt you to enter a password twice. That's all we need to do with a shell prompt, so exit out of the session. ////////////////////////// 첫 번째 명령을 실행하면 VI 편집기가 뜨고 생성한 사용자의 정보를 수정할 수 있다. 기본으로 입력되어있는 정보를 그대로 사용하려면 간단히 `:wq`를 키보드로 입력하고 엔터키를 누른다. -두 번째 명령을 실행하면 생성한 Perforce 사용자의 비밀번호를 묻는데 안전하게 두 번 묻는다. +두 번째 명령을 실행하면 생성한 Perforce 사용자의 암호를 묻는데 안전하게 두 번 묻는다. 쉘에서 하는 작업은 여기까지이므로 쉘에서 나온다. ////////////////////////// @@ -126,8 +126,8 @@ The virtual-machine image comes equipped with a sample project that you can clon Here we're cloning over HTTPS, with the `john` user that we created above; Git asks for credentials for this connection, but the credential cache will allow us to skip this step for any subsequent requests. ////////////////////////// Perforce가 제공한 가상머신 이미지는 안에 샘플 프로젝트가 하나 들어 있다. -HTTPS 프로토콜로 프로젝트를 Clone 할 때 Git은 이름과 암호를 묻는다. 앞서 만든 `john`이라는 사용자 이름과 암호를 입력한다. -Credential 캐시로 사용자 이름과 암호를 저장해 두면 이 단계를 건너뛴다. +HTTPS 프로토콜로 프로젝트를 Clone 할 때 Git은 인증정보를 묻는다. 앞서 만든 `john`이라는 사용자이름과 암호를 입력한다. +Credential 캐시로 사용자이름과 암호를 저장해 두면 이 단계를 건너뛴다. ////////////////////////// ====== Fusion Configuration @@ -303,7 +303,7 @@ Git을 Perforce의 클라이언트로 사용할 때 어떤식으로 사용하면 $ git clone https://10.0.1.254/Jam Cloning into 'Jam'... Username for 'https://10.0.1.254': john -Password for 'https://ben@10.0.1.254': +Password for 'https://john@10.0.1.254': remote: Counting objects: 2070, done. remote: Compressing objects: 100% (1704/1704), done. Receiving objects: 100% (2070/2070), 1.21 MiB | 0 bytes/s, done. diff --git a/book/09-git-and-other-scms/sections/client-svn.asc b/book/09-git-and-other-scms/sections/client-svn.asc index c724bca0..b893464b 100644 --- a/book/09-git-and-other-scms/sections/client-svn.asc +++ b/book/09-git-and-other-scms/sections/client-svn.asc @@ -62,12 +62,10 @@ Subversion은 단순하게 일직선 히스토리만 가능하다. To demonstrate this functionality, you need a typical SVN repository that you have write access to. If you want to copy these examples, you'll have to make a writeable copy of my test repository. In order to do that easily, you can use a tool called `svnsync` that comes with Subversion. -For these tests, we created a new Subversion repository on Google Code that was a partial copy of the `protobuf` project, which is a tool that encodes structured data for network transmission. ////////////////////////// `git svn`을 사용하려면 SVN 저장소가 하나 필요하다. 저장소에 쓰기 권한이 있어야 한다. 필자의 test 저장소를 복사해서 해보자. Subversion에 포함된 `svnsync`라는 도구를 사용하여 SVN 저장소를 복사한다. -테스트용 저장소가 필요해서 Google Code에 새로 Subversion 저장소를 하나 만들었다. `protobuf` 라는 프로젝트의 일부 코드를 복사했다. `protobuf`는 네트워크 전송에 필요한 구조화된 데이터(프로토콜 같은 것들)의 인코딩을 도와주는 도구이다. ////////////////////////// To follow along, you first need to create a new local Subversion repository: @@ -101,7 +99,7 @@ You can now sync this project to your local machine by calling `svnsync init` wi [source,console] ---- $ svnsync init file:///tmp/test-svn \ - http://progit-example.googlecode.com/svn/ + http://your-svn-server.example.org/svn/ ---- ////////////////////////// @@ -504,7 +502,7 @@ When someone else clones that work, all they see is the merge commit with all th ////////////////////////// Branching in Subversion isn't the same as branching in Git; if you can avoid using it much, that's probably best. -However, you can create and commit to branches in Subversion using git svn. +However, you can create and commit to branches in Subversion using `git svn`. ////////////////////////// Subversion의 브랜치는 Git의 브랜치와 달라서 가능한 사용을 하지 않는 것이 좋다. 하지만 `git svn`으로도 Subversion 브랜치를 관리할 수 있다. diff --git a/book/09-git-and-other-scms/sections/import-custom.asc b/book/09-git-and-other-scms/sections/import-custom.asc index c2633e67..8dd41d0c 100644 --- a/book/09-git-and-other-scms/sections/import-custom.asc +++ b/book/09-git-and-other-scms/sections/import-custom.asc @@ -54,7 +54,7 @@ Importer를 만들기 전에 우선 Git이 어떻게 데이터를 저장하는 ////////////////////////// As we did in <<_an_example_git_enforced_policy>>, we'll write this in Ruby, because it's what we generally work with and it tends to be easy to read. You can write this example pretty easily in anything you're familiar with – it just needs to print the appropriate information to `stdout`. -And, if you are running on Windows, this means you'll need to take special care to not introduce carriage returns at the end your lines – git fast-import is very particular about just wanting line feeds (LF) not the carriage return line feeds (CRLF) that Windows uses. +And, if you are running on Windows, this means you'll need to take special care to not introduce carriage returns at the end your lines – `git fast-import` is very particular about just wanting line feeds (LF) not the carriage return line feeds (CRLF) that Windows uses. ////////////////////////// <<_an_example_git_enforced_policy>> 절에서 했던 것 처럼 Ruby로 스크립트를 작성한다. 책에서 계속 스크립트를 작성할 때 Ruby로 해왔고, 읽기도 쉽기에 Ruby를 쓴다. 하지만 자신에게 익숙한 것을 사용해서 표준출력으로 적절한 정보만 출력할 수 있으면 된다. @@ -283,8 +283,8 @@ return mark ////////////////////////// ==== If you are running on Windows you'll need to make sure that you add one extra step. -As mentioned before, Windows uses CRLF for new line characters while git fast-import expects only LF. -To get around this problem and make git fast-import happy, you need to tell ruby to use LF instead of CRLF: +As mentioned before, Windows uses CRLF for new line characters while `git fast-import` expects only LF. +To get around this problem and make `git fast-import` happy, you need to tell ruby to use LF instead of CRLF: [source,ruby] ---- diff --git a/book/09-git-and-other-scms/sections/import-svn.asc b/book/09-git-and-other-scms/sections/import-svn.asc index 85242323..e6729f07 100644 --- a/book/09-git-and-other-scms/sections/import-svn.asc +++ b/book/09-git-and-other-scms/sections/import-svn.asc @@ -22,7 +22,7 @@ Create a file called `users.txt` that has this mapping in a format like this: Subversion에서는 커밋하려면 해당 시스템 계정이 있어야 한다. `blame`이나 `git svn log` 같은 명령에서 `schacon`이라는 이름을 봤을 것이다. 이 정보를 Git 형식의 정보로 변경하려면 Subversion 사용자와 Git Author를 연결시켜줘야 한다. -Subversion 사용자 이름과 Git Author 간에 매핑할 수 있게 해줘야 한다. `users.txt`라는 파일을 아래와 같이 만든다. +Subversion 사용자이름과 Git Author 간에 매핑할 수 있게 해줘야 한다. `users.txt`라는 파일을 아래와 같이 만든다. [source] ---- @@ -37,7 +37,7 @@ SVN에 기록된 Author 이름을 아래 명령으로 조회한다. [source,console] ---- -$ svn log --xml | grep author | sort -u | \ +$ svn log --xml --quiet | grep author | sort -u | \ perl -pe 's/.*>(.*?)<.*/$1 = /' ---- @@ -62,7 +62,8 @@ This makes your `import` command look like this: [source,console] ---- $ git svn clone http://my-project.googlecode.com/svn/ \ - --authors-file=users.txt --no-metadata -s my_project + --authors-file=users.txt --no-metadata --prefix "" -s my_project +$ cd my_project ---- ////////////////////////// @@ -119,14 +120,13 @@ To move the tags to be proper Git tags, run: [source,console] ---- -$ cp -Rf .git/refs/remotes/origin/tags/* .git/refs/tags/ -$ rm -Rf .git/refs/remotes/origin/tags +$ for t in $(git for-each-ref --format='%(refname:short)' refs/remotes/tags); do git tag ${t/tags\//} $t && git branch -D -r $t; done ---- ////////////////////////// -This takes the references that were remote branches that started with `remotes/origin/tags/` and makes them real (lightweight) tags. +This takes the references that were remote branches that started with `refs/remotes/tags/` and makes them real (lightweight) tags. ////////////////////////// -`remotes/origin/tags/`로 시작하는 리모트 브랜치를 가져다 Lightweight 태그로 만들었다. +`refs/remotes/tags/`로 시작하는 리모트 브랜치를 가져다 Lightweight 태그로 만들었다. ////////////////////////// Next, move the rest of the references under `refs/remotes` to be local branches: @@ -135,14 +135,24 @@ Next, move the rest of the references under `refs/remotes` to be local branches: [source,console] ---- -$ cp -Rf .git/refs/remotes/origin/* .git/refs/heads/ -$ rm -Rf .git/refs/remotes/origin +$ for b in $(git for-each-ref --format='%(refname:short)' refs/remotes); do git branch $b refs/remotes/$b && git branch -D -r $b; done ---- ////////////////////////// -It may happen that you'll see some extra branches which are suffixed by `@xxx` (where xxx is a number), while in Subversion you only see one branch. This is actually a Subversion feature called "peg-revisions", which is something that Git simply has no syntactical counterpart for. Hence, `git svn` simply adds the svn version number to the branch name just in the same way as you would have written it in svn to address the peg-revision of that branch. If you do not care anymore about the peg-revisions, simply remove them using `git branch -d`. +It may happen that you'll see some extra branches which are suffixed by `@xxx` (where xxx is a number), while in Subversion you only see one branch. +This is actually a Subversion feature called ``peg-revisions'', which is something that Git simply has no syntactical counterpart for. +Hence, `git svn` simply adds the svn version number to the branch name just in the same way as you would have written it in svn to address the peg-revision of that branch. +If you do not care anymore about the peg-revisions, simply remove them: ////////////////////////// -대개 Subversion에서는 브랜치 하나만 보일 진데 `@xxx` (xxx는 숫자) 문자로 끝나는 몇가지 브랜치가 더 보일 것이다. 이런 이름의 브랜치가 존재하는 것은 "peg-revisions" 이라 부르는 Subversion의 기능 때문이며 Git에서는 마땅이 대응되는 기능이 없다. Subversion에서 peg-revision을 다루기 위해 브랜치 이름 뒤에 버전 숫자를 붙인 것 처럼 `git snv` 역시 그렇게 하는 것이다. peg-revision 기능을 사용하지 않는다면 `git branch -d` 명령으로 브랜치를 삭제할 수 있다. +대개 Subversion에서는 브랜치 하나만 보일 진데 `@xxx` (xxx는 숫자) 문자로 끝나는 몇가지 브랜치가 더 보일 것이다. +이런 이름의 브랜치가 존재하는 것은 "peg-revisions" 이라 부르는 Subversion의 기능 때문이며 Git에서는 마땅이 대응되는 기능이 없다. +Subversion에서 peg-revision을 다루기 위해 브랜치 이름 뒤에 버전 숫자를 붙인 것 처럼 `git snv` 역시 그렇게 하는 것이다. +peg-revision 기능을 사용하지 않는다면 그냥 브랜치를 삭제하면 된다. + +[source,console] +---- +$ git branch -d trunk +---- ////////////////////////// Now all the old branches are real Git branches and all the old tags are real Git tags. @@ -150,9 +160,13 @@ Now all the old branches are real Git branches and all the old tags are real Git 이제 모든 태그와 브랜치는 진짜 Git 태그와 브랜치가 됐다. ////////////////////////// -There's one last thing to clean up. Unfortunately, `git svn` creates an extra branch named `trunk`, which maps to Subversion's default branch, but the `trunk` ref points to the same place as `master`. Since `master` is more idiomatically Git, here's how to remove the extra branch: +There's one last thing to clean up. +Unfortunately, `git svn` creates an extra branch named `trunk`, which maps to Subversion's default branch, but the `trunk` ref points to the same place as `master`. +Since `master` is more idiomatically Git, here's how to remove the extra branch: ////////////////////////// -마지막으로 마무리를 위한 과정이 하나 남았다. 안타깝게도 `git svn` 명령이 만드는 Subversion의 기본 브랜치인 `trunk` 브랜치가 있다. `trunk` 브랜치는 Git의 `master` 역할을 한다고 보면 된다. Git에는 `master` 브랜치가 있기 때문에 여분의 `trunk` 브랜치는 삭제하자. +마지막으로 마무리를 위한 과정이 하나 남았다. +안타깝게도 `git svn` 명령이 만드는 Subversion의 기본 브랜치인 `trunk` 브랜치가 있다. `trunk` 브랜치는 Git의 `master` 역할을 한다고 보면 된다. +Git에는 `master` 브랜치가 있기 때문에 여분의 `trunk` 브랜치는 삭제하자. [source,console] ---- diff --git a/book/09-git-and-other-scms/sections/import-tfs.asc b/book/09-git-and-other-scms/sections/import-tfs.asc index f62852eb..adbc5935 100644 --- a/book/09-git-and-other-scms/sections/import-tfs.asc +++ b/book/09-git-and-other-scms/sections/import-tfs.asc @@ -26,7 +26,7 @@ The first thing to do is map usernames. TFVC is fairly liberal with what goes into the author field for changesets, but Git wants a human-readable name and email address. You can get this information from the `tf` command-line client, like so: //////////// -먼저 사용자 이름을 대응시킨다. +먼저 사용자이름을 대응시킨다. TFVC Changeset의 Author 필드는 형식이 자유롭지만 Git에는 사람이 읽을 수 있는 이름과 E-mail 주소로 정해져 있다. 이 정보는 커맨드라인 클라이언트인 `tf`로 가져온다. diff --git a/book/10-git-internals/sections/environment.asc b/book/10-git-internals/sections/environment.asc index 0950ce7f..3b7d6eb5 100644 --- a/book/10-git-internals/sections/environment.asc +++ b/book/10-git-internals/sections/environment.asc @@ -355,7 +355,7 @@ $ GIT_TRACE_PACKET=true git ls-remote origin ////////////////////////// *`GIT_TRACE_PERFORMANCE`* controls logging of performance data. -The output shows how long each particular git invocation takes. +The output shows how long each particular `git` invocation takes. ////////////////////////// *`GIT_TRACE_PERFORMANCE`* 변수를 설정하면 Git의 성능에 관련된 Trace를 출력한다. 출력한 내용을 살펴보면 어떤 작업이 얼마나 시간이 걸려 실행되었는지 확인할 수 있다. diff --git a/book/10-git-internals/sections/objects.asc b/book/10-git-internals/sections/objects.asc index 453e8188..f166caf6 100644 --- a/book/10-git-internals/sections/objects.asc +++ b/book/10-git-internals/sections/objects.asc @@ -289,6 +289,8 @@ You'll now create a new tree with the second version of `test.txt` and a new fil [source,console] ---- $ echo 'new file' > new.txt +$ git update-index --cacheinfo 100644 \ + 1f7a7a472abf3dd9643fd615f6da379c4acb3e3a test.txt $ git update-index test.txt $ git update-index --add new.txt ---- diff --git a/book/A-git-in-other-environments/sections/bash.asc b/book/A-git-in-other-environments/sections/bash.asc index e99eed6c..c9fdb4e5 100644 --- a/book/A-git-in-other-environments/sections/bash.asc +++ b/book/A-git-in-other-environments/sections/bash.asc @@ -23,7 +23,7 @@ Copy it somewhere handy, like your home directory, and add this to your `.bashrc ----- ////////////////////////// -Once that's done, change your directory to a git repository, and type: +Once that's done, change your directory to a Git repository, and type: ////////////////////////// 이렇게 적용하고 Git 저장소에 들어가서 아래와 같이 입력한다. diff --git a/book/A-git-in-other-environments/sections/powershell.asc b/book/A-git-in-other-environments/sections/powershell.asc index 687794d6..0734db1e 100644 --- a/book/A-git-in-other-environments/sections/powershell.asc +++ b/book/A-git-in-other-environments/sections/powershell.asc @@ -21,22 +21,11 @@ image::images/posh-git.png[Powershell with Posh-git.] .Posh-git을 사용 중인 Powershell. image::images/posh-git.png[Posh-git을 사용 중인 Powershell.] -////////////////////////// -If you've installed GitHub for Windows, Posh-Git is included by default, and all you have to do is add these lines to your `profile.ps1` (which is usually located in `C:\Users\\Documents\WindowsPowerShell`): -////////////////////////// -'GitHub for Windows'에는 'Posh-Git'이 기본으로 포함돼 있다. 그래서 설치하고 `profile.ps1` 파일에 아래 내용을 추가한다. 이 파일은 `C:\Users\\Documents\WindowsPowerShell`에 있다. - -[source,powershell] ------ -. (Resolve-Path "$env:LOCALAPPDATA\GitHub\shell.ps1") -. $env:github_posh_git\profile.example.ps1 ------ - ////////////////////////// If you're not a GitHub for Windows user, just download a Posh-Git release from (https://github.com/dahlbyk/posh-git[]), and uncompress it to the `WindowsPowershell` directory. Then open a Powershell prompt as the administrator, and do this: ////////////////////////// -'GitHub for Windows' 사용자가 아니면 'https://github.com/dahlbyk/posh-git[]'에서 'Posh-Git'을 내려받아 `WindowsPowershell` 디렉토리에 압축을 풀어 놓는다. +'https://github.com/dahlbyk/posh-git[]'에서 'Posh-Git'을 내려받아 `WindowsPowershell` 디렉토리에 압축을 풀어 놓는다. 그리고 관리자 권한으로 Powershell 프롬프트를 열고 아래와 같이 실행한다. [source,powershell] diff --git a/book/A-git-in-other-environments/sections/zsh.asc b/book/A-git-in-other-environments/sections/zsh.asc index 0d606bd3..4439ad00 100644 --- a/book/A-git-in-other-environments/sections/zsh.asc +++ b/book/A-git-in-other-environments/sections/zsh.asc @@ -81,10 +81,11 @@ vcs_info에 대한 자세한 정보는 `zshcontrib(1)` 메뉴얼 페이지를 http://zsh.sourceforge.net/Doc/Release/User-Contributions.html#Version-Control-Information[]에서 확인한다. ////////////////////////// -Instead of vcs_info, you might prefer the prompt customization script that ships with Git, called `git-prompt.sh`; see http://git-prompt.sh[] for details. +Instead of vcs_info, you might prefer the prompt customization script that ships with Git, called `git-prompt.sh`; see https://github.com/git/git/blob/master/contrib/completion/git-prompt.sh[] for details. `git-prompt.sh` is compatible with both Bash and Zsh. ////////////////////////// -vcs_info말고 Git에 들어 있는 `git-prompt.sh`를 직접 수정해서 사용해도 된다. 자세한 내용은 http://git-prompt.sh[]에서 확인한다. `git-prompt.sh`는 Bash와 Zsh 모두 호환된다. +vcs_info말고 Git에 들어 있는 `git-prompt.sh`를 직접 수정해서 사용해도 된다. 자세한 내용은 https://github.com/git/git/blob/master/contrib/completion/git-prompt.sh[]에서 확인한다. +`git-prompt.sh`는 Bash와 Zsh 모두 호환된다. ////////////////////////// Zsh is powerful enough that there are entire frameworks dedicated to making it better. diff --git a/book/C-git-commands/1-git-commands.asc b/book/C-git-commands/1-git-commands.asc index 0eed26a7..9daca507 100644 --- a/book/C-git-commands/1-git-commands.asc +++ b/book/C-git-commands/1-git-commands.asc @@ -36,7 +36,7 @@ There are several files this command will read from and write to so you can set ////////////////////////// Git에는 설정할 수 있는 값이 수백 가지에 달한다. 사용자의 취향에 따라 다르게 동작하도록 설정할 수 있다. -이 명령으로 사용자 이름이나 터미널 색깔, 편집기 등을 설정한다. +이 명령으로 사용자이름이나 터미널 색깔, 편집기 등을 설정한다. 저장소마다 다르게 혹은 글로벌하게 설정할 수 있는데 각각 설정파일이 다르다. ////////////////////////// @@ -62,7 +62,7 @@ In <<_rebasing>> we used it to make `--rebase` the default when you run `git pul ////////////////////////// In <<_credential_caching>> we used it to set up a default store for your HTTP passwords. ////////////////////////// -HTTP 패스워드를 저장하는 방법은 <<_credential_caching>>를 보면 된다. +HTTP 암호를 저장하는 방법은 <<_credential_caching>>를 보면 된다. ////////////////////////// In <<_keyword_expansion>> we showed how to set up smudge and clean filters on content coming in and out of Git. diff --git a/book/cover.png b/book/cover.png index 878b3f03..6537203a 100644 Binary files a/book/cover.png and b/book/cover.png differ