diff --git a/.tgitconfig b/.tgitconfig new file mode 100644 index 00000000..9a9773b3 --- /dev/null +++ b/.tgitconfig @@ -0,0 +1,6 @@ +[bugtraq] + url = https://github.com/progit/progit2/issues/%BUGID% + logregex = "[Ii]ssues?:?(\\s*(,|and)?\\s*#?\\d+)+\n(\\d+)" + +[tgit] + icon = Pro.ico diff --git a/BASE.md b/BASE.md index ae6bf786..6d97a115 100644 --- a/BASE.md +++ b/BASE.md @@ -1 +1 @@ -progit/progit2@63e4c6230b22211ab6c83f7e0351e276becd2fa2 +progit/progit2@e95aba0b236ab57b8ea9a1ef1b4fdae6339573ec diff --git a/LICENSE.asc b/LICENSE.asc index 0514d928..81f2824e 100644 --- a/LICENSE.asc +++ b/LICENSE.asc @@ -1 +1 @@ -This work is licensed under the Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License. To view a copy of this license, visit http://creativecommons.org/licenses/by-nc-sa/3.0/ or send a letter to Creative Commons, 171 Second Street, Suite 300, San Francisco, California, 94105, USA. +This work is licensed under the Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License. To view a copy of this license, visit http://creativecommons.org/licenses/by-nc-sa/3.0/ or send a letter to Creative Commons, PO Box 1866, Mountain View, CA 94042, USA. diff --git a/Pro.ico b/Pro.ico new file mode 100644 index 00000000..992dcc6d Binary files /dev/null and b/Pro.ico differ diff --git a/README.asc b/README.asc index 6cacbf63..ac245517 100644 --- a/README.asc +++ b/README.asc @@ -36,6 +36,12 @@ Converting to PDF... 위 명령이 잘 실행되려면 `asciidoctor`, `asciidoctor-pdf`, `asciidoctor-epub` 프로젝트가 필요합니다. +== 새로 이슈 만들기 + +새로 이슈를 만들기 전에 버그 관리 시스템에 비슷한 이슈가 이미 등록되었는지 먼저 확인해보시기 바랍니다. + +더불어 등록한 이슈의 변경사항이 git-scm.com 사이트로 적용되었을 때 해당 내용이 PDF에도 반영되었는지 확인 바랍니다. 이슈의 변경사항이 기능적으로 반영은 되었지만 문서화까지는 적용되지 않았을 수 있습니다. + == 기여하기 뭔가 더 낫게 하거나 번역에 참여하고 싶다면 link:CONTRIBUTING.md[번역 가이드] 문서를 읽어 보세요. diff --git a/TRANSLATION_NOTES.asc b/TRANSLATION_NOTES.asc index 6b1d73bb..ed85bc30 100644 --- a/TRANSLATION_NOTES.asc +++ b/TRANSLATION_NOTES.asc @@ -44,6 +44,16 @@ chapter 2: proofreading 자세히 작성하면 좋습니다. +==== 원문 갱신 순서 참고 + +[progit2](https://github.com/progit/progit2) 원문이 꾸준히 갱신되므로 이를 적용할 필요가 있다. 아래 순서를 원문을 갱신하는데 참고할 수 있다. + +1. [progit2](https://github.com/progit/progit2) 저장소를 최신 내용으로 업데이트 한다. +2. `git log --oneline --no-merges $(cat ../progit2-ko/BASE.md | sed "s/.*@//")..origin/master` 으로 업데이트 커밋과 그 양을 파악한다. 많을 경우 적절히 양을 나누어 진행한다. +3. `git diff --minimal -b $(cat ../progit2-ko/BASE.md | sed "s/.*@//")..HEAD` +4. `git diff --name-only $(cat ../progit2-ko/BASE.md | sed "s/.*@//")..HEAD` +5. BASE.md 내용을 갱신한 커밋으로 변경한다. `git rev-parse HEAD` + === 마무리 번역이 끝나면 관리자는 `status.json`에 번역이 완료됐음을 표기합니다. 그래야 자동으로 빌드돼 여러 가지 포맷으로 배포되고 사람들에게 얼마나 번역이 진행됐는지 알릴 수 있습니다. diff --git a/book/01-introduction/sections/first-time-setup.asc b/book/01-introduction/sections/first-time-setup.asc index 0abb6be6..e93027bf 100644 --- a/book/01-introduction/sections/first-time-setup.asc +++ b/book/01-introduction/sections/first-time-setup.asc @@ -41,7 +41,7 @@ Each level overrides values in the previous level, so values in `.git/config` tr ////////////////////////// On Windows systems, Git looks for the `.gitconfig` file in the `$HOME` directory (`C:\Users\$USER` for most people). It also still looks for `/etc/gitconfig`, although it's relative to the MSys root, which is wherever you decide to install Git on your Windows system when you run the installer. -If you are using Git for Windows 2.x or later, there is also a system-level config file at +If you are using version 2.x or later of Git for Windows, there is also a system-level config file at `C:\Documents and Settings\All Users\Application Data\Git\config` on Windows XP, and in `C:\ProgramData\Git\config` on Windows Vista and newer. This config file can only be changed by `git config -f ` as an admin. ////////////////////////// @@ -87,11 +87,11 @@ GUI 도구들은 처음 실행할 때 이 설정을 묻는다. ////////////////////////// Now that your identity is set up, you can configure the default text editor that will be used when Git needs you to type in a message. -If not configured, Git uses your system's default editor, which is system dependant. +If not configured, Git uses your system's default editor. If you want to use a different text editor, such as Emacs, you can do the following: ////////////////////////// 사용자 정보를 설정하고 나면 Git에서 사용할 텍스트 편집기를 고른다. -기본적으로 Git은 시스템의 기본 편집기를 사용해서 시스템마다 다르다. +기본적으로 Git은 시스템의 기본 편집기를 사용한다. 하지만, Emacs 같은 다른 텍스트 편집기를 사용할 수 있고 아래와 같이 실행하면 된다. [source,console] diff --git a/book/01-introduction/sections/installing.asc b/book/01-introduction/sections/installing.asc index b8525585..f1666671 100644 --- a/book/01-introduction/sections/installing.asc +++ b/book/01-introduction/sections/installing.asc @@ -143,15 +143,15 @@ The binary installers tend to be a bit behind, though as Git has matured in rece If you do want to install Git from source, you need to have the following libraries that Git depends on: curl, zlib, openssl, expat, and libiconv. For example, if you're on a system that has yum (such as Fedora) or apt-get (such as a Debian based system), you can use one of these commands to install all of the dependencies: ////////////////////////// -Git을 설치하려면 Git이 의존하고 있는 라이브러리인 curl, zlib, openssl, expat, libiconv등이 필요하다. +Git을 설치하려면 Git이 의존하고 있는 라이브러리인 autotools, curl, zlib, openssl, expat, libiconv등이 필요하다. 예를 들어 yum을 사용하는 Fedora등의 시스템이나 apt-get이 있는 데비안 계열 시스템이면 아래 명령어 중 하나를 실행하여 필요한 패키지를 설치할 수 있다. [source,console] ---- -$ sudo yum install curl-devel expat-devel gettext-devel \ - openssl-devel zlib-devel -$ sudo apt-get install libcurl4-gnutls-dev libexpat1-dev gettext \ - libz-dev libssl-dev +$ sudo yum install dh-autoreconf curl-devel expat-devel gettext-devel \ + openssl-devel perl-devel zlib-devel +$ sudo apt-get install dh-autoreconf libcurl4-gnutls-dev libexpat1-dev \ + gettext libz-dev libssl-dev ---- ////////////////////////// diff --git a/book/02-git-basics/sections/recording-changes.asc b/book/02-git-basics/sections/recording-changes.asc index c15d4507..80166e90 100644 --- a/book/02-git-basics/sections/recording-changes.asc +++ b/book/02-git-basics/sections/recording-changes.asc @@ -14,7 +14,7 @@ You need to make some changes and commit snapshots of those changes into your re Remember that each file in your working directory can be in one of two states: tracked or untracked. Tracked files are files that were in the last snapshot; they can be unmodified, modified, or staged. Untracked files are everything else – any files in your working directory that were not in your last snapshot and are not in your staging area. -When you first clone a repository, all of your files will be tracked and unmodified because you just checked them out and haven't edited anything. +When you first clone a repository, all of your files will be tracked and unmodified because Git just checked them out and you haven't edited anything. ////////////////////////// 워킹 디렉토리의 모든 파일은 크게 Tracked(관리대상임)와 Untracked(관리대상이 아님)로 나눈다. Tracked 파일은 이미 스냅샷에 포함돼 있던 파일이다. Tracked 파일은 또 Unmodified(수정하지 않음)와 Modified(수정함) 그리고 Staged(커밋으로 저장소에 기록할) 상태 중 하나이다. @@ -52,6 +52,7 @@ Clone 한 후에 바로 이 명령을 실행하면 아래과 같은 메시지를 ---- $ git status On branch master +Your branch is up-to-date with 'origin/master'. nothing to commit, working directory clean ---- @@ -80,6 +81,7 @@ If the file didn't exist before, and you run `git status`, you see your untracke $ echo 'My Project' > README $ git status On branch master +Your branch is up-to-date with 'origin/master'. Untracked files: (use "git add ..." to include in what will be committed) @@ -126,6 +128,7 @@ If you run your status command again, you can see that your README file is now t ---- $ git status On branch master +Your branch is up-to-date with 'origin/master'. Changes to be committed: (use "git reset HEAD ..." to unstage) @@ -151,15 +154,16 @@ The `git add` command takes a path name for either a file or a directory; if it' ////////////////////////// Let's change a file that was already tracked. -If you change a previously tracked file called ``CONTRIBUTING.md'' and then run your `git status` command again, you get something that looks like this: +If you change a previously tracked file called `CONTRIBUTING.md` and then run your `git status` command again, you get something that looks like this: ////////////////////////// 이미 Tracked 상태인 파일을 수정하는 법을 알아보자. -``CONTRIBUTING.md'' 라는 파일을 수정하고 나서 `git status` 명령을 다시 실행하면 결과는 아래와 같다. +`CONTRIBUTING.md` 라는 파일을 수정하고 나서 `git status` 명령을 다시 실행하면 결과는 아래와 같다. [source,console] ---- $ git status On branch master +Your branch is up-to-date with 'origin/master'. Changes to be committed: (use "git reset HEAD ..." to unstage) @@ -174,23 +178,24 @@ Changes not staged for commit: ---- ////////////////////////// -The ``CONTRIBUTING.md'' file appears under a section named ``Changes not staged for commit'' – which means that a file that is tracked has been modified in the working directory but not yet staged. +The `CONTRIBUTING.md` file appears under a section named ``Changes not staged for commit'' – which means that a file that is tracked has been modified in the working directory but not yet staged. To stage it, you run the `git add` command. `git add` is a multipurpose command – you use it to begin tracking new files, to stage files, and to do other things like marking merge-conflicted files as resolved. It may be helpful to think of it more as ``add this content to the next commit'' rather than ``add this file to the project''.(((git commands, add))) -Let's run `git add` now to stage the ``CONTRIBUTING.md'' file, and then run `git status` again: +Let's run `git add` now to stage the `CONTRIBUTING.md` file, and then run `git status` again: ////////////////////////// -이 ``CONTRIBUTING.md'' 파일은 ``Changes not staged for commit''에 있다. 이것은 수정한 파일이 Tracked 상태이지만 아직 Staged 상태는 아니라는 것이다. +이 `CONTRIBUTING.md` 파일은 ``Changes not staged for commit''에 있다. 이것은 수정한 파일이 Tracked 상태이지만 아직 Staged 상태는 아니라는 것이다. Staged 상태로 만들려면 `git add` 명령을 실행해야 한다. `git add` 명령은 파일을 새로 추적할 때도 사용하고 수정한 파일을 Staged 상태로 만들 때도 사용한다. Merge 할 때 충돌난 상태의 파일을 Resolve 상태로 만들때도 사용한다. add의 의미는 프로젝트에 파일을 추가한다기 보다는 다음 커밋에 추가한다고 받아들이는게 좋다.(((git commands, add))) -`git add` 명령을 실행하여 ``CONTRIBUTING.md'' 파일을 Staged 상태로 만들고 `git status` 명령으로 결과를 확인해보자. +`git add` 명령을 실행하여 `CONTRIBUTING.md` 파일을 Staged 상태로 만들고 `git status` 명령으로 결과를 확인해보자. [source,console] ---- $ git add CONTRIBUTING.md $ git status On branch master +Your branch is up-to-date with 'origin/master'. Changes to be committed: (use "git reset HEAD ..." to unstage) @@ -215,6 +220,7 @@ However, let's run `git status` one more time: $ vim CONTRIBUTING.md $ git status On branch master +Your branch is up-to-date with 'origin/master'. Changes to be committed: (use "git reset HEAD ..." to unstage) @@ -249,6 +255,7 @@ If you modify a file after you run `git add`, you have to run `git add` again to $ git add CONTRIBUTING.md $ git status On branch master +Your branch is up-to-date with 'origin/master'. Changes to be committed: (use "git reset HEAD ..." to unstage) @@ -282,12 +289,12 @@ 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. +There are two columns to the output - the left-hand column indicates the status of the staging area and the right-hand column indicates the status of the working tree. 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` 표시가 붙는다. -위 명령의 결과는 한 라인에 두 가지 정보를 보여준다. 왼쪽에는 파일의 상태를, 오른쪽에는 해당하는 파일의 이름을 표시한다. +위 명령의 결과에서 상태정보 컬럼에는 두 가지 정보를 보여준다. 왼쪽에는 Staging Area에서의 상태를, 오른쪽에는 Working Tree에서의 상태를 표시한다. `README` 파일 같은 경우 내용을 변경했지만 아직 Staged 상태로 추가하지는 않았다. `lib/simplegit.rb` 파일은 내용을 변경하고 Staged 상태로 추가까지 한 상태이다. 위 결과에서 차이점을 비교해보자. `Rakefile`은 변경하고 Staged 상태로 추가한 후 또 내용을 변경해서 Staged 이면서 Unstaged 상태인 파일이다. @@ -321,7 +328,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 저장소에 커밋하고 싶지 않은 파일을 실수로 커밋하는 일을 방지할 수 있다. @@ -346,7 +353,7 @@ The rules for the patterns you can put in the `.gitignore` file are as follows: ////////////////////////// Glob patterns are like simplified regular expressions that shells use. -An asterisk (`*`) matches zero or more characters; `[abc]` matches any character inside the brackets (in this case a, b, or c); a question mark (`?`) matches a single character; and brackets enclosing characters separated by a hyphen(`[0-9]`) matches any character between them (in this case 0 through 9). +An asterisk (`*`) matches zero or more characters; `[abc]` matches any character inside the brackets (in this case a, b, or c); a question mark (`?`) matches a single character; and brackets enclosing characters separated by a hyphen (`[0-9]`) matches any character between them (in this case 0 through 9). You can also use two asterisks to match nested directories; `a/**/z` would match `a/z`, `a/b/z`, `a/b/c/z`, and so on. ////////////////////////// Glob 패턴은 정규표현식을 단순하게 만든 것으로 생각하면 되고 보통 쉘에서 많이 사용한다. @@ -438,6 +445,7 @@ If you run your `git status` command, you once again see something like this: ---- $ git status On branch master +Your branch is up-to-date with 'origin/master'. Changes to be committed: (use "git reset HEAD ..." to unstage) @@ -520,6 +528,7 @@ $ git add CONTRIBUTING.md $ echo '# test line' >> CONTRIBUTING.md $ git status On branch master +Your branch is up-to-date with 'origin/master'. Changes to be committed: (use "git reset HEAD ..." to unstage) @@ -552,9 +561,9 @@ index 643e24f..87f08c8 100644 ---- ////////////////////////// -and `git diff --cached` to see what you've staged so far (--staged and --cached are synonyms): +and `git diff --cached` to see what you've staged so far (`--staged` and `--cached` are synonyms): ////////////////////////// -Staged 상태인 파일은 `git diff --cached` 옵션으로 확인한다. --staged와 --cached는 같은 옵션이다. +Staged 상태인 파일은 `git diff --cached` 옵션으로 확인한다. `--staged` 와 `--cached` 는 같은 옵션이다. [source,console] ---- @@ -636,6 +645,7 @@ The editor displays the following text (this example is a Vim screen): # Please enter the commit message for your changes. Lines starting # with '#' will be ignored, and an empty message aborts the commit. # On branch master +# Your branch is up-to-date with 'origin/master'. # Changes to be committed: # new file: README # modified: CONTRIBUTING.md @@ -660,7 +670,7 @@ When you exit the editor, Git creates your commit with that commit message (with 내용을 저장하고 편집기를 종료하면 Git은 입력된 내용(#로 시작하는 내용을 제외한)으로 새 커밋을 하나 완성한다. ////////////////////////// -Alternatively, you can type your commit message inline with the `commit` command by specifying it after a -m flag, like this: +Alternatively, you can type your commit message inline with the `commit` command by specifying it after a `-m` flag, like this: ////////////////////////// 메시지를 인라인으로 첨부할 수도 있다. `commit` 명령을 실행할 때 아래와 같이 `-m` 옵션을 사용한다. @@ -707,6 +717,7 @@ Staging Area는 커밋할 파일을 정리한다는 점에서 매우 유용하 ---- $ git status On branch master +Your branch is up-to-date with 'origin/master'. Changes not staged for commit: (use "git add ..." to update what will be committed) (use "git checkout -- ..." to discard changes in working directory) @@ -720,9 +731,13 @@ $ git commit -a -m 'added new benchmarks' ---- ////////////////////////// -Notice how you don't have to run `git add` on the ``CONTRIBUTING.md'' file in this case before you commit. +Notice how you don't have to run `git add` on the `CONTRIBUTING.md` file in this case before you commit. +That's because the `-a` flag includes all changed files. +This is convenient, but be careful; sometimes this flag will cause you to include unwanted changes. ////////////////////////// -이 예제에서는 커밋하기 전에 `git add` 명령으로 ``CONTRIBUTING.md'' 파일을 추가하지 않았다는 점을 눈여겨보자. +이 예제에서는 커밋하기 전에 `git add` 명령으로 `CONTRIBUTING.md` 파일을 추가하지 않았다는 점을 눈여겨보자. +`-a` 옵션을 사용하면 모든 파일이 자동으로 추가된다. +편리한 옵션이긴 하지만 주의 깊게 사용해야 한다. 생각 없이 이 옵션을 사용하다 보면 추가하지 말아야 할 변경사항도 추가될 수 있기 때문이다. [[_removing_files]] ////////////////////////// @@ -748,6 +763,7 @@ Git 명령을 사용하지 않고 단순히 워킹 디렉터리에서 파일을 $ rm grit.gemspec $ git status On branch master +Your branch is up-to-date with 'origin/master'. Changes not staged for commit: (use "git add/rm ..." to update what will be committed) (use "git checkout -- ..." to discard changes in working directory) @@ -871,6 +887,7 @@ In fact, if you run something like this and look at the status, you'll see that $ git mv README.md README $ git status On branch master +Your branch is up-to-date with 'origin/master'. Changes to be committed: (use "git reset HEAD ..." to unstage) @@ -891,9 +908,9 @@ $ git add README ////////////////////////// Git figures out that it's a rename implicitly, so it doesn't matter if you rename a file that way or with the `mv` command. -The only real difference is that `mv` is one command instead of three – it's a convenience function. -More important, you can use any tool you like to rename a file, and address the add/rm later, before you commit. +The only real difference is that `git mv` is one command instead of three – it's a convenience function. +More importantly, you can use any tool you like to rename a file, and address the add/rm later, before you commit. ////////////////////////// -`git mv`는 일종의 단축 명령어이다. 이 명령으로 파일이름을 바꿔도 되고 `mv` 명령으로 파일이름을 직접 바꿔도 된다. -단지 Git의 `mv`명령은 편리하게 명령을 세 번 실행해주는 것뿐이다. -어떤 도구로 이름을 바꿔도 상관없다. 중요한 것은 이름을 변경하고 나서 꼭 rm/add 명령을 실행해야 한다는 것뿐이다. +`git mv` 명령은 일종의 단축 명령어이다. 이 명령으로 파일이름을 바꿔도 되고 `mv` 명령으로 파일이름을 직접 바꿔도 된다. +단지 `git mv` 명령은 편리하게 명령을 세 번 실행해주는 것 뿐이다. +어떤 도구로 이름을 바꿔도 상관없다. 중요한 것은 이름을 변경하고 나서 꼭 rm/add 명령을 실행해야 한다는 것 뿐이다. diff --git a/book/02-git-basics/sections/remotes.asc b/book/02-git-basics/sections/remotes.asc index 14204b4a..82718a8d 100644 --- a/book/02-git-basics/sections/remotes.asc +++ b/book/02-git-basics/sections/remotes.asc @@ -100,11 +100,13 @@ Notice that these remotes use a variety of protocols; we'll cover more about thi ==== 리모트 저장소 추가하기 ////////////////////////// -이전 절에서도 리모트 저장소를 추가하는 것에 대해 설명했었지만 수박 겉핥기식으로 살펴봤을 뿐이었다. 여기에서는 리모트 저장소를 추가하는 방법을 자세하게 설명한다.(((git commands, remote))) -새 리모트 저장소를 쉽게 추가할 수 있는데 `git remote add [단축이름] [url]` 명령을 실행한다. +We've mentioned and given some demonstrations of how the 'clone' command implicitly adds the `origin` remote for you. +Here's how to add a new remote explicitly.(((git commands, remote))) +To add a new remote Git repository as a shortname you can reference easily, run `git remote add `: ////////////////////////// -이전 절에서도 리모트 저장소를 추가하는 것에 대해 설명했었지만 수박 겉핥기식으로 살펴봤을 뿐이었다. 여기에서는 리모트 저장소를 추가하는 방법을 자세하게 설명한다.(((git commands, remote))) -새 리모트 저장소를 쉽게 추가할 수 있는데 `git remote add [단축이름] [url]` 명령을 실행한다. +이전 절에서도 'clone' 명령을 묵시적으로 `origin` 리모트 저장소가 어떻게 추가되는지 설명했었지만 수박 겉핥기식으로 살펴봤을 뿐이었다. +여기에서는 리모트 저장소를 추가하는 방법을 자세하게 설명한다.(((git commands, remote))) +기존 워킹 디렉토리에 새 리모트 저장소를 쉽게 추가할 수 있는데 `git remote add [단축이름] [url]` 명령을 사용한다. [source,console] ---- @@ -169,16 +171,16 @@ After you do this, you should have references to all the branches from that remo ////////////////////////// If you clone a repository, the command automatically adds that remote repository under the name ``origin''. So, `git fetch origin` fetches any new work that has been pushed to that server since you cloned (or last fetched from) it. -It's important to note that the `git fetch` command pulls the data to your local repository – it doesn't automatically merge it with any of your work or modify what you're currently working on. +It's important to note that the `git fetch` command only downloads the data to your local repository – it doesn't automatically merge it with any of your work or modify what you're currently working on. You have to merge it manually into your work when you're ready. ////////////////////////// 저장소를 Clone 하면 명령은 자동으로 리모트 저장소를 ``origin''이라는 이름으로 추가한다. -그래서 나중에 `git fetch origin`을 실행하면 Clone 한 이후에(혹은 마지막으로 가져온 이후에) 수정된 것을 모두 가져온다. +그래서 나중에 `git fetch origin` 명령을 실행하면 Clone 한 이후에(혹은 마지막으로 가져온 이후에) 수정된 것을 모두 가져온다. `git fetch` 명령은 리모트 저장소의 데이터를 모두 로컬로 가져오지만, 자동으로 Merge 하지 않는다. 그래서 당신이 로컬에서 하던 작업을 정리하고 나서 수동으로 Merge 해야 한다. ////////////////////////// -If you have a branch set up to track a remote branch (see the next section and <<_git_branching>> for more information), you can use the `git pull` command to automatically fetch and then merge a remote branch into your current branch.(((git commands, pull))) +If your current branch is set up to track a remote branch (see the next section and <<_git_branching>> for more information), you can use the `git pull` command to automatically fetch and then merge that remote branch into your current branch.(((git commands, pull))) This may be an easier or more comfortable workflow for you; and by default, the `git clone` command automatically sets up your local master branch to track the remote master branch (or whatever the default branch is called) on the server you cloned from. Running `git pull` generally fetches data from the server you originally cloned from and automatically tries to merge it into the code you're currently working on. ////////////////////////// @@ -209,7 +211,7 @@ $ git push origin master ////////////////////////// This command works only if you cloned from a server to which you have write access and if nobody has pushed in the meantime. If you and someone else clone at the same time and they push upstream and then you push upstream, your push will rightly be rejected. -You'll have to pull down their work first and incorporate it into yours before you'll be allowed to push. +You'll have to fetch 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 하고 난 이후 아무도 Upstream 저장소에 Push 하지 않았을 때만 사용할 수 있다. @@ -288,7 +290,7 @@ $ git remote show origin ////////////////////////// This command shows which branch is automatically pushed to when you run `git push` while on certain branches. -It also shows you which remote branches on the server you don't yet have, which remote branches you have that have been removed from the server, and multiple branches that are automatically merged when you run `git pull`. +It also shows you which remote branches on the server you don't yet have, which remote branches you have that have been removed from the server, and multiple local branches that are able to merge automatically with their remote-tracking branch when you run `git pull`. ////////////////////////// 브랜치명을 생략하고 `git push` 명령을 실행할 때 어떤 브랜치가 어떤 브랜치로 Push 되는지 보여준다. 또 아직 로컬로 가져오지 않은 리모트 저장소의 브랜치는 어떤 것들이 있는지, 서버에서는 삭제됐지만 아직 가지고 있는 브랜치는 어떤 것인지, `git pull` 명령을 실행했을 때 자동으로 Merge 할 브랜치는 어떤 것이 있는지 보여준다. @@ -314,10 +316,10 @@ paul ---- ////////////////////////// -It's worth mentioning that this changes your remote branch names, too. +It's worth mentioning that this changes all your remote-tracking branch names, too. What used to be referenced at `pb/master` is now at `paul/master`. ////////////////////////// -리모트 저장소의 브랜치 이름도 바뀐다. +로컬에서 관리하던 리모트 저장소의 브랜치 이름도 바뀐다는 점을 생각해두자. 여태까지 `pb/master`로 리모트 저장소 브랜치를 사용했으면 이제는 `paul/master`라고 사용해야 한다. ////////////////////////// diff --git a/book/02-git-basics/sections/undoing.asc b/book/02-git-basics/sections/undoing.asc index 663b0f26..ddc76e2e 100644 --- a/book/02-git-basics/sections/undoing.asc +++ b/book/02-git-basics/sections/undoing.asc @@ -191,8 +191,8 @@ You can see that the changes have been reverted. [IMPORTANT] ////////////////////////// ===== -It's important to understand that `git checkout -- [file]` is a dangerous command. -Any changes you made to that file are gone – you just copied another file over it. +It's important to understand that `git checkout -- ` is a dangerous command. +Any changes you made to that file are gone – Git just copied another file over it Don't ever use this command unless you absolutely know that you don't want the file. ===== ////////////////////////// diff --git a/book/02-git-basics/sections/viewing-history.asc b/book/02-git-basics/sections/viewing-history.asc index 7408cdd4..ad592814 100644 --- a/book/02-git-basics/sections/viewing-history.asc +++ b/book/02-git-basics/sections/viewing-history.asc @@ -204,7 +204,7 @@ a11bef0 - Scott Chacon, 6 years ago : first commit ---- ////////////////////////// -<> lists some of the more useful options that format takes. +<> lists some of the more useful options that `format` takes. ////////////////////////// <> 포맷에서 사용하는 유용한 옵션. @@ -264,10 +264,10 @@ _저자(Author)_ 와 _커미터(Committer)_ 를 구분하는 것이 조금 이 <<_distributed_git>> 에서 이 주제에 대해 자세히 다룰 것이다. ////////////////////////// -The oneline and format options are particularly useful with another `log` option called `--graph`. +The `oneline` and `format` options are particularly useful with another `log` option called `--graph`. This option adds a nice little ASCII graph showing your branch and merge history: ////////////////////////// -`oneline`과 `format` 옵션은 `--graph` 옵션과 함께 사용할 때 더 빛난다. +`oneline` 옵션과 `format` 옵션은 `--graph` 옵션과 함께 사용할 때 더 빛난다. 이 명령은 브랜치와 머지 히스토리를 보여주는 아스키 그래프를 출력한다. [source,console] @@ -426,9 +426,9 @@ In <> 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 merged in the month of October 2008, you can run something like this:(((log filtering))) +For example, if you want to see which commits modifying test files in the Git source code history are merged and were committed by Junio Hamano 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] ---- 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 05a2c8c8..68288a85 100644 --- a/book/03-git-branching/sections/basic-branching-and-merging.asc +++ b/book/03-git-branching/sections/basic-branching-and-merging.asc @@ -185,11 +185,11 @@ Fast-forward ////////////////////////// You'll notice the phrase ``fast-forward'' in that merge. -Because the commit pointed to by the branch you merged in was directly upstream of the commit you're on, Git simply moves the pointer forward. +Because the commit `C4` pointed to by the branch `hotfix` you merged in was directly ahead of the commit `C2` you're on, Git simply moves the pointer forward. 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 과정 없이 그저 최신 커밋으로 이동한다. +`hotfix` 브랜치가 가리키는 `C4` 커밋이 `C2` 커밋에 기반한 브랜치이기 때문에 브랜치 포인터는 Merge 과정 없이 그저 최신 커밋으로 이동한다. 이런 Merge 방식을 'Fast forward'라고 부른다. 다시 말해 A 브랜치에서 다른 B 브랜치를 Merge 할 때 B 브랜치가 A 브랜치 이후의 커밋을 가리키고 있으면 그저 A 브랜치가 B 브랜치와 동일한 커밋을 가리키도록 이동시킬 뿐이다. ////////////////////////// diff --git a/book/03-git-branching/sections/nutshell.asc b/book/03-git-branching/sections/nutshell.asc index 36d23152..b77690a4 100644 --- a/book/03-git-branching/sections/nutshell.asc +++ b/book/03-git-branching/sections/nutshell.asc @@ -121,7 +121,7 @@ $ git branch testing ---- ////////////////////////// -This creates a new pointer at the same commit you're currently on. +This creates a new pointer to the same commit you're currently on. ////////////////////////// 새로 만든 브랜치도 지금 작업하고 있던 마지막 커밋을 가리킨다. @@ -163,9 +163,9 @@ This option is called `--decorate`. [source,console] ---- $ git log --oneline --decorate -f30ab (HEAD, master, testing) add feature #32 - ability to add new -34ac2 fixed bug #1328 - stack overflow under certain conditions -98ca9 initial commit of my project +f30ab (HEAD -> master, testing) add feature #32 - ability to add new formats to the central interface +34ac2 Fixed bug #1328 - stack overflow under certain conditions +98ca9 The initial commit of my project ---- ////////////////////////// diff --git a/book/03-git-branching/sections/remote-branches.asc b/book/03-git-branching/sections/remote-branches.asc index 4b5205f3..f3654c9d 100644 --- a/book/03-git-branching/sections/remote-branches.asc +++ b/book/03-git-branching/sections/remote-branches.asc @@ -7,11 +7,11 @@ (((branches, remote)))(((references, remote))) ////////////////////////// Remote references are references (pointers) in your remote repositories, including branches, tags, and so on. -You can get a full list of remote references explicitly with `git ls-remote (remote)`, or `git remote show (remote)` for remote branches as well as more information. +You can get a full list of remote references explicitly with `git ls-remote [remote]`, or `git remote show [remote]` for remote branches as well as more information. Nevertheless, a more common way is to take advantage of remote-tracking branches. ////////////////////////// 리모트 Refs는 리모트 저장소에 있는 포인터인 레퍼런스다. 리모트 저장소에 있는 브랜치, 태그, 등등을 의미한다. -`git ls-remote (remote)` 명령으로 모든 리모트 Refs를 조회할 수 있다. `git remote show (remote)` 명령은 모든 리모트 브랜치와 그 정보를 보여준다. +`git ls-remote [remote]` 명령으로 모든 리모트 Refs를 조회할 수 있다. `git remote show [remote]` 명령은 모든 리모트 브랜치와 그 정보를 보여준다. 리모트 Refs가 있지만 보통은 리모트 트래킹 브랜치를 사용한다. ////////////////////////// @@ -144,10 +144,10 @@ That way, you can use private branches for work you don't want to share, and pus ////////////////////////// If you have a branch named `serverfix` that you want to work on with others, you can push it up the same way you pushed your first branch. -Run `git push (remote) (branch)`:(((git commands, push))) +Run `git push `:(((git commands, push))) ////////////////////////// `serverfix`라는 브랜치를 다른 사람과 공유할 때도 브랜치를 처음 Push 하는 것과 같은 방법으로 Push 한다. -아래와 같이 `git push (remote) (branch)` 명령을 사용한다.(((git commands, push))) +아래와 같이 `git push ` 명령을 사용한다.(((git commands, push))) [source,console] ---- @@ -250,11 +250,11 @@ This gives you a local branch that you can work on that starts where `origin/ser (((branches, tracking)))(((branches, upstream))) ////////////////////////// -Checking out a local branch from a remote-tracking branch automatically creates what is called a ``tracking branch'' (or sometimes an ``upstream branch''). +Checking out a local branch from a remote-tracking branch automatically creates what is called a ``tracking branch'' (and the branch it tracks is called an ``upstream branch''). Tracking branches are local branches that have a direct relationship to a remote branch. If you're on a tracking branch and type `git pull`, Git automatically knows which server to fetch from and branch to merge into. ////////////////////////// -리모트 트래킹 브랜치를 로컬 브랜치로 Checkout 하면 자동으로 ``트래킹(Tracking) 브랜치''가 만들어진다 (종종 ``Upstream 브랜치'' 라고 부른다). +리모트 트래킹 브랜치를 로컬 브랜치로 Checkout 하면 자동으로 ``트래킹(Tracking) 브랜치''가 만들어진다 (트래킹 하는 대상 브랜치를 ``Upstream 브랜치'' 라고 부른다). 트래킹 브랜치는 리모트 브랜치와 직접적인 연결고리가 있는 로컬 브랜치이다. 트래킹 브랜치에서 `git pull` 명령을 내리면 리모트 저장소로부터 데이터를 내려받아 연결된 리모트 브랜치와 자동으로 Merge 한다. @@ -320,7 +320,7 @@ Branch serverfix set up to track remote branch serverfix from origin. ////////////////////////// .Upstream shorthand ==== -When you have a tracking branch set up, you can reference it with the `@{upstream}` or `@{u}` shorthand. +When you have a tracking branch set up, you can reference its upstream branch with the `@{upstream}` or `@{u}` shorthand. So if you're on the `master` branch and it's tracking `origin/master`, you can say something like `git merge @{u}` instead of `git merge origin/master` if you wish.(((+++@{u}+++)))(((+++@{upstream}+++))) ==== ////////////////////////// @@ -361,12 +361,12 @@ Finally we can see that our `testing` branch is not tracking any remote branch. It's important to note that these numbers are only since the last time you fetched from each server. This command does not reach out to the servers, it's telling you about what it has cached from these servers locally. If you want totally up to date ahead and behind numbers, you'll need to fetch from all your remotes right before running this. -You could do that like this: `$ git fetch --all; git branch -vv` +You could do that like this: `git fetch --all; git branch -vv` ////////////////////////// 여기서 중요한 점은 명령을 실행했을 때 나타나는 결과는 모두 마지막으로 서버에서 데이터를 가져온(fetch) 시점을 바탕으로 계산한다는 점이다. 단순히 이 명령만으로는 서버의 최신 데이터를 반영하지는 않으며 로컬에 저장된 서버의 캐시 데이터를 사용한다. 현재 시점에서 진짜 최신 데이터로 추적 상황을 알아보려면 먼저 서버로부터 최신 데이터를 받아온 후에 추적 상황을 확인해야 한다. -`$ git fetch --all; git branch -vv` 처럼 두 명령을 이어서 사용하는 것이 적당하다 하겠다. +`git fetch --all; git branch -vv` 처럼 두 명령을 이어서 사용하는 것이 적당하다 하겠다. ////////////////////////// ==== Pulling diff --git a/book/04-git-server/sections/git-daemon.asc b/book/04-git-server/sections/git-daemon.asc index 822fe0bb..0fa84266 100644 --- a/book/04-git-server/sections/git-daemon.asc +++ b/book/04-git-server/sections/git-daemon.asc @@ -65,7 +65,6 @@ stop on shutdown exec /usr/bin/git daemon \ --user=git --group=git \ --reuseaddr \ - --detach \ --base-path=/opt/git/ \ /opt/git/ respawn diff --git a/book/04-git-server/sections/git-on-a-server.asc b/book/04-git-server/sections/git-on-a-server.asc index 4f06975d..38319ae6 100644 --- a/book/04-git-server/sections/git-on-a-server.asc +++ b/book/04-git-server/sections/git-on-a-server.asc @@ -69,32 +69,32 @@ It takes the Git repository by itself, without a working directory, and creates ////////////////////////// Now that you have a bare copy of your repository, all you need to do is put it on a server and set up your protocols. -Let's say you've set up a server called `git.example.com` that you have SSH access to, and you want to store all your Git repositories under the `/opt/git` directory. -Assuming that `/opt/git` exists on that server, you can set up your new repository by copying your bare repository over: +Let's say you've set up a server called `git.example.com` that you have SSH access to, and you want to store all your Git repositories under the `/srv/git` directory. +Assuming that `/srv/git` exists on that server, you can set up your new repository by copying your bare repository over: ////////////////////////// Bare 저장소는 이제 만들었으니까 서버에 넣고 프로토콜을 설정한다. -`git.example.com`라는 이름의 서버를 하나 준비하자. 그리고 그 서버에 SSH로 접속할 수 있게 만들고 Git 저장소를 `/opt/git` 디렉토리에 저장할 것이다. -서버에 `/opt/git` 디렉토리가 있다고 가정하고 아래와 같이 Bare 저장소를 복사한다. +`git.example.com`라는 이름의 서버를 하나 준비하자. 그리고 그 서버에 SSH로 접속할 수 있게 만들고 Git 저장소를 `/srv/git` 디렉토리에 저장할 것이다. +서버에 `/srv/git` 디렉토리가 있다고 가정하고 아래와 같이 Bare 저장소를 복사한다. [source,console] ---- -$ scp -r my_project.git user@git.example.com:/opt/git +$ scp -r my_project.git user@git.example.com:/srv/git ---- ////////////////////////// -At this point, other users who have SSH access to the same server which has read-access to the `/opt/git` directory can clone your repository by running +At this point, other users who have SSH access to the same server which has read-access to the `/srv/git` directory can clone your repository by running ////////////////////////// -이제 다른 사용자들은 SSH로 서버에 접근해서 저장소를 Clone 할 수 있다. 사용자는 `/opt/git` 디렉토리에 읽기 권한이 있어야 한다. +이제 다른 사용자들은 SSH로 서버에 접근해서 저장소를 Clone 할 수 있다. 사용자는 `/srv/git` 디렉토리에 읽기 권한이 있어야 한다. [source,console] ---- -$ git clone user@git.example.com:/opt/git/my_project.git +$ git clone user@git.example.com:/srv/git/my_project.git ---- ////////////////////////// If a user SSHs into a server and has write access to the `/opt/git/my_project.git` directory, they will also automatically have push access. ////////////////////////// -이 서버에 SSH로 접근할 수 있는 사용자가 `/opt/git/my_project.git` 디렉토리에 쓰기 권한까지 가지고 있으면 바로 Push 할 수 있다. +이 서버에 SSH로 접근할 수 있는 사용자가 `/srv/git/my_project.git` 디렉토리에 쓰기 권한까지 가지고 있으면 바로 Push 할 수 있다. ////////////////////////// Git will automatically add group write permissions to a repository properly if you run the `git init` command with the `--shared` option.(((git commands, init, bare))) @@ -104,7 +104,7 @@ Git will automatically add group write permissions to a repository properly if y [source,console] ---- $ ssh user@git.example.com -$ cd /opt/git/my_project.git +$ cd /srv/git/my_project.git $ git init --bare --shared ---- diff --git a/book/05-distributed-git/sections/contributing.asc b/book/05-distributed-git/sections/contributing.asc index e933ba02..d071a31e 100644 --- a/book/05-distributed-git/sections/contributing.asc +++ b/book/05-distributed-git/sections/contributing.asc @@ -525,7 +525,7 @@ image::images/small-team-7.png[Jessica가 서버로 Push 하고 난 후의 저 ////////////////////////// That is one of the simplest workflows. You work for a while, generally in a topic branch, and merge into your master branch when it's ready to be integrated. -When you want to share that work, you merge it into your own master branch, then fetch and merge `origin/master` if it has changed, and finally push to the `master` branch on the server. +When you want to share that work, you fetch and merge your master from `origin/master` if it has changed, and finally push to the `master` branch on the server. The general sequence is something like this: ////////////////////////// 매우 간단한 상황의 예제를 살펴보았다. diff --git a/book/05-distributed-git/sections/maintaining.asc b/book/05-distributed-git/sections/maintaining.asc index b076ffd2..f0c47194 100644 --- a/book/05-distributed-git/sections/maintaining.asc +++ b/book/05-distributed-git/sections/maintaining.asc @@ -659,7 +659,7 @@ If you want to pull commit `e43a6` into your master branch, you can run [source,console] ---- -$ git cherry-pick e43a6fd3e94888d76779ad79fb568ed180e5fcdf +$ git cherry-pick e43a6 Finished one cherry-pick. [master]: created a0a41a9: "More friendly message when locking the index fails." 3 files changed, 17 insertions(+), 3 deletions(-) diff --git a/book/07-git-tools/git-credential-read-only b/book/07-git-tools/git-credential-read-only index ec8f4d1f..b98833c4 100755 --- a/book/07-git-tools/git-credential-read-only +++ b/book/07-git-tools/git-credential-read-only @@ -22,7 +22,7 @@ end File.readlines(path).each do |fileline| # <4> prot,user,pass,host = fileline.scan(/^(.*?):\/\/(.*?):(.*?)@(.*)$/).first - if prot == known['protocol'] and host == known['host'] then + if prot == known['protocol'] and host == known['host'] and user == known['username'] then puts "protocol=#{prot}" puts "host=#{host}" puts "username=#{user}" diff --git a/book/07-git-tools/sections/credentials.asc b/book/07-git-tools/sections/credentials.asc index 60ef95ba..b21064de 100644 --- a/book/07-git-tools/sections/credentials.asc +++ b/book/07-git-tools/sections/credentials.asc @@ -69,7 +69,7 @@ Here's an example of how you'd configure the ``store'' helper with a custom file [source,console] ---- -$드 git config --global credential.helper store --file ~/.my-credentials +$ git config --global credential.helper 'store --file ~/.my-credentials' ---- //////////////////// @@ -330,7 +330,7 @@ Since its name starts with ``git-'', we can use the simple syntax for the config [source,console] ---- -$ git config --global credential.helper read-only --file /mnt/shared/creds +$ git config --global credential.helper 'read-only --file /mnt/shared/creds' ---- //////////////////// diff --git a/book/07-git-tools/sections/rewriting-history.asc b/book/07-git-tools/sections/rewriting-history.asc index 8cf1bea4..2516c416 100644 --- a/book/07-git-tools/sections/rewriting-history.asc +++ b/book/07-git-tools/sections/rewriting-history.asc @@ -422,12 +422,12 @@ This occurs fairly commonly. Someone accidentally commits a huge binary file with a thoughtless `git add .`, and you want to remove it everywhere. Perhaps you accidentally committed a file that contained a password, and you want to make your project open source. `filter-branch` is the tool you probably want to use to scrub your entire history. -To remove a file named passwords.txt from your entire history, you can use the `--tree-filter` option to `filter-branch`: +To remove a file named `passwords.txt` from your entire history, you can use the `--tree-filter` option to `filter-branch`: ////////////////////////// 갑자기 누군가 생각 없이 `git add .` 같은 명령을 실행해서 공룡 똥 덩어리를 커밋했거나 실수로 암호가 포함된 파일을 커밋해서 이런 파일을 다시 삭제해야 하는 상황을 살펴보자. 이런 상황은 생각보다 자주 발생한다. `filter-branch`는 히스토리 전체에서 필요한 것만 골라내는 데 사용하는 도구다. -`filter-branch`의 `--tree-filter`라는 옵션을 사용하면 히스토리에서 passwords.txt라는 파일을 아예 제거할 수 있다. +`filter-branch`의 `--tree-filter`라는 옵션을 사용하면 히스토리에서 `passwords.txt` 파일을 아예 제거할 수 있다. [source,console] ---- @@ -438,11 +438,11 @@ Ref 'refs/heads/master' was rewritten ////////////////////////// The `--tree-filter` option runs the specified command after each checkout of the project and then recommits the results. -In this case, you remove a file called passwords.txt from every snapshot, whether it exists or not. +In this case, you remove a file called `passwords.txt` from every snapshot, whether it exists or not. If you want to remove all accidentally committed editor backup files, you can run something like `git filter-branch --tree-filter 'rm -f *~' HEAD`. ////////////////////////// `--tree-filter` 옵션은 프로젝트를 Checkout 한 후에 각 커밋에 명시한 명령을 실행시키고 그 결과를 다시 커밋한다. -이 경우에는 각 스냅샷에 passwords.txt라는 파일이 있으면 그 파일을 삭제한다. +이 경우에는 각 스냅샷에 `passwords.txt` 파일이 있으면 그 파일을 삭제한다. 실수로 편집기의 백업파일을 커밋했으면 `git filter-branch --tree-filter 'rm -f *~' HEAD`라고 실행해서 삭제할 수 있다. ////////////////////////// @@ -460,10 +460,10 @@ To run `filter-branch` on all your branches, you can pass `--all` to the command ===== 하위 디렉토리를 루트 디렉토리로 만들기 ////////////////////////// -Suppose you’ve done an import from another source control system and have subdirectories that make no sense (trunk, tags, and so on). +Suppose you’ve done an import from another source control system and have subdirectories that make no sense (`trunk`, `tags`, and so on). If you want to make the `trunk` subdirectory be the new project root for every commit, `filter-branch` can help you do that, too: ////////////////////////// -다른 VCS에서 코드를 임포트하면 그 VCS만을 위한 디렉토리가 있을 수 있다. SVN에서 코드를 임포트하면 trunk, tags, branch 디렉토리가 포함된다. +다른 VCS에서 코드를 임포트하면 그 VCS만을 위한 디렉토리가 있을 수 있다. SVN에서 코드를 임포트하면 `trunk`, `tags`, `branch` 디렉토리가 포함된다. 모든 커밋에 대해 `trunk` 디렉토리를 프로젝트 루트 디렉토리로 만들 때도 `filter-branch` 명령이 유용하다. [source,console] diff --git a/book/07-git-tools/sections/stashing-cleaning.asc b/book/07-git-tools/sections/stashing-cleaning.asc index e11d01eb..15cff3f5 100644 --- a/book/07-git-tools/sections/stashing-cleaning.asc +++ b/book/07-git-tools/sections/stashing-cleaning.asc @@ -102,13 +102,15 @@ Stash 두 개는 원래 있었다. 그래서 현재 총 세 개의 Stash를 사 [source,console] ---- $ git stash apply -# On branch master -# Changed but not updated: -# (use "git add ..." to update what will be committed) -# -# modified: index.html -# modified: lib/simplegit.rb -# +On branch master +Changes not staged for commit: + (use "git add ..." to update what will be committed) + (use "git checkout -- ..." to discard changes in working directory) + + modified: index.html + modified: lib/simplegit.rb + +no changes added to commit (use "git add" and/or "git commit -a") ---- ////////////////////////// @@ -134,17 +136,17 @@ Git은 Stash를 적용할 때 Staged 상태였던 파일을 자동으로 다시 [source,console] ---- $ git stash apply --index -# On branch master -# Changes to be committed: -# (use "git reset HEAD ..." to unstage) -# -# modified: index.html -# -# Changed but not updated: -# (use "git add ..." to update what will be committed) -# -# modified: lib/simplegit.rb -# +On branch master +Changes to be committed: + (use "git reset HEAD ..." to unstage) + + modified: index.html + +Changes not staged for commit: + (use "git add ..." to update what will be committed) + (use "git checkout -- ..." to discard changes in working directory) + + modified: lib/simplegit.rb ---- ////////////////////////// @@ -271,19 +273,22 @@ If you want an easier way to test the stashed changes again, you can run `git st [source,console] ---- $ git stash branch testchanges -Switched to a new branch "testchanges" -# On branch testchanges -# Changes to be committed: -# (use "git reset HEAD ..." to unstage) -# -# modified: index.html -# -# Changed but not updated: -# (use "git add ..." to update what will be committed) -# -# modified: lib/simplegit.rb -# -Dropped refs/stash@{0} (f0dfc4d5dc332d1cee34a634182e168c4efc3359) +M index.html +M lib/simplegit.rb +Switched to a new branch 'testchanges' +On branch testchanges +Changes to be committed: + (use "git reset HEAD ..." to unstage) + + modified: index.html + +Changes not staged for commit: + (use "git add ..." to update what will be committed) + (use "git checkout -- ..." to discard changes in working directory) + + modified: lib/simplegit.rb + +Dropped refs/stash@{0} (29d385a81d163dfd45a452a2ce816487a6b8b014) ---- ////////////////////////// diff --git a/book/07-git-tools/sections/submodules.asc b/book/07-git-tools/sections/submodules.asc index 0d403dc4..9c515e44 100644 --- a/book/07-git-tools/sections/submodules.asc +++ b/book/07-git-tools/sections/submodules.asc @@ -530,11 +530,11 @@ So now let's go through an example of making changes to the submodule at the sam /////////// So far, when we've run the `git submodule update` command to fetch changes from the submodule repositories, Git would get the changes and update the files in the subdirectory but will leave the sub-repository in what's called a ``detached HEAD'' state. This means that there is no local working branch (like ``master'', for example) tracking changes. -So any changes you make aren't being tracked well. +With no working branch tracking changes, that means even if you commit changes to the submodule, those changes will quite possibly be lost the next time you run `git submodule update`. You have to do some extra steps if you want changes in a submodule to be tracked. /////////// 서브모듈 저장소에서 `git submodule update` 명령을 실행하면 Git은 서브모듈의 변경 사항을 업데이트한다. 하지만, 서브모듈 로컬 저장소는 ``Detached HEAD'' 상태로 남는다. 이 말은 변경 내용을 추적하는 로컬 브랜치(예를 들자면 ``master''같은)가 없다는 것이다. -서브모듈 수정사항을 제대로 추적할 수 없게 된다. +변경 내용을 추적하는 브랜치 없이 서브모듈에서 수정 작업을 하게 되면 이후에 `git submodule update` 명령을 실행했을 때 수정한 내용을 잃어버릴 수 있다. 서브모듈 안에서 수정사항을 추적하려면 다른 작업이 좀 더 필요하다. /////////// In order to set up your submodule to be easier to go in and hack on, you need do two things. diff --git a/book/07-git-tools/sections/subtree-merges.asc b/book/07-git-tools/sections/subtree-merges.asc index abf6bd5d..1c03e669 100644 --- a/book/07-git-tools/sections/subtree-merges.asc +++ b/book/07-git-tools/sections/subtree-merges.asc @@ -26,7 +26,7 @@ Rack 프로젝트의 리모트 저장소를 현재 프로젝트의 리모트로 [source,console] ---- $ git remote add rack_remote https://github.com/rack/rack -$ git fetch rack_remote +$ git fetch rack_remote --no-tags warning: no common commits remote: Counting objects: 3184, done. remote: Compressing objects: 100% (1465/1465), done. diff --git a/book/08-customizing-git/sections/attributes.asc b/book/08-customizing-git/sections/attributes.asc index 4fa3d8b9..5ad0c3cb 100644 --- a/book/08-customizing-git/sections/attributes.asc +++ b/book/08-customizing-git/sections/attributes.asc @@ -191,15 +191,26 @@ It's not perfect – formatting changes wouldn't show up here – but it certain ////////////////////////// Another interesting problem you can solve this way involves diffing image files. One way to do this is to run image files through a filter that extracts their EXIF information – metadata that is recorded with most image formats. -If you download and install the `exiftool` program, you can use it to convert your images into text about the metadata, so at least the diff will show you a textual representation of any changes that happened: +If you download and install the `exiftool` program, you can use it to convert your images into text about the metadata, so at least the diff will show you a textual representation of any changes that happened. +Put the following line in your `.gitattributes` file: ////////////////////////// 이 방법으로 이미지 파일도 Diff 할 수 있다. 필터로 EXIF 정보를 추출해서 이미지 파일을 비교한다. EXIF 정보는 대부분의 이미지 파일에 들어 있는 메타데이터다. -`exiftool`이라는 프로그램을 설치하고 이미지 파일에서 메타데이터 텍스트를 추출한다. 그리고 그 결과를 Diff 해서 무엇이 달라졌는지 본다. +`exiftool` 프로그램을 설치하고 이미지 파일에서 메타데이터 텍스트를 추출한다. 그리고 그 결과를 Diff 해서 무엇이 달라졌는지 본다. +다음 내용을 `.gitattributes` 파일로 저장한다. + +[source,ini] +---- +*.png diff=exif +---- + +////////////////////////// +Configure Git to use this tool: +////////////////////////// +Git에서 위 설정을 사용하려면 다음과 같이 설정한다. [source,console] ---- -$ echo '*.png diff=exif' >> .gitattributes $ git config diff.exif.textconv exiftool ---- @@ -256,15 +267,26 @@ Git은 먼저 체크섬을 계산하고 커밋하기 때문에 그 커밋에 대 ////////////////////////// First, you can inject the SHA-1 checksum of a blob into an `$Id$` field in the file automatically. If you set this attribute on a file or set of files, then the next time you check out that branch, Git will replace that field with the SHA-1 of the blob. -It's important to notice that it isn't the SHA of the commit, but of the blob itself: +It's important to notice that it isn't the SHA-1 of the commit, but of the blob itself. +Put the following line in your `.gitattributes` file: ////////////////////////// 파일 안에 `$Id$` 필드를 넣으면 Blob의 SHA-1 체크섬을 자동으로 삽입한다. 이 필드를 파일에 넣으면 Git은 앞으로 Checkout 할 때 해당 Blob의 SHA-1 값으로 교체한다. 여기서 꼭 기억해야 할 것이 있다. 교체되는 체크섬은 커밋의 것이 아니라 Blob 그 자체의 SHA-1 체크섬이다. +다음 내용을 `.gitattributes` 파일로 저장한다. + +[source,ini] +---- +*.txt ident +---- + +////////////////////////// +Add an `$Id$` reference to a test file: +////////////////////////// +테스트 할 파일에 `$Id$` 레퍼런스를 넣고 저장한다. [source,console] ---- -$ echo '*.txt ident' >> .gitattributes $ echo '$Id$' > test.txt ---- @@ -383,15 +405,19 @@ $ git config filter.dater.clean 'perl -pe "s/\\\$Date[^\\\$]*\\\$/\\\$Date\\\$/" ////////////////////////// This Perl snippet strips out anything it sees in a `$Date$` string, to get back to where you started. -Now that your filter is ready, you can test it by setting up a file with your `$Date$` keyword and then setting up a Git attribute for that file that engages the new filter: +Now that your filter is ready, you can test it by setting up a Git attribute for that file that engages the new filter and creating a file with your `$Date$` keyword: ////////////////////////// 이 Perl 코드는 `$Date$` 스트링에 있는 문자를 제거해서 원래대로 복원한다. 이제 필터가 준비됐으니 `$Date$` 키워드가 들어 있는 파일을 만들고 Git Attribute를 설정하고 새 필터를 시험해보자. +[source,ini] +---- +date*.txt filter=dater +---- + [source,console] ---- $ echo '# $Date$' > date_test.txt -$ echo 'date*.txt filter=dater' >> .gitattributes ---- ////////////////////////// @@ -467,12 +493,16 @@ When exporting files for deployment you can apply `git log`'s formatting and key ////////////////////////// For instance, if you want to include a file named `LAST_COMMIT` in your project, and have metadata about the last commit automatically injected into it when `git archive` runs, you can for example set up the file like this: ////////////////////////// -`git archive` 명령을 실행할 때 자동으로 마지막 커밋의 메타데이터가 자동으로 삽입되게 할 수 있다. 예를 들어 `LAST_COMMIT`이라는 파일을 아래와 같이 만든다. +`git archive` 명령을 실행할 때 자동으로 마지막 커밋의 메타데이터가 자동으로 삽입되게 할 수 있다. 예를 들어 `.gitattributes` 파일과 `LAST_COMMIT` 파일을 아래와 같이 만든다. + +[source,ini] +---- +LAST_COMMIT export-subst +---- [source,console] ---- $ echo 'Last commit date: $Format:%cd by %aN$' > LAST_COMMIT -$ echo "LAST_COMMIT export-subst" >> .gitattributes $ git add LAST_COMMIT .gitattributes $ git commit -am 'adding LAST_COMMIT file for archives' ---- @@ -489,8 +519,9 @@ $ cat ../deployment-testing/LAST_COMMIT Last commit date: Tue Apr 21 08:38:48 2009 -0700 by Scott Chacon ---- +////////////////////////// The substitutions can include for example the commit message and any git notes, and git log can do simple word wrapping: - +////////////////////////// 이 키워드 치환 기능으로 커밋 메시지와 Git 노트, Git Log도 넣을 수 있다. 어렵지 않다. [source,console] @@ -510,8 +541,9 @@ Last commit: 312ccc8 by Jim Hill at Fri May 8 09:14:04 2015 -0700 strips the surrounding `$Format:` and `$` markup from the output. ---- +////////////////////////// The resulting archive is suitable for deployment work, but like any exported archive it isn't suitable for further development work. - +////////////////////////// 이 아카이브 기능은 개발할 때가 아니라 배포할 때 좋다. ////////////////////////// @@ -563,4 +595,4 @@ Merge made by recursive. ////////////////////////// In this case, `database.xml` stays at whatever version you originally had. ////////////////////////// -Merge 했지만 `database.xml`은 원래 가지고 있던 파일 그대로다. +Merge 했지만 `database.xml` 파일은 원래 가지고 있던 파일 그대로다. diff --git a/book/08-customizing-git/sections/config.asc b/book/08-customizing-git/sections/config.asc index e586f932..31f9934e 100644 --- a/book/08-customizing-git/sections/config.asc +++ b/book/08-customizing-git/sections/config.asc @@ -244,6 +244,7 @@ If you create a `~/.gitignore_global` file with these contents: [source,ini] ---- *~ +.*.swp .DS_Store ---- @@ -389,12 +390,12 @@ P4Merge는 중요 플랫폼을 모두 지원하기 때문에 웬만한 환경이 여기서는 Mac과 Linux 시스템에 설치하는 것을 보여준다. Windows에서 사용하려면 `/usr/local/bin` 경로만 Windows 경로로 바꿔준다. ////////////////////////// -To begin, download P4Merge from http://www.perforce.com/downloads/Perforce/[]. +To begin, https://www.perforce.com/product/components/perforce-visual-merge-and-diff-tools[download P4Merge from Perforce]. Next, you'll set up external wrapper scripts to run your commands. I'll use the Mac path for the executable; in other systems, it will be where your `p4merge` binary is installed. Set up a merge wrapper script named `extMerge` that calls your binary with all the arguments provided: ////////////////////////// -먼저 http://www.perforce.com/downloads/Perforce/[] 에서 P4Merge를 내려받는다. +먼저 https://www.perforce.com/product/components/perforce-visual-merge-and-diff-tools[] 에서 P4Merge를 내려받는다. 그 후에 P4Merge 에 쓸 Wrapper 스크립트를 만든다. 필자는 Mac 사용자라서 Mac 경로를 사용한다. 어떤 시스템이든 `p4merge`가 설치된 경로를 사용하면 된다. 예제에서는 `extMerge`라는 Merge 용 Wrapper 스크립트를 만들고 이 스크립트로 넘어오는 모든 아규먼트를 p4merge 프로그램으로 넘긴다. diff --git a/book/08-customizing-git/sections/policy.asc b/book/08-customizing-git/sections/policy.asc index 71b10868..546912bd 100644 --- a/book/08-customizing-git/sections/policy.asc +++ b/book/08-customizing-git/sections/policy.asc @@ -261,9 +261,11 @@ Now that you have the permissions sorted out, you need to determine what paths t 이렇게 사용할 권한 정보를 만들었다. 이제 Push 하는 파일을 그 사용자가 Push 할 수 있는지 없는지 알아내야 한다. ////////////////////////// -You can pretty easily see what files have been modified in a single commit with the `--name-only` option to the `git log` command (mentioned briefly in Chapter 2): +You can pretty easily see what files have been modified in a single commit with the `--name-only` option to the `git log` command +(mentioned briefly in <<_git_basics_chapter>>) ////////////////////////// -`git log` 명령에 `--name-only` 옵션을 주면 해당 커밋에서 수정된 파일이 뭔지 알려준다. (`git log` 명령은 **2장**에서 다루었다) +`git log` 명령에 `--name-only` 옵션을 주면 해당 커밋에서 수정된 파일이 뭔지 알려준다. +(`git log` 명령은 <<_git_basics_chapter>>에서 다루었다) [source,console] ---- @@ -628,9 +630,9 @@ end ---- ////////////////////////// -This script uses a syntax that wasn't covered in the Revision Selection section of Chapter 6. You get a list of commits that have already been pushed up by running this: +This script uses a syntax that wasn't covered in <<_revision_selection>>. You get a list of commits that have already been pushed up by running this: ////////////////////////// -이 스크립트는 6장 '리비전 조회하기' 절에서 설명하지 않은 표현을 사용했다. 아래의 표현은 이미 Push 한 커밋 목록을 얻어오는 부분이다. +이 스크립트는 <<_revision_selection>> 절에서 설명하지 않은 표현을 사용했다. 아래의 표현은 이미 Push 한 커밋 목록을 얻어오는 부분이다. [source,ruby] ---- diff --git a/book/09-git-and-other-scms/sections/import-svn.asc b/book/09-git-and-other-scms/sections/import-svn.asc index 3dc80114..85242323 100644 --- a/book/09-git-and-other-scms/sections/import-svn.asc +++ b/book/09-git-and-other-scms/sections/import-svn.asc @@ -44,19 +44,19 @@ $ svn log --xml | grep author | sort -u | \ ////////////////////////// That generates the log output in XML format, then keeps only the lines with author information, discards duplicates, strips out the XML tags. (Obviously this only works on a machine with `grep`, `sort`, and `perl` installed.) -Then, redirect that output into your users.txt file so you can add the equivalent Git user data next to each entry. +Then, redirect that output into your `users.txt` file so you can add the equivalent Git user data next to each entry. ////////////////////////// 우선 XML 형식으로 SVN 로그를 출력하고, 거기서 Author 정보만 찾고, 중복된 것을 제거하고, XML 태그는 버린다. 물론 `grep`, `sort`, `perl` 명령이 동작하는 시스템에서만 이 명령을 사용할 수 있다. -이 결과에 Git Author 정보를 더해서 `users.txt`를 만든다. +이 결과에 Git Author 정보를 더해서 `users.txt` 파일을 만든다. ////////////////////////// You can provide this file to `git svn` to help it map the author data more accurately. -You can also tell `git svn` not to include the metadata that Subversion normally imports, by passing `--no-metadata` to the `clone` or `init` command. +You can also tell `git svn` not to include the metadata that Subversion normally imports, by passing `--no-metadata` to the `clone` or `init` command (though if you want to keep the synchronisation-metadata, feel free to omit this parameter). This makes your `import` command look like this: ////////////////////////// 이 파일을 `git svn` 명령에 전달하면 보다 정확한 Author 정보를 Git 저장소에 남길 수 있다. -그리고 `git svn`의 `clone`이나 `init` 명령에 `--no-metadata` 옵션을 주면 Subversion의 메타데이터를 저장하지 않는다. +그리고 `git svn` 명령의 `clone` 또는 `init` 명령에 `--no-metadata` 옵션을 주면 Subversion의 메타데이터를 저장하지 않는다 (기존 메타데이터를 유지하려면 이 옵션을 사용하지 않아도 괜찮다). 해당 명령은 아래와 같다. [source,console] @@ -135,16 +135,34 @@ Next, move the rest of the references under `refs/remotes` to be local branches: [source,console] ---- -$ cp -Rf .git/refs/remotes/* .git/refs/heads/ -$ rm -Rf .git/refs/remotes +$ cp -Rf .git/refs/remotes/origin/* .git/refs/heads/ +$ rm -Rf .git/refs/remotes/origin ---- +////////////////////////// +It may happen that you'll see some extra branches which are suffixed by `@xxx` (where xxx is a number), while in Subversion you only see one branch. This is actually a Subversion feature called "peg-revisions", which is something that Git simply has no syntactical counterpart for. Hence, `git svn` simply adds the svn version number to the branch name just in the same way as you would have written it in svn to address the peg-revision of that branch. If you do not care anymore about the peg-revisions, simply remove them using `git branch -d`. +////////////////////////// +대개 Subversion에서는 브랜치 하나만 보일 진데 `@xxx` (xxx는 숫자) 문자로 끝나는 몇가지 브랜치가 더 보일 것이다. 이런 이름의 브랜치가 존재하는 것은 "peg-revisions" 이라 부르는 Subversion의 기능 때문이며 Git에서는 마땅이 대응되는 기능이 없다. Subversion에서 peg-revision을 다루기 위해 브랜치 이름 뒤에 버전 숫자를 붙인 것 처럼 `git snv` 역시 그렇게 하는 것이다. peg-revision 기능을 사용하지 않는다면 `git branch -d` 명령으로 브랜치를 삭제할 수 있다. + ////////////////////////// Now all the old branches are real Git branches and all the old tags are real Git tags. +////////////////////////// +이제 모든 태그와 브랜치는 진짜 Git 태그와 브랜치가 됐다. + +////////////////////////// +There's one last thing to clean up. Unfortunately, `git svn` creates an extra branch named `trunk`, which maps to Subversion's default branch, but the `trunk` ref points to the same place as `master`. Since `master` is more idiomatically Git, here's how to remove the extra branch: +////////////////////////// +마지막으로 마무리를 위한 과정이 하나 남았다. 안타깝게도 `git svn` 명령이 만드는 Subversion의 기본 브랜치인 `trunk` 브랜치가 있다. `trunk` 브랜치는 Git의 `master` 역할을 한다고 보면 된다. Git에는 `master` 브랜치가 있기 때문에 여분의 `trunk` 브랜치는 삭제하자. + +[source,console] +---- +$ git branch -d trunk +---- + +////////////////////////// The last thing to do is add your new Git server as a remote and push to it. Here is an example of adding your server as a remote: ////////////////////////// -이제 모든 태그와 브랜치는 진짜 Git 태그와 브랜치가 됐다. Git 서버를 새로 추가를 하고 지금까지 작업한 것을 Push 하는 일이 남았다. 아래처럼 리모트 서버를 추가한다. @@ -160,7 +178,7 @@ Because you want all your branches and tags to go up, you can now run this: [source,console] ---- -$ git push origin --all +$ git push origin --tags ---- ////////////////////////// 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 a8b4defe..f62852eb 100644 --- a/book/09-git-and-other-scms/sections/import-tfs.asc +++ b/book/09-git-and-other-scms/sections/import-tfs.asc @@ -44,18 +44,18 @@ Open the file and find at which characters start and end the column and replace, [source,powershell] ---- -PS> cat AUTHORS_TMP | cut -b 11-20 | tail -n+3 | uniq | sort > AUTHORS +PS> cat AUTHORS_TMP | cut -b 11-20 | tail -n+3 | sort | uniq > AUTHORS ---- //////////// The `cut` command keeps only the characters between 11 and 20 from each line. The `tail` command skips the first two lines, which are field headers and ASCII-art underlines. -The result of all of this is piped to `uniq` to eliminate duplicates, and saved to a file named `AUTHORS`. +The result of all of this is piped to `sort` and `uniq` to eliminate duplicates, and saved to a file named `AUTHORS`. The next step is manual; in order for git-tfs to make effective use of this file, each line must be in this format: //////////// `cut` 명령어는 각 라인에서 11-20의 문자열만 취한다. `tail` 명령어로는 필드 헤더와 밑줄인 윗 두 라인을 건너뛴다. -그 결과를 `uniq`에 파이프로 보내서 중복을 지운다. 그리고는 `AUTHORS` 파일에 저장한다. +그 결과를 `sort`, `uniq` 명령에 파이프로 보내서 중복을 지운다. 그리고는 `AUTHORS` 파일에 저장한다. 그 다음은 수동으로 한다. git-tfs가 필요로 하는 파일의 포맷은 아래와 같다. [source,text] diff --git a/book/10-git-internals/sections/objects.asc b/book/10-git-internals/sections/objects.asc index d2a4d6bf..453e8188 100644 --- a/book/10-git-internals/sections/objects.asc +++ b/book/10-git-internals/sections/objects.asc @@ -227,15 +227,15 @@ image::images/data-model-1.png[단순화한 Git 데이터 모델.] You can fairly easily create your own tree. Git normally creates a tree by taking the state of your staging area or index and writing a series of tree objects from it. So, to create a tree object, you first have to set up an index by staging some files. -To create an index with a single entry – the first version of your test.txt file – you can use the plumbing command `update-index`. -You use this command to artificially add the earlier version of the test.txt file to a new staging area. +To create an index with a single entry – the first version of your `test.txt` file – you can use the plumbing command `update-index`. +You use this command to artificially add the earlier version of the `test.txt` file to a new staging area. You must pass it the `--add` option because the file doesn't yet exist in your staging area (you don't even have a staging area set up yet) and `--cacheinfo` because the file you're adding isn't in your directory but is in your database. Then, you specify the mode, SHA-1, and filename: ////////////////////////// 직접 Tree 개체를 만들어 보자. Git은 일반적으로 Staging Area(Index)의 상태대로 Tree 개체를 만들고 기록한다. 그래서 Tree 개체를 만들려면 우선 Staging Area에 파일을 추가해서 Index를 만들어야 한다. -우선 Plumbing 명령어 `update-index`로 `test.txt` 파일만 들어 있는 Index를 만든다. +우선 Plumbing 명령인 `update-index` 명령으로 `test.txt` 파일만 들어 있는 Index를 만든다. 이 명령어는 파일을 인위적으로 Staging Area에 추가하는 명령이다. 아직 Staging Area에 없는 파일이기 때문에 `--add` 옵션을 꼭 줘야 한다(사실 아직 Staging Area도 설정하지 않았다). 그리고 디렉토리에 있는 파일이 아니라 데이터베이스에 있는 파일을 추가하는 것이기 때문에 `--cacheinfo` 옵션이 필요하다. 파일 모드, SHA-1 해시, 파일 이름 정보도 입력한다. @@ -282,9 +282,9 @@ tree ---- ////////////////////////// -You'll now create a new tree with the second version of test.txt and a new file as well: +You'll now create a new tree with the second version of `test.txt` and a new file as well: ////////////////////////// -파일을 새로 하나 추가하고 test.txt 파일도 두 번째 버전을 만든다. 그리고 나서 Tree 개체를 만든다. +파일을 새로 하나 추가하고 `test.txt` 파일도 두 번째 버전을 만든다. 그리고 나서 Tree 개체를 만든다. [source,console] ---- @@ -294,10 +294,10 @@ $ git update-index --add new.txt ---- ////////////////////////// -Your staging area now has the new version of test.txt as well as the new file new.txt. +Your staging area now has the new version of `test.txt` as well as the new file `new.txt`. Write out that tree (recording the state of the staging area or index to a tree object) and see what it looks like: ////////////////////////// -새 파일인 new.txt와 새로운 버전의 test.txt 파일까지 Staging Area에 추가했다. +새 파일인 `new.txt` 파일과 새로운 버전의 `test.txt` 파일까지 Staging Area에 추가했다. 현재 상태의 Staging Area를 새로운 Tree 개체로 기록하면 어떻게 보이는지 살펴보자. [source,console] @@ -310,12 +310,12 @@ $ git cat-file -p 0155eb4229851634a0f03eb265b69f5a2d56f341 ---- ////////////////////////// -Notice that this tree has both file entries and also that the test.txt SHA is the ``version 2'' SHA from earlier (`1f7a7a`). +Notice that this tree has both file entries and also that the `test.txt` SHA-1 is the ``version 2'' SHA-1 from earlier (`1f7a7a`). Just for fun, you'll add the first tree as a subdirectory into this one. You can read trees into your staging area by calling `read-tree`. In this case, you can read an existing tree into your staging area as a subtree by using the `--prefix` option to `read-tree`: ////////////////////////// -이 Tree 개체에는 파일이 두 개 있고 test.txt 파일의 SHA 값도 두 번째 버전인 `1f7a7a1`이다. +이 Tree 개체에는 파일이 두 개 있고 `test.txt` 파일의 SHA 값도 두 번째 버전인 `1f7a7a1` 이다. 재미난 걸 해보자. 처음에 만든 Tree 개체를 하위 디렉토리로 만들 수 있다. `read-tree` 명령으로 Tree 개체를 읽어 Staging Area에 추가한다. `--prefix` 옵션을 주면 Tree 개체를 하위 디렉토리로 추가할 수 있다. @@ -332,10 +332,10 @@ $ git cat-file -p 3c4e9cd789d88d8d89c1073707c3585e41b0e614 ---- ////////////////////////// -If you created a working directory from the new tree you just wrote, you would get the two files in the top level of the working directory and a subdirectory named `bak` that contained the first version of the test.txt file. +If you created a working directory from the new tree you just wrote, you would get the two files in the top level of the working directory and a subdirectory named `bak` that contained the first version of the `test.txt` file. You can think of the data that Git contains for these structures as being like this: ////////////////////////// -이 Tree 개체로 워킹 디렉토리를 만들면 파일 두 개와 `bak`이라는 하위 디렉토리가 생긴다. 그리고 `bak` 디렉토리 안에는 test.txt 파일의 처음 버전이 들어 있다. +이 Tree 개체로 워킹 디렉토리를 만들면 파일 두 개와 `bak` 이라는 하위 디렉토리가 생긴다. 그리고 `bak` 디렉토리 안에는 `test.txt` 파일의 처음 버전이 들어 있다. 아래와 그림과 같은 구조로 데이터가 저장된다. ////////////////////////// @@ -374,8 +374,12 @@ fdf4fc3344e67ab068f836878b6c4951e3b15f3d ---- ////////////////////////// +You will get a different hash value because of different creation time and author data. +Replace commit and tag hashes with your own checksums further in this chapter. Now you can look at your new commit object with `cat-file`: ////////////////////////// +물론 위의 명령을 실행한 시간이나 Author 정보가 다르기 때문에 Hash 값은 다를 것이다. +이어지는 내용에서 커밋과 태그에 사용하는 해시 값을 위의 값을 그대로 사용하지 말고 독자가 실행해서 얻은 해시 값을 사용해야 한다. 새로 생긴 커밋 개체를 `cat-file` 명령으로 확인해보자. [source,console] diff --git a/book/10-git-internals/sections/packfiles.asc b/book/10-git-internals/sections/packfiles.asc index 538fbd72..e94d8919 100644 --- a/book/10-git-internals/sections/packfiles.asc +++ b/book/10-git-internals/sections/packfiles.asc @@ -38,6 +38,7 @@ Git은 zlib으로 파일 내용을 압축하기 때문에 저장 공간이 많 [source,console] ---- $ curl https://raw.githubusercontent.com/mojombo/grit/master/lib/grit/repo.rb > repo.rb +$ git checkout master $ git add repo.rb $ git commit -m 'added repo.rb' [master 484a592] added repo.rb @@ -112,7 +113,7 @@ $ git cat-file -s b042a60ef7dff760008df33cee372b945b6e884e You have two nearly identical 22K objects on your disk. Wouldn't it be nice if Git could store one of them in full but then the second object only as the delta between it and the first? ////////////////////////// -그럼 약 22K짜리 파일을 두 개 가지게 된다. +그럼 약 22K짜리 파일을 두 개 가지게 된다 (두 파일 각자도 압축하면 약 7K 사이즈). 거의 같은 파일을 두 개나 가지게 되는 것이 못마땅할 수도 있다. 처음 것과 두 번째 것 사이의 차이점만 저장할 수 없을까? ////////////////////////// @@ -164,14 +165,14 @@ Because you never added them to any commits, they're considered dangling and are The other files are your new packfile and an index. The packfile is a single file containing the contents of all the objects that were removed from your filesystem. The index is a file that contains offsets into that packfile so you can quickly seek to a specific object. -What is cool is that although the objects on disk before you ran the `gc` were collectively about 22K in size, the new packfile is only 7K. -You've cut your disk usage by ⅔ by packing your objects. +What is cool is that although the objects on disk before you ran the `gc` were collectively about 15K in size, the new packfile is only 7K. +You've cut your disk usage by half by packing your objects. ////////////////////////// 새로 생긴 파일은 Packfile과 그 Index이다. 파일 시스템에서 삭제된 개체가 전부 이 Packfile에 저장된다. Index 파일에 대해서는 빠르게 찾을 수 있도록 Packfile에 오프셋이 들어 있다. -`gc` 명령을 실행하기 전에 있던 파일 크기는 약 22K 정도였었는데 새로 만들어진 Packfile은 겨우 7K에 불과하다. 짱이다. -개체를 압축하여 디스크 사용량이 ⅔으로 줄었다. +`gc` 명령을 실행하기 전에 있던 파일 크기는 약 15K 정도였었는데 새로 만들어진 Packfile은 겨우 7K에 불과하다. 짱이다. +개체를 압축하여 디스크 사용량이 반 정도로 줄었다. ////////////////////////// How does Git do this? diff --git a/book/10-git-internals/sections/transfer-protocols.asc b/book/10-git-internals/sections/transfer-protocols.asc index 05ccb9da..64cbea30 100644 --- a/book/10-git-internals/sections/transfer-protocols.asc +++ b/book/10-git-internals/sections/transfer-protocols.asc @@ -323,10 +323,10 @@ HTTP를 통해 데이터를 업로드하는 과정도 크게 다르지 않지만 ////////////////////////// That's the end of the first client-server exchange. -The client then makes another request, this time a `POST`, with the data that `git-upload-pack` provides. +The client then makes another request, this time a `POST`, with the data that `send-pack` provides. ////////////////////////// 첫 번째 클라이언트 요청과 서버의 응답이다. -이어지는 클라이언트 요청은 `POST` 메소드를 써서 `git-upload-pack`이 제공하는 데이터를 서버로 전송하는 요청이다. +이어지는 클라이언트 요청은 `POST` 메소드를 써서 `send-pack` 명령이 제공하는 데이터를 서버로 전송하는 요청이다. [source] ---- diff --git a/book/B-embedding-git/sections/libgit2.asc b/book/B-embedding-git/sections/libgit2.asc index 280759d0..c86c5750 100644 --- a/book/B-embedding-git/sections/libgit2.asc +++ b/book/B-embedding-git/sections/libgit2.asc @@ -1,6 +1,6 @@ === Libgit2 -(((libgit2)))(((C))) +(((libgit2)))((("C"))) ////////////////////////// Another option at your disposal is to use Libgit2. Libgit2 is a dependency-free implementation of Git, with a focus on having a nice API for use within other programs.