chapter 7: review

book/07-git-tools/sections/advanced-merging.asc

@@ -255,7 +255,7 @@ The `:1:hello.rb` is just a shorthand for looking up that blob SHA.
 ///////////////////
 Now that we have the content of all three stages in our working directory, we can manually fix up theirs to fix the whitespace issue and re-merge the file with the little-known `git merge-file` command which does just that.
 ///////////////////
-이제 워킹 디렉토리에 세 Stage의 파일을 갖게 되었다. 공백 문제를 수동으로 고친 다음 다시 Merge한다. Merge 할 때에는 잘 알려지지 않은 명령인 `git merge-file` 명령을 이용한다.
+이제 워킹 디렉토리에 세 버전의 파일을 모두 가지게 되었다. 공백 문제를 수동으로 고친 다음 다시 Merge한다. Merge할 때에는 'git merge-file'명령을 이용한다.
 
 [source,console]
 ----
@@ -390,7 +390,7 @@ Removing hello.theirs.rb
 ///////////////////
 Perhaps we're not happy with the resolution at this point for some reason, or maybe manually editing one or both sides still didn't work well and we need more context.
 ///////////////////
-어떠한 이유로든 위에서 제시된 여러가지 방식으로 충돌을 해결하는 것이 맘에 안들 수 있다. 혹은 충돌을 해결하기 위해 수정을 했는데도 충돌이 잘 해결되지 않아 더 많은 정보가 필요한 경우도 있을 수 있다.
+어떠한 이유로든 위에서 제시한 여러가지 방식으로 충돌을 해결하는 것이 맘에 안들 수 있다. 혹은 충돌을 해결하기 위해 수정을 했는데도 충돌이 잘 해결되지 않아 더 많은 정보가 필요한 경우도 있을 수 있다.
 
 ///////////////////
 Let's change up the example a little. For this example, we have two longer lived branches that each have a few commits in them but create a legitimate content conflict when merged.
@@ -918,7 +918,7 @@ If you want to do something like this but not have Git even try to merge changes
 ///////////////////
 This will basically do a fake merge. It will record a new merge commit with both branches as parents, but it will not even look at the branch you're merging in. It will simply record as the result of the merge the exact code in your current branch.
 ///////////////////
-이 작업은 기본적으로 거짓으로 Merge를 수행한다. 그리고 양 브랜치를 부모로 삼는 새 Merge 커밋을 만든다. 하지만 Merge한 대상 브랜치를 가리키지 않는다. Merge한 결과로 그냥 단순히 현재 브랜치의 코드를 기록해두는 것 뿐이다.
+이 작업은 기본적으로 거짓으로 Merge를 수행한다. 그리고 양 브랜치를 부모로 삼는 새 Merge 커밋을 만든다. 하지만 Merge한 대상 브랜치를 가리키지 않는다. Merge한 결과로 그냥 단순히 현재 브랜치의 코드를 사용하는 것 뿐이다.
 
 [source,console]
 ----
@@ -931,7 +931,7 @@ $
 ///////////////////
 You can see that there is no difference between the branch we were on and the result of the merge.
 ///////////////////
-지금 있는 브랜치와 Merge 결과가이 다르지 않다는 것을 알 수 있다.
+지금 있는 브랜치와 Merge 결과가 다르지 않다는 것을 알 수 있다.
 
 ///////////////////
 This can often be useful to basically trick Git into thinking that a branch is already merged when doing a merge later on. For example, say you branched off a ``release'' branch and have done some work on it that you will want to merge back into your ``master'' branch at some point. In the meantime some bugfix on ``master'' needs to be backported into your `release` branch. You can merge the bugfix branch into the `release` branch and also `merge -s ours` the same branch into your `master` branch (even though the fix is already there) so when you later merge the `release` branch again, there are no conflicts from the bugfix.

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

@@ -7,12 +7,12 @@
 ///////////
 Though we've covered the common ways to transfer Git data over a network (HTTP, SSH, etc), there is actually one more way to do so that is not commonly used but can actually be quite useful.
 ///////////
-앞에서 Git 데이터를 네트워크를 거쳐 전송하는 일반적인 방법(HTTP, SSH등)을 다루었었다. 사실 일반적으로 사용하진 않지만 꽤 유용한 방법이 하나 더 있다.
+앞에서 Git 데이터를 네트워크를 거쳐 전송하는 일반적인 방법(HTTP, SSH등)을 다루었었다. 일반적으로 사용하진 않지만 꽤 유용한 방법이 하나 더 있다.
 
 ///////////
 Git is capable of ``bundling'' it's data into a single file. This can be useful in various scenarios. Maybe your network is down and you want to send changes to your co-workers. Perhaps you're working somewhere offsite and don't have access to the local network for security reasons. Maybe your wireless/ethernet card just broke.  Maybe you don't have access to a shared server for the moment, you want to email someone updates and you don't want to transfer 40 commits via `format-patch`.
 ///////////
-Git에서는 ``Bundle''이란 것이 있다. 데이터를 하나의 파일에 몰아넣는 것이다. 이 방법은 다양한 경우 유용하게 사용할 수 있다. 예를 들어 네트워크가 불통인데 변경사항을 동료에게 보낼 때, 출장을 나갔는데 보안상의 이유로 로컬 네트워크에 접속하지 못할 때, 통신 인터페이스 장비가 부서졌을 때, 갑자기 잠시 동안 공용 서버에 접근하지 못할 때, 누군가에게 수정사항을 이메일로 보내야 하는데 40개 씩이나 되는 커밋을 `format-patch`로 보내고 싶지 않을 때를 예로 들 수 있다.
+Git에는 ``Bundle''이란 것이 있다. 데이터를 하나의 파일에 몰아넣는 것이다. 이 방법은 다양한 경우 유용하게 사용할 수 있다. 예를 들어 네트워크가 불통인데 변경사항을 동료에게 보낼 때, 출장을 나갔는데 보안상의 이유로 로컬 네트워크에 접속하지 못할 때, 통신 인터페이스 장비가 부서졌을 때, 갑자기 잠시 동안 공용 서버에 접근하지 못할 때, 누군가에게 수정사항을 이메일로 보내야 하는데 40개 씩이나 되는 커밋을 `format-patch`로 보내고 싶지 않을 때를 예로 들 수 있다.
 
 ///////////
 This is where the `git bundle` command can be helpful. The `bundle` command will package up everything that would normally be pushed over the wire with a `git push` command into a binary file that you can email to someone or put on a flash drive, then unbundle into another repository.
@@ -83,7 +83,7 @@ b1ec324 first commit
 ///////////
 If you don't include HEAD in the references, you have to also specify `-b master` or whatever branch is included because otherwise it won't know what branch to check out.
 ///////////
-Bundle 파일에 HEAD 레퍼런스를 포함시키지 않으면 `-b master` 옵션을 써주거나 어떠한 브랜치든 포함시킨 브랜치를 지정해줘야 한다. 그렇지 않으면 Git은 어떤 브랜치로 Checkout 할지 알 수 없다.
+Bundle 파일에 HEAD 레퍼런스를 포함시키지 않으려면 `-b master` 옵션을 써주거나 어떠한 브랜치든 포함시킨 브랜치를 지정해줘야 한다. 그렇지 않으면 Git은 어떤 브랜치로 Checkout 할지 알 수 없다.
 
 ///////////
 Now let's say you do three commits on it and want to send the new commits back via a bundle on a USB stick or email.
@@ -108,7 +108,7 @@ First we need to determine the range of commits we want to include in the bundle
 ///////////
 In order to do that, you'll have to calculate the difference. As we described in <<_commit_ranges>>, you can specify a range of commits in a number of ways. To get the three commits that we have in our master branch that weren't in the branch we originally cloned, we can use something like `origin/master..master` or `master ^origin/master`. You can test that with the `log` command.
 ///////////
-이렇게 Bundle 파일을 만들기 위해 우선 차이점을 찾아내야 한다. <<_commit_ranges>>에서 살펴본대로 숫자를 사용하여 커밋의 범위를 지정할 수 있다. 원래 Clone 한 브랜치인 master에는 없던 세 개의 커밋을 얻어내려면 `origin/master..master` 또는 `master ^origin//master` 파라미터를 쓰면 된다. `log` 명령으로 시험해볼 수 있다.
+이렇게 Bundle 파일을 만들기 위해 우선 차이점을 찾아내야 한다. <<_commit_ranges>>에서 살펴본대로 숫자를 사용하여 커밋의 범위를 지정할 수 있다. 원래 Clone 한 브랜치인 master에는 없던 세 개의 커밋을 얻어내려면 `origin/master..master` 또는 `master ^origin/master` 파라미터를 쓰면 된다. `log` 명령으로 시험해볼 수 있다.
 
 [source,console]
 ----

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

@@ -299,7 +299,7 @@ include::../git-credential-read-only[]
 <4> This loop reads the contents of the storage file, looking for matches.
     If the protocol and host from `known` match this line, the program prints the results to stdout and exits.
 ////////////////////
-<1> 우선 명령 옵션을 처리한다. 인증정보 파일을 명시하는 옵션을 처리하며 기본값은 `~/.git-credentials` 으로 처리한다.
+<1> 우선 명령 옵션을 처리한다. 옵션으로는 인증정보 파일명이 들어온다. 기본값은 `~/.git-credentials` 이다.
 <2> 헬퍼 프로그램은 `get` 액션만 처리하며 인증정보 파일이 존재하는 경우만 처리한다.
 <3> 이후에는 빈 줄이 나타날때 까지 표준입력으로부터 한 줄 한 줄 읽는다.
     각 줄을 파싱하여 `known` 해시에 저장하고 <4>의 응답에서 사용한다.
@@ -338,4 +338,4 @@ $ git config --global credential.helper read-only --file /mnt/shared/creds
 ////////////////////
 As you can see, extending this system is pretty straightforward, and can solve some common problems for you and your team.
 ////////////////////
-이렇게 살펴본대로 인증정보 저장소를 상황에 맞게 맞춤 프로그램을 작성해서 확장하는 것이 어렵지 않으며 이렇게 스크립트를 통해 사용자나 팀의 가려운 부분을 긁어줄 수 있다.
+이렇게 살펴본대로 인증정보 저장소를 상황에 맞게 맞춤 프로그램을 작성해서 확장하는 것이 어렵지 않으며 스크립트를 통해 사용자나 팀의 가려운 부분을 긁어줄 수 있다.

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

@@ -7,9 +7,10 @@
 Git also provides a couple of tools to help you debug issues in your projects.
 Because Git is designed to work with nearly any type of project, these tools are pretty generic, but they can often help you hunt for a bug or culprit when things go wrong.
 //////////////////////////
-Git이 제공하는 기능 중에 디버깅에 도움을 줄 수 있는 도구도 있다.
+Git에는 디버깅에 사용하면 좋은 기능도 있다.
 Git은 굉장히 유연해서 어떤 형식의 프로젝트에나 사용할 수 있다. 디버깅에 도움이 될 만한 도구는 프로젝트 성격에 영향을 받지 않고 문제를 일으킨 범인이나 버그도 쉽게 찾을 수 있도록 도와준다.
 
+
 [[_file_annotation]]
 //////////////////////////
 ==== File Annotation

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

@@ -99,7 +99,7 @@ What now> 1
 Now you can see that the TODO and index.html files are staged and the simplegit.rb file is still unstaged.
 If you want to unstage the TODO file at this point, you use the `3` or `r` (for revert) option:
 //////////////////////////
-이제 TODO와 index.html 파일은 Stage했고 simplegit.rb 파일만 아직 Unstaged 상태로 남아 있다. 이제 TODO 파일을 다시 Snstage하고 싶으면 `3`이나 `r`을(revert) 입력한다.
+이제 TODO와 index.html 파일은 Stage했고 simplegit.rb 파일만 아직 Unstaged 상태로 남아 있다. 이제 TODO 파일을 다시 Unstage하고 싶으면 `3`이나 `r`을(revert) 입력한다.
 
 [source,console]
 ----

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

@@ -4,7 +4,7 @@
 ////////////////////
 Git's objects are unchangable, but it does provide an interesting way to pretend to replace objects in it's database with other objects.
 ////////////////////
-히스토리(혹은 데이터베이스)에 일단 저장한 Git의 개체는 기본적으로 변경할 수 없다. 하지만 변경된 것처럼 보이게 하는 재밌는 기능이 숨어있어 이를 활용해볼 수 있다.
+히스토리(혹은 데이터베이스)에 일단 저장한 Git의 개체는 기본적으로 변경할 수 없다. 하지만 변경된 것처럼 보이게 하는 재밌는 기능이 숨어있다.
 
 ////////////////////
 The `replace` command lets you specify an object in Git and say "every time you see this, pretend it's this other thing". This is most commonly useful for replacing one commit in your history with another one.
@@ -254,4 +254,4 @@ c6e1e95051d41771a649f3145423f8809d1a74d4 commit	refs/replace/81a708dd0e167a3f691
 ////////////////////
 This means that it's easy to share our replacement with others, because we can push this to our server and other people can easily download it.  This is not that helpful in the history grafting scenario we've gone over here (since everyone would be downloading both histories anyhow, so why seperate them?) but it can be useful in other circumstances.
 ////////////////////
-Replace 내용을 레퍼런스로 관리한다는 말은 손쉽게 이 내용을 서버로 Push 하여 다른 팀원과 공유할 수 있다는 것을 말한다. 위에서 살펴본 예제에서는 이렇게 Replace 내용을 공유하는 것이 유용하진 않지만(모든 팀원이 전체 히스토리를 가질 필요는 없는 경우) 다른 어떤 경우에는 Replace 내용을 공유하는 것이 유용할 수도 있다.
+Replace 내용을 레퍼런스로 관리한다는 말은 손쉽게 이 내용을 서버로 Push 하여 다른 팀원과 공유할 수 있다는 것을 뜻한다. 위에서 살펴본 예제에서는 이렇게 Replace 내용을 공유하는 것이 유용하진 않지만(모든 팀원이 전체 히스토리를 가질 필요는 없는 경우) 다른 어떤 경우에는 Replace 내용을 공유하는 것이 유용할 수도 있다.

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

@@ -282,7 +282,7 @@ end
 We saw an example of this in <<_advanced_merging>>.
 For now though, let's re-resolve it by just running `rerere` again:
 ///////////////////
-<<_advanced_merging>>에서 이러한 명령을 사용하는 예제를 살펴본다.
+<<_advanced_merging>>에서 이러한 명령을 사용하는 예제를 본 적이 있다.
 이 때에 `rerere` 명령을 실행하면 충돌이 발생한 코드를 자동으로 다시 해결한다.
 
 [source,console]

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

@@ -296,8 +296,8 @@ When you run `git commit`, Git creates a new commit and moves the branch that HE
 When you `reset` back to `HEAD~` (the parent of HEAD), you are moving the branch back to where it was, without changing the Index or Working Directory.
 You could now update the Index and run `git commit` again to accomplish what `git commit --amend` would have done (see <<_git_amend>>).
 //////////////////////////
-이제 위의 다이어그램을 보고 어떤 일이 일어날지 생각해보자. `reset` 명령은 가장 최근의 `git commit`명령을 되돌린다.
-`git commit` 명령을 실행하면 Git은 새로운 커밋을 생성하고 HEAD가 가리키고 있는 브랜치가 새로운 커밋을 가리키도록 업데이트한다.
+이제 위의 다이어그램을 보고 어떤 일이 일어난건지 생각해보자. `reset` 명령은 가장 최근의 `git commit`명령을 되돌렸다.
+이제 `git commit` 명령을 실행하면 Git은 새로운 커밋을 생성하고 HEAD가 가리키고 있는 브랜치가 새로운 커밋을 가리키도록 업데이트한다.
 `reset` 명령 뒤에 `HEAD~`(HEAD의 부모 커밋)를 주면 인덱스나 워킹 디렉토리는 그대로 놔두고 브랜치가 가리키는 커밋만 이전으로 되돌린다.
 인덱스를 업데이트한 다음에 `git commit` 명령를 실행하면 `git commit --amend`와 같은 것이다(<<_git_amend>>를 참조).
 
@@ -534,7 +534,7 @@ Actually, it's a bit smarter than that – it tries to do a trivial merge in the
 //////////////////////////
 첫 번째로 `reset --hard` 명령과는 달리 `checkout` 명령은 워킹 디렉토리를 안전하게 다룬다. 저장하지 않은 변경점이 있는지 확인하여 날려버리지 않는다는 것을 보장한다.
 사실 보기보다 좀 더 똑똑하게 동작하는데 워킹 디렉토리에서 Merge 작업을 한번 시도해보고 변경하지 않은 파일만 업데이트 한다.
-반면 `reset --hard` 명령은 간단히 확인하지 않고 모든 것을 바꿔버린다.
+반면 `reset --hard` 명령은 확인하지 않고 단순히 모든 것을 바꿔버린다.
 
 //////////////////////////
 The second important difference is how it updates HEAD.

book/07-git-tools/sections/revision-selection.asc

@@ -19,7 +19,8 @@ They aren’t necessarily obvious but are helpful to know.
 You can obviously refer to a commit by the SHA-1 hash that it’s given, but there are more human-friendly ways to refer to commits as well.
 This section outlines the various ways you can refer to a single commit.
 //////////////////////////
-사람은 커밋을 나타내는 SHA-1 해시 값을 쉽게 기억할 수 없다. 이 절에서는 커밋을 표현하는 방법을 몇 가지 설명하며 사람이 알기 쉬운 방법도 포함하고 있다.
+SHA-1 해시 값만 있으면 커밋을 기억할 수 있지만 사람이 더 사용하기 좋은 방법도 많다.
+이 절에서는 커밋을 표현하는 방법을 몇 가지 설명한다.
 
 //////////////////////////
 ==== Short SHA
@@ -155,7 +156,7 @@ You can see <<_git_internals>> for more information about plumbing tools; basica
 However, it can be helpful sometimes when you need to see what’s really going on.
 Here you can run `rev-parse` on your branch.
 //////////////////////////
-브랜치가 가리키는 개체의 SHA-1 값에 대한 궁금증은 `rev-parse`이라는 Plumbing 도구가 해결해 준다. <<_git_internals>>에서 이 뚫어뻥에 대해 좀 더 자세히 설명한다. 기본적으로 `rev-parse`은 저수준 명령이기 때문에 평소에는 전혀 필요하지 않지만 그래도 한번 사용해보고 어떤 결과가 나오는지 알아 두자.
+브랜치가 가리키는 개체의 SHA-1 값에 대한 궁금증은 `rev-parse`이라는 Plumbing 도구가 해결해 준다. 이 도구에 대해서는 <<_git_internals>>에서 자세히 설명한다. 기본적으로 `rev-parse`은 저수준 명령이기 때문에 평소에는 전혀 필요하지 않지만 그래도 한번 사용해보고 어떤 결과가 나오는지 알아 두자.
 
 [source,console]
 ----
@@ -441,7 +442,7 @@ The double-dot syntax is useful as a shorthand; but perhaps you want to specify
 Git allows you to do this by using either the `^` character or `--not` before any reference from which you don’t want to see reachable commits.
 Thus these three commands are equivalent:
 //////////////////////////
-Double Dot은 간단하고 유용하지만 두 개 이상의 브랜치에는 사용할 수 없다. 그러니까 현재 작업 중인 브랜치에는 있지만 다른 여러 브랜치에는 없는 커밋을 보고 싶으면 `..`으로는 확인할 수 없다. `^`과 `--not` 옵션 뒤에 브랜치 이름을 넣으면 그 브랜치에 없는 커밋을 찾아준다. 다음 명령 세 가지는 모두 같은 명령이다.
+Double Dot은 간단하고 유용하지만 두 개 이상의 브랜치에는 사용할 수 없다. 그러니까 현재 작업 중인 브랜치에는 있지만 다른 여러 브랜치에는 없는 커밋을 보고 싶으면 `..`으로는 확인할 수 없다. `^`이나 `--not` 옵션 뒤에 브랜치 이름을 넣으면 그 브랜치에 없는 커밋을 찾아준다. 다음 명령 세 가지는 모두 같은 명령이다.
 
 [source,console]
 ----