fix some files in chapter 7.

book/07-git-tools/sections/credentials.asc

@@ -157,15 +157,15 @@ There are several forms it can take:
 이 Credential 시스템은 사실 Git과 분리된 독립적인 프로그램을 실행시켜 동작한다. 어떤 프로그램을 실행시킬지는 `credential.helper` 설정 값에 따른다.
 이 설정 값을 아래와 같이 설정한다.
 
-[options="header"]
-|======
 ////////////////////
 | Configuration Value | Behavior
 | `foo` | Runs `git-credential-foo`
 | `foo -a --opt=bcd` | Runs `git-credential-foo -a --opt=bcd`
 | `/absolute/path/foo -xyz` | Runs `/absolute/path/foo -xyz`
 | `!f() { echo "password=s3cre7"; }; f` | Code after `!` evaluated in shell
 ////////////////////
+[options="header"]
+|======
 | 설정 값 | 결과
 | `foo` | `git-credential-foo` 실행
 | `foo -a --opt=bcd` | `git-credential-foo -a --opt=bcd` 실행

book/07-git-tools/sections/interactive-staging.asc

@@ -264,7 +264,7 @@ At this point, you can exit the interactive adding script and run `git commit` t
 //////////////////////////
 simplegit.rb 파일의 상태를 보자.
 어떤 라인은 Staged 상태이고 어떤 라인은 Unstaged라고 알려줄 것이다.
-이 파일은 부분적으로 Stage 했다.
+이 파일의 일부를 Stage 했다.
 이제 대화형 모드를 종료하고 일부분만 Stage 한 파일을 커밋할 수 있다.
 
 //////////////////////////

book/07-git-tools/sections/replace.asc

@@ -126,7 +126,7 @@ image::images/replace3.png[]
 ////////////////////
 OK, so now that we have a base commit, we can rebase the rest of our history on top of that with `git rebase --onto`.  The `--onto` argument will be the SHA-1 we just got back from `commit-tree` and the rebase point will be the third commit (the parent of the first commit we want to keep, `9c68fdc`):
 ////////////////////
-이제 네 번째 커밋 이후의 히스토리를 쌓아 올릴 커밋이 준비됐다. `git rebase --onto` 명령으로 네 번째 이후 커밋을 새 커밋에 Rebase 한다. `--onto` 옵션 뒤에 전달할 커밋은 쌓아올릴 대상이 되는 커밋을 입력한다. 위에서 `commit-tree` 명령으로 반환받은 커밋을 사용하고 Rebase의 기준은 네 번째 커밋의 부모 커밋 즉 세 번째 커밋인 `9c68fdc` 해시를 전달한다.
+이제 네 번째 커밋 이후의 히스토리를 쌓을 커밋이 준비됐다. `git rebase --onto` 명령으로 네 번째 이후의 커밋을 새 커밋에 Rebase 한다. `--onto` 옵션 뒤에 전달할 커밋은 쌓아올릴 대상이 되는 커밋을 입력한다. 위에서 `commit-tree` 명령으로 반환받은 커밋을 사용하고 Rebase의 기준은 네 번째 커밋의 부모 커밋, 즉 세 번째 커밋인 `9c68fdc` 해시를 전달한다.
 
 [source,console]
 ----

book/07-git-tools/sections/rerere.asc

@@ -312,4 +312,4 @@ Applying: i18n one word
 ///////////////////
 So, if you do a lot of re-merges, or want to keep a topic branch up to date with your master branch without a ton of merges, or you rebase often, you can turn on `rerere` to help your life out a bit.
 ///////////////////
-이처럼 여러 번 Merge 하거나 Merge 커밋은 쌓지 않으면서 토픽 브랜치를 master 브랜치의 최신 내용을 바탕으로 유지하거나 Rebase를 자주 한다면 `rerere` 기능을 켜두는 게 여러모로 몸과 마음에 도움이 된다.
+이처럼 여러 번 Merge 하거나, Merge 커밋을 쌓지 않으면서도 토픽 브랜치를 master 브랜치의 최신 내용으로 유지하거나, Rebase를 자주 한다면 `rerere` 기능을 켜두는 게 여러모로 몸과 마음에 도움이 된다.

book/07-git-tools/sections/reset.asc

@@ -26,22 +26,22 @@ By ``tree'' here we really mean ``collection of files'', not specifically the da
 (There are a few cases where the index doesn't exactly act like a tree, but for our purposes it is easier to think about it this way for now.)
 //////////////////////////
 Git을 서로 다른 세 트리를 관리하는 컨텐츠 관리자로 생각하면 `reset`과 `checkout`을 좀 더 쉽게 이해할 수 있다.
-여기서 ``트리''란 실제로는 ``파일의 묶음''이다. 자료구조의 트리가 아니다
+여기서 ``트리'' 란 실제로는 ``파일의 묶음'' 이다. 자료구조의 트리가 아니다
 (세 트리 중 Index는 트리도 아니지만, 이해를 쉽게 하려고 일단 트리라고 한다).
 
 //////////////////////////
 Git as a system manages and manipulates three trees in its normal operation:
 //////////////////////////
 Git은 일반적으로 세 가지 트리를 관리하는 시스템이다.
 
-[cols="1,2",options="header"]
-|================================
 //////////////////////////
 | Tree              | Role
 | HEAD              | Last commit snapshot, next parent
 | Index             | Proposed next commit snapshot
 | Working Directory | Sandbox
 //////////////////////////
+[cols="1,2",options="header"]
+|================================
 | 트리             | 역할
 | HEAD             | 마지막 커밋 스냅샷, 다음 커밋의 부모 커밋
 | Index            | 다음에 커밋할 스냅샷

book/07-git-tools/sections/searching.asc

@@ -124,7 +124,7 @@ The `git grep` command has a few advantages over normal searching commands like
 //////////////////////////
 Perhaps you're looking not for **where** a term exists, but **when** it existed or was introduced. The `git log` command has a number of powerful tools for finding specific commits by the content of their messages or even the content of the diff they introduce.
 //////////////////////////
-만약 **where**라는 단어가 어떤 파일에 있는지를 찾아보는 것이 아니라 언제 추가되었고 히스토리 상 어느 시점에 나타나는지를 찾고자 할 수 있다. `git log` 명령을 이용하면 Diff 내용도 검색하여 어떤 커밋에 찾고자 하는 내용을 추가했는지 찾을 수 있다.
+만약 **where**라는 단어가 어떤 파일에 있는지를 찾아보는 것이 아니라, 언제 추가되었고 히스토리의 어느 시점에 나타나는지를 찾고자 할 수 있다. `git log` 명령을 이용하면 Diff 내용도 검색하여 어떤 커밋에서 찾고자 하는 내용을 추가했는지 찾을 수 있다.
 
 //////////////////////////
 If we want to find out for example when the `ZLIB_BUF_MAX` constant was originally introduced, we can tell Git to only show us the commits that either added or removed that string with the `-S` option.

book/07-git-tools/sections/signing.asc

@@ -17,7 +17,7 @@ Git은 암호학적으로 안전하다. 하지만, 그냥 되는 건 아니다.
 //////////////////////////
 First of all, if you want to sign anything you need to get GPG configured and your personal key installed.
 //////////////////////////
-우선 서명을 하려면 어쨌든 간에 GPG 설정도 하고 개인키도 설치해야 한다.
+우선 뭔가를 서명 하려면, GPG 설정도 하고 개인키도 설치해야 한다.
 
 [source,console]
 ----
@@ -32,7 +32,7 @@ sub   2048R/874529A9 2014-06-04
 //////////////////////////
 If you don't have a key installed, you can generate one with `gpg --gen-key`.
 //////////////////////////
-가진 키가 없으면 키를 만든다. 키를 만들려면 `gpg --genkey` 명령을 실행한다.
+가진 키가 없으면 키를 새로 만들어야 한다. 키를 만들려면 `gpg --genkey` 명령을 실행한다.
 
 [source,console]
 ----

book/07-git-tools/sections/submodules.asc

@@ -749,7 +749,7 @@ Automatic merge failed; fix conflicts and then commit the result.
 ///////////
 So basically what has happened here is that Git has figured out that the two branches record points in the submodule's history that are divergent and need to be merged. It explains it as ``merge following commits not found'', which is confusing but we'll explain why that is in a bit.
 ///////////
-위 결과를 통해 현재 상태를 살펴본다면 Git은 분기된 두 히스토리 브랜치를 찾았고 Merge가 필요하다는 것을 알게 된다. 이 상황은 ``merge following commits not found''(Merge 커밋을 찾을 수 없음)라는 메시지로 표현하는데 의미가 좀 이상하지만 왜 그런지는 이어지는 내용으로 설명한다.
+위 결과를 통해 현재 상태를 살펴본다면 Git은 분기된 두 히스토리 브랜치를 찾았고 Merge가 필요하다는 것을 알게 된다. 이 상황은 ``merge following commits not found''(Merge 커밋을 찾을 수 없음)라는 메시지로 표현하는데, 의미가 좀 이상하지만 왜 그런지는 이어지는 내용으로 설명한다.
 
 ///////////
 To solve the problem, you need to figure out what state the submodule should be in. Strangely, Git doesn't really give you much information to help out here, not even the SHA-1s of the commits of both sides of the history. Fortunately, it's simple to figure out.  If you run `git diff` you can get the SHA-1s of the commits recorded in both branches you were trying to merge.
@@ -840,7 +840,7 @@ $ git commit -m "Merge Tom's Changes" <5>
 ///////////
 It can be a bit confusing, but it's really not very hard.
 ///////////
-좀 따라가기 어려울 수 있지만 사실 그렇게 어려운 건 아니다.
+좀 따라가기 어려울 수 있지만, 사실 그렇게 어려운 건 아니다.
 
 ///////////
 Interestingly, there is another case that Git handles.
@@ -896,7 +896,7 @@ $ git commit -am 'Fast forwarded to a common submodule child'
 ///////////
 This accomplishes the same thing, but at least this way you can verify that it works and you have the code in your submodule directory when you're done.
 ///////////
-위와 같은 명령으로도 같은 작업을 수행할 수 있다. 이 방법을 사용하면 Merge 커밋에 해당하는 코드로 테스트까지 해 볼 수 있으며 Merge 작업 후에 서브모듈 디렉토리에 해당 코드로 업데이트된다.
+위와 같은 명령으로도 같은 작업을 수행할 수 있다. 이 방법을 사용하면 Merge 커밋에 해당하는 코드로 테스트까지 해 볼 수 있으며, Merge 작업 후에 서브모듈 디렉토리가 해당 코드로 업데이트된다.
 
 
 ///////////