diff --git a/C-git-commands.asc b/C-git-commands.asc index 73d3666..9a53b88 100644 --- a/C-git-commands.asc +++ b/C-git-commands.asc @@ -83,12 +83,12 @@ The `git help` command is used to show you all the documentation shipped with Gi While we're giving a rough overview of most of the more popular ones in this appendix, for a full listing of all of the possible options and flags for every command, you can always run `git help `. ////////////////////////// `git help` 명령은 Git에 포함된 문서를 보여준다. -이 장에서는 많이 사용하는 것만 간단히 설명한다. `git help `라고 실행하면 해당 명령어에 어떤 옵션이 있고 어떻게 사용하는지 알려준다. +이 장에서는 많이 사용하는 것만 간단히 설명한다. `git help ` 라고 실행하면 해당 명령어에 어떤 옵션이 있고 어떻게 사용하는지 알려준다. ////////////////////////// We introduced the `git help` command in <> and showed you how to use it to find more information about the `git shell` in <>. ////////////////////////// -`git help` 명령은 <>에 소개한다. `git shell`을 서버에 설정하는 방법은 <>에서 보여준다. +`git help` 명령은 <>에 소개한다. `git shell` 을 서버에 설정하는 방법은 <>에서 보여준다. ////////////////////////// @@ -108,7 +108,7 @@ Git 저장소는 두 가지 방법으로 만든다. ////////////////////////// To take a directory and turn it into a new Git repository so you can start version controlling it, you can simply run `git init`. ////////////////////////// -프로젝트 디렉토리로 가서 `git init`이라고 실행한다. 디렉토리에 Git 저장소가 새로 만들어지고 프로젝트를 버전 관리할 수 있다. +프로젝트 디렉토리로 가서 `git init` 이라고 실행한다. 디렉토리에 Git 저장소가 새로 만들어지고 프로젝트를 버전 관리할 수 있다. ////////////////////////// We first introduce this in <>, where we show creating a brand new repository to start working with. @@ -197,7 +197,7 @@ We'll quickly cover some of the unique uses that can be found. ////////////////////////// We first introduce and explain `git add` in detail in <>. ////////////////////////// -`git add`는 <>에서 자세히 설명한다. +`git add` 는 <>에서 자세히 설명한다. ////////////////////////// We mention how to use it to resolve merge conflicts in <>. @@ -243,7 +243,7 @@ This could be the difference between your working environment and your staging a ////////////////////////// We first look at the basic uses of `git diff` in <>, where we show how to see what changes are staged and which are not yet staged. ////////////////////////// -`git diff`는 <>에서 처음 설명한다. Staged 상태인 내용이 무엇이고 반대 상태인 내용은 무엇인지 비교하는 법을 설명한다. +`git diff` 는 <>에서 처음 설명한다. Staged 상태인 내용이 무엇이고 반대 상태인 내용은 무엇인지 비교하는 법을 설명한다. ////////////////////////// We use it to look for possible whitespace issues before committing with the `--check` option in <>. @@ -270,7 +270,7 @@ Finally, we use it to effectively compare submodule changes with `--submodule` i ////////////////////////// The `git difftool` command simply launches an external tool to show you the difference between two trees in case you want to use something other than the built in `git diff` command. ////////////////////////// -`git difftool` 명령은 단순히 외부 diff 도구를 실행해준다. `git diff`는 Git에 들어 있는 기능을 사용하는 것이고 외부 diff 도구로 두 트리를 비교하고 싶을 때 사용한다. +`git difftool` 명령은 단순히 외부 diff 도구를 실행해준다. `git diff` 는 Git에 들어 있는 기능을 사용하는 것이고 외부 diff 도구로 두 트리를 비교하고 싶을 때 사용한다. ////////////////////////// We only briefly mention this in <>. @@ -282,14 +282,14 @@ We only briefly mention this in <>. ////////////////////////// The `git commit` command takes all the file contents that have been staged with `git add` and records a new permanent snapshot in the database and then moves the branch pointer on the current branch up to it. ////////////////////////// -`git commit` 명령은 `git add`로 Staging Area에 넣은 모든 파일을 커밋한다. 데이터베이스에는 하나의 스냅샷으로 기록된다. 그리고 현 브랜치가 새 커밋을 가리키게 한다. +`git commit` 명령은 `git add` 로 Staging Area에 넣은 모든 파일을 커밋한다. 데이터베이스에는 하나의 스냅샷으로 기록된다. 그리고 현 브랜치가 새 커밋을 가리키게 한다. ////////////////////////// We first cover the basics of committing in <>. There we also demonstrate how to use the `-a` flag to skip the `git add` step in daily workflows and how to use the `-m` flag to pass a commit message in on the command line instead of firing up an editor. ////////////////////////// 커밋에 대한 기본적인 내용은 <>에서 다룬다. -`-a` 플래그를 주고 `git add`를 건너뛰고 바로 커밋하는 것과 `-m`으로 커밋 메시지를 파라미터로 넘기는 방법도 보여준다. +`-a` 플래그를 주고 `git add` 를 건너뛰고 바로 커밋하는 것과 `-m` 으로 커밋 메시지를 파라미터로 넘기는 방법도 보여준다. ////////////////////////// In <> we cover using the `--amend` option to redo the most recent commit. @@ -299,7 +299,7 @@ In <> we cover using the `--amend` option to r ////////////////////////// In <>, we go into much more detail about what `git commit` does and why it does it like that. ////////////////////////// -<>을 보면 `git commit`이 무엇을 하는지 왜 그렇게 하는지 설명한다. +<>을 보면 `git commit` 이 무엇을 하는지 왜 그렇게 하는지 설명한다. ////////////////////////// We looked at how to sign commits cryptographically with the `-S` flag in <>. @@ -325,7 +325,7 @@ This final option makes it possible for this command to lose your work if used i ////////////////////////// We first effectively cover the simplest use of `git reset` in <>, where we use it to unstage a file we had run `git add` on. ////////////////////////// -`git reset`은 무엇보다도 `git add`로 추가한 파일을 Unstage 하는데 사용한다. <>에서 설명한다. +`git reset` 은 무엇보다도 `git add` 로 추가한 파일을 Unstage 하는데 사용한다. <>에서 설명한다. ////////////////////////// We then cover it in quite some detail in <>, which is entirely devoted to explaining this command. @@ -363,7 +363,7 @@ This can be useful for scripting purposes. ////////////////////////// The `git mv` command is a thin convenience command to move a file and then run `git add` on the new file and `git rm` on the old file. ////////////////////////// -`git mv` 명령은 파일을 옮기고(이름을 변경하고) 나서 새 파일에 `git add` 명령을 실행하고 이전 파일에는 `git rm`을 실행시켜주는 명령이다. +`git mv` 명령은 파일을 옮기고(이름을 변경하고) 나서 새 파일에 `git add` 명령을 실행하고 이전 파일에는 `git rm` 을 실행시켜주는 명령이다. ////////////////////////// We only briefly mention this command in <>. @@ -440,7 +440,7 @@ We see how to use it to start tracking branches with the `--track` flag in <>. ////////////////////////// -<>를 통해 이 명령에 `--conflict=diff3`을 주면 충돌 표시된 파일을 재현할 수 있다. +<>를 통해 이 명령에 `--conflict=diff3` 을 주면 충돌 표시된 파일을 재현할 수 있다. ////////////////////////// We go into closer detail on its relationship with `git reset` in <>. @@ -450,7 +450,7 @@ We go into closer detail on its relationship with `git reset` in <>. ////////////////////////// -마지막으로 `git checkout`이 어떻게 구현됐는지는 <>를 참고한다. +마지막으로 `git checkout` 이 어떻게 구현됐는지는 <>를 참고한다. ==== git merge @@ -458,7 +458,7 @@ Finally, we go into some implementation detail in <>에서 이 명령을 깊게 다뤘다. -`-p`와 `--stat` 옵션을 주면 각 커밋 사이에 생긴 변화를 확인할 수 있다. `--pretty`와 `--oneline` 옵션을 주면 히스토리를 좀 더 깔끔하게 볼 수 있다. 이 옵션은 Author나 날짜를 중심으로 히스토리를 보여준다. +`-p` 와 `--stat` 옵션을 주면 각 커밋 사이에 생긴 변화를 확인할 수 있다. `--pretty` 와 `--oneline` 옵션을 주면 히스토리를 좀 더 깔끔하게 볼 수 있다. 이 옵션은 Author나 날짜를 중심으로 히스토리를 보여준다. ////////////////////////// In <> we use it with the `--decorate` option to easily visualize where our branch pointers are located and we also use the `--graph` option to see what divergent histories look like. @@ -532,7 +532,7 @@ In <> we use it with the `--decorate` opt In <> and <> we cover the `branchA..branchB` syntax to use the `git log` command to see what commits are unique to a branch relative to another branch. In <> we go through this fairly extensively. ////////////////////////// -<>과 <>에서 `branchA..branchB` 문법을 사용하는 방법을 설명한다. `branchB`에만 있고 `branchA`에는 없는 커밋만 걸러서 볼 수 있다. +<>과 <>에서 `branchA..branchB` 문법을 사용하는 방법을 설명한다. `branchB` 에만 있고 `branchA` 에는 없는 커밋만 걸러서 볼 수 있다. <>에서 이 문법을 다양하게 조합하는 방법을 설명한다. ////////////////////////// @@ -550,7 +550,7 @@ In <> we use the `-g` option to view the Git reflog ////////////////////////// In <> we look at using the `-S` and `-L` options to do fairly sophisticated searches for something that happened historically in the code such as seeing the history of a function. ////////////////////////// -<>에서는 `-S`와 `-L` 옵션을 소개한다. 이 옵션을 사용하면 특정 코드에 대한 히스토리만 찾아볼 수 있다. 특정 함수의 히스토리를 보고 싶을 때 사용하면 유용하다. +<>에서는 `-S` 와 `-L` 옵션을 소개한다. 이 옵션을 사용하면 특정 코드에 대한 히스토리만 찾아볼 수 있다. 특정 함수의 히스토리를 보고 싶을 때 사용하면 유용하다. ////////////////////////// In <> we see how to use `--show-signature` to add a validation string to each commit in the `git log` output based on if it was validly signed or not. @@ -677,7 +677,7 @@ In <> we use the `--delete` flag to delete ////////////////////////// Throughout <> we see several examples of using `git push` to share work on branches through multiple remotes. ////////////////////////// -<>에서는 `git push`를 주구장창 사용한다. 리모트를 여러 개 사용해서 브랜치에 작업한 내용을 공유하는 것을 보여준다. +<>에서는 `git push` 를 주구장창 사용한다. 리모트를 여러 개 사용해서 브랜치에 작업한 내용을 공유하는 것을 보여준다. ////////////////////////// We see how to use it to share tags that you have made with the `--tags` option in <>. @@ -777,7 +777,7 @@ Later we use it quite a bit in <> to show th ////////////////////////// One of the more interesting things we do with `git show` is in <> to extract specific file contents of various stages during a merge conflict. ////////////////////////// -Merge 하다가 충돌이 났을 때 특정 버전의 파일 내용을 `git show`로 꺼내 볼 수 있다. <>에서 이 점을 설명한다. +Merge 하다가 충돌이 났을 때 특정 버전의 파일 내용을 `git show` 로 꺼내 볼 수 있다. <>에서 이 점을 설명한다. ==== git shortlog @@ -821,7 +821,7 @@ Git에는 디버깅용 명령어도 있다. ////////////////////////// The `git bisect` tool is an incredibly helpful debugging tool used to find which specific commit was the first one to introduce a bug or problem by doing an automatic binary search. ////////////////////////// -`git bisect`는 굉장히 유용하다. 이진 탐색 알고리즘을 사용해서 버그나 문제가 생긴 커밋을 쉽게 찾을 수 있다. +`git bisect` 는 굉장히 유용하다. 이진 탐색 알고리즘을 사용해서 버그나 문제가 생긴 커밋을 쉽게 찾을 수 있다. ////////////////////////// It is fully covered in <> and is only mentioned in that section. @@ -834,7 +834,7 @@ It is fully covered in <> and is only mentioned i The `git blame` command annotates the lines of any file with which commit was the last one to introduce a change to each line of the file and what person authored that commit. This is helpful in order to find the person to ask for more information about a specific section of your code. ////////////////////////// -`git blame`은 파일의 각 라인을 누가 마지막으로 수정했는지 보여준다. +`git blame` 은 파일의 각 라인을 누가 마지막으로 수정했는지 보여준다. 그래서 특정 코드에 대해 궁금한 게 있을 때 누구에게 물어야 할지 바로 알 수 있다. ////////////////////////// @@ -886,7 +886,7 @@ Cherry picking is described and demonstrated in <>. ////////////////////////// -`git format-patch`로 프로젝트에 기여하는 예제를 <>에서 보여준다. +`git format-patch` 로 프로젝트에 기여하는 예제를 <>에서 보여준다. ==== git imap-send ////////////////////////// The `git imap-send` command uploads a mailbox generated with `git format-patch` into an IMAP drafts folder. ////////////////////////// -`git imap-send` 명령은 `git format-patch`로 생성한 메일을 IMAP drafts 폴더에 넣어준다. +`git imap-send` 명령은 `git format-patch` 로 생성한 메일을 IMAP drafts 폴더에 넣어준다. ////////////////////////// We go through an example of contributing to a project by sending patches with the `git imap-send` tool in <>. @@ -1071,7 +1071,7 @@ If you're administering a Git repository or need to fix something in a big way, ////////////////////////// The `git gc` command runs “garbage collection” on your repository, removing unnecessary files in your database and packing up the remaining files into a more efficient format. ////////////////////////// -`git gc`는 저장소에 필요없는 파일을 삭제하고 남은 파일을 압축하는 “Garbage Collection” 명령이다. +`git gc` 는 저장소에 필요없는 파일을 삭제하고 남은 파일을 압축하는 “Garbage Collection” 명령이다. ////////////////////////// This command normally runs in the background for you, though you can manually run it if you wish. @@ -1085,7 +1085,7 @@ We go over some examples of this in <>. ////////////////////////// The `git fsck` command is used to check the internal database for problems or inconsistencies. ////////////////////////// -`git fsck`는 Git 데이터베이스에 문제가 없는지 검사해준다. +`git fsck` 는 Git 데이터베이스에 문제가 없는지 검사해준다. ////////////////////////// We only quickly use this once in <> to search for dangling objects. @@ -1145,7 +1145,7 @@ The first one we encounter is `ls-remote` in <> which we u ////////////////////////// We use `ls-files` in <>, <> and <> to take a more raw look at what your staging area looks like. ////////////////////////// -<>와 <>, <>에서 사용하는 `ls-files`는 Staging Area의 저수준 모습을 보여준다. +<>와 <>, <>에서 사용하는 `ls-files` 는 Staging Area의 저수준 모습을 보여준다. ////////////////////////// We also mention `rev-parse` in <> to take just about any string and turn it into an object SHA-1. diff --git a/TRANSLATION_NOTES.asc b/TRANSLATION_NOTES.asc index ed85bc3..29e9671 100644 --- a/TRANSLATION_NOTES.asc +++ b/TRANSLATION_NOTES.asc @@ -56,4 +56,4 @@ chapter 2: proofreading === 마무리 -번역이 끝나면 관리자는 `status.json`에 번역이 완료됐음을 표기합니다. 그래야 자동으로 빌드돼 여러 가지 포맷으로 배포되고 사람들에게 얼마나 번역이 진행됐는지 알릴 수 있습니다. +번역이 끝나면 관리자는 `status.json` 에 번역이 완료됐음을 표기합니다. 그래야 자동으로 빌드돼 여러 가지 포맷으로 배포되고 사람들에게 얼마나 번역이 진행됐는지 알릴 수 있습니다. diff --git a/book/01-introduction/sections/first-time-setup.asc b/book/01-introduction/sections/first-time-setup.asc index 0e95b6b..389057b 100644 --- a/book/01-introduction/sections/first-time-setup.asc +++ b/book/01-introduction/sections/first-time-setup.asc @@ -128,7 +128,7 @@ $ git config --global core.editor "'C:/Program Files/Notepad++/notepad++.exe' -m ////////////////////////// If you have a 32-bit editor on a 64-bit system, the program will be installed in `C:\Program Files (x86)`: ////////////////////////// -64비트 Windows 시스템에서 32비트 Notepad++을 설치했다면 `C:\Program Files (x86)`에 설치된다. +64비트 Windows 시스템에서 32비트 Notepad++을 설치했다면 `C:\Program Files (x86)` 에 설치된다. [source,console] ---- diff --git a/book/01-introduction/sections/installing.asc b/book/01-introduction/sections/installing.asc index 5dfd8a3..bfd1eac 100644 --- a/book/01-introduction/sections/installing.asc +++ b/book/01-introduction/sections/installing.asc @@ -37,7 +37,7 @@ If you want to install the basic Git tools on Linux via a binary installer, you If you're on Fedora (or any closely-related RPM-based distribution, such as RHEL or CentOS), you can use `dnf`: ////////////////////////// Linux에서 패키지로 Git을 설치할 때는 보통 각 배포판에서 사용하는 패키지 관리도구를 사용하여 설치한다. -Fedora(또는 비슷하게 RPM 기반 패키지 시스템을 사용하는 RHEL, CentOS)에서는 아래와 같이 `dnf`를 사용 한다. +Fedora(또는 비슷하게 RPM 기반 패키지 시스템을 사용하는 RHEL, CentOS)에서는 아래와 같이 `dnf` 를 사용 한다. [source,console] ---- @@ -47,7 +47,7 @@ $ sudo dnf install git-all ////////////////////////// If you're on a Debian-based distribution, such as Ubuntu, try `apt`: ////////////////////////// -Ubuntu등의 데비안 계열 배포판에서는 `apt`를 사용한다. +Ubuntu등의 데비안 계열 배포판에서는 `apt` 를 사용한다. [source,console] ---- @@ -161,7 +161,7 @@ If you do want to install Git from source, you need to have the following librar For example, if you're on a system that has `dnf` (such as Fedora) or `apt-get` (such as a Debian-based system), you can use one of these commands to install the minimal dependencies for compiling and installing the Git binaries: ////////////////////////// Git을 설치하려면 Git이 의존하고 있는 라이브러리인 autotools, curl, zlib, openssl, expat, libiconv등이 필요하다. -예를 들어 `dnf`을 사용하는 Fedora등의 시스템이나 `apt-get`이 있는 데비안 계열 시스템이면 아래 명령어 중 하나를 실행하여 필요한 패키지를 설치할 수 있다. +예를 들어 `dnf` 을 사용하는 Fedora등의 시스템이나 `apt-get` 이 있는 데비안 계열 시스템이면 아래 명령어 중 하나를 실행하여 필요한 패키지를 설치할 수 있다. [source,console] ---- diff --git a/book/02-git-basics/sections/getting-a-repository.asc b/book/02-git-basics/sections/getting-a-repository.asc index 0c4e5a6..6308d89 100644 --- a/book/02-git-basics/sections/getting-a-repository.asc +++ b/book/02-git-basics/sections/getting-a-repository.asc @@ -143,7 +143,7 @@ If you go into the new `libgit2` directory that was just created, you'll see the ////////////////////////// If you want to clone the repository into a directory named something other than `libgit2`, you can specify the new directory name as an additional argument: ////////////////////////// -아래과 같은 명령을 사용하여 저장소를 Clone 하면 `libgit2`이 아니라 다른 디렉토리 이름으로 Clone 할 수 있다. +아래과 같은 명령을 사용하여 저장소를 Clone 하면 `libgit2` 이 아니라 다른 디렉토리 이름으로 Clone 할 수 있다. [source,console] ---- diff --git a/book/02-git-basics/sections/recording-changes.asc b/book/02-git-basics/sections/recording-changes.asc index 1ee85b6..d2d5616 100644 --- a/book/02-git-basics/sections/recording-changes.asc +++ b/book/02-git-basics/sections/recording-changes.asc @@ -350,7 +350,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 패턴을 사용한다. 이는 프로젝트 전체에 적용된다. * 슬래시(`/`)로 시작하면 하위 디렉토리에 적용되지(Recursivity) 않는다. * 디렉토리는 슬래시(`/`)를 끝에 사용하는 것으로 표현한다. @@ -430,7 +430,7 @@ However, it is also possible to have additional `.gitignore` files in subdirecto The rules in these nested `.gitignore` files apply only to the files under the directory where they are located. (The Linux kernel source repository has 206 `.gitignore` files.) ////////////////////////// -`.gitignore`를 사용하는 간단한 방식은 하나의 `.gitignore` 파일을 최상위 디렉토리에 하나 두고 모든 하위 디렉토리에까지 적용시키는 방식이다. +`.gitignore` 를 사용하는 간단한 방식은 하나의 `.gitignore` 파일을 최상위 디렉토리에 하나 두고 모든 하위 디렉토리에까지 적용시키는 방식이다. 물론 `.gitignore` 파일을 하나만 두는 것이 아니라 하위 디렉토리에도 추가로 둘 수도 있다. `.gitignore` 정책은 현재 `.gitignore` 파일이 위치한 디렉토리와 그 하위 디렉토리에 적용된다. (리눅스 커널 소스 저장소에는 `.gitignore` 파일이 206개나 있음) @@ -439,7 +439,7 @@ The rules in these nested `.gitignore` files apply only to the files under the d ////////////////////////// It is beyond the scope of this book to get into the details of multiple `.gitignore` files; see `man gitignore` for the details. ////////////////////////// -다수의 `.gitignore` 파일을 두고 정책을 적용하는 부분은 이 책에서 다루는 범위를 벗어난다. 자세한 내용은 `man gitignore`에서 확인할 수 있다. +다수의 `.gitignore` 파일을 두고 정책을 적용하는 부분은 이 책에서 다루는 범위를 벗어난다. 자세한 내용은 `man gitignore` 에서 확인할 수 있다. ==== [[_git_diff_staged]] diff --git a/book/02-git-basics/sections/remotes.asc b/book/02-git-basics/sections/remotes.asc index e8a9ebd..0497385 100644 --- a/book/02-git-basics/sections/remotes.asc +++ b/book/02-git-basics/sections/remotes.asc @@ -47,7 +47,7 @@ If you've cloned your repository, you should at least see `origin` -- that is th ////////////////////////// `git remote` 명령으로 현재 프로젝트에 등록된 리모트 저장소를 확인할 수 있다.(((git commands, remote))) 이 명령은 리모트 저장소의 단축 이름을 보여준다. -저장소를 Clone 하면 `origin`이라는 리모트 저장소가 자동으로 등록되기 때문에 `origin`이라는 이름을 볼 수 있다. +저장소를 Clone 하면 `origin` 이라는 리모트 저장소가 자동으로 등록되기 때문에 `origin` 이라는 이름을 볼 수 있다. [source,console] ---- @@ -216,7 +216,7 @@ The command for this is simple: `git push `.(((git commands, pu 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: ////////////////////////// 프로젝트를 공유하고 싶을 때 Upstream 저장소에 Push 할 수 있다. -이 명령은 `git push <리모트 저장소 이름> <브랜치 이름>`으로 단순하다.(((git commands, push))) +이 명령은 `git push <리모트 저장소 이름> <브랜치 이름>` 으로 단순하다.(((git commands, push))) master 브랜치를 `origin` 서버에 Push 하려면(다시 말하지만 Clone 하면 보통 자동으로 origin 이름이 생성된다) 아래와 같이 서버에 Push 한다. [source,console] diff --git a/book/02-git-basics/sections/tagging.asc b/book/02-git-basics/sections/tagging.asc index a627aa6..9627834 100644 --- a/book/02-git-basics/sections/tagging.asc +++ b/book/02-git-basics/sections/tagging.asc @@ -23,7 +23,7 @@ In this section, you'll learn how to list the available tags, how to create new Listing the available tags in Git is straightforward. Just type `git tag` (with optional `-l` or `--list`):(((git commands, tag))) ////////////////////////// -우선 `git tag` 명령으로 (`-l`, `--list`는 옵션) +우선 `git tag` 명령으로 (`-l`, `--list` 는 옵션) 이미 만들어진 태그가 있는지 확인할 수 있다.(((git commands, tag))) [source,console] @@ -285,7 +285,7 @@ This process is just like sharing remote branches -- you can run `git push origi ////////////////////////// `git push` 명령은 자동으로 리모트 서버에 태그를 전송하지 않는다.(((git commands, push))) 태그를 만들었으면 서버에 별도로 Push 해야 한다. -브랜치를 공유하는 것과 같은 방법으로 할 수 있다. `git push origin <태그 이름>`을 실행한다. +브랜치를 공유하는 것과 같은 방법으로 할 수 있다. `git push origin <태그 이름>` 을 실행한다. [source,console] ---- diff --git a/book/02-git-basics/sections/viewing-history.asc b/book/02-git-basics/sections/viewing-history.asc index 804fc4f..1babf91 100644 --- a/book/02-git-basics/sections/viewing-history.asc +++ b/book/02-git-basics/sections/viewing-history.asc @@ -69,7 +69,7 @@ One of the more helpful options is `-p` or `--patch`, which shows the difference You can also limit the number of log entries displayed, such as using `-2` to show only the last two entries. ////////////////////////// 여러 옵션 중 `-p`, `--patch` 는 굉장히 유용한 옵션이다. `-p` 는 각 커밋의 diff 결과를 보여준다. -다른 유용한 옵션으로 `-2`가 있는데 최근 두 개의 결과만 보여주는 옵션이다: +다른 유용한 옵션으로 `-2` 가 있는데 최근 두 개의 결과만 보여주는 옵션이다: [source,console] ---- @@ -347,7 +347,7 @@ In reality, you're unlikely to use that often, because Git by default pipes all ////////////////////////// 출력 형식과 관련된 옵션을 살펴봤지만 `git log` 명령은 조회 범위를 제한하는 옵션들도 있다. 히스토리 전부가 아니라 부분만 조회한다. 이미 최근 두 개만 조회하는 `-2` 옵션은 살펴봤다. -실제 사용법은 `-`이고 n은 최근 n개의 커밋을 의미한다. +실제 사용법은 `-` 이고 n은 최근 n개의 커밋을 의미한다. 사실 이 옵션을 자주 쓰진 않는다. Git은 기본적으로 출력을 pager류의 프로그램을 거쳐서 내보내므로 한 번에 한 페이지씩 보여준다. ////////////////////////// @@ -382,7 +382,7 @@ will limit the commit output to commits that match _any_ of the `--author` patte of the `--grep` patterns; however, adding the `--all-match` option further limits the output to just those commits that match _all_ `--grep` patterns. ////////////////////////// -`--author`와 `--grep` 옵션을 함께 사용하여 모두 만족하는 커밋을 찾으려면 `--all-match` 옵션도 반드시 함께 사용해야 한다. +`--author` 와 `--grep` 옵션을 함께 사용하여 모두 만족하는 커밋을 찾으려면 `--all-match` 옵션도 반드시 함께 사용해야 한다. ==== ////////////////////////// diff --git a/book/03-git-branching/sections/basic-branching-and-merging.asc b/book/03-git-branching/sections/basic-branching-and-merging.asc index 8ebfa6e..e2155d4 100644 --- a/book/03-git-branching/sections/basic-branching-and-merging.asc +++ b/book/03-git-branching/sections/basic-branching-and-merging.asc @@ -147,7 +147,7 @@ Next, you have a hotfix to make. Let's create a `hotfix` branch on which to work until it's completed: ////////////////////////// 이젠 해결해야 할 핫픽스가 생겼을 때를 살펴보자. -`hotfix`라는 브랜치를 만들고 새로운 이슈를 해결할 때까지 사용한다. +`hotfix` 라는 브랜치를 만들고 새로운 이슈를 해결할 때까지 사용한다. [source,console] ---- @@ -195,7 +195,7 @@ Merge 메시지에서 “fast-forward” 가 보이는가. ////////////////////////// Your change is now in the snapshot of the commit pointed to by the `master` branch, and you can deploy the fix. ////////////////////////// -이제 `hotfix`는 `master` 브랜치에 포함됐고 운영환경에 적용할 수 있는 상태가 되었다고 가정해보자. +이제 `hotfix` 는 `master` 브랜치에 포함됐고 운영환경에 적용할 수 있는 상태가 되었다고 가정해보자. ////////////////////////// .`master` is fast-forwarded to `hotfix` @@ -408,7 +408,7 @@ After you've resolved each of these sections in each conflicted file, run `git a Staging the file marks it as resolved in Git. ////////////////////////// 충돌한 양쪽에서 조금씩 가져와서 새로 수정했다. -그리고 `<<<<<<<`, `=======`, `>>>>>>>`가 포함된 행을 삭제했다. +그리고 `<<<<<<<`, `=======`, `>>>>>>>` 가 포함된 행을 삭제했다. 이렇게 충돌한 부분을 해결하고 `git add` 명령으로 다시 Git에 저장한다. ////////////////////////// diff --git a/book/03-git-branching/sections/rebasing.asc b/book/03-git-branching/sections/rebasing.asc index 83d5c18..b6225fa 100644 --- a/book/03-git-branching/sections/rebasing.asc +++ b/book/03-git-branching/sections/rebasing.asc @@ -76,8 +76,8 @@ It works by going to the common ancestor of the two branches (the one you're on .Rebasing the change introduced in `C4` onto `C3` image::images/basic-rebase-3.png[Rebasing the change introduced in `C4` onto `C3`.] ////////////////////////// -.`C4`의 변경사항을 `C3`에 적용하는 Rebase 과정 -image::images/basic-rebase-3.png[`C4`의 변경사항을 `C3`에 적용하는 Rebase 과정.] +.`C4` 의 변경사항을 `C3` 에 적용하는 Rebase 과정 +image::images/basic-rebase-3.png[`C4` 의 변경사항을 `C3` 에 적용하는 Rebase 과정.] ////////////////////////// At this point, you can go back to the `master` branch and do a fast-forward merge. @@ -347,7 +347,7 @@ It's pretty safe to assume that the other developer doesn't want `C4` and `C6` t ////////////////////////// `git log` 로 히스토리를 확인해보면 저자, 커밋 날짜, 메시지가 같은 커밋이 두 개 있다(C4, C4'). 이렇게 되면 혼란스럽다. 게다가 이 히스토리를 서버에 Push 하면 같은 커밋이 두 개 있기 때문에 다른 사람들도 혼란스러워한다. -`C4`와 `C6`는 포함되지 말았어야 할 커밋이다. 애초에 서버로 데이터를 보내기 전에 Rebase로 커밋을 정리했어야 했다. +`C4` 와 `C6` 는 포함되지 말았어야 할 커밋이다. 애초에 서버로 데이터를 보내기 전에 Rebase로 커밋을 정리했어야 했다. [[_rebase_rebase]] ////////////////////////// diff --git a/book/03-git-branching/sections/remote-branches.asc b/book/03-git-branching/sections/remote-branches.asc index b62c7c8..938711a 100644 --- a/book/03-git-branching/sections/remote-branches.asc +++ b/book/03-git-branching/sections/remote-branches.asc @@ -30,7 +30,7 @@ If you were working on an issue with a partner and they pushed up an `iss53` bra ////////////////////////// 리모트 트래킹 브랜치의 이름은 `/` 형식으로 되어 있다. 예를 들어 리모트 저장소 `origin` 의 `master` 브랜치를 보고 싶다면 `origin/master` 라는 이름으로 브랜치를 확인하면 된다. -다른 팀원과 함께 어떤 이슈를 구현할 때 그 팀원이 `iss53` 브랜치를 서버로 Push 했고 당신도 로컬에 `iss53` 브랜치가 있다고 가정하자. 이때 서버의 `iss53` 브랜치가 가리키는 커밋은 로컬에서 `origin/iss53`이 가리키는 커밋이다. +다른 팀원과 함께 어떤 이슈를 구현할 때 그 팀원이 `iss53` 브랜치를 서버로 Push 했고 당신도 로컬에 `iss53` 브랜치가 있다고 가정하자. 이때 서버의 `iss53` 브랜치가 가리키는 커밋은 로컬에서 `origin/iss53` 이 가리키는 커밋이다. ////////////////////////// This may be a bit confusing, so let's look at an example. diff --git a/book/04-git-server/sections/git-daemon.asc b/book/04-git-server/sections/git-daemon.asc index a890349..cf3cea9 100644 --- a/book/04-git-server/sections/git-daemon.asc +++ b/book/04-git-server/sections/git-daemon.asc @@ -48,7 +48,7 @@ You can daemonize this process a number of ways, depending on the operating syst Since `systemd` is the most common init system among modern Linux distributions, you can use it for that purpose. Simply place a file in `/etc/systemd/system/git-daemon.service` with these contents: ////////////////////////// -대개의 리눅스 배포판은 `systemd`를 가장 보편적으로 사용하며 이를 이용하는 방법이 가장 일반적이다. +대개의 리눅스 배포판은 `systemd` 를 가장 보편적으로 사용하며 이를 이용하는 방법이 가장 일반적이다. 아래의 내용으로 `/etc/systemd/system/git-daemon.service` 파일을 작성한다. [source,console] @@ -123,7 +123,7 @@ For security reasons, it is strongly encouraged to have this daemon run as a use For the sake of simplicity we'll simply run it as the same 'git' user that `git-shell` is running as. ////////////////////////// 보안을 위해서 저장소를 읽을 수만 있는 사용자로 데몬을 실행시킬 것을 강력하게 권고한다. `git-ro` 라는 계정을 새로 만들고 그 계정으로 데몬을 실행시키는 것이 좋다. -하지만 여기에서는 쉽게 설명하려고 `git-shell`을 실행하는 동일한 사용자인 `git` 계정을 사용한다. +하지만 여기에서는 쉽게 설명하려고 `git-shell` 을 실행하는 동일한 사용자인 `git` 계정을 사용한다. ////////////////////////// When you restart your machine, your Git daemon will start automatically and respawn if it goes down. diff --git a/book/04-git-server/sections/gitlab.asc b/book/04-git-server/sections/gitlab.asc index 1052766..c5b182a 100644 --- a/book/04-git-server/sections/gitlab.asc +++ b/book/04-git-server/sections/gitlab.asc @@ -91,7 +91,7 @@ If the user +jane+ had a project named +project+, that project's url would be `h GitLab의 사용자 계정은 한 사람당 하나씩 만든다. 사용자 계정의 내용은 복잡하지 않다. 로그인 데이터에 추가로 개인 정보가 들어있다. 각 사용자마다 **네임스페이스**가 있다. 네임스페이스는 프로젝트를 묶는 단위이다. -*jane* 사용자가 **project**라는 프로젝트를 진행 중이라면 프로젝트의 URL은 `http://server/jane/project`가 될 것이다. +*jane* 사용자가 **project**라는 프로젝트를 진행 중이라면 프로젝트의 URL은 `http://server/jane/project` 가 될 것이다. [[gitlab_users]] ////////////////////////// @@ -128,7 +128,7 @@ A GitLab group is an assemblage of projects, along with data about how users can Each group has a project namespace (the same way that users do), so if the group +training+ has a project +materials+, its url would be `http://server/training/materials`. ////////////////////////// GitLab 그룹은 프로젝트와 누가 어떤 프로젝트에 어떻게 접근할지에 대한 권한 데이터의 모음이다. -그룹에도 사용자처럼 프로젝트 네임스페이스가 있다. +training+라는 그룹이 +materials+라는 프로젝트를 가지고 있으면 URL은 `http://server/training/materials`가 된다. +그룹에도 사용자처럼 프로젝트 네임스페이스가 있다. +training+라는 그룹이 +materials+라는 프로젝트를 가지고 있으면 URL은 `http://server/training/materials` 가 된다. [[gitlab_groups]] ////////////////////////// diff --git a/book/05-distributed-git/sections/contributing.asc b/book/05-distributed-git/sections/contributing.asc index 838b229..bad5f8b 100644 --- a/book/05-distributed-git/sections/contributing.asc +++ b/book/05-distributed-git/sections/contributing.asc @@ -232,7 +232,7 @@ The first developer, John, clones the repository, makes a change, and commits lo 물론 Git이 가진 오프라인 커밋 기능이나 브랜치 Merge 기능을 이용하긴 하지만 크게 다르지 않다. 가장 큰 차이점은 서버가 아닌 클라이언트 쪽에서 Merge 한다는 점이다. 두 개발자가 저장소를 공유하는 시나리오를 살펴보자. 개발자인 John은 저장소를 Clone 하고 파일을 수정하고 나서 로컬에 커밋한다 -(예제에서 Git이 출력하는 메시지 중 일부는 `...`으로 줄이고 생략했다). +(예제에서 Git이 출력하는 메시지 중 일부는 `...` 으로 줄이고 생략했다). [source,console] ---- @@ -286,7 +286,7 @@ You'll see similar output like this below in the discussions, so having a basic More details are available in the documentation for https://git-scm.com/docs/git-push[git-push]. ////////////////////////// Push 명령을 실행하고 난 결과 중 가장 마지막 줄은 유용한 정보를 보여주고 있다. -마지막 줄의 기본적인 형태는 `.. fromref -> toref` 이다. `oldref`는 이전 레퍼런스를, `newref`는 새 레퍼런스를, `fromref`는 Push 명령에서 사용한 로컬 레퍼런스의 이름을, `toref`는 Push로 업데이트한 리모트 레퍼런스를 나타낸다. +마지막 줄의 기본적인 형태는 `.. fromref -> toref` 이다. `oldref` 는 이전 레퍼런스를, `newref` 는 새 레퍼런스를, `fromref` 는 Push 명령에서 사용한 로컬 레퍼런스의 이름을, `toref` 는 Push로 업데이트한 리모트 레퍼런스를 나타낸다. 이어지는 내용에서 지금과 비슷한 Push 명령 출력 결과는 여러번 등장한다. 이 출력 메시지의 내용을 이해하고 있으면 다양한 상태에서 정확하게 어떤일이 벌어지는가를 좀 더 쉽게 이해할 수 있다. 자세한 내용을 좀 더 살펴보려면 Git 문서 https://git-scm.com/docs/git-push[git-push]를 참고한다. @@ -504,7 +504,7 @@ No problems occur; as you can see it was a simple fast-forward merge. Jessica now completes the local merging process by merging John's earlier fetched work that is sitting in the `origin/master` branch: ////////////////////////// 보다시피 Fast-forward Merge 이기 때문에 명령 실행 결과는 별 문제가 없다. -`origin/master`에 쌓여있던 John의 작업 내용을 다음과 같이 실행하여 Jessica는 Merge 작업을 완료할 수 있다. +`origin/master` 에 쌓여있던 John의 작업 내용을 다음과 같이 실행하여 Jessica는 Merge 작업을 완료할 수 있다. [source,console] ---- @@ -709,7 +709,7 @@ At this point, Jessica wants to push all of this merged “featureB” work back Rather, since Josie has already started an upstream `featureBee` branch, Jessica wants to push to _that_ branch, which she does with: ////////////////////////// 이 시점에서 Jissica는 Merge 한 “featureB” 작업을 서버로 Push 할 때 서버의 `featureB` 브랜치로 Push하지 않고자 한다. -이미 Josie가 생성한 `featureBee`로 작업 내용을 Push 하러면 아래와 같이 실행한다. +이미 Josie가 생성한 `featureBee` 로 작업 내용을 Push 하러면 아래와 같이 실행한다. [source,console] ---- @@ -885,7 +885,7 @@ When your branch work is finished and you're ready to contribute it back to the You then need to add this repository URL as a new remote of your local repository; in this example, let's call it `myfork`: ////////////////////////// 일단 프로젝트의 웹사이트로 가서 “Fork” 버튼을 누르면 원래 프로젝트 저장소에서 갈라져 나온, 쓰기 권한이 있는 저장소가 하나 만들어진다. 그러면 로컬에서 수정한 커밋을 원래 저장소에 Push 할 수 있다. -그 저장소를 로컬 저장소의 리모트 저장소로 등록한다. 예를 들어 `myfork`로 등록한다. +그 저장소를 로컬 저장소의 리모트 저장소로 등록한다. 예를 들어 `myfork` 로 등록한다. [source,console] ---- diff --git a/book/05-distributed-git/sections/maintaining.asc b/book/05-distributed-git/sections/maintaining.asc index eef30d1..ed15e7c 100644 --- a/book/05-distributed-git/sections/maintaining.asc +++ b/book/05-distributed-git/sections/maintaining.asc @@ -463,7 +463,7 @@ However, neither of those is particularly convenient, so Git provides another sh In the context of the `git diff` command, you can put three periods after another branch to do a `diff` between the last commit of the branch you're on and its common ancestor with another branch: ////////////////////////// 이 방법으로 원하는 결과를 얻을 수 있지만, 사용법이 불편하다. Git은 Triple-Dot 구문으로 간단하게 위와 같이 비교하는 방법을 지원한다. -`diff` 명령을 사용할 때 두 브랜치 사이에 `...`를 쓰면, 두 브랜치의 공통 조상과 브랜치의 마지막 커밋을 비교한다. +`diff` 명령을 사용할 때 두 브랜치 사이에 `...` 를 쓰면, 두 브랜치의 공통 조상과 브랜치의 마지막 커밋을 비교한다. [source,console] ---- @@ -827,7 +827,7 @@ They can use that key to verify all your signed tags. Also, if you include instructions in the tag message, running `git show ` will let you give the end user more specific instructions about tag verification. ////////////////////////// 사람들은 이렇게 공개키를 얻어서 서명된 태그를 확인한다. -또한, 관리자가 태그 메시지에 서명을 확인하는 방법을 적어 놓으면 좋다. `git show `으로 어떻게 서명된 태그를 확인하는지 설명한다. +또한, 관리자가 태그 메시지에 서명을 확인하는 방법을 적어 놓으면 좋다. `git show ` 으로 어떻게 서명된 태그를 확인하는지 설명한다. [[_build_number]] ////////////////////////// diff --git a/book/06-github/sections/2-contributing.asc b/book/06-github/sections/2-contributing.asc index acff7f0..aa3bed1 100644 --- a/book/06-github/sections/2-contributing.asc +++ b/book/06-github/sections/2-contributing.asc @@ -326,7 +326,7 @@ image::images/blink-06-final.png[최종 PR] ////////////////////////// An interesting thing to notice is that if you click on the “Files Changed” tab on this Pull Request, you'll get the “unified” diff -- that is, the total aggregate difference that would be introduced to your main branch if this topic branch was merged in. In `git diff` terms, it basically automatically shows you `git diff master...` for the branch this Pull Request is based on. See <> for more about this type of diff. ////////////////////////// -꼭 짚고 넘어가야 할 것이 있다. 이 Pull Request의 “Files Changed” 탭을 클릭하면 “unified” diff를 볼 수 있다. 이 Pull Request가 주 브랜치에 Merge 되면 어떻게 달라지는지 보여준다. `git diff` 명령을 빌어 표현하자면 `git diff master...`와 같은 명령이 실행되는 거고 ``는 Pull Request의 브랜치를 의미한다. <>에서 자세히 설명한다. +꼭 짚고 넘어가야 할 것이 있다. 이 Pull Request의 “Files Changed” 탭을 클릭하면 “unified” diff를 볼 수 있다. 이 Pull Request가 주 브랜치에 Merge 되면 어떻게 달라지는지 보여준다. `git diff` 명령을 빌어 표현하자면 `git diff master...` 와 같은 명령이 실행되는 거고 `` 는 Pull Request의 브랜치를 의미한다. <>에서 자세히 설명한다. ////////////////////////// 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. @@ -511,7 +511,7 @@ Your next question may be “How do I reference the old Pull Request?”. It tur ////////////////////////// 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 `#` in any comment or description. You can also be more specific if the Issue or Pull request lives somewhere else; write `username#` if you're referring to an Issue or Pull Request in a fork of the repository you're in, or `username/repo#` to reference something in another repository. ////////////////////////// -먼저 Issue와 Pull Request를 서로 참조시키는 방법부터 살펴보자. 모든 Pull Request와 Issue에는 프로젝트 내에서 유일한 번호를 하나 할당한다. 예를 들어, #3인 Pull Request와 #3인 Issue는 동시에 있을 수 없다. `#`과 같은 형태로 코멘트가나 설명에 Pull Request와 Issue를 참조시킬 수 있다. 이 방법은 단일 프로젝트 범위에서만 유효하다. Fork 저장소의 Issue나 Pull Request를 참조시키려고 한다면 `username#`라고 쓰고 아예 다른 저장소면 `username/repo#`라고 써야 한다. +먼저 Issue와 Pull Request를 서로 참조시키는 방법부터 살펴보자. 모든 Pull Request와 Issue에는 프로젝트 내에서 유일한 번호를 하나 할당한다. 예를 들어, \#3인 Pull Request와 #3인 Issue는 동시에 있을 수 없다. `#` 과 같은 형태로 코멘트가나 설명에 Pull Request와 Issue를 참조시킬 수 있다. 이 방법은 단일 프로젝트 범위에서만 유효하다. Fork 저장소의 Issue나 Pull Request를 참조시키려고 한다면 `username#` 라고 쓰고 아예 다른 저장소면 `username/repo#` 라고 써야 한다. ////////////////////////// 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>>. diff --git a/book/06-github/sections/3-maintaining.asc b/book/06-github/sections/3-maintaining.asc index 3d3fa04..59f8fa2 100644 --- a/book/06-github/sections/3-maintaining.asc +++ b/book/06-github/sections/3-maintaining.asc @@ -64,11 +64,11 @@ We won't belabor this here; if you need a refresher, check out </`, and over SSH as `git@github.com:/`. +Every project on GitHub is accessible over HTTPS as `\https://github.com//`, and over SSH as `git@github.com:/`. Git can fetch from and push to both of these URLs, but they are access-controlled based on the credentials of the user connecting to them. ////////////////////////// GitHub에 프로젝트를 올렸으면 다른 사람들에게 프로젝트 URL을 알려주고 공유할 수 있다. -모든 프로젝트의 HTTPS URL은 `https://github.com//`처럼 생겼고 SSH는 `git@github.com:/`처럼 생겼다. +모든 프로젝트의 HTTPS URL은 `\https://github.com//` 처럼 생겼고 SSH는 `git@github.com:/` 처럼 생겼다. Git은 이 두 URL을 통해서 Fetch 하고 Push 할 수 있지만, 인증 방식은 사용하는 프로토콜에 따라 다르다. [NOTE] @@ -102,7 +102,7 @@ Ben과 Jeff, Louise라는 동료가 있는데 그들이 내 저장소에 Push ////////////////////////// Click the “Settings” link at the bottom of the right-hand sidebar. ////////////////////////// -오른쪽 밑에 있는 ``Settings` ` 링크를 클릭한다. +오른쪽 밑에 있는 `` Settings` ` 링크를 클릭한다. ////////////////////////// .The repository settings link. @@ -188,7 +188,7 @@ If you notice the line that says `git pull patch-1`, this is a simple way We went over this quickly in <>. If you wish, you can create and switch to a topic branch and then run this command to merge in the Pull Request changes. ////////////////////////// -`git pull patch-1`라는 명령이 궁금할 텐데 이렇게 하면 리모트 브랜치를 간단히 Merge 할 수 있다. 저장소를 리모트로 추가하지 않아도 된다. +`git pull patch-1` 라는 명령이 궁금할 텐데 이렇게 하면 리모트 브랜치를 간단히 Merge 할 수 있다. 저장소를 리모트로 추가하지 않아도 된다. 필요하면 토픽 브랜치를 만들고 <>에서 배운 명령어로 Pull Request로 직접 Merge 해도 된다. @@ -321,7 +321,7 @@ So if someone opens a Pull Request in our repository and their branch is named ` 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//head` 형식의 브랜치가 자동으로 생긴다. +누군가 우리 저장소에 `bug-fix` 라는 브랜치를 Pull Request로 보내는 상황을 살펴보자. 이 브랜치는 `a5a775` 커밋을 가리킨다. `bug-fix` 브랜치는 Fork 한 저장소에 있는 브랜치라서 우리 저장소에 없다. 그럼에도 `a5a775` 를 가리키는 `pull//head` 형식의 브랜치가 자동으로 생긴다. 그래서 매번 다른 저장소를 리모트로 등록하지 않고서도 Pull Request 브랜치를 쉽게 Pull 할 수 있다. ////////////////////////// @@ -472,13 +472,13 @@ GitHub는 어떤 팀이나 사람에게 질문하거나 피드백을 받을 수 ////////////////////////// In any comment you can start typing a `@` character and it will begin to autocomplete with the names and usernames of people who are collaborators or contributors in the project. ////////////////////////// -GitHub 어디에서나 `@`만 입력해도 동료나 기여자의 사용자이름이 자동완성 된다. +GitHub 어디에서나 `@` 만 입력해도 동료나 기여자의 사용자이름이 자동완성 된다. ////////////////////////// .Start typing @ to mention someone. image::images/maint-05-mentions.png[Mentions] ////////////////////////// -.`@`만 입력. +.`@` 만 입력. image::images/maint-05-mentions.png[멘션] ////////////////////////// @@ -491,7 +491,7 @@ Once you post a comment with a user mention, that user will be notified. This means that this can be a really effective way of pulling people into conversations rather than making them poll. Very often in Pull Requests on GitHub people will pull in other people on their teams or in their company to review an Issue or Pull Request. ////////////////////////// -GitHub에서 글을 쓸 때 `@멘션`을 하면 해당 사용자에게 알림이 간다. +GitHub에서 글을 쓸 때 `@멘션` 을 하면 해당 사용자에게 알림이 간다. 일일이 의견을 물으러 다니는 것보다 이렇게 토론에 참여시키는 게 훨씬 유용하다. GitHub에서는 멘션으로 팀의 동료나 다른 사람을 이슈나 Pull Request에 참여시킨다. @@ -500,7 +500,7 @@ If someone gets mentioned on a Pull Request or Issue, they will be “subscribed You will also be subscribed to something if you opened it, if you're watching the repository or if you comment on something. If you no longer wish to receive notifications, there is an “Unsubscribe” button on the page you can click to stop receiving updates on it. ////////////////////////// -한번 `@멘션`으로 언급되면 그 사람은 “구독 상태(Subscribed)” 가 된다. 그래서 해당 이슈나 Pull Request에서 계속 알림이 온다. +한번 `@멘션` 으로 언급되면 그 사람은 “구독 상태(Subscribed)” 가 된다. 그래서 해당 이슈나 Pull Request에서 계속 알림이 온다. 이슈나 Pull Request를 직접 만들었거나, 해당 저장소를 'Watching'하는 상태이거나, 코멘트를 단 경우에도 구독 상태가 된다. 더는 알림을 받고 싶지 않으면 화면의 “Unsubscribe” 버튼으로 멈출 수 있다. @@ -619,7 +619,7 @@ If this were an issue, for example, the `` field would have been “issues ////////////////////////// 프로젝트에 따라 혹은 Pull Request인지에 따라 분류하거나 다른 주소로 재전송하고 싶다면 `Message-ID` 를 이용하는 게 좋다. 이 데이터는 `///` 형식으로 돼 있다. -만약 이슈에 대한 데이터면 ``부분이 “pull” 이 아니라 “issues” 라고 돼 있을 것이다. +만약 이슈에 대한 데이터면 `` 부분이 “pull” 이 아니라 “issues” 라고 돼 있을 것이다. ////////////////////////// The `List-Post` and `List-Unsubscribe` fields mean that if you have a mail client that understands those, you can easily post to the list or “Unsubscribe” from the thread. diff --git a/book/06-github/sections/5-scripting.asc b/book/06-github/sections/5-scripting.asc index 0e7748e..4c5f0c7 100644 --- a/book/06-github/sections/5-scripting.asc +++ b/book/06-github/sections/5-scripting.asc @@ -459,7 +459,7 @@ Hopefully this is fairly simple to follow. In this web hook handler we look through each commit that was just pushed, we look for the string 'Signed-off-by' in the commit message and finally we POST via HTTP to the `/repos///statuses/` API endpoint with the status. ////////////////////////// 이 웹훅 서비스는 별로 어렵지 않다. -누군가 Push 하면 모든 커밋을 훑는데, 커밋 메시지에서 `Signed-off-by` 스트링을 찾는다. 그 결과의 상태를 `/repos///statuses/`라는 Endpoint 주소에 POST 요청으로 보낸다. +누군가 Push 하면 모든 커밋을 훑는데, 커밋 메시지에서 `Signed-off-by` 스트링을 찾는다. 그 결과의 상태를 `/repos///statuses/` 라는 Endpoint 주소에 POST 요청으로 보낸다. ////////////////////////// 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. diff --git a/book/07-git-tools/sections/advanced-merging.asc b/book/07-git-tools/sections/advanced-merging.asc index 6e3f786..7f11631 100644 --- a/book/07-git-tools/sections/advanced-merging.asc +++ b/book/07-git-tools/sections/advanced-merging.asc @@ -530,7 +530,7 @@ This can be useful if you want to reset the markers and try to resolve them agai You can pass `--conflict` either `diff3` or `merge` (which is the default). If you pass it `diff3`, Git will use a slightly different version of conflict markers, not only giving you the “ours” and “theirs” versions, but also the “base” version inline to give you more context. /////////////////// -`--conflict` 옵션에는 `diff3`나 `merge` 를 넘길 수 있고 `merge` 가 기본 값이다. +`--conflict` 옵션에는 `diff3` 나 `merge` 를 넘길 수 있고 `merge` 가 기본 값이다. `--conflict` 옵션에 `diff3` 를 사용하면 Git은 약간 다른 모양의 충돌 표시를 남긴다. “ours” 나 “theirs” 말고도 “base” 버전의 내용까지 제공한다. [source,console] diff --git a/book/07-git-tools/sections/interactive-staging.asc b/book/07-git-tools/sections/interactive-staging.asc index 50fbf85..a1a3dda 100644 --- a/book/07-git-tools/sections/interactive-staging.asc +++ b/book/07-git-tools/sections/interactive-staging.asc @@ -67,7 +67,7 @@ Update>> ////////////////////////// To stage the `TODO` and `index.html` files, you can type the numbers: ////////////////////////// -`TODO`와 `index.html` 파일을 Stage 하려면 아래와 같이 입력한다. +`TODO` 와 `index.html` 파일을 Stage 하려면 아래와 같이 입력한다. [source,console] ---- @@ -105,7 +105,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` 와 `index.html` 파일은 Stage했고 `simplegit.rb` 파일만 아직 Unstaged 상태로 남아 있다. 이제 `TODO` 파일을 다시 Unstage 하고 싶으면 `3` 이나 `r` 을(revert) 입력한다. [source,console] diff --git a/book/07-git-tools/sections/replace.asc b/book/07-git-tools/sections/replace.asc index 3b477f5..e504a16 100644 --- a/book/07-git-tools/sections/replace.asc +++ b/book/07-git-tools/sections/replace.asc @@ -11,7 +11,7 @@ The `replace` command lets you specify an object in Git and say "every time you This is most commonly useful for replacing one commit in your history with another one without having to rebuild the entire history with, say, `git filter-branch`. //////////////////// Git의 `replace` 명령은 "어떤 개체를 읽을 때 항상 다른 개체로 보이게" 한다. -히스토리에서 어떤 커밋이 다른 커밋처럼 보이도록 할 때 이 명령이 유용하다(`git filter-branch`를 사용하여 전체 히스토리를 다시 작성할 필요가 없는 것이다). +히스토리에서 어떤 커밋이 다른 커밋처럼 보이도록 할 때 이 명령이 유용하다(`git filter-branch` 를 사용하여 전체 히스토리를 다시 작성할 필요가 없는 것이다). //////////////////// For example, let's say you have a huge code history and want to split your repository into one short history for new developers and one much longer and larger history for people interested in data mining. diff --git a/book/07-git-tools/sections/reset.asc b/book/07-git-tools/sections/reset.asc index 26dec4a..2bb4cd4 100644 --- a/book/07-git-tools/sections/reset.asc +++ b/book/07-git-tools/sections/reset.asc @@ -283,7 +283,7 @@ This means if HEAD is set to the `master` branch (i.e. you're currently on the ` ////////////////////////// `reset` 명령이 하는 첫 번째 일은 HEAD 브랜치를 이동시킨다. `checkout` 명령처럼 HEAD가 가리키는 브랜치를 바꾸지는 않는다. HEAD는 계속 현재 브랜치를 가리키고 있고, 현재 브랜치가 가리키는 커밋을 바꾼다. -HEAD가 `master` 브랜치를 가리키고 있다면(즉 `master` 브랜치를 Checkout 하고 작업하고 있다면) `git reset 9e5e6a4` 명령은 `master` 브랜치가 `9e5e6a4`를 가리키게 한다. +HEAD가 `master` 브랜치를 가리키고 있다면(즉 `master` 브랜치를 Checkout 하고 작업하고 있다면) `git reset 9e5e6a4` 명령은 `master` 브랜치가 `9e5e6a4` 를 가리키게 한다. image::images/reset-soft.png[] diff --git a/book/07-git-tools/sections/revision-selection.asc b/book/07-git-tools/sections/revision-selection.asc index 2fd9e75..3a04e0f 100755 --- a/book/07-git-tools/sections/revision-selection.asc +++ b/book/07-git-tools/sections/revision-selection.asc @@ -493,7 +493,7 @@ For example, you can get the same results as in the previous example by typing ` ////////////////////////// 이 명령은 `origin` 저장소의 `master` 브랜치에는 없고 현재 Checkout 중인 브랜치에만 있는 커밋을 보여준다. Checkout 한 브랜치가 `origin/master` 라면 `git log origin/master..HEAD` 가 보여주는 커밋이 Push 하면 서버에 전송될 커밋들이다. -그리고 한쪽의 Refs를 생략하면 Git은 `HEAD`라고 가정하기 때문에 +그리고 한쪽의 Refs를 생략하면 Git은 `HEAD` 라고 가정하기 때문에 `git log origin/master..` 는 `git log origin/master..HEAD` 와 같다. ////////////////////////// diff --git a/book/07-git-tools/sections/rewriting-history.asc b/book/07-git-tools/sections/rewriting-history.asc index 46d29d6..f4f415b 100644 --- a/book/07-git-tools/sections/rewriting-history.asc +++ b/book/07-git-tools/sections/rewriting-history.asc @@ -125,8 +125,8 @@ You must indicate how far back you want to rewrite commits by telling the comman For example, if you want to change the last three commit messages, or any of the commit messages in that group, you supply as an argument to `git rebase -i` the parent of the last commit you want to edit, which is `HEAD~2^` or `HEAD~3`. It may be easier to remember the `~3` because you’re trying to edit the last three commits, but keep in mind that you’re actually designating four commits ago, the parent of the last commit you want to edit: ////////////////////////// -마지막 커밋 메시지 세 개를 모두 수정하거나 그 중 몇 개를 수정하는 시나리오를 살펴보자. `git rebase -i` 의 인자로 편집하려는 마지막 커밋의 부모를 `HEAD~2^`나 `HEAD~3`로 해서 넘긴다. -마지막 세 개의 커밋을 수정하는 것이기 때문에 `~3`이 좀 더 기억하기 쉽다. 그렇지만, 실질적으로 가리키게 되는 것은 수정하려는 커밋의 부모인 네 번째 이전 커밋이다. +마지막 커밋 메시지 세 개를 모두 수정하거나 그 중 몇 개를 수정하는 시나리오를 살펴보자. `git rebase -i` 의 인자로 편집하려는 마지막 커밋의 부모를 `HEAD~2^` 나 `HEAD~3` 로 해서 넘긴다. +마지막 세 개의 커밋을 수정하는 것이기 때문에 `~3` 이 좀 더 기억하기 쉽다. 그렇지만, 실질적으로 가리키게 되는 것은 수정하려는 커밋의 부모인 네 번째 이전 커밋이다. [source,console] ---- @@ -193,12 +193,12 @@ It lists the oldest at the top, rather than the newest, because that’s the fir ////////////////////////// 위 결과의 역순임을 기억하자. 대화형 Rebase는 스크립트에 적혀 있는 순서대로 -`HEAD~3`부터 적용하기 시작하고 위에서 아래로 각각의 커밋을 순서대로 수정한다. +`HEAD~3` 부터 적용하기 시작하고 위에서 아래로 각각의 커밋을 순서대로 수정한다. 순서대로 적용하는 것이기 때문에 제일 위에 있는 것이 최신이 아니라 가장 오래된 것이다. ////////////////////////// You need to edit the script so that it stops at the commit you want to edit. -To do so, change the word `pick' to the word `edit' for each of the commits you want the script to stop after. +To do so, change the word `pick' to the word ` edit' for each of the commits you want the script to stop after. For example, to modify only the third commit message, you change the file to look like this: ////////////////////////// 특정 커밋에서 실행을 멈추게 하려면 스크립트를 수정해야 한다. diff --git a/book/07-git-tools/sections/signing.asc b/book/07-git-tools/sections/signing.asc index fe164db..6807cf3 100644 --- a/book/07-git-tools/sections/signing.asc +++ b/book/07-git-tools/sections/signing.asc @@ -219,7 +219,7 @@ Here we can see that only the latest commit is signed and valid and the previous ////////////////////////// In Git 1.8.3 and later, `git merge` and `git pull` can be told to inspect and reject when merging a commit that does not carry a trusted GPG signature with the `--verify-signatures` command. ////////////////////////// -1.8.3 버전 이후의 Git에서는 `git merge`와 `git pull`에서 GPG 서명 정보를 이용해 Merge를 허용하지 않을 수 있다. `--verify-signatures` 옵션으로 이 기능을 사용할 수 있다. +1.8.3 버전 이후의 Git에서는 `git merge` 와 `git pull` 에서 GPG 서명 정보를 이용해 Merge를 허용하지 않을 수 있다. `--verify-signatures` 옵션으로 이 기능을 사용할 수 있다. ////////////////////////// If you use this option when merging a branch and it contains commits that are not signed and valid, the merge will not work. diff --git a/book/07-git-tools/sections/stashing-cleaning.asc b/book/07-git-tools/sections/stashing-cleaning.asc index 7356ccc..831a85b 100644 --- a/book/07-git-tools/sections/stashing-cleaning.asc +++ b/book/07-git-tools/sections/stashing-cleaning.asc @@ -28,7 +28,7 @@ Stash 명령을 사용하면 워킹 디렉토리에서 수정한 파일들만 As of late October 2017, there has been extensive discussion on the Git mailing list, wherein the command `git stash save` is being deprecated in favour of the existing alternative `git stash push`. The main reason for this is that `git stash push` introduces the option of stashing selected _pathspecs_, something `git stash save` does not support. ////////////////////////// -2017년 10월 말 Git 메일링 리스트에는 엄청난 논의가 있었습니다. 논의는 `git stash save` 명령을 은퇴시키고 `git stash push`로 대체하는 내용에 대한 것이었습니다. +2017년 10월 말 Git 메일링 리스트에는 엄청난 논의가 있었습니다. 논의는 `git stash save` 명령을 은퇴시키고 `git stash push` 로 대체하는 내용에 대한 것이었습니다. `git stash push` 명령의 경우 _pathspec_ 으로 선택하여 Stash하는 옵션이 추가되었는데 `git stash save` 명령이 지원하지 못하는 것이었습니다. ////////////////////////// @@ -117,7 +117,7 @@ If you don’t specify a stash, Git assumes the most recent stash and tries to a ////////////////////////// Stash 두 개는 원래 있었다. 그래서 현재 총 세 개의 Stash를 사용할 수 있다. 이제 `git stash apply` 를 사용하여 Stash를 다시 적용할 수 있다. `git stash` 명령을 실행하면 Stash를 다시 적용하는 방법도 알려줘서 편리하다. -`git stash apply stash@{2}`처럼 Stash 이름을 입력하면 골라서 적용할 수 있다. +`git stash apply stash@{2}` 처럼 Stash 이름을 입력하면 골라서 적용할 수 있다. 이름이 없으면 Git은 가장 최근의 Stash를 적용한다. [source,console] diff --git a/book/07-git-tools/sections/submodules.asc b/book/07-git-tools/sections/submodules.asc index a84faa4..ea6a197 100644 --- a/book/07-git-tools/sections/submodules.asc +++ b/book/07-git-tools/sections/submodules.asc @@ -197,7 +197,7 @@ $ git commit -am 'added DbConnector module' Notice the `160000` mode for the `DbConnector` entry. That is a special mode in Git that basically means you’re recording a commit as a directory entry rather than a subdirectory or a file. ////////////////////////// -`DbConnector` 디렉토리의 모드는 `160000`이다. +`DbConnector` 디렉토리의 모드는 `160000` 이다. Git에게 있어 160000 모드는 일반적인 파일이나 디렉토리가 아니라 특별하다는 의미다. ////////////////////////// @@ -853,7 +853,7 @@ So, in this case, `eb41d76` is the commit in our submodule that *we* had and `c7 If we go into our submodule directory, it should already be on `eb41d76` as the merge would not have touched it. If for whatever reason it's not, you can simply create and checkout a branch pointing to it. /////////// -위 같은 경우 `eb41d76`이 *로컬* 서브모듈의 커밋이고 `c771610`이 Upstream에 있는 커밋이다. +위 같은 경우 `eb41d76` 이 *로컬* 서브모듈의 커밋이고 `c771610` 이 Upstream에 있는 커밋이다. 서브모듈의 디렉토리로 가면 현재 `eb41d76` 커밋을 가리키고 있고 Merge 작업은 아직 이루어지지 않았다. 이 상태에서 현재 `eb41d76` 커밋을 브랜치로 만들어 Merge 작업을 진행할 수 있다. diff --git a/book/08-customizing-git/sections/config.asc b/book/08-customizing-git/sections/config.asc index 740e05a..3aa3451 100644 --- a/book/08-customizing-git/sections/config.asc +++ b/book/08-customizing-git/sections/config.asc @@ -579,7 +579,7 @@ $ git config --global merge.tool kdiff3 ////////////////////////// If you run this instead of setting up the `extMerge` and `extDiff` files, Git will use KDiff3 for merge resolution and the normal Git diff tool for diffs. ////////////////////////// -`extMerge` 와 `extDiff` 파일을 만들지 않고 이렇게 Merge 도구만 `kdiff3`로 설정하고 Diff 도구는 Git에 원래 들어 있는 것을 사용할 수 있다. +`extMerge` 와 `extDiff` 파일을 만들지 않고 이렇게 Merge 도구만 `kdiff3` 로 설정하고 Diff 도구는 Git에 원래 들어 있는 것을 사용할 수 있다. ==== Formatting and Whitespace diff --git a/book/08-customizing-git/sections/policy.asc b/book/08-customizing-git/sections/policy.asc index 2cda411..88c40d3 100644 --- a/book/08-customizing-git/sections/policy.asc +++ b/book/08-customizing-git/sections/policy.asc @@ -643,7 +643,7 @@ You get a list of commits that have already been pushed up by running this: The `SHA^@` syntax resolves to all the parents of that commit. You're looking for any commit that is reachable from the last commit on the remote and that isn't reachable from any parent of any of the SHA-1s you're trying to push up – meaning it's a fast-forward. ////////////////////////// -`SHA^@`은 해당 커밋의 모든 부모를 가리킨다. +`SHA^@` 은 해당 커밋의 모든 부모를 가리킨다. 그러니까 이 명령은 지금 Push 하려는 커밋에서 리모트 저장소의 커밋에 도달할 수 있는지 확인하는 명령이다. 즉, Fast-forward인지 확인하는 것이다. ////////////////////////// diff --git a/book/09-git-and-other-scms/sections/client-bzr.asc b/book/09-git-and-other-scms/sections/client-bzr.asc index 889621c..3031234 100644 --- a/book/09-git-and-other-scms/sections/client-bzr.asc +++ b/book/09-git-and-other-scms/sections/client-bzr.asc @@ -25,7 +25,7 @@ To install it, you just have to download the file git-remote-bzr in a folder con ////////////////////////// 여러분이 Git을 Bazaar 클라이언트로 사용하도록 기능을 제공해주는 수 많은 프로젝트가 있다. 이 책에서는 Felipe Contreras의 프로젝트를 가져다 사용하며 https://github.com/felipec/git-remote-bzr[] 에서 구할 수 있다. -프로젝트에서 git-remote-bzr 파일을 받아 `$PATH`에 지정된 디렉토리 중 하나에 위치시켜 두면 바로 사용할 수 있다. +프로젝트에서 git-remote-bzr 파일을 받아 `$PATH` 에 지정된 디렉토리 중 하나에 위치시켜 두면 바로 사용할 수 있다. [source,console] ---- $ wget https://raw.github.com/felipec/git-remote-bzr/master/git-remote-bzr -O ~/bin/git-remote-bzr diff --git a/book/09-git-and-other-scms/sections/client-p4.asc b/book/09-git-and-other-scms/sections/client-p4.asc index 256d950..c59c350 100644 --- a/book/09-git-and-other-scms/sections/client-p4.asc +++ b/book/09-git-and-other-scms/sections/client-p4.asc @@ -439,7 +439,7 @@ The rest of the view is given to the details view for the selected revision (`2` Perforce의 이런 히스토리 뷰어를 본 적이 없다면 다소 혼란스럽겠지만 Git 히스토리를 보는 것과 크게 다르지 않다. 그림은 `README` 파일의 히스토리를 보는 상황이다. 왼쪽 위 창에서 `README` 파일과 관련된 브랜치와 디렉토리가 나타난다. 오른쪽 위 창에서는 파일의 리비전 히스토리 그래프를 볼 수 있다. 오른쪽 아래 창에서는 이 그래프의 큰 그림을 확인할 수 있다. -왼쪽 아래 창에는 선택한 리비전을 자세히 보여준다(이 그림에서는 리비전 `2`다) +왼쪽 아래 창에는 선택한 리비전을 자세히 보여준다(이 그림에서는 리비전 `2` 다) ////////////////////////// One thing to notice is that the graph looks exactly like the one in Git's history. @@ -500,7 +500,7 @@ As of this writing, it is freely available at http://www.perforce.com/downloads/ ////////////////////////// ====== git-p4가 잘 동작하려면 `p4` 명령을 어디에서나 사용할 수 있게 `PATH` 에 등록해두어야 한다. -`p4`는 무료로 http://www.perforce.com/downloads/Perforce/20-User[] 에서 다운로드 받을 수 있다. +`p4` 는 무료로 http://www.perforce.com/downloads/Perforce/20-User[] 에서 다운로드 받을 수 있다. ====== ////////////////////////// diff --git a/book/09-git-and-other-scms/sections/import-bzr.asc b/book/09-git-and-other-scms/sections/import-bzr.asc index 5038395..a86c20b 100644 --- a/book/09-git-and-other-scms/sections/import-bzr.asc +++ b/book/09-git-and-other-scms/sections/import-bzr.asc @@ -22,7 +22,7 @@ In the first case, the simplest is to install the `bzr-fastimport` package that ////////////////////////// For example, with Debian and derived, you would do the following: ////////////////////////// -예를 들어 Debian 이나 파생 Linux라면 다음과 같이 `bzr-fastimport`를 설치할 수 있다. +예를 들어 Debian 이나 파생 Linux라면 다음과 같이 `bzr-fastimport` 를 설치할 수 있다. [source,console] ---- @@ -32,7 +32,7 @@ $ sudo apt-get install bzr-fastimport ////////////////////////// With RHEL, you would do the following: ////////////////////////// -RHEL이나 파생 Linux라면 다음과 같이 `bzr-fastimport`를 설치할 수 있다. +RHEL이나 파생 Linux라면 다음과 같이 `bzr-fastimport` 를 설치할 수 있다. [source,console] ---- @@ -42,7 +42,7 @@ $ sudo yum install bzr-fastimport ////////////////////////// With Fedora, since release 22, the new package manager is dnf: ////////////////////////// -Fedora release 22 이상이라면 dnf를 사용하여 `bzr-fastimport`를 설치할 수 있다. +Fedora release 22 이상이라면 dnf를 사용하여 `bzr-fastimport` 를 설치할 수 있다. [source,console] ---- @@ -87,7 +87,7 @@ If it is not available, you can download it at address https://pypi.python.org/p In the second case (on Windows), `bzr-fastimport` is automatically installed with the standalone version and the default installation (let all the checkboxes checked). So in this case you have nothing to do. ////////////////////////// -Windows 에서 `bzr-fastimport`는 Git 설치시 Standalone 버전이나 기본 설치(모든 체크박스가 설정되)의 경우 함께 설치된다. +Windows 에서 `bzr-fastimport` 는 Git 설치시 Standalone 버전이나 기본 설치(모든 체크박스가 설정되)의 경우 함께 설치된다. 따라서 따로 더 설치 작업이 필요하지 않다. ////////////////////////// @@ -193,8 +193,8 @@ Check the logs to make sure they’re complete and get rid of the `marks.bzr` an Whatever the number of branches you had and the import method you used, your staging area is not synchronized with `HEAD`, and with the import of several branches, your working directory is not synchronized either. This situation is easily solved by the following command: ////////////////////////// -위 과정을 실행하고 나면 하나 혹은 여러 브랜치의 히스토리가 Git 저장소 히스토리로 변환되었지만 Staging Area와 워킹 디렉토리가 `HEAD`와 동기화가 이루어지지 않은 상태이다. -다음 명령으로 쉽게 `HEAD`와 동기화를 시킬 수 있다. +위 과정을 실행하고 나면 하나 혹은 여러 브랜치의 히스토리가 Git 저장소 히스토리로 변환되었지만 Staging Area와 워킹 디렉토리가 `HEAD` 와 동기화가 이루어지지 않은 상태이다. +다음 명령으로 쉽게 `HEAD` 와 동기화를 시킬 수 있다. [source,console] ---- diff --git a/book/09-git-and-other-scms/sections/import-hg.asc b/book/09-git-and-other-scms/sections/import-hg.asc index 9b452c5..0934c15 100644 --- a/book/09-git-and-other-scms/sections/import-hg.asc +++ b/book/09-git-and-other-scms/sections/import-hg.asc @@ -60,9 +60,9 @@ If all the usernames look fine, we won't need this file at all. In this example, we want our file to look like this: ////////////////////////// 예제를 보면 Bob 이라는 한 사람은 적어도 네 가지의 다른 저자 정보를 Changeset에 기록했다. 어떤 정보는 Git에서 쓸 수 있지만 어떤 정보는 Git에서 쓰기에 적절치 않다. -Hg-fast-export 에서는 `""=""` 규칙을 사용하여 ``을 ``에 매핑할 수 있다. -``과 `` 문자열에는 Python의 `string_escape` 인코딩을 사용하는 이스케이프 문자열을 사용할 수 있다. -``에서 찾을 수 없는 문자열을 만나는 경우 Git은 그 저자 내용을 변경하지 않고 그대로 사용한다. +Hg-fast-export 에서는 `""=""` 규칙을 사용하여 `` 을 `` 에 매핑할 수 있다. +`` 과 `` 문자열에는 Python의 `string_escape` 인코딩을 사용하는 이스케이프 문자열을 사용할 수 있다. +`` 에서 찾을 수 없는 문자열을 만나는 경우 Git은 그 저자 내용을 변경하지 않고 그대로 사용한다. 물론 저자 정보가 모든 Changeset에 제대로 입력돼있다면 이런 변환 과정을 거치지 않아도 된다. 예제에서는 아래와 같이 저자 정보를 수정한다. diff --git a/book/09-git-and-other-scms/sections/import-tfs.asc b/book/09-git-and-other-scms/sections/import-tfs.asc index 2ffa1b7..fe5f13c 100644 --- a/book/09-git-and-other-scms/sections/import-tfs.asc +++ b/book/09-git-and-other-scms/sections/import-tfs.asc @@ -40,7 +40,7 @@ This grabs all of the changesets in the history of the project and put it in the Open the file and find at which characters start and end the column and replace, in the following command-line, the parameters `11-20` of the `cut` command with the ones found: //////////// 이 명령어는 프로젝트의 모든 Chagneset을 가져와서 AUTHORS_TMP 파일에 저장한다. AUTHORS_TMP 파일에서 두 번째 열의 'User' 정보를 추출해서 사용한다. -추출할 때 아래 이어지는 `cut` 명령에서 사용할 `11-20`과 같은 파라미터를 구하기 위해 몇 번 실험해서 해당 필드를 자를 수 있는 적당한 숫자를 알아내야 한다. +추출할 때 아래 이어지는 `cut` 명령에서 사용할 `11-20` 과 같은 파라미터를 구하기 위해 몇 번 실험해서 해당 필드를 자를 수 있는 적당한 숫자를 알아내야 한다. [source,powershell] ---- @@ -66,7 +66,7 @@ DOMAIN\username = User Name //////////// The portion on the left is the “User” field from TFVC, and the portion on the right side of the equals sign is the user name that will be used for Git commits. //////////// -`=`의 왼쪽은 TFVC의 “User” 필드고 오른쪽은 Git 커밋에 사용할 개발자 정보다. +`=` 의 왼쪽은 TFVC의 “User” 필드고 오른쪽은 Git 커밋에 사용할 개발자 정보다. //////////// Once you have this file, the next thing to do is make a full clone of the TFVC project you're interested in: diff --git a/book/10-git-internals/sections/environment.asc b/book/10-git-internals/sections/environment.asc index 3a48f58..b8337e6 100644 --- a/book/10-git-internals/sections/environment.asc +++ b/book/10-git-internals/sections/environment.asc @@ -235,7 +235,7 @@ The default is a value like `git/2.0.0`. The only valid values are `-u` or `--unified=`, which controls the number of context lines shown in a `git diff` command. ////////////////////////// *`GIT_DIFF_OPTS` * 변수는 이름이 잘못 지어진 변수다. -`git diff` 명령을 실행했을 때 변경된 부분 아래위로 보여주는 라인의 개수를 조절한다. 명령의 옵션으로 사용할 때는 `-u` 이나 `--unified=`로 사용한다. +`git diff` 명령을 실행했을 때 변경된 부분 아래위로 보여주는 라인의 개수를 조절한다. 명령의 옵션으로 사용할 때는 `-u` 이나 `--unified=` 로 사용한다. ////////////////////////// *`GIT_EXTERNAL_DIFF`* is used as an override for the `diff.external` configuration value. diff --git a/book/10-git-internals/sections/maintenance.asc b/book/10-git-internals/sections/maintenance.asc index 6aef7d7..a9bdfd0 100644 --- a/book/10-git-internals/sections/maintenance.asc +++ b/book/10-git-internals/sections/maintenance.asc @@ -93,7 +93,7 @@ Git은 Refs가 가리키는 SHA-1 값을 찾을 때 먼저 `refs` 디렉토리 Notice the last line of the file, which begins with a `^`. This means the tag directly above is an annotated tag and that line is the commit that the annotated tag points to. ////////////////////////// -마지막에 있는 `^`로 시작하는 라인을 살펴보자. +마지막에 있는 `^` 로 시작하는 라인을 살펴보자. 이것은 바로 윗줄의 태그가 Annotated 태그라는 것을 말해준다. 해당 커밋은 윗 태그가 가리키는 커밋이라는 뜻이다. [[_data_recovery]] diff --git a/book/10-git-internals/sections/objects.asc b/book/10-git-internals/sections/objects.asc index 8130252..a821b1e 100644 --- a/book/10-git-internals/sections/objects.asc +++ b/book/10-git-internals/sections/objects.asc @@ -565,7 +565,7 @@ Git concatenates the header and the original content and then calculates the SHA You can calculate the SHA-1 value of a string in Ruby by including the SHA1 digest library with the `require` command and then calling `Digest::SHA1.hexdigest()` with the string: ////////////////////////// Git은 헤더와 원래 내용을 합쳐서 SHA-1 체크섬을 계산한다. -Ruby에서도 `require` 로 SHA1 라이브러리를 가져다가 흉내 낼 수 있다. `require` 로 라이브러리를 포함하고 나서 `Digest::SHA1.hexdigest()`를 호출한다. +Ruby에서도 `require` 로 SHA1 라이브러리를 가져다가 흉내 낼 수 있다. `require` 로 라이브러리를 포함하고 나서 `Digest::SHA1.hexdigest()` 를 호출한다. [source,console] ---- @@ -595,7 +595,7 @@ Git compresses the new content with zlib, which you can do in Ruby with the zlib First, you need to require the library and then run `Zlib::Deflate.deflate()` on the content: ////////////////////////// Git은 또 zlib으로 내용을 압축한다. Ruby에도 zlib 라이브러리가 있으니 Ruby에서도 할 수 있다. -라이브러리를 포함하고 `Zlib::Deflate.deflate()`를 호출한다. +라이브러리를 포함하고 `Zlib::Deflate.deflate()` 를 호출한다. [source,console] ---- diff --git a/book/10-git-internals/sections/packfiles.asc b/book/10-git-internals/sections/packfiles.asc index 422e728..d48f884 100644 --- a/book/10-git-internals/sections/packfiles.asc +++ b/book/10-git-internals/sections/packfiles.asc @@ -218,7 +218,7 @@ The third column in the output is the size of the object in the pack, so you can What is also interesting is that the second version of the file is the one that is stored intact, whereas the original version is stored as a delta -- this is because you're most likely to need faster access to the most recent version of the file. ////////////////////////// `033b4` Blob이 처음 추가한 `repo.rb` 파일인데, 이 Blob은 두 번째 버전인 `b042a` Blob을 가리킨다. -결과에서 세 번째 컬럼은 압축된 개체의 크기를 나타낸다. `b042a` 의 크기는 22K지만 `033b4`는 9바이트밖에 안 된다. +결과에서 세 번째 컬럼은 압축된 개체의 크기를 나타낸다. `b042a` 의 크기는 22K지만 `033b4` 는 9바이트밖에 안 된다. 특이한 점은 원본을 그대로 저장하는 것이 첫 번째가 아니라 두 번째 버전이라는 것이다. 첫 번째 버전은 차이점만 저장된다. 최신 버전에 접근할 때가 더 많고 최신 버전에 접근하는 속도가 더 빨라야 하기 때문에 이렇게 한다. ////////////////////////// diff --git a/book/B-embedding-git/sections/command-line.asc b/book/B-embedding-git/sections/command-line.asc index 8132bd6..616477b 100644 --- a/book/B-embedding-git/sections/command-line.asc +++ b/book/B-embedding-git/sections/command-line.asc @@ -35,4 +35,4 @@ Trying to coordinate many of these processes (especially when potentially access ////////////////////////// 마지막 결점은 프로세스를 관리해야 한다는 점이다. 별도의 프로세스로 Git을 실행하기 때문에 애플리케이션에 불필요한 복잡성이 추가된다. -여러 프로세스를 조종하는 일은 지뢰밭이라 할 수 있다. 특히 동시에 여러 프로세스가 한 저장소에 접근하면 `!@#$%^&*`되기 쉽다. +여러 프로세스를 조종하는 일은 지뢰밭이라 할 수 있다. 특히 동시에 여러 프로세스가 한 저장소에 접근하면 `!@#$%^&*` 되기 쉽다.