improve translation

book/01-introduction/sections/basics.asc

@@ -78,7 +78,7 @@ Because you have the entire history of the project right there on your local dis
 //////////////////////////
 거의 모든 명령이 로컬 파일과 데이터만 사용하기 때문에 네트워크에 있는 다른 컴퓨터는 필요 없다.
 대부분의 명령어가 네트워크의 속도에 영향을 받는 CVCS에 익숙하다면 Git이 매우 놀라울 것이다. Git의 이런 특징에서 나오는 미칠듯한 속도는 오직 Git느님만이 구사할 수 있는 전능이다.
-프로젝트의 모든 히스토리가 로컬 디스크에 있기 때문에 모든 명령을 순식간에 실행된다.
+프로젝트의 모든 히스토리가 로컬 디스크에 있기 때문에 모든 명령이 순식간에 실행된다.
 
 //////////////////////////
 For example, to browse the history of the project, Git doesn't need to go out to the server to get the history and display it for you – it simply reads it directly from your local database.
@@ -97,7 +97,7 @@ In many other systems, doing so is either impossible or painful.
 In Perforce, for example, you can't do much when you aren't connected to the server; and in Subversion and CVS, you can edit files, but you can't commit changes to your database (because your database is offline).
 This may not seem like a huge deal, but you may be surprised what a big difference it can make.
 //////////////////////////
-즉 오프라인 상태이거나 VPN으로 연결할 수 없어도 할 수 없는 일이 별로 없다.
+즉 오프라인 상태이거나 VPN에 연결하지 못해도 막힘 없이 일 할 수 있다.
 비행기나 기차 등에서 작업하고 네트워크에 접속하고 있지 않아도 커밋할 수 있다.
 다른 VCS 시스템에서는 불가능한 일이다.
 Perforce를 예로 들자면 서버에 연결할 수 없을 때 할 수 있는 일이 별로 없다. Subversion이나 CVS에서도 마찬가지다. 오프라인이기 때문에 데이터베이스에 접근할 수 없어서 파일을 편집할 수는 있지만, 커밋할 수 없다.

book/01-introduction/sections/command-line.asc

@@ -12,7 +12,7 @@ If you know how to run the command line version, you can probably also figure ou
 Also, while your choice of graphical client is a matter of personal taste, _all_ users will have the command-line tools installed and available.
 //////////////////////////
 Git을 사용하는 방법은 많다.
-CLI로 사용할수도 있고 GUI를 사용할 수도 있다.
+CLI로 사용할 수도 있고 GUI를 사용할 수도 있다.
 이 책에서는 Git CLI 사용법을 설명한다.
 Git의 *모든* 기능을 지원하는 것은 CLI 뿐이다. GUI 프로그램의 대부분은 Git 기능을 전부 구현하지 않아서 비교적 단순하다.
 CLI를 사용할 줄 알면 GUI도 사용할 수 있지만 반대는 성립하지 않는다.

book/01-introduction/sections/first-time-setup.asc

@@ -72,7 +72,7 @@ $ git config --global user.email johndoe@example.com
 Again, you need to do this only once if you pass the `--global` option, because then Git will always use that information for anything you do on that system.
 If you want to override this with a different name or email address for specific projects, you can run the command without the `--global` option when you're in that project.
 //////////////////////////
-다시 말하자면 `--global` 옵션으로 설정한 것은 딱 한 번만 하면 된다. 해당 시스템에서 해당 사용자가 사용할 때에는 이 정보를 사용한다.
+다시 말하자면 `--global` 옵션으로 설정한 것은 딱 한 번만 하면 된다. 해당 시스템에서 해당 사용자가 사용할 때는 이 정보를 사용한다.
 만약 프로젝트마다 다른 이름과 이메일 주소를 사용하고 싶으면 `--global` 옵션을 빼고 명령을 실행한다.
 
 //////////////////////////

book/01-introduction/sections/installing.asc

@@ -36,7 +36,7 @@ Git은 정말 이전 버전과 잘 호환되도록 유지하기 때문에 2.0 
 If you want to install the basic Git tools on Linux via a binary installer, you can generally do so through the basic package-management tool that comes with your distribution.
 If you're on Fedora for example, you can use yum:
 //////////////////////////
-Linux에서 패키지로 Git을 설치할 때에는 보통 각 배포판에서 사용하는 패키지 관리도구를 사용하여 설치한다.
+Linux에서 패키지로 Git을 설치할 때는 보통 각 배포판에서 사용하는 패키지 관리도구를 사용하여 설치한다.
 Fedora에서는 아래와 같이 한다.
 
 [source,console]

book/02-git-basics/sections/recording-changes.asc

@@ -424,7 +424,7 @@ Although `git status` answers those questions very generally by listing the file
 //////////////////////////
 단순히 파일이 변경됐다는 사실이 아니라 어떤 내용이 변경됐는지 살펴보려면 `git status` 명령이 아니라 `git diff` 명령을 사용해야 한다.(((git commands, diff)))
 보통 우리는 '수정했지만, 아직 Staged 파일이 아닌 것?'과 '어떤 파일이 Staged 상태인지?'가 궁금하기 때문에 `git status` 명령으로도 충분하다.
-더 자세하게 볼 때는 `git diff` 명령을 사용하는데 Patch처럼 어떤 라인을 추가했고 삭제했는지가 궁금할 때에 사용한다.
+더 자세하게 볼 때는 `git diff` 명령을 사용하는데 Patch처럼 어떤 라인을 추가했고 삭제했는지가 궁금할 때 사용한다.
 `git diff`는 나중에 더 자세히 다룬다.
 
 //////////////////////////

book/02-git-basics/sections/remotes.asc

@@ -64,7 +64,7 @@ If you have more than one remote, the command lists them all.
 For example, a repository with multiple remotes for working with several collaborators might look something like this.
 //////////////////////////
 리모트 저장소가 여러 개 있다면 이 명령은 등록된 전부를 보여준다.
-프로젝트를 여러 사람과 함께 작업하여 등록시킨 리모트 저장소가 여러개라면 아래와 같은 결과를 얻을 수도 있다.
+여러 사람과 함께 작업하는 리모트 저장소가 여러개라면 아래와 같은 결과를 얻을 수도 있다.
 
 [source,console]
 ----
@@ -86,7 +86,7 @@ origin    git@github.com:mojombo/grit.git (push)
 This means we can pull contributions from any of these users pretty easily.
 We may additionally have permission to push to one or more of these, though we can't tell that here.
 //////////////////////////
-이렇게 리모트 저장소가 여러 개가 등록되어 있으면 다른 사람이 기여한 내용(Contributions)을 쉽게 가져올 수 있다.
+이렇게 리모트 저장소가 여러 개 등록되어 있으면 다른 사람이 기여한 내용(Contributions)을 쉽게 가져올 수 있다.
 어떤 저장소에는 Push 권한까지 제공하기도 하지만 일단 이 화면에서 Push 가능 권한까지는 확인할 수 없다.
 
 //////////////////////////
@@ -259,7 +259,7 @@ It also lists all the remote references it has pulled down.
 That is a simple example you're likely to encounter.
 When you're using Git more heavily, however, you may see much more information from `git remote show`:
 //////////////////////////
-좀 더 Git을 열심히 사용하게 되면 `git remote show` 명령은 더 많은 정보를 보여줄 것이다.
+좀 더 Git을 열심히 사용하다 보면 `git remote show` 명령으로 더 많은 정보를 보는 날이 온다.
 여러분도 언젠가는 아래와 같은 메시지(역주 - 다수의 브랜치를 사용하는 메시지)를 볼 날이 올 것이다.
 
 [source,console]

book/02-git-basics/sections/tagging.asc

@@ -84,7 +84,7 @@ It's generally recommended that you create annotated tags so you can have all th
 //////////////////////////
 한편 Annotated 태그는 Git 데이터베이스에 태그를 만든 사람의 이름, 이메일과 태그를 만든 날짜, 그리고 태그 메시지도 저장한다.
 GPG(GNU Privacy Guard)로 서명할 수도 있다.
-이 모든 정보를 저장해둬야 할 때에만 Annotated 태그를 추천한다. 그냥 다른 정보를 저장하지 않는 단순한 태그가 필요하다면 Lightweight 태그를 사용하는 것이 좋다.
+이 모든 정보를 저장해둬야 할 때만 Annotated 태그를 추천한다. 그냥 다른 정보를 저장하지 않는 단순한 태그가 필요하다면 Lightweight 태그를 사용하는 것이 좋다.
 
 [[_annotated_tags]]
 //////////////////////////
@@ -155,7 +155,7 @@ To create a lightweight tag, don't supply the `-a`, `-s`, or `-m` option:
 //////////////////////////
 Lightweight 태그는 기본적으로 파일에 커밋 체크섬을 저장하는 것뿐이다.
 다른 정보는 저장하지 않는다.
-Lightweight 태그를 만들 때에는 `-a`, `-s`, `-m` 옵션을 사용하지 않는다.
+Lightweight 태그를 만들 때는 `-a`, `-s`, `-m` 옵션을 사용하지 않는다.
 
 [source,console]
 ----

book/02-git-basics/sections/undoing.asc

@@ -13,7 +13,7 @@ This is one of the few areas in Git where you may lose some work if you do it wr
 일을 하다보면 모든 단계에서 어떤 것은 되돌리고(Undo) 싶을 때가 있다.
 이번에는 우리가 한 일을 되돌리는 방법을 살펴본다.
 한 번 되돌리면 복구할 수 없기에 주의해야 한다.
-Git을 사용하면 우리가 한 실수를 복구하지 못할 것은 거의 없지만 되돌린 것은 복구할 수 없다.
+Git을 사용하면 우리가 저지른 실수는 대부분 복구할 수 있지만 되돌린 것은 복구할 수 없다.
 
 //////////////////////////
 One of the common undos takes place when you commit too early and possibly forget to add some files, or you mess up your commit message.
@@ -56,7 +56,7 @@ $ git commit --amend
 //////////////////////////
 You end up with a single commit – the second commit replaces the results of the first.
 //////////////////////////
-여기서 실행한 명령어 3개는 모두 하나의 커밋으로 기록된다. 두 번째 커밋은 첫 번째 커밋을 덮어쓴다.
+여기서 실행한 명령어 3개는 모두 커밋 한 개로 기록된다. 두 번째 커밋은 첫 번째 커밋을 덮어쓴다.
 
 [[_unstaging]]
 //////////////////////////
@@ -199,7 +199,7 @@ Don't ever use this command unless you absolutely know that you don't want the f
 =====
 `git checkout -- [file]` 명령은 꽤 위험한 명령이라는 것을 알아야 한다.
 원래 파일로 덮어썼기 때문에 수정한 내용은 전부 사라진다.
-수정한 내용이 진짜 마음에 들지 않을 때에만 사용하자.
+수정한 내용이 진짜 마음에 들지 않을 때만 사용하자.
 =====
 
 //////////////////////////

book/02-git-basics/sections/viewing-history.asc

@@ -288,7 +288,7 @@ $ git log --pretty=format:"%h %s" --graph
 //////////////////////////
 This type of output will become more interesting as we go through branching and merging in the next chapter.
 //////////////////////////
-다음 장에서 살펴볼 브랜치나 Merge 결과를 히스토리를 이런 식으로 살펴보면 훨씬 흥미롭게 볼 수 있다.
+다음 장에서 살펴볼 브랜치나 Merge 결과의 히스토리를 이런 식으로 살펴보면 훨씬 흥미롭다.
 
 //////////////////////////
 Those are only some simple output-formatting options to `git log` – there are many more.

book/03-git-branching/sections/basic-branching-and-merging.asc

@@ -123,7 +123,7 @@ There are ways to get around this (namely, stashing and commit amending) that we
 For now, let's assume you've committed all your changes, so you can switch back to your `master` branch:
 //////////////////////////
 그렇지만, 브랜치를 이동하려면 해야 할 일이 있다. 아직 커밋하지 않은 파일이 Checkout 할 브랜치와 충돌 나면 브랜치를 변경할 수 없다.
-브랜치를 변경할 때에는 워킹 디렉토리를 정리하는 것이 좋다.
+브랜치를 변경할 때는 워킹 디렉토리를 정리하는 것이 좋다.
 이런 문제를 다루는 방법은(주로, Stash이나 커밋 Amend에 대해) 나중에 <<_git_stashing>> 에서 다룰 것이다.
 지금은 작업하던 것을 모두 커밋하고 `master` 브랜치로 옮긴다:
 
@@ -146,7 +146,7 @@ Checkout 한 브랜치의 마지막 스냅샷으로 되돌려 놓는다는 것
 Next, you have a hotfix to make.
 Let's create a hotfix branch on which to work until it's completed:
 //////////////////////////
-이젠 해결해야 할 핫픽스가 생겼을 때를 예를 들어보자.
+이젠 해결해야 할 핫픽스가 생겼을 때를 살펴보자.
 hotfix라는 브랜치를 만들고 새로운 이슈를 해결할 때까지 사용한다.
 
 [source,console]
@@ -483,7 +483,7 @@ If you're happy with that, and you verify that everything that had conflicts has
 The commit message by default looks something like this:
 //////////////////////////
 충돌을 해결하고 나서 해당 파일이 Staging Area에 저장됐는지 확인했으면 `git commit` 명령으로 Merge 한 것을 커밋한다.
-충돌을 해결하고 Merge 할 때에는 커밋 메시지가 아래와 같다.
+충돌을 해결하고 Merge 할 때는 커밋 메시지가 아래와 같다.
 
 [source,console]
 ----

book/03-git-branching/sections/branch-management.asc

@@ -30,7 +30,7 @@ Notice the `*` character that prefixes the `master` branch: it indicates the bra
 This means that if you commit at this point, the `master` branch will be moved forward with your new work.
 To see the last commit on each branch, you can run `git branch -v`:
 //////////////////////////
-`*` 기호가 붙어 있는 `master`브랜치는 현재 Checkout 해서 작업하는 브랜치를 나타낸다.
+`*` 기호가 붙어 있는 `master` 브랜치는 현재 Checkout 해서 작업하는 브랜치를 나타낸다.
 즉, 지금 수정한 내용을 커밋하면 `master` 브랜치에 커밋되고 포인터가 앞으로 한 단계 나아간다.
 `git branch -v` 명령을 실행하면 브랜치마다 마지막 커밋 메시지도 함께 보여준다.
 

book/03-git-branching/sections/nutshell.asc

@@ -331,7 +331,7 @@ This can take several seconds or even minutes, depending on the size of the proj
 Also, because we're recording the parents when we commit, finding a proper merge base for merging is automatically done for us and is generally very easy to do.
 These features help encourage developers to create and use branches often.
 //////////////////////////
-브랜치를 만들어야 하면 프로젝트를 통째로 복사해야 하는 다른 버전 관리 도구와 Git의 차이는 극명하다.
+브랜치가 필요할 때 프로젝트를 통째로 복사해야 하는 다른 버전 관리 도구와 Git의 차이는 극명하다.
 통째로 복사하는 작업은 프로젝트 크기에 따라 다르겠지만 수십 초에서 수십 분까지 걸린다. 그에 비해 Git은 순식간이다.
 게다가 커밋을 할 때마다 이전 커밋의 정보를 저장하기 때문에 Merge 할 때 어디서부터(Merge Base) 합쳐야 하는지 안다.
 이런 특징은 개발자들이 수시로 브랜치를 만들어 사용하게 한다.

book/03-git-branching/sections/rebasing.asc

@@ -48,7 +48,7 @@ However, there is another way: you can take the patch of the change that was int
 In Git, this is called _rebasing_.
 With the `rebase` command, you can take all the changes that were committed on one branch and replay them on another one.(((git commands, rebase)))
 //////////////////////////
-비슷한 결과를 만드는 다른 방식으로, `C3`에서 변경된 사항을 Patch(Patch)로 만들고 이를 다시 `C4`에 적용시키는 방법이 있다.
+비슷한 결과를 만드는 다른 방식으로, `C3`에서 변경된 사항을 Patch로 만들고 이를 다시 `C4`에 적용시키는 방법이 있다.
 Git에서는 이런 방식을 _Rebase_라고 한다.
 `rebase` 명령으로 한 브랜치에서 변경된 사항을 다른 브랜치에 적용할 수 있다.(((git commands, rebase)))
 
@@ -356,7 +356,7 @@ It's pretty safe to assume that the other developer doesn't want `C4` and `C6` t
 If you *do* find yourself in a situation like this, Git has some further magic that might help you out.
 If someone on your team force pushes changes that overwrite work that you've based work on, your challenge is to figure out what is yours and what they've rewritten.
 //////////////////////////
-만약 이런 상황에 빠질 때에 유용한 Git 기능이 하나 있다.
+만약 이런 상황에 빠질 때 유용한 Git 기능이 하나 있다.
 어떤 팀원이 강제로 내가 한일을 덮어썼다고 하자. 그러면 내가 했던 일이 무엇이고 덮어쓴 내용이 무엇인지 알아내야 한다.
 
 //////////////////////////

book/03-git-branching/sections/remote-branches.asc

@@ -146,7 +146,7 @@ That way, you can use private branches for work you don't want to share, and pus
 If you have a branch named `serverfix` that you want to work on with others, you can push it up the same way you pushed your first branch.
 Run `git push (remote) (branch)`:(((git commands, push)))
 //////////////////////////
-`serverfix`라는 브랜치를 다른 사람과 공유할 때에도 브랜치를 처음 Push 하는 것과 같은 방법으로 Push 한다.
+`serverfix`라는 브랜치를 다른 사람과 공유할 때도 브랜치를 처음 Push 하는 것과 같은 방법으로 Push 한다.
 아래와 같이 `git push (remote) (branch)` 명령을 사용한다.(((git commands, push)))
 
 [source,console]

book/04-git-server/1-git-server.asc

@@ -16,7 +16,7 @@ Therefore, the preferred method for collaborating with someone is to set up an i
 다른 사람과 협업하려면 리모트 저장소가 필요하다.
 물론 혼자서 저장소를 만들고 거기에 Push 하고 Pull 할 수도 있지만 이렇게 하는 것은 아무 의미가 없다.
 이런 방식으로는 다른 사람이 무슨 일을 하고 있는지 알려면 항상 지켜보고 있어야 간신히 알 수 있을 터이다.
-당신이 오프라인일 때에도 동료가 저장소를 사용할 수 있게 하려면 언제나 이용할 수 있는 저장소가 필요하다.
+당신이 오프라인일 때도 동료가 저장소를 사용할 수 있게 하려면 언제나 이용할 수 있는 저장소가 필요하다.
 즉, 공동으로 사용할 수 있는 저장소를 만들고 모두 이 저장소에 접근하여 Push, Pull 할 수 있어야 한다.
 
 //////////////////////////

book/04-git-server/sections/gitlab.asc

@@ -156,7 +156,7 @@ 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.
 //////////////////////////
 GitLab의 프로젝트는 간단히 이야기하면 하나의 Git 저장소다.
-모든 프로젝트는 한 명의 사용자나 하나의 그룹에 속하게 된다.
+모든 프로젝트는 한 사용자나 한 그룹에 속하게 된다.
 사용자에 딸린 프로젝트는 사용자가 관리자로서 그 프로젝트를 완전히 제어한다. 그룹에 딸린 프로젝트는 해당 그룹의 사용자 권한 레벨에 따라 다르다.
 
 //////////////////////////

book/04-git-server/sections/protocols.asc

@@ -174,7 +174,7 @@ If you try to push and the repository requires authentication (which it normally
 //////////////////////////
 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.
 //////////////////////////
-실제로 GitHub 같은 서비스에서 제공하는 저장소는 Clone을 할 때나 Push를 할 때에 같은 URL을 사용한다. (예, ``https://github.com/schacon/simplegit[]'' )
+실제로 GitHub 같은 서비스에서 제공하는 저장소는 Clone을 할 때나 Push를 할 때 같은 URL을 사용한다. (예, ``https://github.com/schacon/simplegit[]'' )
 
 //////////////////////////
 ===== Dumb HTTP