인사이트 수정

book/01-introduction/sections/about-version-control.asc

@@ -138,4 +138,4 @@ Furthermore, many of these systems deal pretty well with having several remote r
 This allows you to set up several types of workflows that aren't possible in centralized systems, such as hierarchical models.
 //////////////////////////
 게다가 대부분의 DVCS 환경에서는 리모트 저장소가 존재한다. 리모트 저장소가 많을 수도 있다. 그래서 사람들은 동시에 다양한 그룹과 다양한 방법으로 협업할 수 있다.
-계층 모델 같은 중앙집중식 시스템으로는 할 수 없는 Workflow를 다양하게 사용할 수 있다.
+계층 모델 같은 중앙집중식 시스템으로는 할 수 없는 워크플로를 다양하게 사용할 수 있다.

book/01-introduction/sections/basics.asc

@@ -159,7 +159,7 @@ This makes using Git a joy because we know we can experiment without the danger
 For a more in-depth look at how Git stores its data and how you can recover data that seems lost, see <<_undoing>>.
 //////////////////////////
 Git을 사용하면 프로젝트가 심각하게 망가질 걱정 없이 매우 즐겁게 여러 가지 실험을 해 볼 수 있다.
-<<_undoing>>을 보면 Git이 데이터를 어떻게 저장하고 손실을 어떻게 복구해야 할지 알 수 있다.
+<<_undoing>>을 보면 Git에서 데이터를 어떻게 저장하고 손실을 어떻게 복구하는지 알 수 있다.
 
 //////////////////////////
 ==== The Three States

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

@@ -16,7 +16,7 @@ CLI로 사용할 수도 있고 GUI를 사용할 수도 있다.
 이 책에서는 Git CLI 사용법을 설명한다.
 Git의 *모든* 기능을 지원하는 것은 CLI 뿐이다. GUI 프로그램의 대부분은 Git 기능 중 일부만 구현하기 때문에 비교적 단순하다.
 CLI를 사용할 줄 알면 GUI도 사용할 수 있지만 반대는 성립하지 않는다.
-GUI를 선호하는 사람이 있다고 하더라도, CLI는 _모든_ 사람의 컴퓨터에 설치돼 있어서 바로 사용할 수 있을 것이다.
+GUI를 사용하고 싶더라도 CLI가 기본으로 설치되는 도구이기 때문에 CLI기준으로 설명하겠다.
 
 //////////////////////////
 So we will expect you to know how to open Terminal in Mac or Command Prompt or Powershell in Windows.

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

@@ -124,7 +124,7 @@ You can download this from the GitHub for Windows website, at http://windows.git
 윈도에서도 'GitHub for Windows'를 설치할 수 있다.
 이 인스톨러는 CLI와 GUI를 모두 설치해준다.
 설치하면 Git을 Powershell에서 사용할 수 있다. 인증정보(Credential) 캐싱과 CRLF 설정까지 잘 된다.(((Powershell)))(((CRLF)))(((credential caching)))
-이런 것들은 차차 배우게 될 것인데, 하나하나가 다 필요하다는 것을 알게 될 것이다.
+이런 것들은 차차 배우게 될 것인데, Git 사용자라면 쓰게 될 기능들이다.
 'GitHub for Windows'는 http://windows.github.com[]에서 내려받는다.
 
 //////////////////////////

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

@@ -10,7 +10,7 @@ The first takes an existing project or directory and imports it into Git.
 The second clones an existing Git repository from another server.
 //////////////////////////
 Git 저장소를 만드는 방법은 두 가지다.
-기존 프로젝트를 Git 저장소로 만드는 방법이 있고,
+기존 프로젝트나 디렉토리를 Git 저장소로 만드는 방법이 있고,
 다른 서버에 있는 저장소를 Clone 하는 방법이 있다.
 
 //////////////////////////

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

@@ -141,8 +141,8 @@ The `git add` command takes a path name for either a file or a directory; if it'
 //////////////////////////
 ``Changes to be committed'' 에 들어 있는 파일은 Staged 상태라는 것을 의미한다.
 커밋하면 `git add`를 실행한 시점의 파일이 커밋되어 저장소 히스토리에 남는다.
-앞에서 `git init` 명령을 실행했을 때, 그 다음 `git add (files)` 명령을 실행했던 걸 기억할 것이다. 이 명령을 통해 디렉토리에 있는 파일을 추적하고 관리하도록 한다.(((git commands, init)))(((git commands, add)))
-`git add` 명령은 파일 또는 디렉토리의 경로명을 아규먼트로 받는다. 만일 디렉토리를 아규먼트로 줄 경우, 그 디렉토리 아래에 있는 모든 파일을 재귀적으로 추가한다.
+앞에서 `git init` 명령을 실행한 후, `git add (files)` 명령을 실행했던 걸 기억할 것이다. 이 명령을 통해 디렉토리에 있는 파일을 추적하고 관리하도록 한다.(((git commands, init)))(((git commands, add)))
+`git add` 명령은 파일 또는 디렉토리의 경로를 아규먼트로 받는다. 디렉토리면 아래에 있는 모든 파일들까지 재귀적으로 추가한다.
 
 //////////////////////////
 ==== Staging Modified Files
@@ -736,12 +736,12 @@ To remove a file from Git, you have to remove it from your tracked files (more a
 The `git rm` command does that, and also removes the file from your working directory so you don't see it as an untracked file the next time around.
 //////////////////////////
 Git에서 파일을 제거하려면 `git rm` 명령으로 Tracked 상태의 파일을 삭제한 후에(정확하게는 Staging Area에서 삭제하는 것) 커밋해야 한다.
-이 명령은 워킹 디렉토리에 있는 파일도 삭제하기 때문에 실제로 지워진다.
+이 명령은 워킹 디렉토리에 있는 파일도 삭제하기 때문에 실제로 파일도 지워진다.
 
 //////////////////////////
 If you simply remove the file from your working directory, it shows up under the ``Changed but not updated'' (that is, _unstaged_) area of your `git status` output:
 //////////////////////////
-만약 Git없이 그냥 파일을 삭제하고 `git status` 명령으로 상태를 확인하면 ``Changes not staged for commit''(즉, Unstaged) 에 속한다는 것을 확인할 수 있다.
+Git 명령을 사용하지 않고 단순히 워킹 디렉터리에서 파일을 삭제하고 git status 명령으로 상태를 확인하면 Git은 현재 "Changes not staged for commit"(즉, Unstaged 상태)라고 표시해준다.
 
 [source,console]
 ----
@@ -781,7 +781,7 @@ This is a safety feature to prevent accidental removal of data that hasn't yet b
 //////////////////////////
 커밋하면 파일은 삭제되고 Git은 이 파일을 더는 추적하지 않는다.
 이미 파일을 수정했거나 Index에(역주 - Staging Area을 Git Index라고도 부른다) 추가했다면 `-f`옵션을 주어 강제로 삭제해야 한다.
-이 점은 실수로 데이터를 삭제하지 못하도록 하는 안전장치다. 한 번도 커밋한적 없는 데이터는 Git으로 복구할 수 없다.
+이 점은 실수로 데이터를 삭제하지 못하도록 하는 안전장치다. 커밋 하지 않고 수정한 데이터는 Git으로 복구할 수 없기 때문이다.
 
 //////////////////////////
 Another useful thing you may want to do is to keep the file in your working tree but remove it from your staging area.

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

@@ -129,7 +129,7 @@ While `git reset` _can_ be a dangerous command if you call it with `--hard`, in
 =====
 //////////////////////////
 =====
-`git reset` 명령을 `--hard` 옵션과 함께 사용하면 워킹 디렉토리의 파일이 수정돼서 을 조심해야 한다. `--hard` 옵션만 사용하지 않는다면 `git reset` 명령은 Staging Area의 파일만 조작하기 때문에 위험하지 않다.
+`git reset` 명령을 `--hard` 옵션과 함께 사용하면 워킹 디렉토리의 파일까지 수정돼서 조심해야 한다. `--hard` 옵션만 사용하지 않는다면 `git reset` 명령은 Staging Area의 파일만 조작하기 때문에 위험하지 않다.
 =====
 
 //////////////////////////

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

@@ -92,7 +92,7 @@ You work on your web site 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` 브랜치를 가리킨다)
-뭔가 일을 하고 커밋하면 `iss53` 브랜치가 앞으로 진행한다.
+뭔가 일을 하고 커밋하면 `iss53` 브랜치가 앞으로 나아간다.
 
 [source,console]
 ----
@@ -114,7 +114,7 @@ All you have to do is switch back to your `master` branch.
 //////////////////////////
 다른 상황을 가정해보자. 만드는 사이트에 문제가 생겨서 즉시 고쳐야 한다.
 버그를 해결한 Hotfix에 `iss53`이 섞이는 것을 방지하기 위해 `iss53`과 관련된 코드를 어딘가에 저장해두고 원래 운영 환경의 소스로 복구해야 한다.
-Git을 사용하면 이런 노력을 들일 필요 없이 그냥 `master` 브랜치로 옮기면 된다.
+Git을 사용하면 이런 노력을 들일 필요 없이 그냥 `master` 브랜치로 돌아가면 된다.
 
 //////////////////////////
 However, before you do that, note that if your working directory or staging area has uncommitted changes that conflict with the branch you're checking out, Git won't let you switch branches.
@@ -189,8 +189,8 @@ Because the commit pointed to by the branch you merged in was directly upstream
 To phrase that another way, when you try to merge one commit with a commit that can be reached by following the first commit's history, Git simplifies things by moving the pointer forward because there is no divergent work to merge together – this is called a ``fast-forward.''
 //////////////////////////
 Merge 메시지에서 ``fast-forward''가 보이는가.
-Merge 할 브랜치가 가리키는 커밋이 현 브랜치 커밋의 Upstream 브랜치이기 때문에 master 브랜치 포인터는 최신 커밋으로 이동한다.
-이런 Merge 방식을 'Fast forward'라고 부른다. 다시 말해서 A 브랜치에서 다른 B 브랜치를 Merge 할 때 B가 A 이후의 커밋을 가리키고 있으면 그저 A가 B의 커밋을 가리키게 할 뿐이다.
+Merge 할 브랜치가 가리키는 커밋이 현 브랜치 커밋의 Upstream 브랜치이기 때문에 master 브랜치 포인터는 Merge 과정 없이 그저 최신 커밋으로 이동한다.
+이런 Merge 방식을 'Fast forward'라고 부른다. 다시 말해 A 브랜치에서 다른 B 브랜치를 Merge 할 때 B 브랜치가 A 브랜치 이후의 커밋을 가리키고 있으면 그저 A 브랜치가 B 브랜치와 동일한 커밋을 가리키도록 이동시킬 뿐이다.
 
 //////////////////////////
 Your change is now in the snapshot of the commit pointed to by the `master` branch, and you can deploy the fix.

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

@@ -72,9 +72,9 @@ As you start making commits, you're given a `master` branch that points to the l
 Every time you commit, it moves forward automatically.
 //////////////////////////
 Git의 브랜치는 커밋 사이를 가볍게 이동할 수 있는 어떤 포인터 같은 것이다.
-기본적으로 Git은 `master` 브랜치를 만든다.
-최초로 커밋하면 Git은 master라는 이름의 브랜치를 만든다.
-커밋을 만들 때 마다 브랜치가 자동으로 가장 마지막 커밋을 가리키게 한다.
+기본적으로 Git은 master 브랜치를 만든다.
+처음 커밋하면 이 master 브랜치가 생성된 커밋을 가리킨다.
+이후 커밋을 만들면 브랜치는 자동으로 가장 마지막 커밋을 가리킨다.
 
 [NOTE]
 //////////////////////////

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

@@ -478,4 +478,4 @@ Git은 매우 강력한 도구고 기능이 많아서 히스토리를 잘 쌓을
 //////////////////////////
 In general the way to get the best of both worlds is to rebase local changes you've made but haven't shared yet before you push them in order to clean up your story, but never rebase anything you've pushed somewhere.
 //////////////////////////
-일반적인 해답을 굳이 드리자면 로컬 브랜치에서 작업할 때는 히스토리를 정리하기 위해서 Rebase 할 수도 있지만, Push로 리모트에든 밖으로 내보낸 커밋에 대해서는 절대 Rebase 하지 말아야 한다.
+일반적인 해답을 굳이 드리자면 로컬 브랜치에서 작업할 때는 히스토리를 정리하기 위해서 Rebase 할 수도 있지만, 리모트 등 어딘가에 Push로 내보낸 커밋에 대해서는 절대 Rebase 하지 말아야 한다.

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

@@ -326,7 +326,7 @@ So if you're on the `master` branch and it's tracking `origin/master`, you can s
 //////////////////////////
 .Upstream 별명
 ====
-추적 브랜치를 설정했다면 추적 브랜치를 `@{upstream}`이나 `@{u}`로 짧게 대체하여 사용할 수 있다.
+추적 브랜치를 설정했다면 추적 브랜치 이름을 `@{upstream}`이나 `@{u}`로 짧게 대체하여 사용할 수 있다.
 `master` 브랜치가 `origin/master` 브랜치를 추적하는 경우라면 `git merge origin/master` 명령과 `git merge @{u}` 명령을 똑같이 사용할 수 있다.(((+++@{u}+++)))(((+++@{upstream}+++)))
 ====
 

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

@@ -1,14 +1,14 @@
 //////////////////////////
 === Branching Workflows
 //////////////////////////
-=== 브랜치 Workflow
+=== 브랜치 워크플로
 
 //////////////////////////
 Now that you have the basics of branching and merging down, what can or should you do with them?
 In this section, we'll cover some common workflows that this lightweight branching makes possible, so you can decide if you would like to incorporate it into your own development cycle.
 //////////////////////////
 브랜치를 만들고 Merge 하는 것을 어디에 써먹어야 할까.
-이 절에서는 Git 브랜치가 유용한 몇 가지 Workflow를 살펴본다. 여기서 설명하는 Workflow를 개발에 적용하면 도움이 될 것이다.
+이 절에서는 Git 브랜치가 유용한 몇 가지 워크플로를 살펴본다. 여기서 설명하는 워크플로를 개발에 적용하면 도움이 될 것이다.
 
 //////////////////////////
 ==== Long-Running Branches
@@ -28,15 +28,15 @@ Many Git developers have a workflow that embraces this approach, such as having
 They have another parallel branch named `develop` or `next` that they work from or use to test stability – it isn't necessarily always stable, but whenever it gets to a stable state, it can be merged into `master`.
 It's used to pull in topic branches (short-lived branches, like your earlier `iss53` branch) when they're ready, to make sure they pass all the tests and don't introduce bugs.
 //////////////////////////
-이런 접근법에 따라서 Git 개발자가 많이 선호하는 Workflow가 하나 있다. 배포했거나 배포할 코드만 `master` 브랜치에 Merge 해서 안정 버전의 코드만 `master` 브랜치에 둔다.
+이런 접근법에 따라서 Git 개발자가 많이 선호하는 워크플로가 하나 있다. 배포했거나 배포할 코드만 `master` 브랜치에 Merge 해서 안정 버전의 코드만 `master` 브랜치에 둔다.
 개발을 진행하고 안정화하는 브랜치는 `develop`이나 `next`라는 이름으로 추가로 만들어 사용한다. 이 브랜치는 언젠가 안정 상태가 되겠지만, 항상 안정 상태를 유지해야 하는 것이 아니다. 테스트를 거쳐서 안정적이라고 판단되면 `master` 브랜치에 Merge 한다.
 토픽 브랜치(앞서 살펴본 `iss53` 브랜치 같은 짧은 호흡 브랜치)에도 적용할 수 있는데, 해당 토픽을 처리하고 테스트해서 버그도 없고 안정적이면 그때 Merge 한다.
 
 //////////////////////////
 In reality, we're talking about pointers moving up the line of commits you're making.
 The stable branches are farther down the line in your commit history, and the bleeding-edge branches are farther up the history.
 //////////////////////////
-사실 우리가 얘기하는 것은 커밋을 가리키는 포인터에 대한 얘기다.
+사실 우리가 얘기하는 것은 커밋을 가리키는 포인터에 대한 얘기다. 커밋 포인터를 만들고 수정하고 분리하고 합치는지에 대한 것이다.
 개발 브랜치는 공격적으로 히스토리를 만들어 나아가고 안정 브랜치는 이미 만든 히스토리를 뒤따르며 나아간다.
 
 //////////////////////////
@@ -132,7 +132,7 @@ image::images/topic-branches-2.png[`dumbidea`와 `iss91v2` 브랜치를 Merge 
 //////////////////////////
 We will go into more detail about the various possible workflows for your Git project in <<_distributed_git>>, so before you decide which branching scheme your next project will use, be sure to read that chapter.
 //////////////////////////
-<<_distributed_git>>에서 프로젝트를 Git으로 관리할 때 브랜치를 이용하여 만들 수 있는 여러 Workflow에 대해 살펴본다. 관련 부분을 살펴보면 프로젝트에 어떤 형태로 응용할수 있을 지 감이 올 것이다.
+<<_distributed_git>>에서 프로젝트를 Git으로 관리할 때 브랜치를 이용하여 만들 수 있는 여러 워크플로에 대해 살펴본다. 관련 부분을 살펴보면 프로젝트에 어떤 형태로 응용할수 있을 지 감이 올 것이다.
 
 //////////////////////////
 It's important to remember when you're doing all this that these branches are completely local.

book/04-git-server/sections/generating-ssh-key.asc

@@ -79,4 +79,4 @@ NrRFi9wrf+M7Q== schacon@mylaptop.local
 //////////////////////////
 For a more in-depth tutorial on creating an SSH key on multiple operating systems, see the GitHub guide on SSH keys at https://help.github.com/articles/generating-ssh-keys[].
 //////////////////////////
-다른 운영 체제에서 SSH 키를 만드는 방법이 궁금하면 https://help.github.com/articles/generating-ssh-keys[]에 있는 Github 설명서를 찾아보는 게 좋다.
+다른 운영 체제에서 SSH 키를 만드는 방법이 궁금하면 https://help.github.com/articles/generating-ssh-keys[]에 있는 GitHub 설명서를 찾아보는 게 좋다.

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

@@ -60,7 +60,7 @@ First, you need to get the Git source code, which GitWeb comes with, and generat
 자신의 프로젝트에서 언제나 웹 인터페이스를 운영하려면 먼저 웹서버에 이 CGI 스크립트를 설치해야 한다.
 `apt`나 `yum`으로도 `gitweb`을 설치할 수 있지만, 여기에서는 수동으로 설치한다.
 GitWeb을 수동으로 설치하는 방법을 간단히 살펴보자.
-먼저 GitWeb이 포함된 Git 소스 코드를 구한 아래의 CGI 스크립트를 빌드한다.
+먼저 GitWeb이 포함된 Git 소스 코드를 구한 다음 아래의 CGI 스크립트를 빌드한다.
 
 [source,console]
 ----

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

@@ -169,7 +169,7 @@ If you try to push and the repository requires authentication (which it normally
 //////////////////////////
 아마 지금은 Git에서 가장 많이 사용하는 프로토콜일 것이다. `git://` 프로토콜처럼 익명으로 사용할 수도 있고, SSH처럼 인증을 거쳐 Push 할 수도 있기 때문이다.
 이 두 가지 동작을 다른 URL로 나눌 필요없이 하나의 URL로 통합해서 사용할 수 있다.
-그냥 인증기능을 켜놓은 저장소에 Push를 하면 서버는 사용자 이름과 비밀번호를 물어본다. 그리고 Fetch 나 Pull 같은 읽기도 같은 URL을 사용한다.
+그냥 인증기능을 켜놓은 저장소에 Push를 하면 서버는 사용자 이름과 비밀번호를 물어본다. 그리고 Fetch나 Pull 같은 읽기 작업에서도 같은 URL을 사용한다.
 
 //////////////////////////
 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.