progit · pismute · Jun 12, 2017 · Jan 4, 2017 · Jan 4, 2017 · Jan 4, 2017
diff --git 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
diff --git 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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -426,9 +426,9 @@ In <<limit_options>> 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
@@ -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
@@ -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
@@ -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` 브랜치를 기반으로 새로 만들어 적용한다.
 조금 복잡하긴 해도 꽤 쓸모 있다.
 
 //////////////////////////