경축 100%

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

@@ -275,7 +275,7 @@ M  lib/simplegit.rb
 //////////////////////////
 New files that aren't tracked have a `??` next to them, new files that have been added to the staging area have an `A`, modified files have an `M` and so on. There are two columns to the output - the left hand column indicates that the file is staged and the right hand column indicates that it's modified.  So for example in that output, the `README` file is modified in the working directory but not yet staged, while the `lib/simplegit.rb` file is modified and staged. The `Rakefile` was modified, staged and then modified again, so there are changes to it that are both staged and unstaged.
 //////////////////////////
-아직 추적하지 않는 새 파일 앞에는 `??`표시가 붙는다. Staged 상태로 추가한 파일 중 새로 생성한 파일 앞에는 `A` 표시가, 수정한 파일 앞에는 `M` 표시가 붙는다. 위 명령의 결과는 한 줄에 두 가지 정보를 보여준다. 왼쪽에는 파일 변경 내용이 어떤 것인지를, 오른쪽에는 해당하는 파일의 이름을 표시한다. `README` 파일 같은 경우 내용을 변경했지만 아직 Stage 상태로 추가하지는 않았다. `lib/simplegit.rb` 파일은 내용을 변경하고 Stage 상태로 추가까지 한 상태이다. 위 결과에서 차이점을 비교해보자. `Rakefile`은 변경하고 Stage 상태로 추가한 후 또 내용을 변경해서 Staged 이면서 Unstaged 상태인 파일이다.
+아직 추적하지 않는 새 파일 앞에는 `??`표시가 붙는다. Staged 상태로 추가한 파일 중 새로 생성한 파일 앞에는 `A` 표시가, 수정한 파일 앞에는 `M` 표시가 붙는다. 위 명령의 결과는 한 라인에 두 가지 정보를 보여준다. 왼쪽에는 파일 변경 내용이 어떤 것인지를, 오른쪽에는 해당하는 파일의 이름을 표시한다. `README` 파일 같은 경우 내용을 변경했지만 아직 Stage 상태로 추가하지는 않았다. `lib/simplegit.rb` 파일은 내용을 변경하고 Stage 상태로 추가까지 한 상태이다. 위 결과에서 차이점을 비교해보자. `Rakefile`은 변경하고 Stage 상태로 추가한 후 또 내용을 변경해서 Staged 이면서 Unstaged 상태인 파일이다.
 
 [[_ignoring]]
 //////////////////////////
@@ -307,7 +307,7 @@ The second line tells Git to ignore all files that end with a tilde (`~`), which
 You may also include a log, tmp, or pid directory; automatically generated documentation; and so on.
 Setting up a `.gitignore` file before you get going is generally a good idea so you don't accidentally commit files that you really don't want in your Git repository.
 //////////////////////////
-첫번째 줄은 확장자가 ``.o'' 나 ``.a'' 인 파일을 Git이 무시하라는 것이고 둘째 줄은 `~`로 끝나는 모든 파일을 무시하라는 것이다.
+첫번째 라인은 확장자가 ``.o'' 나 ``.a'' 인 파일을 Git이 무시하라는 것이고 둘째 라인은 `~`로 끝나는 모든 파일을 무시하라는 것이다.
 ``.o'' 와 ``.a'' 는 각각 빌드 시스템이 만들어내는 오브젝트와 아카이브 파일이고 `~`로 끝나는 파일은 Emacs나 VI 같은 텍스트 편집기가 임시로 만들어내는 파일이다.
 또 log, tmp, pid 같은 디렉토리나, 자동으로 생성하는 문서 같은 것들도 추가할 수 있다.
 `.gitignore` 파일은 보통 처음에 만들어 두는 것이 편리하다. 그래서 Git 저장소에 커밋하고 싶지 않은 파일을 실수로 커밋하는 일을 방지할 수 있다.
@@ -323,7 +323,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 패턴을 사용한다.
 *  디렉토리는 슬래시(`/`)를 끝에 사용하는 것으로 표현한다.
 *  느낌표(`!`)로 시작하는 패턴의 파일은 무시하지 않는다.
@@ -340,7 +340,7 @@ Glob 패턴은 정규표현식을 단순하게 만든 것으로 생각하면 되
 //////////////////////////
 Here is another example .gitignore file:
 //////////////////////////
-다음은 .gitignore 파일의 예이다.
+아래는 .gitignore 파일의 예이다.
 
 [source]
 //////////////////////////
@@ -368,7 +368,7 @@ doc/**/*.txt
 # 확장자가 .a인 파일 무시
 *.a
 
-# 윗 줄에서 확장자가 .a인 파일은 무시하게 했지만 lib.a는 무시하지 않음
+# 윗 라인에서 확장자가 .a인 파일은 무시하게 했지만 lib.a는 무시하지 않음
 !lib.a
 
 # 루트 디렉토리에 있는 TODO파일은 무시하고 subdir/TODO처럼 하위디렉토리에 있는 파일은 무시하지 않음
@@ -635,7 +635,7 @@ You can remove these comments and type your commit message, or you can leave the
 Doing so also puts the diff of your change in the editor so you can see exactly what changes you're committing.)
 When you exit the editor, Git creates your commit with that commit message (with the comments and diff stripped out).
 //////////////////////////
-자동으로 생성되는 커밋 메시지의 첫 줄은 비어 있고 둘째 줄부터 `git status` 명령의 결과가 채워진다.
+자동으로 생성되는 커밋 메시지의 첫 라인은 비어 있고 둘째 라인부터 `git status` 명령의 결과가 채워진다.
 커밋한 내용을 쉽게 기억할 수 있도록 이 메시지를 포함할 수도 있고 메시지를 전부 지우고 새로 작성할 수 있다
 (정확히 뭘 수정했는지도 보여줄 수 있는데,
 `git commit`에 -v 옵션을 추가하면 편집기에 diff 메시지도 추가된다).
@@ -659,7 +659,7 @@ Now you've created your first commit!
 You can see that the commit has given you some output about itself: which branch you committed to (`master`), what SHA-1 checksum the commit has (`463dc4f`), how many files were changed, and statistics about lines added and removed in the commit.
 //////////////////////////
 이렇게 첫번째 커밋을 작성해보았다.
-`commit` 명령은 몇 가지 정보를 출력하는데 위 예제는 (`master`) 브랜치에 커밋했고 체크섬은 (`463dc4f`)이라고 알려준다. 그리고 수정한 파일이 몇 개이고 삭제됐거나 추가된 줄이 몇 줄인지 알려준다.
+`commit` 명령은 몇 가지 정보를 출력하는데 위 예제는 (`master`) 브랜치에 커밋했고 체크섬은 (`463dc4f`)이라고 알려준다. 그리고 수정한 파일이 몇 개이고 삭제됐거나 추가된 라인이 몇 라인인지 알려준다.
 
 //////////////////////////
 Remember that the commit records the snapshot you set up in your staging area.
@@ -762,7 +762,7 @@ If you modified the file and added it to the index already, you must force the r
 This is a safety feature to prevent accidental removal of data that hasn't yet been recorded in a snapshot and that can't be recovered from Git.
 //////////////////////////
 커밋하면 파일은 삭제되고 Git은 이 파일을 더는 추적하지 않는다.
-이미 파일을 수정했거나 Index에(역주, Staging Area을 Git Index라고도 부른다) 추가했다면 `-f`옵션을 주어 강제로 삭제해야 한다.
+이미 파일을 수정했거나 Index에(역주 - Staging Area을 Git Index라고도 부른다) 추가했다면 `-f`옵션을 주어 강제로 삭제해야 한다.
 이 점은 실수로 데이터를 삭제하지 못하도록 하는 안전장치다. 한 번도 커밋한적 없는 데이터는 Git으로 복구할 수 없다.
 
 //////////////////////////

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

@@ -64,7 +64,7 @@ If you have more than one remote, the command lists them all.
 For example, a repository with multiple remotes for working with several collaborators might look something like this.
 //////////////////////////
 리모트 저장소가 여러 개 있다면 이 명령은 등록된 전부를 보여준다.
-프로젝트를 여러 사람과 함께 작업하여 등록시킨 리모트 저장소가 여러개라면 다음과 같은 결과를 얻을 수도 있다.
+프로젝트를 여러 사람과 함께 작업하여 등록시킨 리모트 저장소가 여러개라면 아래와 같은 결과를 얻을 수도 있다.
 
 [source,console]
 ----
@@ -195,7 +195,7 @@ When you have your project at a point that you want to share, you have to push i
 The command for this is simple: `git push [remote-name] [branch-name]`.(((git commands, push)))
 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:
 //////////////////////////
-프로젝트를 공유하고 싶을 때 리모트 저장소에 Push 할 수 있다.
+프로젝트를 공유하고 싶을 때 Upstream 저장소에 Push 할 수 있다.
 이 명령은 `git push [리모트 저장소 이름] [브랜치 이름]`으로 단순하다.(((git commands, push)))
 master 브랜치를 `origin` 서버에 Push 하려면(다시 말하지만 Clone 하면 보통 자동으로 origin 이름이 생성된다) 아래와 같이 서버에 Push 한다.
 
@@ -210,7 +210,7 @@ If you and someone else clone at the same time and they push upstream and then y
 You'll have to pull down their work first and incorporate it into yours before you'll be allowed to push.
 See <<_git_branching>> for more detailed information on how to push to remote servers.
 //////////////////////////
-이 명령은 Clone 한 리모트 저장소에 쓰기 권한이 있고, Clone 하고 난 이후 아무도 리모트 저장소에 Push 하지 않았을 때만 사용할 수 있다.
+이 명령은 Clone 한 리모트 저장소에 쓰기 권한이 있고, Clone 하고 난 이후 아무도 Upstream 저장소에 Push 하지 않았을 때만 사용할 수 있다.
 다시 말해서 Clone 한 사람이 여러 명 있을 때, 다른 사람이 Push 한 후에 Push 하려고 하면 Push 할 수 없다.
 먼저 다른 사람이 작업한 것을 가져와서 Merge 한 후에 Push 할 수 있다.
 <<_git_branching>> 에서 서버에 Push 하는 방법에 대해 자세히 설명할 것이다.
@@ -258,7 +258,7 @@ That is a simple example you're likely to encounter.
 When you're using Git more heavily, however, you may see much more information from `git remote show`:
 //////////////////////////
 좀 더 Git을 열심히 사용하게 되면 `git remote show` 명령은 더 많은 정보를 보여줄 것이다.
-여러분도 언젠가는 아래와 같은 메시지(역주, 다수의 브랜치를 사용하는 메시지)를 볼 날이 올 것이다.
+여러분도 언젠가는 아래와 같은 메시지(역주 - 다수의 브랜치를 사용하는 메시지)를 볼 날이 올 것이다.
 
 [source,console]
 ----

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

@@ -315,7 +315,7 @@ You can't really check out a tag in Git, since they can't be moved around.
 If you want to put a version of your repository in your working directory that looks like a specific tag, you can create a new branch at a specific tag:
 //////////////////////////
 태그는 브랜치와는 달리 가리키는 커밋을 바꿀 수 없는 이름이기 때문에 Checkout 해서 사용할 수 없다.
-태그가 가리키는 특정 커밋 기반의 브랜치를 만들어 작업하려면 다음과 같이 새로 브랜치를 생성한다.
+태그가 가리키는 특정 커밋 기반의 브랜치를 만들어 작업하려면 아래와 같이 새로 브랜치를 생성한다.
 
 [source,console]
 ----

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

@@ -164,7 +164,7 @@ Date:   Sat Mar 15 10:31:28 2008 -0700
 As you can see, the `--stat` option prints below each commit entry a list of modified files, how many files were changed, and how many lines in those files were added and removed.
 It also puts a summary of the information at the end.
 //////////////////////////
-이 결과에서 `--stat` 옵션은 어떤 파일이 수정됐는지, 얼마나 많은 파일이 변경됐는지, 또 얼마나 많은 줄을 추가하거나 삭제했는지 보여준다.
+이 결과에서 `--stat` 옵션은 어떤 파일이 수정됐는지, 얼마나 많은 파일이 변경됐는지, 또 얼마나 많은 라인을 추가하거나 삭제했는지 보여준다.
 요약정보는 가장 뒤쪽에 보여준다.
 
 //////////////////////////
@@ -177,7 +177,7 @@ In addition, the `short`, `full`, and `fuller` options show the output in roughl
 다른 또 유용한 옵션은 `--pretty` 옵션이다.
 이 옵션을 통해 히스토리 내용을 보여줄 때 기본 형식 이외에 여러 가지 중에 하나를 선택할 수 있다.
 몇개 선택할 수 있는 옵션의 값이 있다.
-`oneline` 옵션은 각 커밋을 한 줄로 보여준다. 이 옵션은 많은 커밋을 한 번에 조회할 때 유용하다.
+`oneline` 옵션은 각 커밋을 한 라인으로 보여준다. 이 옵션은 많은 커밋을 한 번에 조회할 때 유용하다.
 추가로 `short`, `full`, `fuller` 옵션도 있는데 이것은 정보를 조금씩 가감해서 보여준다.
 
 [source,console]
@@ -288,7 +288,7 @@ $ git log --pretty=format:"%h %s" --graph
 //////////////////////////
 This type of output will become more interesting as we go through branching and merging in the next chapter.
 //////////////////////////
-다음장에서 살펴볼 브랜치나 Merge 결과를 히스토리를 이런 식으로 살펴보면 훨씬 흥미롭게 볼 수 있다.
+다음 장에서 살펴볼 브랜치나 Merge 결과를 히스토리를 이런 식으로 살펴보면 훨씬 흥미롭게 볼 수 있다.
 
 //////////////////////////
 Those are only some simple output-formatting options to `git log` – there are many more.
@@ -320,7 +320,7 @@ Those are only some simple output-formatting options to `git log` – there are
 | 옵션               | 설명
 | `-p`              | 각 커밋에 적용된 패치를 보여준다.
 | `--stat`          | 각 커밋에서 수정된 파일의 통계정보를 보여준다.
-| `--shortstat`     | `--stat` 명령의 결과 중에서 수정한 파일, 추가된 줄, 삭제된 줄만 보여준다.
+| `--shortstat`     | `--stat` 명령의 결과 중에서 수정한 파일, 추가된 라인, 삭제된 라인만 보여준다.
 | `--name-only`     | 커밋 정보중에서 수정된 파일의 목록만 보여준다.
 | `--name-status`   | 수정된 파일의 목록을 보여줄 뿐만 아니라 파일을 추가한 것인지, 수정한 것인지, 삭제한 것인지도 보여준다.
 | `--abbrev-commit` | 40자 짜리 SHA-1 체크섬을 전부 보여주는 것이 아니라 처음 몇 자만 보여준다.
@@ -374,7 +374,7 @@ The `--author` option allows you to filter on a specific author, and the `--grep
 //////////////////////////
 Another really helpful filter is the `-S` option which takes a string and only shows the commits that introduced a change to the code that added or removed that string.  For instance, if you wanted to find the last commit that added or removed a reference to a specific function, you could call:
 //////////////////////////
-진짜 유용한 옵션으로 `-S`가 있는데 이 옵션은 코드에서 추가되거나 제거된 내용 중에 특정 텍스트가 포함되어 있는지를 검색한다. 예를 들어 어떤 함수가 추가되거나 제거된 커밋만을 찾아보려 한다면 다음과 같은 명령을 사용한다.
+진짜 유용한 옵션으로 `-S`가 있는데 이 옵션은 코드에서 추가되거나 제거된 내용 중에 특정 텍스트가 포함되어 있는지를 검색한다. 예를 들어 어떤 함수가 추가되거나 제거된 커밋만을 찾아보려 한다면 아래와 같은 명령을 사용한다.
 
 [source,console]
 ----
@@ -388,7 +388,7 @@ This is always the last option and is generally preceded by double dashes (`--`)
 //////////////////////////
 마지막으로 파일 경로로 검색하는 옵션이 있는데 이것도 정말 유용하다.
 디렉토리나 파일 이름을 사용하여 그 파일이 변경된 log의 결과를 검색할 수 있다.
-이 옵션은 `--`와 함께 경로 이름을 사용하는데 명령어 끝 부분에 쓴다(역주, `git log -- path1 path2`).
+이 옵션은 `--`와 함께 경로 이름을 사용하는데 명령어 끝 부분에 쓴다(역주 - `git log -- path1 path2`).
 
 //////////////////////////
 In <<limit_options>> we'll list these and a few other common options for your reference.
@@ -426,7 +426,7 @@ In <<limit_options>> we'll list these and a few other common options for your re
 //////////////////////////
 For example, if you want to see which commits modifying test files in the Git source code history were committed by Junio Hamano and were not merges in the month of October 2008, you can run something like this:(((log filtering)))
 //////////////////////////
-다음 살펴볼 예제는 Git 소스코드 저장소에서 2008년 10월에 Junio Hamano가 테스트 파일을 수정한 커밋 중 merge 되지 않은 커밋을 확인해보는 명령이다.(((log filtering)))
+이제 살펴볼 예제는 Git 소스코드 저장소에서 2008년 10월에 Junio Hamano가 테스트 파일을 수정한 커밋 중 merge 되지 않은 커밋을 확인해보는 명령이다.(((log filtering)))
 
 [source,console]
 ----