Fix asciidoc korean issue (#47)

Detail
======
 - issue #47
   - find . -type f -name "*.asc" -exec ruby -pi -e 'gsub(/(`[^`]*?`) ?(.)/){|e| s = $1 + " " + $2; $2 =~ /(?u)\w/ ? s : e}' {} +

Author: limejuny

C-git-commands.asc

@@ -56,4 +56,4 @@ chapter 2: proofreading
 
 === 마무리
 
-번역이 끝나면 관리자는 `status.json`에 번역이 완료됐음을 표기합니다. 그래야 자동으로 빌드돼 여러 가지 포맷으로 배포되고 사람들에게 얼마나 번역이 진행됐는지 알릴 수 있습니다.
+번역이 끝나면 관리자는 `status.json` 에 번역이 완료됐음을 표기합니다. 그래야 자동으로 빌드돼 여러 가지 포맷으로 배포되고 사람들에게 얼마나 번역이 진행됐는지 알릴 수 있습니다.

TRANSLATION_NOTES.asc

@@ -128,7 +128,7 @@ $ git config --global core.editor "'C:/Program Files/Notepad++/notepad++.exe' -m
 //////////////////////////
 If you have a 32-bit editor on a 64-bit system, the program will be installed in `C:\Program Files (x86)`:
 //////////////////////////
-64비트 Windows 시스템에서 32비트 Notepad++을 설치했다면 `C:\Program Files (x86)`에 설치된다.
+64비트 Windows 시스템에서 32비트 Notepad++을 설치했다면 `C:\Program Files (x86)` 에 설치된다.
 
 [source,console]
 ----

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

@@ -37,7 +37,7 @@ If you want to install the basic Git tools on Linux via a binary installer, you
 If you're on Fedora (or any closely-related RPM-based distribution, such as RHEL or CentOS), you can use `dnf`:
 //////////////////////////
 Linux에서 패키지로 Git을 설치할 때는 보통 각 배포판에서 사용하는 패키지 관리도구를 사용하여 설치한다.
-Fedora(또는 비슷하게 RPM 기반 패키지 시스템을 사용하는 RHEL, CentOS)에서는 아래와 같이 `dnf`를 사용 한다.
+Fedora(또는 비슷하게 RPM 기반 패키지 시스템을 사용하는 RHEL, CentOS)에서는 아래와 같이 `dnf` 를 사용 한다.
 
 [source,console]
 ----
@@ -47,7 +47,7 @@ $ sudo dnf install git-all
 //////////////////////////
 If you're on a Debian-based distribution, such as Ubuntu, try `apt`:
 //////////////////////////
-Ubuntu등의 데비안 계열 배포판에서는 `apt`를 사용한다.
+Ubuntu등의 데비안 계열 배포판에서는 `apt` 를 사용한다.
 
 [source,console]
 ----
@@ -161,7 +161,7 @@ If you do want to install Git from source, you need to have the following librar
 For example, if you're on a system that has `dnf` (such as Fedora) or `apt-get` (such as a Debian-based system), you can use one of these commands to install the minimal dependencies for compiling and installing the Git binaries:
 //////////////////////////
 Git을 설치하려면 Git이 의존하고 있는 라이브러리인 autotools, curl, zlib, openssl, expat, libiconv등이 필요하다.
-예를 들어 `dnf`을 사용하는 Fedora등의 시스템이나 `apt-get`이 있는 데비안 계열 시스템이면 아래 명령어 중 하나를 실행하여 필요한 패키지를 설치할 수 있다.
+예를 들어 `dnf` 을 사용하는 Fedora등의 시스템이나 `apt-get` 이 있는 데비안 계열 시스템이면 아래 명령어 중 하나를 실행하여 필요한 패키지를 설치할 수 있다.
 
 [source,console]
 ----

book/01-introduction/sections/installing.asc

@@ -143,7 +143,7 @@ If you go into the new `libgit2` directory that was just created, you'll see the
 //////////////////////////
 If you want to clone the repository into a directory named something other than `libgit2`, you can specify the new directory name as an additional argument:
 //////////////////////////
-아래과 같은 명령을 사용하여 저장소를 Clone 하면 `libgit2`이 아니라 다른 디렉토리 이름으로 Clone 할 수 있다.
+아래과 같은 명령을 사용하여 저장소를 Clone 하면 `libgit2` 이 아니라 다른 디렉토리 이름으로 Clone 할 수 있다.
 
 [source,console]
 ----

book/02-git-basics/sections/getting-a-repository.asc

@@ -350,7 +350,7 @@ The rules for the patterns you can put in the `.gitignore` file are as follows:
 *  You can end patterns with a forward slash (`/`) to specify a directory.
 *  You can negate a pattern by starting it with an exclamation point (`!`).
 //////////////////////////
-*  아무것도 없는 라인이나, `#`로 시작하는 라인은 무시한다.
+*  아무것도 없는 라인이나, `#` 로 시작하는 라인은 무시한다.
 *  표준 Glob 패턴을 사용한다. 이는 프로젝트 전체에 적용된다.
 *  슬래시(`/`)로 시작하면 하위 디렉토리에 적용되지(Recursivity) 않는다.
 *  디렉토리는 슬래시(`/`)를 끝에 사용하는 것으로 표현한다.
@@ -430,7 +430,7 @@ However, it is also possible to have additional `.gitignore` files in subdirecto
 The rules in these nested `.gitignore` files apply only to the files under the directory where they are located.
 (The Linux kernel source repository has 206 `.gitignore` files.)
 //////////////////////////
-`.gitignore`를 사용하는 간단한 방식은 하나의 `.gitignore` 파일을 최상위 디렉토리에 하나 두고 모든 하위 디렉토리에까지 적용시키는 방식이다.
+`.gitignore` 를 사용하는 간단한 방식은 하나의 `.gitignore` 파일을 최상위 디렉토리에 하나 두고 모든 하위 디렉토리에까지 적용시키는 방식이다.
 물론 `.gitignore` 파일을 하나만 두는 것이 아니라 하위 디렉토리에도 추가로 둘 수도 있다.
 `.gitignore` 정책은 현재 `.gitignore` 파일이 위치한 디렉토리와 그 하위 디렉토리에 적용된다.
 (리눅스 커널 소스 저장소에는 `.gitignore` 파일이 206개나 있음)
@@ -439,7 +439,7 @@ The rules in these nested `.gitignore` files apply only to the files under the d
 //////////////////////////
 It is beyond the scope of this book to get into the details of multiple `.gitignore` files; see `man gitignore` for the details.
 //////////////////////////
-다수의 `.gitignore` 파일을 두고 정책을 적용하는 부분은 이 책에서 다루는 범위를 벗어난다. 자세한 내용은 `man gitignore`에서 확인할 수 있다.
+다수의 `.gitignore` 파일을 두고 정책을 적용하는 부분은 이 책에서 다루는 범위를 벗어난다. 자세한 내용은 `man gitignore` 에서 확인할 수 있다.
 ====
 
 [[_git_diff_staged]]

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

@@ -47,7 +47,7 @@ If you've cloned your repository, you should at least see `origin` -- that is th
 //////////////////////////
 `git remote` 명령으로 현재 프로젝트에 등록된 리모트 저장소를 확인할 수 있다.(((git commands, remote)))
 이 명령은 리모트 저장소의 단축 이름을 보여준다.
-저장소를 Clone 하면 `origin`이라는 리모트 저장소가 자동으로 등록되기 때문에 `origin`이라는 이름을 볼 수 있다.
+저장소를 Clone 하면 `origin` 이라는 리모트 저장소가 자동으로 등록되기 때문에 `origin` 이라는 이름을 볼 수 있다.
 
 [source,console]
 ----
@@ -216,7 +216,7 @@ The command for this is simple: `git push <remote> <branch>`.(((git commands, pu
 If you want to push your master branch to your `origin` server (again, cloning generally sets up both of those names for you automatically), then you can run this to push any commits you've done back up to the server:
 //////////////////////////
 프로젝트를 공유하고 싶을 때 Upstream 저장소에 Push 할 수 있다.
-이 명령은 `git push <리모트 저장소 이름> <브랜치 이름>`으로 단순하다.(((git commands, push)))
+이 명령은 `git push <리모트 저장소 이름> <브랜치 이름>` 으로 단순하다.(((git commands, push)))
 master 브랜치를 `origin` 서버에 Push 하려면(다시 말하지만 Clone 하면 보통 자동으로 origin 이름이 생성된다) 아래와 같이 서버에 Push 한다.
 
 [source,console]

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

@@ -23,7 +23,7 @@ In this section, you'll learn how to list the available tags, how to create new
 Listing the available tags in Git is straightforward.
 Just type `git tag` (with optional `-l` or `--list`):(((git commands, tag)))
 //////////////////////////
-우선 `git tag` 명령으로 (`-l`, `--list`는 옵션)
+우선 `git tag` 명령으로 (`-l`, `--list` 는 옵션)
 이미 만들어진 태그가 있는지 확인할 수 있다.(((git commands, tag)))
 
 [source,console]
@@ -285,7 +285,7 @@ This process is just like sharing remote branches -- you can run `git push origi
 //////////////////////////
 `git push` 명령은 자동으로 리모트 서버에 태그를 전송하지 않는다.(((git commands, push)))
 태그를 만들었으면 서버에 별도로 Push 해야 한다.
-브랜치를 공유하는 것과 같은 방법으로 할 수 있다. `git push origin <태그 이름>`을 실행한다.
+브랜치를 공유하는 것과 같은 방법으로 할 수 있다. `git push origin <태그 이름>` 을 실행한다.
 
 [source,console]
 ----

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

@@ -69,7 +69,7 @@ One of the more helpful options is `-p` or `--patch`, which shows the difference
 You can also limit the number of log entries displayed, such as using `-2` to show only the last two entries.
 //////////////////////////
 여러 옵션 중 `-p`, `--patch` 는 굉장히 유용한 옵션이다. `-p` 는 각 커밋의 diff 결과를 보여준다.
-다른 유용한 옵션으로 `-2`가 있는데 최근 두 개의 결과만 보여주는 옵션이다:
+다른 유용한 옵션으로 `-2` 가 있는데 최근 두 개의 결과만 보여주는 옵션이다:
 
 [source,console]
 ----
@@ -347,7 +347,7 @@ In reality, you're unlikely to use that often, because Git by default pipes all
 //////////////////////////
 출력 형식과 관련된 옵션을 살펴봤지만 `git log` 명령은 조회 범위를 제한하는 옵션들도 있다. 히스토리 전부가 아니라 부분만 조회한다.
 이미 최근 두 개만 조회하는 `-2` 옵션은 살펴봤다.
-실제 사용법은 `-<n>`이고 n은 최근 n개의 커밋을 의미한다.
+실제 사용법은 `-<n>` 이고 n은 최근 n개의 커밋을 의미한다.
 사실 이 옵션을 자주 쓰진 않는다. Git은 기본적으로 출력을 pager류의 프로그램을 거쳐서 내보내므로 한 번에 한 페이지씩 보여준다.
 
 //////////////////////////
@@ -382,7 +382,7 @@ will limit the commit output to commits that match _any_ of the `--author` patte
 of the `--grep` patterns; however, adding the `--all-match` option further limits the output to
 just those commits that match _all_ `--grep` patterns.
 //////////////////////////
-`--author`와 `--grep` 옵션을 함께 사용하여 모두 만족하는 커밋을 찾으려면 `--all-match` 옵션도 반드시 함께 사용해야 한다.
+`--author` 와 `--grep` 옵션을 함께 사용하여 모두 만족하는 커밋을 찾으려면 `--all-match` 옵션도 반드시 함께 사용해야 한다.
 ====
 
 //////////////////////////

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

@@ -147,7 +147,7 @@ Next, you have a hotfix to make.
 Let's create a `hotfix` branch on which to work until it's completed:
 //////////////////////////
 이젠 해결해야 할 핫픽스가 생겼을 때를 살펴보자.
-`hotfix`라는 브랜치를 만들고 새로운 이슈를 해결할 때까지 사용한다.
+`hotfix` 라는 브랜치를 만들고 새로운 이슈를 해결할 때까지 사용한다.
 
 [source,console]
 ----
@@ -195,7 +195,7 @@ Merge 메시지에서 “fast-forward” 가 보이는가.
 //////////////////////////
 Your change is now in the snapshot of the commit pointed to by the `master` branch, and you can deploy the fix.
 //////////////////////////
-이제 `hotfix`는 `master` 브랜치에 포함됐고 운영환경에 적용할 수 있는 상태가 되었다고 가정해보자.
+이제 `hotfix` 는 `master` 브랜치에 포함됐고 운영환경에 적용할 수 있는 상태가 되었다고 가정해보자.
 
 //////////////////////////
 .`master` is fast-forwarded to `hotfix`
@@ -408,7 +408,7 @@ After you've resolved each of these sections in each conflicted file, run `git a
 Staging the file marks it as resolved in Git.
 //////////////////////////
 충돌한 양쪽에서 조금씩 가져와서 새로 수정했다.
-그리고 `<<<<<<<`, `=======`, `>>>>>>>`가 포함된 행을 삭제했다.
+그리고 `<<<<<<<`, `=======`, `>>>>>>>` 가 포함된 행을 삭제했다.
 이렇게 충돌한 부분을 해결하고 `git add` 명령으로 다시 Git에 저장한다.
 
 //////////////////////////

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

@@ -76,8 +76,8 @@ It works by going to the common ancestor of the two branches (the one you're on
 .Rebasing the change introduced in `C4` onto `C3`
 image::images/basic-rebase-3.png[Rebasing the change introduced in `C4` onto `C3`.]
 //////////////////////////
-.`C4`의 변경사항을 `C3`에 적용하는 Rebase 과정
-image::images/basic-rebase-3.png[`C4`의 변경사항을 `C3`에 적용하는 Rebase 과정.]
+.`C4` 의 변경사항을 `C3` 에 적용하는 Rebase 과정
+image::images/basic-rebase-3.png[`C4` 의 변경사항을 `C3` 에 적용하는 Rebase 과정.]
 
 //////////////////////////
 At this point, you can go back to the `master` branch and do a fast-forward merge.
@@ -347,7 +347,7 @@ It's pretty safe to assume that the other developer doesn't want `C4` and `C6` t
 //////////////////////////
 `git log` 로 히스토리를 확인해보면 저자, 커밋 날짜, 메시지가 같은 커밋이 두 개 있다(C4, C4'). 이렇게 되면 혼란스럽다.
 게다가 이 히스토리를 서버에 Push 하면 같은 커밋이 두 개 있기 때문에 다른 사람들도 혼란스러워한다.
-`C4`와 `C6`는 포함되지 말았어야 할 커밋이다. 애초에 서버로 데이터를 보내기 전에 Rebase로 커밋을 정리했어야 했다.
+`C4` 와 `C6` 는 포함되지 말았어야 할 커밋이다. 애초에 서버로 데이터를 보내기 전에 Rebase로 커밋을 정리했어야 했다.
 
 [[_rebase_rebase]]
 //////////////////////////

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

@@ -30,7 +30,7 @@ If you were working on an issue with a partner and they pushed up an `iss53` bra
 //////////////////////////
 리모트 트래킹 브랜치의 이름은 `<remote>/<branch>` 형식으로 되어 있다.
 예를 들어 리모트 저장소 `origin` 의 `master` 브랜치를 보고 싶다면 `origin/master` 라는 이름으로 브랜치를 확인하면 된다.
-다른 팀원과 함께 어떤 이슈를 구현할 때 그 팀원이 `iss53` 브랜치를 서버로 Push 했고 당신도 로컬에 `iss53` 브랜치가 있다고 가정하자. 이때 서버의 `iss53` 브랜치가 가리키는 커밋은 로컬에서 `origin/iss53`이 가리키는 커밋이다.
+다른 팀원과 함께 어떤 이슈를 구현할 때 그 팀원이 `iss53` 브랜치를 서버로 Push 했고 당신도 로컬에 `iss53` 브랜치가 있다고 가정하자. 이때 서버의 `iss53` 브랜치가 가리키는 커밋은 로컬에서 `origin/iss53` 이 가리키는 커밋이다.
 
 //////////////////////////
 This may be a bit confusing, so let's look at an example.

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

@@ -48,7 +48,7 @@ You can daemonize this process a number of ways, depending on the operating syst
 Since `systemd` is the most common init system among modern Linux distributions, you can use it for that purpose.
 Simply place a file in `/etc/systemd/system/git-daemon.service` with these contents:
 //////////////////////////
-대개의 리눅스 배포판은 `systemd`를 가장 보편적으로 사용하며 이를 이용하는 방법이 가장 일반적이다.
+대개의 리눅스 배포판은 `systemd` 를 가장 보편적으로 사용하며 이를 이용하는 방법이 가장 일반적이다.
 아래의 내용으로 `/etc/systemd/system/git-daemon.service` 파일을 작성한다.
 
 [source,console]
@@ -123,7 +123,7 @@ For security reasons, it is strongly encouraged to have this daemon run as a use
 For the sake of simplicity we'll simply run it as the same 'git' user that `git-shell` is running as.
 //////////////////////////
 보안을 위해서 저장소를 읽을 수만 있는 사용자로 데몬을 실행시킬 것을 강력하게 권고한다. `git-ro` 라는 계정을 새로 만들고 그 계정으로 데몬을 실행시키는 것이 좋다.
-하지만 여기에서는 쉽게 설명하려고 `git-shell`을 실행하는 동일한 사용자인 `git` 계정을 사용한다.
+하지만 여기에서는 쉽게 설명하려고 `git-shell` 을 실행하는 동일한 사용자인 `git` 계정을 사용한다.
 
 //////////////////////////
 When you restart your machine, your Git daemon will start automatically and respawn if it goes down.

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

@@ -91,7 +91,7 @@ If the user +jane+ had a project named +project+, that project's url would be `h
 GitLab의 사용자 계정은 한 사람당 하나씩 만든다.
 사용자 계정의 내용은 복잡하지 않다. 로그인 데이터에 추가로 개인 정보가 들어있다.
 각 사용자마다 **네임스페이스**가 있다. 네임스페이스는 프로젝트를 묶는 단위이다.
-*jane* 사용자가 **project**라는 프로젝트를 진행 중이라면 프로젝트의 URL은 `http://server/jane/project`가 될 것이다.
+*jane* 사용자가 **project**라는 프로젝트를 진행 중이라면 프로젝트의 URL은 `http://server/jane/project` 가 될 것이다.
 
 [[gitlab_users]]
 //////////////////////////
@@ -128,7 +128,7 @@ A GitLab group is an assemblage of projects, along with data about how users can
 Each group has a project namespace (the same way that users do), so if the group +training+ has a project +materials+, its url would be `http://server/training/materials`.
 //////////////////////////
 GitLab 그룹은 프로젝트와 누가 어떤 프로젝트에 어떻게 접근할지에 대한 권한 데이터의 모음이다.
-그룹에도 사용자처럼 프로젝트 네임스페이스가 있다. +training+라는 그룹이 +materials+라는 프로젝트를 가지고 있으면 URL은 `http://server/training/materials`가 된다.
+그룹에도 사용자처럼 프로젝트 네임스페이스가 있다. +training+라는 그룹이 +materials+라는 프로젝트를 가지고 있으면 URL은 `http://server/training/materials` 가 된다.
 
 [[gitlab_groups]]
 //////////////////////////