diff --git a/book/06-github/sections/1-setting-up-account.asc b/book/06-github/sections/1-setting-up-account.asc
index cea3f2cb..718d275e 100644
--- a/book/06-github/sections/1-setting-up-account.asc
+++ b/book/06-github/sections/1-setting-up-account.asc
@@ -163,7 +163,7 @@ image::images/email-settings.png[이메일 주소를 전부 추가하기.]
 //////////////////////////
 In <<_add_email_addresses>> we can see some of the different states that are possible. The top address is verified and set as the primary address, meaning that is where you'll get any notifications and receipts. The second address is verified and so can be set as the primary if you wish to switch them. The final address is unverified, meaning that you can't make it your primary address. If GitHub sees any of these in commit messages in any repository on the site, it will be linked to your user now.
 //////////////////////////
-<<_add_email_addresses>>의 이메일 주소는 각각 다른 상태다. 첫 번째 주소는 주(Primary) 주소고 이미 확인됐다. 알림이나 영수증 메일은 주 주소로 간다. 두 번째 주소는 확인한 상태라서 주 주소로 바꿀 수 있는 상태다. 마지막 주소는 아직 확인되지 않아 주 주소로 변경할 수 없다. GitHub은 저장소의 커밋 메시지에 이 주소 세 개 중의 하나가 있으면 해당 사용자 계정 페이지로 링크를 걸어준다.
+<<_add_email_addresses>>의 이메일 주소는 각각 다른 상태다. 첫 번째 주소는 이미 확인이 된 주(Primary) 주소이다. 알림이나 영수증 메일은 주 주소로 간다. 두 번째 주소는 확인된 상태라 주 주소로 변경 할 수 있는 상태다. 마지막 주소는 아직 확인되지 않아 주 주소로 변경할 수 없다. 저장소의 커밋 메시지에 이 주소 세 개 중의 하나라도 있으면 GitHub가 해당 사용자 계정 페이지로 링크를 걸어준다.
 
 //////////////////////////
 ==== Two Factor Authentication
@@ -173,7 +173,7 @@ In <<_add_email_addresses>> we can see some of the different states that are pos
 //////////////////////////
 Finally, for extra security, you should definitely set up Two-factor Authentication or ``2FA''. Two-factor Authentication is an authentication mechanism that is becoming more and more popular recently to mitigate the risk of your account being compromised if your password is stolen somehow. Turning it on will make GitHub ask you for two different methods of authentication, so that if one of them is compromised, an attacker will not be able to access your account.
 //////////////////////////
-더 안전한 보안을 위해서 ``2FA''(2 팩터 인증)을 설정한다. 2FA는 최근 들어 인기가 높아지는 인증 메커니즘이다. 암호를 도둑맞았을 때 위험을 완화하기 위해 사용한다. 2FA를 켜면 GitHub은 두 가지 방법으로 인증받도록 요구한다. 둘 중 한 가지 방법만 뚫려서는 공격자가 계정에 접근할 수 없다.
+더 안전한 보안을 위해서 ``2FA''(2 팩터 인증)을 설정한다. 2FA는 최근 들어 인기가 높아지는 인증 메커니즘이다. 암호를 도둑맞았을 때 위험을 완화하기 위해 사용한다. 2FA를 활성화 시키면 GitHub은 두 가지 방법의 인증을 요구한다. 둘 중 한 가지 방법만 뚫려서는 공격자가 계정에 접근할 수 없다.
 
 //////////////////////////
 You can find the Two-factor Authentication setup under the Security tab of your Account settings.
diff --git a/book/06-github/sections/2-contributing.asc b/book/06-github/sections/2-contributing.asc
index ad0169c8..3b88a107 100644
--- a/book/06-github/sections/2-contributing.asc
+++ b/book/06-github/sections/2-contributing.asc
@@ -72,7 +72,7 @@ This flow works whether you're collaborating with a tightly-knit team in a singl
 It is centered on the <<_topic_branch>> workflow covered  in <<_git_branching>>.
 //////////////////////////
 GitHub은 Pull Request가 중심인 협업 Workflow를 위주로 설계됐다.
-이 Workflow는 Fork 해서 프로젝트에 기여하는 것인데 단일 저장소를 사용하는 긴밀한 팀에서도 유용하고 전 세계에서 흩어져서 일하는 회사나 한 번도 본 적 없는 사람들 사이에서도 유용하다.
+이 Workflow는 Fork 해서 프로젝트에 기여하는 것인데 단일 저장소만 사용하는 작은 팀이나 전 세계에서 흩어져서 일하는 회사, 혹은 한 번도 본 적 없는 사람들 사이에서도 유용하게 쓰인다.
 <<_git_branching>> 에서 설명했던 <<_topic_branch>> 중심으로 일하는 방식이다.
 
 //////////////////////////
@@ -245,7 +245,7 @@ Pull Request는 보통 공개 프로젝트에서 사용한다. 기여자는 수
 //////////////////////////
 At this point, the project owner can look at the suggested change and merge it, reject it or comment on it. Let's say that he likes the idea, but would prefer a slightly longer time for the light to be off than on.
 //////////////////////////
-Pull Request가 오면 프로젝트 소유자는 변경 점이 무엇인지 확인하고 Merge 하거나 거절하거나 코멘트을 달 수 있다. 소유자가 아이디어 자체를 마음에 들어 한다면 빛을 보기까지 좀 더 공을 들여야 한다.
+Pull Request가 오면 프로젝트 소유자는 변경 점이 무엇인지 확인한 후, Merge 혹은 거절하거나 코멘트를 달 수 있다. 소유자가 아이디어 자체를 마음에 들어 한다면 빛을 보기까지 좀 더 공을 들여야 한다.
 
 //////////////////////////
 Where this conversation may take place over email in the workflows presented in <<_distributed_git>>, on GitHub this happens online. The project owner can review the unified diff and leave a comment by clicking on any of the lines.
@@ -275,7 +275,7 @@ image::images/blink-04-email.png[이메일 알림]
 //////////////////////////
 Anyone can also leave general comments on the Pull Request. In <<_pr_discussion>> we can see an example of the project owner both commenting on a line of code and then leaving a general comment in the discussion section. You can see that the code comments are brought into the conversation as well.
 //////////////////////////
-누구나 Pull Request에 코멘트을 달 수 있다. <<_pr_discussion>>은 보면 프로젝트 소유자가 코드 코멘트과 일반 코멘트을 달면서 토론하는 것을 보여 준다. 코드 코멘트로 대화의 맥락을 이끌어 간다는 것을 볼 수 있다.
+누구나 Pull Request에 코멘트을 달 수 있다. <<_pr_discussion>>은 보면 프로젝트 소유자가 코드 코멘트과 일반 코멘트을 달면서 토론하는 것을 보여 준다. 코드 코멘트로 커뮤니케이션 하는 것을 볼 수 있다.
 
 [[_pr_discussion]]
 //////////////////////////
@@ -288,12 +288,12 @@ image::images/blink-05-general-comment.png[PR 토론 페이지]
 //////////////////////////
 Now the contributor can see what they need to do in order to get their change accepted. Luckily this is also a very simple thing to do. Where over email you may have to re-roll your series and resubmit it to the mailing list, with GitHub you simply commit to the topic branch again and push.
 //////////////////////////
-이 토론을 보고 기여자는 자신이 무엇을 해야 자신의 코드가 받아들여질지 알 수 있다. 만약 이 일을 이메일로 하고자 한다면 관련 커밋을 다시 말아서 메일링 리스트에 다시 보내야 한다. 하지만, GitHub에서는 해당 토픽 브랜치에 이어서 커밋하고 Push 하면 된다.
+이 토론을 보고 기여자는 자신이 무엇을 해야 자신의 코드가 받아들여질지 알 수 있다. 만약 이 일을 이메일로 하고자 한다면 관련 커밋을 다시 묶어서 메일링 리스트에 다시 보내야 한다. 하지만, GitHub에서는 해당 토픽 브랜치에 이어서 커밋하고 Push 하면 된다.
 
 //////////////////////////
 If the contributor does that then the project owner will get notified again and when they visit the page they will see that it's been addressed. In fact, since a line of code changed that had a comment on it, GitHub notices that and collapses the outdated diff.
 //////////////////////////
-기여자가 Push 하면 프로젝트 소유자에게 다시 알림이 간다. 다시 토론 페이지에 가면 해당 내용을 알 수 있다. 코멘트이 달린 코드를 수정했기 때문에 Github은 이점을 보여주고 때 지난 diff는 숨긴다.
+기여자가 Push 하면 프로젝트 소유자에게 다시 알림이 간다. 다시 토론 페이지에 가면 해당 내용을 알 수 있다. 코멘트가 달린 코드를 수정했기 때문에 Github은 이러한 사항을 보여주고, 옛날 diff는 숨긴다.
 
 [[_pr_final]]
 //////////////////////////
@@ -311,7 +311,7 @@ An interesting thing to notice is that if you click on the ``Files Changed'' tab
 //////////////////////////
 The other thing you'll notice is that GitHub checks to see if the Pull Request merges cleanly and provides a button to do the merge for you on the server. This button only shows up if you have write access to the repository and a trivial merge is possible. If you click it GitHub will perform a ``non-fast-forward'' merge, meaning that even if the merge *could* be a fast-forward, it will still create a merge commit.
 //////////////////////////
-그 외 알아두면 좋은 것은 GitHub은 Pull Request가 Merge 될 수 있는지 검사해서 서버에서 Merge 할 수 있도록 Merge 버튼을 제공한다. 이 버튼은 저장소에 쓰기 권한이 있는 사람만 볼 수 있고 이 버튼으로 Merge 하면 Merge 커밋이 생긴다(Trivial Merge). ``fast-forward'' Merge가 가능할 때도 ``non-fast-forwrd''로 Merge 한다.
+그 외 알아두면 좋은 것은 GitHub는 Pull Request가 Merge 될 수 있는지 검사해서 서버에서 Merge 할 수 있도록 Merge 버튼을 제공한다. 이 버튼은 저장소에 쓰기 권한이 있는 사람만 볼 수 있고 이 버튼으로 Merge 하면 Merge 커밋이 생긴다(Trivial Merge). ``fast-forward'' Merge가 가능할 때도 ``non-fast-forwrd''로 Merge 한다.
 
 //////////////////////////
 If you would prefer, you can simply pull the branch down and merge it locally. If you merge this branch into the `master` branch and push it to GitHub, the Pull Request will automatically be closed.
@@ -491,7 +491,7 @@ Your next question may be ``How to I reference the old Pull Request?''. It turns
 //////////////////////////
 Let's start with how to cross-reference another Pull Request or an Issue. All Pull Requests and Issues are assigned numbers and they are unique within the project. For example, you can't have Pull Request #3 _and_ Issue #3. If you want to reference any Pull Request or Issue from any other one, you can simply put `#<num>` in any comment or description. You can also be more specific if the Issue or Pull request lives somewhere else; write `username#<num>` if you're referring to an Issue or Pull Request in a fork of the repository you're in, or `username/repo#<num>` to reference something in another repository.
 //////////////////////////
-먼저 Issue와 Pull Request를 서로 참조시키는 방법부터 살펴보자. 모든 Pull Request와 Issue에는 번호가 할당되며 프로젝트 내에서는 유일하다. 예를 들어, #3인 Pull Request와 #3인 Issue는 동시에 있을 수 없다. `#<num>`과 같은 형태로 코멘트이나 설명에 Pull Request와 Issue를 참조시킬 수 있다. 이 방법은 한 프로젝트 내에서만 가능하다. Fork 저장소의 Issue나 Pull Request를 참조시키려고 한다면 `username#<num>`라고 쓰고 아예 다른 저장소면 `username/repo#<num>`라고 써야 한다.
+먼저 Issue와 Pull Request를 서로 참조시키는 방법부터 살펴보자. 모든 Pull Request와 Issue에는 프로젝트 내에서 유일한 번호가 할당된다. 예를 들어, #3인 Pull Request와 #3인 Issue는 동시에 있을 수 없다. `#<num>`과 같은 형태로 코멘트이나 설명에 Pull Request와 Issue를 참조시킬 수 있다. 이 방법은 단일 프로젝트 범위 에서만 유효하다. Fork 저장소의 Issue나 Pull Request를 참조시키려고 한다면 `username#<num>`라고 쓰고 아예 다른 저장소면 `username/repo#<num>`라고 써야 한다.
 
 //////////////////////////
 Let's look at an example. Say we rebased the branch in the previous example, created a new pull request for it, and now we want to reference the old pull request from the new one. We also want to reference an issue in the fork of the repository and an issue in a completely different project. We can fill out the description just like <<_pr_references>>.
@@ -540,14 +540,14 @@ image::images/mentions-03-closed.png[닫은 PR의 트랙백]
 //////////////////////////
 In addition to issue numbers, you can also reference a specific commit by SHA. You have to specify a full 40 character SHA, but if GitHub sees that in a comment, it will link directly to the commit. Again, you can reference commits in forks or other repositories in the same way you did with issues.
 //////////////////////////
-이슈뿐만 아니라 커밋의 SHA도 참조할 수 있다. 40자 SHA를 적으면 GitHub은 자동으로 해당 커밋에 링크시켜 준다. Fork 저장소나 아예 다른 저장소의 커밋도 이슈와 동일한 방식으로 링크시킬 수 있다.
+이슈뿐만 아니라 커밋의 SHA도 참조할 수 있다. 40자 SHA를 적으면 GitHub은 자동으로 해당 커밋에 링크를 걸어 준다. Fork 저장소나 아예 다른 저장소의 커밋도 이슈와 동일한 방식으로 링크시킬 수 있다.
 
 ==== Markdown
 
 //////////////////////////
 Linking to other Issues is just the beginning of interesting things you can do with almost any text box on GitHub. In  Issue and Pull Request descriptions, comments, code comments and more, you can use what is called ``GitHub Flavored Markdown''. Markdown is like writing in plain text but which is rendered richly.
 //////////////////////////
-다른 이슈를 링크하는 것은 GitHub 글쓰기의 첫걸음에 불과하다. 이슈나 Pull Request의 설명, 코멘트, 코드 주석 등등에서 ``GitHub Flavored Markdown''이라는 형식으로 글을 쓸 수 있다. Markdown 형식으로 글을 쓰면 그냥 텍스트 형식으로 글을 쓰는 것 같지만 미끈하고 아름답게 렌더링된다.
+다른 이슈를 링크하는 것은 GitHub 글쓰기의 첫걸음에 불과하다. ``GitHub Flavored Markdown''라 불리는 방식으로 이슈나 Pull Request의 설명, 코멘트, 코드 주석 등등에서  글을 쓸 수 있다. Markdown 형식으로 글을 쓰면 그냥 텍스트 형식으로 글을 쓰고 있음에도 불구하고, 미끈하고 아름답게 렌더링된다.
 
 //////////////////////////
 See <<_example_markdown>> for an example of how comments or text can be written and then rendered using Markdown.
@@ -607,7 +607,7 @@ image::images/markdown-02-tasks.png[타스크 리스트]
 //////////////////////////
 This is often used in Pull Requests to indicate what all you would like to get done on the branch before the Pull Request will be ready to merge. The really cool part is that you can simply click the checkboxes to update the comment -- you don't have to edit the Markdown directly to check tasks off.
 //////////////////////////
-Pull Request를 Merge 하기 전에 꼭 처리해야 하는 일의 목록을 표현할 때 타스크 리스트를 사용한다. 그리고 이게 좋은 게 Markdown을 직접 고치지 않고 체크박스만 클릭해도 해당 타스크가 완료됐다고 업데이트된다.
+Pull Request를 Merge 하기 전에 꼭 처리해야 하는 일의 목록을 표현할 때 타스크 리스트를 사용한다. Markdown을 직접 고치지 않고 체크박스만 클릭해도 해당 타스크가 완료됐다고 업데이트되기 때문에 상당히 좋은 기능이다.
 
 //////////////////////////
 What's more, GitHub will look for task lists in your Issues and Pull Requests and show them as metadata on the pages that list them out. For example, if you have a Pull Request with tasks and you look at the overview page of all Pull Requests, you can see how far done it is. This helps people break down Pull Requests into subtasks and helps other people track the progress of the branch. You can see an example of this in <<_task_list_progress>>.
@@ -625,7 +625,7 @@ image::images/markdown-03-task-summary.png[타스크 리스트의 예]
 //////////////////////////
 These are incredibly useful when you open a Pull Request early and use it to track your progress through the implementation of the feature.
 //////////////////////////
-Pull Request부터 열어 두고 일을 하면 해당 기능이 얼마나 진행됐는지 쉽게 알 수 있다.
+Pull Request을 열어놓은 뒤 해당 기능이 얼마나 진행되었는지 이력관리 용도로 사용할 수 있는데, 상당히 유용하다.
 
 //////////////////////////
 ====== Code Snippets
@@ -673,7 +673,7 @@ image::images/markdown-04-fenced-code.png[미끈한 코드]
 //////////////////////////
 If you're responding to a small part of a long comment, you can selectively quote out of the other comment by preceding the lines with the `>` character. In fact, this is so common and so useful that there is a keyboard shortcut for it. If you highlight text in a comment that you want to directly reply to and hit the `r` key, it will quote that text in the comment box for you.
 //////////////////////////
-아주 긴 글에서 딱 한 부분만 집어서 논의하고 싶을 때 `>` 문자로 해당 부분을 인용하고 그 밑에 코멘트을 단다. 이 방법은 매우 유용해서 흔히 사용하는 방법이고 단축키도 있다. 인용하고 싶은 텍스트를 선택하고 `r` 키를 누르면 바로 코멘트 상자에 해당 텍스트가 인용된다.
+아주 긴 글에서 딱 한 부분만 집어서 논의하고 싶을 때 `>` 문자로 해당 부분을 인용하고 그 밑에 코멘트을 단다. 이 방법은 매우 흔히 사용하는 방법이라, 상당히 유용하고, 단축키도 지원한다. 인용하고 싶은 텍스트를 선택하고 `r` 키를 누르면 바로 코멘트 상자에 해당 텍스트가 인용된다.
 
 //////////////////////////
 The quotes look something like this:
@@ -772,7 +772,7 @@ http://www.emoji-cheat-sheet.com
 //////////////////////////
 This isn't technically GitHub Flavored Markdown, but it is incredibly useful. In addition to adding Markdown image links to comments, which can be difficult to find and embed URLs for, GitHub allows you to drag and drop images into text areas to embed them.
 //////////////////////////
-GFM은 이미지까지 확장하지 않았지만 GitHub에서 이미지 첨부는 매우 쉽다. Markdown 형식으로 이미지를 첨부하고 싶을 때 이미지 올리고 그 URL을 찾아서 일일이 입력하기 번거롭다. GitHub에서는 그냥 이미지를 바로 Drag-and-Drop으로 붙여 넣을 수 있다.
+기술적으로 GFM은 아니지만, 이미지 기능은 상당히 유용하다. Markdown 형식으로 이미지를 첨부하고 싶을 때 이미지 올리고 그 URL을 찾아서 일일이 입력하기 번거롭다. GitHub에서는 그냥 이미지를 바로 Drag-and-Drop으로 붙여 넣을 수 있다.
 
 [[_md_drag]]
 //////////////////////////
diff --git a/book/06-github/sections/3-maintaining.asc b/book/06-github/sections/3-maintaining.asc
index 120105c5..2abb4051 100644
--- a/book/06-github/sections/3-maintaining.asc
+++ b/book/06-github/sections/3-maintaining.asc
@@ -52,7 +52,7 @@ image::images/newrepoform.png[``새 저장소'' 만들기.]
 All you really have to do here is provide a project name; the rest of the fields are completely optional.
 For now, just click the ``Create Repository'' button, and boom – you have a new repository on GitHub, named `<user>/<project_name>`.
 //////////////////////////
-꼭 해야 하는 것은 프로젝트 이름을 넣는 것뿐이다. 다른 것은 생략해도 된다.
+프로젝트 이름을 넣는 것만 필수다. 다른 것은 생략해도 된다.
 ``Create Repository'' 버튼을 클릭하면 '뿅'하고  `<user>/<project_name>` 위치에 GitHub 저장소가 생긴다.
 
 //////////////////////////
@@ -192,7 +192,7 @@ $ curl http://github.com/tonychacon/fade/pull/1.patch | git am
 //////////////////////////
 As we covered in <<_github_flow>>, you can now have a conversation with the person who opened the Pull Request. You can comment on specific lines of code, comment on whole commits or comment on the entire Pull Request itself, using GitHub Flavored Markdown everywhere.
 //////////////////////////
-<<_github_flow>>에서 설명했듯이 Pull Request를 만든 사람과 토론할 수 있다. 코멘트를 Pull Request에 대고 남길 수도 있고 특정 커밋을 고르거나 특정 라인을 집어서 남길 수도 있다.
+<<_github_flow>>에서 설명했듯이 Pull Request를 만든 사람과 토론할 수 있다. GFM을 사용하여 특정 커밋을 선택하거나, 특정 라인을 지정하거나, 혹은 전체 Pull Request 자체에도 코멘트를 남길 수 있다.
 
 //////////////////////////
 Every time someone else comments on the Pull Request you will continue to get email notifications so you know there is activity happening. They will each have a link to the Pull Request where the activity is happening and you can also directly respond to the email to comment on the Pull Request thread.
@@ -276,12 +276,12 @@ Of course, if you're in your repository and you run `git ls-remote origin` or wh
 //////////////////////////
 If the repository is on GitHub and you have any Pull Requests that have been opened, you'll get these references that are prefixed with `refs/pull/`. These are basically branches, but since they're not under `refs/heads/` you don't get them normally when you clone or fetch from the server -- the process of fetching ignores them normally.
 //////////////////////////
-GitHub에 있는 저장소에 열려 있는 Pull Reqeust가 있으면 `refs/pull/`로 시작하는 이름으로 Ref가 생성된다. 이것도 브랜치지만 `refs/heads/`로 시작하는 브랜치와는 달리 Clone과 Fetch 할 때 받아지지 않는다. 기본적으로 무시된다.
+GitHub 저장소에  어떤 Pull Reqeust라도 열려있다면 `refs/pull/`로 시작하는 이름으로 Ref가 생성된다. 이것도 브랜치지만 `refs/heads/`로 시작하는 브랜치와는 달리 Clone과 Fetch 할 때 받아지지 않는다. 기본적으로 무시된다.
 
 //////////////////////////
 There are two references per Pull Request - the one that ends in `/head` points to exactly the same commit as the last commit in the Pull Request branch. So if someone opens a Pull Request in our repository and their branch is named `bug-fix` and it points to commit `a5a775`, then in *our* repository we will not have a `bug-fix` branch (since that's in their fork), but we _will_ have `pull/<pr#>/head` that points to `a5a775`. This means that we can pretty easily pull down every Pull Request branch in one go without having to add a bunch of remotes.
 //////////////////////////
-Pull Request에는 두 종류의 Ref가 있다. `/head`로 끝나는 것은 Pull Request 브랜치가 가리키는 마지막 커밋이다. 누군가 우리 저장소에 `bug-fix`라는 브랜치를 Pull Request로 보내는 상황을 살펴보자. 이 브랜치는 `a5a775` 커밋을 가리킨다. `bug-fix` 브랜치는 Fork 한 저장소에 있는 브랜치라서 우리 저장소에 없다. 하지만 `a5a775`를 가리키는 `pull/<pr#>/head` 형식의 브랜치가 자동으로 생긴다. 그래서 매번 다른 저장소를 리모트로 등록하지 않고서도 Pull Request 브랜치를 쉽게 Pull 할 수 있다.
+Pull Request에는 두 종류의 Ref가 있다. `/head`로 끝나는 것은 Pull Request 브랜치가 가리키는 마지막 커밋이다. 누군가 우리 저장소에 `bug-fix`라는 브랜치를 Pull Request로 보내는 상황을 살펴보자. 이 브랜치는 `a5a775` 커밋을 가리킨다. `bug-fix` 브랜치는 Fork 한 저장소에 있는 브랜치라서 우리 저장소에 없다. 그럼에도 불구하고 `a5a775`를 가리키는 `pull/<pr#>/head` 형식의 브랜치가 자동으로 생긴다. 그래서 매번 다른 저장소를 리모트로 등록하지 않고서도 Pull Request 브랜치를 쉽게 Pull 할 수 있다.
 
 //////////////////////////
 Now, you could do something like fetching the reference directly.
@@ -303,7 +303,7 @@ Also, if you're reviewing a *lot* of pull requests, this gets tedious.
 //////////////////////////
 ``리모트의 브랜치 `origin`을 `refs/pull/958/head`로 Fetch 한다''는 뜻이다.
 Git은 충실하게 전부 내려받고 마지막 커밋을 `.git/FETCH_HEAD`에 저장한다.
-`git merge FETCH_HEAD`으로 Merge 해서 테스트할 수 있다. 이렇게 Merge 하면 Merge 커밋 메시지가 특이해지고 많은 Pull Request를 처리해야 하면 쓸데없는 Merge 커밋도 많이 생긴다.
+`git merge FETCH_HEAD`으로 Merge 해서 테스트할 수 있다. 이렇게 Merge 하면 Merge 커밋 메시지가 약간 이상해진다. 또한 많은 Pull Request를 처리해야 하는경우, 쓸데없는 Merge 커밋도 많아 진다.
 
 //////////////////////////
 There's also a way to fetch _all_ of the pull requests, and keep them up to date whenever you connect to the remote.
@@ -552,7 +552,7 @@ The `List-Post` and `List-Unsubscribe` fields mean that if you have a mail clien
 //////////////////////////
 It's also worth noting that if you have both email and web notifications enabled and you read the email version of the notification, the web version will be marked as read as well if you have images allowed in your mail client.
 //////////////////////////
-이메일과 웹 알림이 둘 다 켜져 있으면 알림이 이메일로도 오고 웹으로도 온다. 이메일 클라이언트에 이미지를 읽도록 설정돼 있으면 이메일 클라이언트에서 메일을 읽으면 웹에서도 읽었다고 표시된다.
+이메일과 웹 알림이 둘 다 켜져 있으면 알림이 이메일로도 오고 웹으로도 온다. 이메일 클라이언트에서 이미지가 허용되어 있으면, 메일을 읽었을 때 웹에서도 읽었다고 표시된다.
 
 //////////////////////////
 ==== Special Files
@@ -562,7 +562,7 @@ It's also worth noting that if you have both email and web notifications enabled
 //////////////////////////
 There are a couple of special files that GitHub will notice if they are present in your repository.
 //////////////////////////
-저장소에 있는 파일 중에서 GitHub이 사용하는 파일이 있다.
+저장소에 있는 파일 중에서 GitHub가 사용하는 몇가지 특이한 파일들이 있다.
 
 ==== README
 
diff --git a/book/06-github/sections/5-scripting.asc b/book/06-github/sections/5-scripting.asc
index 8950f2f8..d08141ef 100644
--- a/book/06-github/sections/5-scripting.asc
+++ b/book/06-github/sections/5-scripting.asc
@@ -95,7 +95,7 @@ image::images/scripting-03-webhook.png[웹훅]
 //////////////////////////
 The configuration for a web hook is pretty simple. In most cases you simply enter a URL and a secret key and hit ``Add webhook''. There are a few options for which events you want GitHub to send you a payload for -- the default is to only get a payload for the `push` event, when someone pushes new code to any branch of your repository.
 //////////////////////////
-웹훅 설정은 매우 간단하다. URL와 보안 키를 입력하고 ``Add webhook'' 버튼을 클릭한다. 어떤 이벤트의 페이로드가 필요한 것인지 선택할 수 있지만 `push` 이벤트의 페이로드만 보내는 것이 기본이다. 그래서 누군가 아무 브랜치에나 코드를 Push 하면 HTTP 페이로드가 전송된다.
+웹훅 설정은 매우 간단하다. URL와 보안 키를 입력하고 ``Add webhook'' 버튼을 클릭한다. 어떤 이벤트의 페이로드가 필요한 것인지도 선택할 수 있지만 `push` 이벤트의 페이로드만 보내는 것이 기본이다. 그래서 누군가 아무 브랜치에나 코드를 Push 하면 HTTP 페이로드가 전송된다.
 
 //////////////////////////
 Let's see a small example of a web service you may set up to handle a web hook. We'll use the Ruby web framework Sinatra since it's fairly concise and you should be able to easily see what we're doing.
@@ -265,7 +265,7 @@ image::images/scripting-05-access-token.png[엑세스 토큰]
 //////////////////////////
 It will ask you which scopes you want for this token and a description. Make sure to use a good description so you feel comfortable removing the token when your script or application is no longer used.
 //////////////////////////
-토큰을 어디에 쓸지 범위를 선택하고 설명을 입력한다. 나중에 다 쓰고 삭제하기 쉽도록 이해하기 쉬운 설명을 다는 게 좋다.
+토큰을 어디에 쓸지 범위를 선택하고 설명을 입력한다. 나중에 스크립트나 애플리케이션을 더이상 사용하지 않게 되었을 때, 삭제를 편히 할 수 있도록 설명 이해하기 쉽게 다는 게 좋다.
 
 //////////////////////////
 GitHub will only show you the token once, so be sure to copy it. You can now use this to authenticate in your script instead of using a username and password. This is nice because you can limit the scope of what you want to do and the token is revokable.
@@ -393,7 +393,7 @@ Hopefully this is fairly simple to follow. In this web hook handler we look thro
 //////////////////////////
 In this case you can send a state ('success', 'failure', 'error'), a description of what happened, a target URL the user can go to for more information and a ``context'' in case there are multiple statuses for a single commit. For example, a testing service may provide a status and a validation service like this may also provide a status -- the ``context'' field is how they're differentiated.
 //////////////////////////
-커밋의 상태는 'success', 'failure', 'error'일 수 있다. 커밋의 상태(state)와 설명(description), 자세한 정보를 확인할 수 있는 URL(target_url), 상태를 구분하는 ``컨텍스트(context)''를 함께 전송한다. 한 커밋에 대해서 테스팅 서비스도 어떤 상태를 보내올 것이고 검증 서비스도 어떤 상태를 보내올 것이라서 ``컨텍스트''가 필요하다.
+커밋의 상태는 'success', 'failure', 'error'일 수 있다. 커밋의 상태(state)와 설명(description), 자세한 정보를 확인할 수 있는 URL(target_url), 상태를 구분하는 ``컨텍스트(context)''를 함께 전송한다. 단일 커밋에서도 다양한 경우가 있기 때문에, 컨텍스트가 필요하다. 예를 들어  유효성을 검증하거나 상태값을 제공해 주는 테스팅 서비스의 경우 상태값을 제공해야 하는데, ``컨텍스트'' 필드를 통해 어떻게 상태가 변화하였는지를 알 수 있다.
 
 //////////////////////////
 If someone opens a new Pull Request on GitHub and this hook is setup, you may see something like <<_commit_status>>.