diff --git a/book/01-introduction/sections/basics.asc b/book/01-introduction/sections/basics.asc index 45403f4e..4317766a 100644 --- a/book/01-introduction/sections/basics.asc +++ b/book/01-introduction/sections/basics.asc @@ -78,7 +78,7 @@ Because you have the entire history of the project right there on your local dis ////////////////////////// 거의 모든 명령이 로컬 파일과 데이터만 사용하기 때문에 네트워크에 있는 다른 컴퓨터는 필요 없다. 대부분의 명령어가 네트워크의 속도에 영향을 받는 CVCS에 익숙하다면 Git이 매우 놀라울 것이다. Git의 이런 특징에서 나오는 미칠듯한 속도는 오직 Git느님만이 구사할 수 있는 전능이다. -프로젝트의 모든 히스토리가 로컬 디스크에 있기 때문에 모든 명령을 순식간에 실행된다. +프로젝트의 모든 히스토리가 로컬 디스크에 있기 때문에 모든 명령이 순식간에 실행된다. ////////////////////////// For example, to browse the history of the project, Git doesn't need to go out to the server to get the history and display it for you – it simply reads it directly from your local database. @@ -97,7 +97,7 @@ In many other systems, doing so is either impossible or painful. In Perforce, for example, you can't do much when you aren't connected to the server; and in Subversion and CVS, you can edit files, but you can't commit changes to your database (because your database is offline). This may not seem like a huge deal, but you may be surprised what a big difference it can make. ////////////////////////// -즉 오프라인 상태이거나 VPN으로 연결할 수 없어도 할 수 없는 일이 별로 없다. +즉 오프라인 상태이거나 VPN에 연결하지 못해도 막힘 없이 일 할 수 있다. 비행기나 기차 등에서 작업하고 네트워크에 접속하고 있지 않아도 커밋할 수 있다. 다른 VCS 시스템에서는 불가능한 일이다. Perforce를 예로 들자면 서버에 연결할 수 없을 때 할 수 있는 일이 별로 없다. Subversion이나 CVS에서도 마찬가지다. 오프라인이기 때문에 데이터베이스에 접근할 수 없어서 파일을 편집할 수는 있지만, 커밋할 수 없다. diff --git a/book/01-introduction/sections/command-line.asc b/book/01-introduction/sections/command-line.asc index 777e0bc7..a5d1efd4 100644 --- a/book/01-introduction/sections/command-line.asc +++ b/book/01-introduction/sections/command-line.asc @@ -12,7 +12,7 @@ If you know how to run the command line version, you can probably also figure ou Also, while your choice of graphical client is a matter of personal taste, _all_ users will have the command-line tools installed and available. ////////////////////////// Git을 사용하는 방법은 많다. -CLI로 사용할수도 있고 GUI를 사용할 수도 있다. +CLI로 사용할 수도 있고 GUI를 사용할 수도 있다. 이 책에서는 Git CLI 사용법을 설명한다. Git의 *모든* 기능을 지원하는 것은 CLI 뿐이다. GUI 프로그램의 대부분은 Git 기능을 전부 구현하지 않아서 비교적 단순하다. CLI를 사용할 줄 알면 GUI도 사용할 수 있지만 반대는 성립하지 않는다. diff --git a/book/01-introduction/sections/first-time-setup.asc b/book/01-introduction/sections/first-time-setup.asc index 51974aae..8b2e6d07 100644 --- a/book/01-introduction/sections/first-time-setup.asc +++ b/book/01-introduction/sections/first-time-setup.asc @@ -72,7 +72,7 @@ $ git config --global user.email johndoe@example.com Again, you need to do this only once if you pass the `--global` option, because then Git will always use that information for anything you do on that system. If you want to override this with a different name or email address for specific projects, you can run the command without the `--global` option when you're in that project. ////////////////////////// -다시 말하자면 `--global` 옵션으로 설정한 것은 딱 한 번만 하면 된다. 해당 시스템에서 해당 사용자가 사용할 때에는 이 정보를 사용한다. +다시 말하자면 `--global` 옵션으로 설정한 것은 딱 한 번만 하면 된다. 해당 시스템에서 해당 사용자가 사용할 때는 이 정보를 사용한다. 만약 프로젝트마다 다른 이름과 이메일 주소를 사용하고 싶으면 `--global` 옵션을 빼고 명령을 실행한다. ////////////////////////// diff --git a/book/01-introduction/sections/installing.asc b/book/01-introduction/sections/installing.asc index 6d8db090..868cbd73 100644 --- a/book/01-introduction/sections/installing.asc +++ b/book/01-introduction/sections/installing.asc @@ -36,7 +36,7 @@ Git은 정말 이전 버전과 잘 호환되도록 유지하기 때문에 2.0 If you want to install the basic Git tools on Linux via a binary installer, you can generally do so through the basic package-management tool that comes with your distribution. If you're on Fedora for example, you can use yum: ////////////////////////// -Linux에서 패키지로 Git을 설치할 때에는 보통 각 배포판에서 사용하는 패키지 관리도구를 사용하여 설치한다. +Linux에서 패키지로 Git을 설치할 때는 보통 각 배포판에서 사용하는 패키지 관리도구를 사용하여 설치한다. Fedora에서는 아래와 같이 한다. [source,console] diff --git a/book/02-git-basics/sections/recording-changes.asc b/book/02-git-basics/sections/recording-changes.asc index 9b8d4ede..e53e363c 100644 --- a/book/02-git-basics/sections/recording-changes.asc +++ b/book/02-git-basics/sections/recording-changes.asc @@ -424,7 +424,7 @@ Although `git status` answers those questions very generally by listing the file ////////////////////////// 단순히 파일이 변경됐다는 사실이 아니라 어떤 내용이 변경됐는지 살펴보려면 `git status` 명령이 아니라 `git diff` 명령을 사용해야 한다.(((git commands, diff))) 보통 우리는 '수정했지만, 아직 Staged 파일이 아닌 것?'과 '어떤 파일이 Staged 상태인지?'가 궁금하기 때문에 `git status` 명령으로도 충분하다. -더 자세하게 볼 때는 `git diff` 명령을 사용하는데 Patch처럼 어떤 라인을 추가했고 삭제했는지가 궁금할 때에 사용한다. +더 자세하게 볼 때는 `git diff` 명령을 사용하는데 Patch처럼 어떤 라인을 추가했고 삭제했는지가 궁금할 때 사용한다. `git diff`는 나중에 더 자세히 다룬다. ////////////////////////// diff --git a/book/02-git-basics/sections/remotes.asc b/book/02-git-basics/sections/remotes.asc index 4975c0af..14204b4a 100644 --- a/book/02-git-basics/sections/remotes.asc +++ b/book/02-git-basics/sections/remotes.asc @@ -64,7 +64,7 @@ If you have more than one remote, the command lists them all. For example, a repository with multiple remotes for working with several collaborators might look something like this. ////////////////////////// 리모트 저장소가 여러 개 있다면 이 명령은 등록된 전부를 보여준다. -프로젝트를 여러 사람과 함께 작업하여 등록시킨 리모트 저장소가 여러개라면 아래와 같은 결과를 얻을 수도 있다. +여러 사람과 함께 작업하는 리모트 저장소가 여러개라면 아래와 같은 결과를 얻을 수도 있다. [source,console] ---- @@ -86,7 +86,7 @@ origin git@github.com:mojombo/grit.git (push) This means we can pull contributions from any of these users pretty easily. We may additionally have permission to push to one or more of these, though we can't tell that here. ////////////////////////// -이렇게 리모트 저장소가 여러 개가 등록되어 있으면 다른 사람이 기여한 내용(Contributions)을 쉽게 가져올 수 있다. +이렇게 리모트 저장소가 여러 개 등록되어 있으면 다른 사람이 기여한 내용(Contributions)을 쉽게 가져올 수 있다. 어떤 저장소에는 Push 권한까지 제공하기도 하지만 일단 이 화면에서 Push 가능 권한까지는 확인할 수 없다. ////////////////////////// @@ -259,7 +259,7 @@ It also lists all the remote references it has pulled down. That is a simple example you're likely to encounter. When you're using Git more heavily, however, you may see much more information from `git remote show`: ////////////////////////// -좀 더 Git을 열심히 사용하게 되면 `git remote show` 명령은 더 많은 정보를 보여줄 것이다. +좀 더 Git을 열심히 사용하다 보면 `git remote show` 명령으로 더 많은 정보를 보는 날이 온다. 여러분도 언젠가는 아래와 같은 메시지(역주 - 다수의 브랜치를 사용하는 메시지)를 볼 날이 올 것이다. [source,console] diff --git a/book/02-git-basics/sections/tagging.asc b/book/02-git-basics/sections/tagging.asc index 45246b27..e4420ac8 100644 --- a/book/02-git-basics/sections/tagging.asc +++ b/book/02-git-basics/sections/tagging.asc @@ -84,7 +84,7 @@ It's generally recommended that you create annotated tags so you can have all th ////////////////////////// 한편 Annotated 태그는 Git 데이터베이스에 태그를 만든 사람의 이름, 이메일과 태그를 만든 날짜, 그리고 태그 메시지도 저장한다. GPG(GNU Privacy Guard)로 서명할 수도 있다. -이 모든 정보를 저장해둬야 할 때에만 Annotated 태그를 추천한다. 그냥 다른 정보를 저장하지 않는 단순한 태그가 필요하다면 Lightweight 태그를 사용하는 것이 좋다. +이 모든 정보를 저장해둬야 할 때만 Annotated 태그를 추천한다. 그냥 다른 정보를 저장하지 않는 단순한 태그가 필요하다면 Lightweight 태그를 사용하는 것이 좋다. [[_annotated_tags]] ////////////////////////// @@ -155,7 +155,7 @@ To create a lightweight tag, don't supply the `-a`, `-s`, or `-m` option: ////////////////////////// Lightweight 태그는 기본적으로 파일에 커밋 체크섬을 저장하는 것뿐이다. 다른 정보는 저장하지 않는다. -Lightweight 태그를 만들 때에는 `-a`, `-s`, `-m` 옵션을 사용하지 않는다. +Lightweight 태그를 만들 때는 `-a`, `-s`, `-m` 옵션을 사용하지 않는다. [source,console] ---- diff --git a/book/02-git-basics/sections/undoing.asc b/book/02-git-basics/sections/undoing.asc index 83ce5bb5..b34d1dee 100644 --- a/book/02-git-basics/sections/undoing.asc +++ b/book/02-git-basics/sections/undoing.asc @@ -13,7 +13,7 @@ This is one of the few areas in Git where you may lose some work if you do it wr 일을 하다보면 모든 단계에서 어떤 것은 되돌리고(Undo) 싶을 때가 있다. 이번에는 우리가 한 일을 되돌리는 방법을 살펴본다. 한 번 되돌리면 복구할 수 없기에 주의해야 한다. -Git을 사용하면 우리가 한 실수를 복구하지 못할 것은 거의 없지만 되돌린 것은 복구할 수 없다. +Git을 사용하면 우리가 저지른 실수는 대부분 복구할 수 있지만 되돌린 것은 복구할 수 없다. ////////////////////////// One of the common undos takes place when you commit too early and possibly forget to add some files, or you mess up your commit message. @@ -56,7 +56,7 @@ $ git commit --amend ////////////////////////// You end up with a single commit – the second commit replaces the results of the first. ////////////////////////// -여기서 실행한 명령어 3개는 모두 하나의 커밋으로 기록된다. 두 번째 커밋은 첫 번째 커밋을 덮어쓴다. +여기서 실행한 명령어 3개는 모두 커밋 한 개로 기록된다. 두 번째 커밋은 첫 번째 커밋을 덮어쓴다. [[_unstaging]] ////////////////////////// @@ -199,7 +199,7 @@ Don't ever use this command unless you absolutely know that you don't want the f ===== `git checkout -- [file]` 명령은 꽤 위험한 명령이라는 것을 알아야 한다. 원래 파일로 덮어썼기 때문에 수정한 내용은 전부 사라진다. -수정한 내용이 진짜 마음에 들지 않을 때에만 사용하자. +수정한 내용이 진짜 마음에 들지 않을 때만 사용하자. ===== ////////////////////////// diff --git a/book/02-git-basics/sections/viewing-history.asc b/book/02-git-basics/sections/viewing-history.asc index 0c9a0b4b..7408cdd4 100644 --- a/book/02-git-basics/sections/viewing-history.asc +++ b/book/02-git-basics/sections/viewing-history.asc @@ -288,7 +288,7 @@ $ git log --pretty=format:"%h %s" --graph ////////////////////////// This type of output will become more interesting as we go through branching and merging in the next chapter. ////////////////////////// -다음 장에서 살펴볼 브랜치나 Merge 결과를 히스토리를 이런 식으로 살펴보면 훨씬 흥미롭게 볼 수 있다. +다음 장에서 살펴볼 브랜치나 Merge 결과의 히스토리를 이런 식으로 살펴보면 훨씬 흥미롭다. ////////////////////////// Those are only some simple output-formatting options to `git log` – there are many more. 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 4e410e13..29982a47 100644 --- a/book/03-git-branching/sections/basic-branching-and-merging.asc +++ b/book/03-git-branching/sections/basic-branching-and-merging.asc @@ -123,7 +123,7 @@ There are ways to get around this (namely, stashing and commit amending) that we For now, let's assume you've committed all your changes, so you can switch back to your `master` branch: ////////////////////////// 그렇지만, 브랜치를 이동하려면 해야 할 일이 있다. 아직 커밋하지 않은 파일이 Checkout 할 브랜치와 충돌 나면 브랜치를 변경할 수 없다. -브랜치를 변경할 때에는 워킹 디렉토리를 정리하는 것이 좋다. +브랜치를 변경할 때는 워킹 디렉토리를 정리하는 것이 좋다. 이런 문제를 다루는 방법은(주로, Stash이나 커밋 Amend에 대해) 나중에 <<_git_stashing>> 에서 다룰 것이다. 지금은 작업하던 것을 모두 커밋하고 `master` 브랜치로 옮긴다: @@ -146,7 +146,7 @@ Checkout 한 브랜치의 마지막 스냅샷으로 되돌려 놓는다는 것 Next, you have a hotfix to make. Let's create a hotfix branch on which to work until it's completed: ////////////////////////// -이젠 해결해야 할 핫픽스가 생겼을 때를 예를 들어보자. +이젠 해결해야 할 핫픽스가 생겼을 때를 살펴보자. hotfix라는 브랜치를 만들고 새로운 이슈를 해결할 때까지 사용한다. [source,console] @@ -483,7 +483,7 @@ If you're happy with that, and you verify that everything that had conflicts has The commit message by default looks something like this: ////////////////////////// 충돌을 해결하고 나서 해당 파일이 Staging Area에 저장됐는지 확인했으면 `git commit` 명령으로 Merge 한 것을 커밋한다. -충돌을 해결하고 Merge 할 때에는 커밋 메시지가 아래와 같다. +충돌을 해결하고 Merge 할 때는 커밋 메시지가 아래와 같다. [source,console] ---- diff --git a/book/03-git-branching/sections/branch-management.asc b/book/03-git-branching/sections/branch-management.asc index b5f6b77b..f18e38b5 100644 --- a/book/03-git-branching/sections/branch-management.asc +++ b/book/03-git-branching/sections/branch-management.asc @@ -30,7 +30,7 @@ Notice the `*` character that prefixes the `master` branch: it indicates the bra This means that if you commit at this point, the `master` branch will be moved forward with your new work. To see the last commit on each branch, you can run `git branch -v`: ////////////////////////// -`*` 기호가 붙어 있는 `master`브랜치는 현재 Checkout 해서 작업하는 브랜치를 나타낸다. +`*` 기호가 붙어 있는 `master` 브랜치는 현재 Checkout 해서 작업하는 브랜치를 나타낸다. 즉, 지금 수정한 내용을 커밋하면 `master` 브랜치에 커밋되고 포인터가 앞으로 한 단계 나아간다. `git branch -v` 명령을 실행하면 브랜치마다 마지막 커밋 메시지도 함께 보여준다. diff --git a/book/03-git-branching/sections/nutshell.asc b/book/03-git-branching/sections/nutshell.asc index 5116b2e2..b4cc57e8 100644 --- a/book/03-git-branching/sections/nutshell.asc +++ b/book/03-git-branching/sections/nutshell.asc @@ -331,7 +331,7 @@ This can take several seconds or even minutes, depending on the size of the proj Also, because we're recording the parents when we commit, finding a proper merge base for merging is automatically done for us and is generally very easy to do. These features help encourage developers to create and use branches often. ////////////////////////// -브랜치를 만들어야 하면 프로젝트를 통째로 복사해야 하는 다른 버전 관리 도구와 Git의 차이는 극명하다. +브랜치가 필요할 때 프로젝트를 통째로 복사해야 하는 다른 버전 관리 도구와 Git의 차이는 극명하다. 통째로 복사하는 작업은 프로젝트 크기에 따라 다르겠지만 수십 초에서 수십 분까지 걸린다. 그에 비해 Git은 순식간이다. 게다가 커밋을 할 때마다 이전 커밋의 정보를 저장하기 때문에 Merge 할 때 어디서부터(Merge Base) 합쳐야 하는지 안다. 이런 특징은 개발자들이 수시로 브랜치를 만들어 사용하게 한다. diff --git a/book/03-git-branching/sections/rebasing.asc b/book/03-git-branching/sections/rebasing.asc index 2ef9e5e5..6a1edfb9 100644 --- a/book/03-git-branching/sections/rebasing.asc +++ b/book/03-git-branching/sections/rebasing.asc @@ -48,7 +48,7 @@ However, there is another way: you can take the patch of the change that was int In Git, this is called _rebasing_. With the `rebase` command, you can take all the changes that were committed on one branch and replay them on another one.(((git commands, rebase))) ////////////////////////// -비슷한 결과를 만드는 다른 방식으로, `C3`에서 변경된 사항을 Patch(Patch)로 만들고 이를 다시 `C4`에 적용시키는 방법이 있다. +비슷한 결과를 만드는 다른 방식으로, `C3`에서 변경된 사항을 Patch로 만들고 이를 다시 `C4`에 적용시키는 방법이 있다. Git에서는 이런 방식을 _Rebase_라고 한다. `rebase` 명령으로 한 브랜치에서 변경된 사항을 다른 브랜치에 적용할 수 있다.(((git commands, rebase))) @@ -356,7 +356,7 @@ It's pretty safe to assume that the other developer doesn't want `C4` and `C6` t If you *do* find yourself in a situation like this, Git has some further magic that might help you out. If someone on your team force pushes changes that overwrite work that you've based work on, your challenge is to figure out what is yours and what they've rewritten. ////////////////////////// -만약 이런 상황에 빠질 때에 유용한 Git 기능이 하나 있다. +만약 이런 상황에 빠질 때 유용한 Git 기능이 하나 있다. 어떤 팀원이 강제로 내가 한일을 덮어썼다고 하자. 그러면 내가 했던 일이 무엇이고 덮어쓴 내용이 무엇인지 알아내야 한다. ////////////////////////// diff --git a/book/03-git-branching/sections/remote-branches.asc b/book/03-git-branching/sections/remote-branches.asc index 7457a33f..31482220 100644 --- a/book/03-git-branching/sections/remote-branches.asc +++ b/book/03-git-branching/sections/remote-branches.asc @@ -146,7 +146,7 @@ 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))) ////////////////////////// -`serverfix`라는 브랜치를 다른 사람과 공유할 때에도 브랜치를 처음 Push 하는 것과 같은 방법으로 Push 한다. +`serverfix`라는 브랜치를 다른 사람과 공유할 때도 브랜치를 처음 Push 하는 것과 같은 방법으로 Push 한다. 아래와 같이 `git push (remote) (branch)` 명령을 사용한다.(((git commands, push))) [source,console] diff --git a/book/04-git-server/1-git-server.asc b/book/04-git-server/1-git-server.asc index 600a2a73..7ec8775f 100644 --- a/book/04-git-server/1-git-server.asc +++ b/book/04-git-server/1-git-server.asc @@ -16,7 +16,7 @@ Therefore, the preferred method for collaborating with someone is to set up an i 다른 사람과 협업하려면 리모트 저장소가 필요하다. 물론 혼자서 저장소를 만들고 거기에 Push 하고 Pull 할 수도 있지만 이렇게 하는 것은 아무 의미가 없다. 이런 방식으로는 다른 사람이 무슨 일을 하고 있는지 알려면 항상 지켜보고 있어야 간신히 알 수 있을 터이다. -당신이 오프라인일 때에도 동료가 저장소를 사용할 수 있게 하려면 언제나 이용할 수 있는 저장소가 필요하다. +당신이 오프라인일 때도 동료가 저장소를 사용할 수 있게 하려면 언제나 이용할 수 있는 저장소가 필요하다. 즉, 공동으로 사용할 수 있는 저장소를 만들고 모두 이 저장소에 접근하여 Push, Pull 할 수 있어야 한다. ////////////////////////// diff --git a/book/04-git-server/sections/gitlab.asc b/book/04-git-server/sections/gitlab.asc index c8c8e546..6572f3e4 100644 --- a/book/04-git-server/sections/gitlab.asc +++ b/book/04-git-server/sections/gitlab.asc @@ -156,7 +156,7 @@ Every project belongs to a single namespace, either a user or a group. If the project belongs to a user, the owner of the project has direct control over who has access to the project; if the project belongs to a group, the group's user-level permissions will also take effect. ////////////////////////// GitLab의 프로젝트는 간단히 이야기하면 하나의 Git 저장소다. -모든 프로젝트는 한 명의 사용자나 하나의 그룹에 속하게 된다. +모든 프로젝트는 한 사용자나 한 그룹에 속하게 된다. 사용자에 딸린 프로젝트는 사용자가 관리자로서 그 프로젝트를 완전히 제어한다. 그룹에 딸린 프로젝트는 해당 그룹의 사용자 권한 레벨에 따라 다르다. ////////////////////////// diff --git a/book/04-git-server/sections/protocols.asc b/book/04-git-server/sections/protocols.asc index 63d4b439..eea0f8b1 100644 --- a/book/04-git-server/sections/protocols.asc +++ b/book/04-git-server/sections/protocols.asc @@ -174,7 +174,7 @@ If you try to push and the repository requires authentication (which it normally ////////////////////////// In fact, for services like GitHub, the URL you use to view the repository online (for example, ``https://github.com/schacon/simplegit[]'') is the same URL you can use to clone and, if you have access, push over. ////////////////////////// -실제로 GitHub 같은 서비스에서 제공하는 저장소는 Clone을 할 때나 Push를 할 때에 같은 URL을 사용한다. (예, ``https://github.com/schacon/simplegit[]'' ) +실제로 GitHub 같은 서비스에서 제공하는 저장소는 Clone을 할 때나 Push를 할 때 같은 URL을 사용한다. (예, ``https://github.com/schacon/simplegit[]'' ) ////////////////////////// ===== Dumb HTTP diff --git a/book/05-distributed-git/sections/contributing.asc b/book/05-distributed-git/sections/contributing.asc index cad5ea8b..c0a352d0 100644 --- a/book/05-distributed-git/sections/contributing.asc +++ b/book/05-distributed-git/sections/contributing.asc @@ -64,7 +64,7 @@ All these questions can affect how you contribute effectively to a project and w We'll cover aspects of each of these in a series of use cases, moving from simple to more complex; you should be able to construct the specific workflows you need in practice from these examples. ////////////////////////// 이런 질문에 따라 프로젝트에 기여하는 방법과 Workflow 등이 달라진다. -간단한 것부터 복잡한 것까지 예제를 통해 각 상황을 살펴보면 실제 프로젝트에 필요한 방식을 선택할 수 있게 도움이 될 것이다. +간단한 것부터 복잡한 것까지 예제를 통해 각 상황을 살펴보면 필요한 방식을 선택하는 데 도움이 될 것이다. [[_commit_guidelines]] ////////////////////////// @@ -111,8 +111,8 @@ This approach also makes it easier to pull out or revert one of the changesets i <<_rewriting_history>> describes a number of useful Git tricks for rewriting history and interactively staging files – use these tools to help craft a clean and understandable history before sending the work to someone else. ////////////////////////// 그리고 각 커밋은 논리적으로 구분되는 Changeset이다. -최대한 수정사항을 하나의 주제로 요약할 수 있어야 하고 여러 가지 이슈에 대한 수정사항을 하나의 커밋에 담지 않아야 한다. -여러 가지 이슈를 한꺼번에 수정했다고 하더라도 Staging Area을 이용하여 한 커밋에 하나의 이슈만 담기도록 한다. 작업 내용을 분할하고, 각 커밋마다 적절한 메시지를 작성한다. +최대한 수정사항을 한 주제로 요약할 수 있어야 하고 여러 가지 이슈에 대한 수정사항을 하나의 커밋에 담지 않아야 한다. +여러 가지 이슈를 한꺼번에 수정했다고 하더라도 Staging Area을 이용하여 한 커밋에 이슈 하나만 담기도록 한다. 작업 내용을 분할하고, 각 커밋마다 적절한 메시지를 작성한다. 같은 파일의 다른 부분을 수정하는 경우에는 `git add -patch` 명령을 써서 한 부분씩 나누어 Staging Area에 저장해야 한다(관련 내용은 <<_interactive_staging> 에서 다룬다). 결과적으로 최종 프로젝트의 모습은 한 번에 커밋을 하든 다섯 번에 나누어 커밋을 하든 똑같다. 하지만, 여러 번 나누어 커밋하는 것이 다른 동료가 수정한 부분을 확인할 때나 각 커밋의 시점으로 복원해서 검토할 때 이해하기 훨씬 쉽다. @@ -514,7 +514,7 @@ To jessica@githost:simplegit.git ////////////////////////// Each developer has committed a few times and merged each other's work successfully. ////////////////////////// -두 개발자의 커밋과 Merge가 성공적으로 이루어지고 난 후의 결과는 아래와 같다. +두 개발자의 커밋을 성공적으로 Merge 하고 나면 결과는 아래와 같다. ////////////////////////// .Jessica's history after pushing all changes back to the server. @@ -531,7 +531,7 @@ The general sequence is something like this: ////////////////////////// 매우 간단한 상황의 예제를 살펴보았다. 토픽 브랜치에서 수정하고 로컬의 `master` 브랜치에 Merge 한다. -작업한 내용을 프로젝트의 공유 저장소에 Push 하고자 할 때에는 우선 `origin/master` 브랜치를 Fetch 하고 Merge 한다. 그리고 나서 Merge 한 결과를 다시 서버로 Push 한다. +작업한 내용을 프로젝트의 공유 저장소에 Push 하고자 할 때는 우선 `origin/master` 브랜치를 Fetch 하고 Merge 한다. 그리고 나서 Merge 한 결과를 다시 서버로 Push 한다. 이런 Workflow가 일반적이며 아래와 같이 나타낼 수 있다. ////////////////////////// @@ -818,7 +818,7 @@ Many hosting sites support this (including GitHub, BitBucket, Google Code, repo. The next section deals with projects that prefer to accept contributed patches via email. ////////////////////////// 비공개 팀을 운영하는 것과 공개 팀을 운영하는 것은 약간 다르다. -공개 팀을 운영할 때에는 모든 개발자가 프로젝트의 공유 저장소에 직접적으로 쓰기 권한을 가지지는 않는다. 그래서 프로젝트의 관리자는 몇 가지 일을 더 해줘야 한다. +공개 팀을 운영할 때는 모든 개발자가 프로젝트의 공유 저장소에 직접적으로 쓰기 권한을 가지지는 않는다. 그래서 프로젝트의 관리자는 몇 가지 일을 더 해줘야 한다. Fork를 지원하는 Git 호스팅에서 Fork를 통해 프로젝트에 기여하는 법을 예제를 통해 살펴본다. Git 호스팅 사이트(Github, BitBucket, Google Code, repo.or.cz 등) 대부분은 Fork 기능을 지원하며 프로젝트 관리자는 보통 Fork 하는 것으로 프로젝트를 운영한다. 다른 방식으로 이메일과 Patch를 사용하는 방식도 있는데 뒤이어 살펴본다. @@ -872,7 +872,7 @@ If the maintainers merge, rebase, or cherry-pick your work, you'll eventually ge 자 이제 등록한 리모트 저장소에 Push 한다. 작업하던 것을 로컬 저장소의 master 브랜치에 Merge 한 후 Push 하는 것보다 리모트 브랜치에 바로 Push를 하는 방식이 훨씬 간단하다. 이렇게 하는 이유는 관리자가 토픽 브랜치를 프로젝트에 포함시키고 싶지 않을 때 토픽 브랜치를 Merge 하기 이전 상태로 master 브랜치를 되돌릴 필요가 없기 때문이다. -관리자가 토픽 브랜치를 Merge 하든 Rebase 하든 cherry-pick 하든지 간에 결국 다시 관리자의 저장소를 Pull 할 때에는 토픽 브랜치의 내용이 들어 있을 것이다. +관리자가 토픽 브랜치를 Merge 하든 Rebase 하든 cherry-pick 하든지 간에 결국 다시 관리자의 저장소를 Pull 할 때는 토픽 브랜치의 내용이 들어 있을 것이다. [source,console] ---- @@ -1007,7 +1007,7 @@ The `--squash` option takes all the work on the merged branch and squashes it in This means your future commit will have one parent only and allows you to introduce all the changes from another branch and then make more changes before recording the new commit. Also the `--no-commit` option can be useful to delay the merge commit in case of the default merge process. ////////////////////////// -`--squash` 옵션은 현재 브랜치에 Merge 할 때 해당 브랜치의 커밋을 모두 하나의 커밋으로 합쳐서 Merge 한다. 이 때 Merge 커밋은 만들지 않는다. +`--squash` 옵션은 현재 브랜치에 Merge 할 때 해당 브랜치의 커밋을 모두 커밋 하나로 합쳐서 Merge 한다. 이 때 Merge 커밋은 만들지 않는다. 다른 브랜치에서 수정한 사항을 전부 가져오는 것은 똑같다. 하지만 새로 만들어지는 커밋은 부모가 하나이고 커밋을 기록하기 전에 좀 더 수정할 기회도 있다. 다른 브랜치에서 수정한 사항을 전부 가져오면서 그전에 추가적으로 수정할 게 있으면 수정하고 Merge 할 수 있다. 게다가 새로 만들어지는 커밋은 부모가 하나다. `--no-commit` 옵션을 추가하면 커밋을 합쳐 놓고 자동으로 커밋하지 않는다. diff --git a/book/05-distributed-git/sections/distributed-workflows.asc b/book/05-distributed-git/sections/distributed-workflows.asc index 895b4864..c86b0649 100644 --- a/book/05-distributed-git/sections/distributed-workflows.asc +++ b/book/05-distributed-git/sections/distributed-workflows.asc @@ -12,7 +12,7 @@ This opens a vast range of workflow possibilities for your project and/or your t We'll go over the strengths and possible weaknesses of each design; you can choose a single one to use, or you can mix and match features from each. ////////////////////////// 중앙집중형 버전 관리 시스템과는 달리 Git은 분산형이다. Git은 구조가 매우 유연하기 때문에 여러 개발자가 함께 작업하는 방식을 더 다양하게 구성할 수 있다. -중앙집중형 버전 관리 시스템에서 각 개발자는 중앙 저장소를 중심으로 하는 하나의 노드일 뿐이다. 하지만, Git에서는 각 개발자의 저장소가 하나의 노드이기도 하고 중앙 저장소 같은 역할도 할 수 있다. +중앙집중형 버전 관리 시스템에서 각 개발자는 중앙 저장소를 중심으로 하는 한 노드일 뿐이다. 하지만, Git에서는 각 개발자의 저장소가 하나의 노드이기도 하고 중앙 저장소 같은 역할도 할 수 있다. 즉, 모든 개발자는 다른 개발자의 저장소에 일한 내용을 전송하거나, 다른 개발자들이 참여할 수 있도록 자신이 운영하는 저장소 위치를 공개할 수도 있다. 이런 특징은 프로젝트나 팀이 코드를 운영할 때 다양한 Workflow을 만들 수 있도록 해준다. 이런 유연성을 살려 저장소를 운영하는 몇 가지 방식을 소개한다. 각 방식의 장단점을 살펴보고 그 방식 중 하나를 고르거나 여러 가지를 적절히 섞어 쓰면 된다. @@ -87,7 +87,7 @@ The maintainer can then add your repository as a remote, test your changes local The process works as follows (see <>): ////////////////////////// Git을 사용하면 리모트 저장소를 여러 개 운영할 수 있다. 다른 개발자는 읽기만 가능하고 자신은 쓰기도 가능한 공개 저장소를 만드는 Workflow도 된다. -이 Worlflow에는 보통 프로젝트를 대표하는 하나의 공식 저장소가 있다. +이 Worlflow에는 보통 프로젝트를 대표하는 공식 저장소가 있다. 기여자는 우선 공식 저장소를 하나 Clone 하고 수정하고 나서 자신의 저장소에 Push 한다. 그 다음에 프로젝트 Integration-Manager에게 새 저장소에서 Pull 하라고 요청한다. 그러면 그 Integration-Manager는 기여자의 저장소를 리모트 저장소로 등록하고, 로컬에서 기여물을 테스트하고, 프로젝트 메인 브랜치에 Merge 하고, 그 내용을 다시 프로젝트 메인 저장소에 Push 한다. diff --git a/book/05-distributed-git/sections/maintaining.asc b/book/05-distributed-git/sections/maintaining.asc index 17be78f4..029fac34 100644 --- a/book/05-distributed-git/sections/maintaining.asc +++ b/book/05-distributed-git/sections/maintaining.asc @@ -75,7 +75,7 @@ Patch를 적용하는 방법은 `git apply` 명령을 사용하는 것과 `git a If you received the patch from someone who generated it with the `git diff` or a Unix `diff` command (which is not recommended; see the next section), you can apply it with the `git apply` command. Assuming you saved the patch at `/tmp/patch-ruby-client.patch`, you can apply the patch like this: ////////////////////////// -`git diff`나 Unix의 `diff` 명령(다음 절에서 다루겠지만 추천하지 않는 방법)으로 만든 Patch파일을 적용할 때에는 `git apply` 명령을 사용한다. +`git diff`나 Unix의 `diff` 명령(다음 절에서 다루겠지만 추천하지 않는 방법)으로 만든 Patch파일을 적용할 때는 `git apply` 명령을 사용한다. Patch 파일이 `/tmp/patch-ruby-client.patch`라고 하면 아래와 같은 명령으로 Patch를 적용할 수 있다. [source,console] @@ -161,7 +161,7 @@ If you run a mail client that can save several emails out in mbox format, you ca 이 내용은 format-patch 명령으로 생성한 파일의 앞부분이다. 이 파일은 mbox 형식이다. 받은 메일이 `git send-email`로 만든 메일이라면 mbox 형식으로 저장하고 이 mbox 파일을 `git am` 명령으로 적용한다. -사용하는 메일 클라이언트가 여러 이메일을 하나의 mbox 파일로 저장할 수 있다면 메일 여러 개를 한 번에 Patch 할 수 있다. +사용하는 메일 클라이언트가 여러 이메일을 mbox 파일 하나로 저장할 수 있다면 메일 여러 개를 한 번에 Patch 할 수 있다. ////////////////////////// However, if someone uploaded a patch file generated via `format-patch` to a ticketing system or something similar, you can save the file locally and then pass that file saved on your disk to `git am` to apply it: @@ -519,7 +519,7 @@ image::images/merging-workflows-2.png[Merge 한 후의 저장소.] ////////////////////////// That is probably the simplest workflow, but it can possibly be problematic if you're dealing with larger or more stable projects where you want to be really careful about what you introduce. ////////////////////////// -이 Workflow에서 가장 간단한 시나리오다. 프로젝트의 규모가 커지거나 코드를 더 안정적으로 관리할 때에는 이렇게 쉽게 Merge 되지 않을 것이다. +이 Workflow에서 가장 간단한 시나리오다. 프로젝트의 규모가 커지거나 코드를 더 안정적으로 관리할 때는 이렇게 쉽게 Merge 되지 않을 것이다. ////////////////////////// If you have a more important project, you might want to use a two-phase merge cycle. diff --git a/book/06-github/sections/1-setting-up-account.asc b/book/06-github/sections/1-setting-up-account.asc index f7acac39..d6cba0c2 100644 --- a/book/06-github/sections/1-setting-up-account.asc +++ b/book/06-github/sections/1-setting-up-account.asc @@ -182,14 +182,14 @@ If GitHub sees any of these in commit messages in any repository on the site, it ////////////////////////// ==== Two Factor Authentication ////////////////////////// -==== 투 팩터 인증 +==== 투팩터 인증 ////////////////////////// Finally, for extra security, you should definitely set up Two-factor Authentication or ``2FA''. Two-factor Authentication is an authentication mechanism that is becoming more and more popular recently to mitigate the risk of your account being compromised if your password is stolen somehow. Turning it on will make GitHub ask you for two different methods of authentication, so that if one of them is compromised, an attacker will not be able to access your account. ////////////////////////// -더 안전한 보안을 위해서 ``2FA''(2 팩터 인증)을 설정한다. +더 안전한 보안을 위해서 ``2FA''(투팩터 인증)을 설정한다. 2FA는 최근 들어 인기가 높아지는 인증 메커니즘이다. 암호를 도둑맞았을 때 위험을 완화하기 위해 사용한다. 2FA를 활성화 시키면 GitHub에 로그인 할 때 인증수단이 두 가지 필요하다(역주 - 기존 로그인 방식에 OTP나 SMS를 추가). 둘 중 한 가지 방법만 뚫려서는 공격자가 계정에 접근할 수 없다. diff --git a/book/06-github/sections/3-maintaining.asc b/book/06-github/sections/3-maintaining.asc index 40d1b67b..011f2b86 100644 --- a/book/06-github/sections/3-maintaining.asc +++ b/book/06-github/sections/3-maintaining.asc @@ -241,7 +241,7 @@ This will do a ``non-fast-forward'' merge, creating a merge commit even if a fas This means that no matter what, every time you hit the merge button, a merge commit is created. As you can see in <<_merge_button>>, GitHub gives you all of this information if you click the hint link. ////////////////////////// -GitHub 사이트에서 ``Merge'' 버튼을 누르는 것으로 간편하게 Merge 할 수 있다(Trivial Merge). ``fast-forward''가 가능할 때에도 ``non-fast-forward'' Merge를 하기 때문에 Merge 커밋이 생긴다. +GitHub 사이트에서 ``Merge'' 버튼을 누르는 것으로 간편하게 Merge 할 수 있다(Trivial Merge). ``fast-forward''가 가능할 때도 ``non-fast-forward'' Merge를 하기 때문에 Merge 커밋이 생긴다. 그래서 ``Merge'' 버튼을 클릭해서 Merge 하면 항상 Merge 커밋이 생긴다. 여기서 어떻게 해야 하는지 'command line' 힌트 링크를 클릭하면 <<_merge_button>>과 같이 알려준다. @@ -636,7 +636,7 @@ It's also worth noting that if you have both email and web notifications enabled ////////////////////////// There are a couple of special files that GitHub will notice if they are present in your repository. ////////////////////////// -저장소에 있는 파일 중에서 GitHub가 사용하는 몇가지 특이한 파일들이 있다. +저장소에 있는 파일 중에서 GitHub이 사용하는 몇가지 특이한 파일들이 있다. ==== README diff --git a/book/07-git-tools/sections/advanced-merging.asc b/book/07-git-tools/sections/advanced-merging.asc index d426a277..c24f94d2 100644 --- a/book/07-git-tools/sections/advanced-merging.asc +++ b/book/07-git-tools/sections/advanced-merging.asc @@ -35,7 +35,7 @@ We'll also cover some of the different, non-standard types of merges you can do, /////////////////// While we covered some basics on resolving merge conflicts in <<_basic_merge_conflicts>>, for more complex conflicts, Git provides a few tools to help you figure out what's going on and how to better deal with the conflict. /////////////////// -<<_basic_merge_conflicts>>에서 기초적인 Merge 충돌 해결에 대해서 다뤘다. Git은 Merge 충돌이 복잡한 상황에서 필요한 도구도 가지고 있다. 무슨 일이 일어 났고 어떻게 해결하는 게 나은지 알 수 있다. +<<_basic_merge_conflicts>>에서 기초적인 Merge 충돌 해결에 대해서 다뤘다. Git은 복잡한 Merge 충돌이 났을 때 필요한 도구도 가지고 있다. 무슨 일이 일어 났고 어떻게 해결하는 게 나은지 알 수 있다. /////////////////// First of all, if at all possible, try to make sure your working directory is clean before doing a merge that may have conflicts. @@ -43,7 +43,7 @@ If you have work in progress, either commit it to a temporary branch or stash it This makes it so that you can undo *anything* you try here. If you have unsaved changes in your working directory when you try a merge, some of these tips may help you lose that work. /////////////////// -Merge 할 때에는 충돌이 날 수 있어서 Merge 하기 전에 워킹 디렉토리를 깔끔히 정리하는 것이 좋다. +Merge 할 때는 충돌이 날 수 있어서 Merge 하기 전에 워킹 디렉토리를 깔끔히 정리하는 것이 좋다. 워킹 디렉토리에 작업하던 게 있다면 임시 브랜치에 커밋하거나 Stash 해둔다. 그래야 어떤 일이 일어나도 다시 되돌릴 수 있다. 작업 중인 파일을 저장하지 않은 채로 Merge 하면 작업했던 일부를 잃을 수도 있다. @@ -208,7 +208,7 @@ If you see that you have a lot of whitespace issues in a merge, you can simply a The first option ignores whitespace *completely* when comparing lines, the second treats sequences of one or more whitespace characters as equivalent. /////////////////// 기본 Merge 전략은 공백의 변화는 무시하도록 하는 옵션을 주는 것이다. -Merge 할 때에 무수한 공백 때문에 문제가 생기면 그냥 Merge를 취소한 다음 `-Xignore-all-space`나 `-Xignore-space-change` 옵션을 주어 다시 Merge 한다. +Merge 할 때 무수한 공백 때문에 문제가 생기면 그냥 Merge를 취소한 다음 `-Xignore-all-space`나 `-Xignore-space-change` 옵션을 주어 다시 Merge 한다. 첫 번째 옵션은 *모든* 공백을 무시하고 두 번째 옵션은 뭉쳐 있는 공백을 하나로 취급한다. [source,console] @@ -297,7 +297,7 @@ The `:1:hello.rb` is just a shorthand for looking up that blob SHA-1. /////////////////// Now that we have the content of all three stages in our working directory, we can manually fix up theirs to fix the whitespace issue and re-merge the file with the little-known `git merge-file` command which does just that. /////////////////// -이제 워킹 디렉토리에 세 버전의 파일을 모두 가져왔다. 공백 문제를 수동으로 고친 다음에 다시 Merge 한다. Merge 할 때에는 'git merge-file' 명령을 이용한다. +이제 워킹 디렉토리에 세 버전의 파일을 모두 가져왔다. 공백 문제를 수동으로 고친 다음에 다시 Merge 한다. Merge 할 때는 'git merge-file' 명령을 이용한다. [source,console] ---- @@ -447,7 +447,7 @@ Let's change up the example a little. For this example, we have two longer lived branches that each have a few commits in them but create a legitimate content conflict when merged. /////////////////// 예제를 조금 바꿔보자. -이번 예제에서는 긴 호흡의 브랜치 두 개가 있다. 각 브랜치에는 몇 개의 커밋이 있는데 양쪽은 Merge 할 때에 반드시 충돌이 날 만한 내용이 들어 있다. +이번 예제에서는 긴 호흡의 브랜치 두 개가 있다. 각 브랜치에는 몇 개의 커밋이 있는데 양쪽은 Merge 할 때 반드시 충돌이 날 만한 내용이 들어 있다. [source,console] ---- @@ -482,7 +482,7 @@ We would like to see what the merge conflict is. If we open up the file, we'll see something like this: /////////////////// 해당 파일을 열어서 충돌이 발생한 내용을 보면 -아래와 같은 내용으로 나온다. +아래와 같다. [source,ruby] ---- @@ -527,7 +527,7 @@ 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`가 기본 값이다. -`diff3` 명령에 `--conflict` 옵션을 사용하면 Git은 약간 다른 모양의 충돌 표시를 남긴다. ``ours''나 ``theirs''말고도 ``base''버전의 내용까지 제공한다. +`--conflict` 옵션에 `diff3`를 사용하면 Git은 약간 다른 모양의 충돌 표시를 남긴다. ``ours''나 ``theirs''말고도 ``base''버전의 내용까지 제공한다. [source,console] ---- @@ -569,12 +569,12 @@ $ git config --global merge.conflictstyle diff3 /////////////////// The `git checkout` command can also take `--ours` and `--theirs` options, which can be a really fast way of just choosing either one side or the other without merging things at all. /////////////////// -`git checkout` 명령도 `--ours`와 `--theirs` 옵션을 지원한다. 이 옵션은 Merge 하지 않고 둘 중 한쪽만을 선택할 때에 사용한다. +`git checkout` 명령도 `--ours`와 `--theirs` 옵션을 지원한다. 이 옵션은 Merge 하지 않고 둘 중 한쪽만을 선택할 때 사용한다. /////////////////// This can be particularly useful for conflicts of binary files where you can simply choose one side, or where you only want to merge certain files in from another branch - you can do the merge and then checkout certain files from one side or the other before committing. /////////////////// -이 옵션은 바이너리 파일이 충돌 나서 한쪽을 선택해야 하는 상황이나 한쪽 브랜치의 온전한 파일을 원할 때에 사용할 수 있다. 일단 Merge 하고 나서 특정 파일만 Checkout 한 후에 커밋하는 방법도 있다. +이 옵션은 바이너리 파일이 충돌 나서 한쪽을 선택해야 하는 상황이나 한쪽 브랜치의 온전한 파일을 원할 때 사용할 수 있다. 일단 Merge 하고 나서 특정 파일만 Checkout 한 후에 커밋하는 방법도 있다. [[_merge_log]] /////////////////// @@ -719,7 +719,7 @@ This can be useful to review before committing the resolution. You can also get this from the `git log` for any merge to see how something was resolved after the fact. Git will output this format if you run `git show` on a merge commit, or if you add a `--cc` option to a `git log -p` (which by default only shows patches for non-merge commits). /////////////////// -이 정보를 `git log` 명령을 통해서도 얻을 수 있다. Merge 후에 무엇이 어떻게 바뀌었는지 알아야 할 때에 유용하다. +이 정보를 `git log` 명령을 통해서도 얻을 수 있다. Merge 후에 무엇이 어떻게 바뀌었는지 알아야 할 때 유용하다. Merge 커밋에 대해서 `git show` 명령을 실행하거나 `git log -p`에 `--cc` 옵션을 추가해도 같은 결과를 얻을 수 있다. `git log -p` 명령은 기본적으로 Merge 커밋이 아닌 커밋의 Patch를 출력한다. [source,console] @@ -762,7 +762,7 @@ Now that you know how to create a merge commit, you'll probably make some by mis One of the great things about working with Git is that it's okay to make mistakes, because it's possible (and in many cases easy) to fix them. /////////////////// 지금까지 Merge 하는 방법을 배웠으나 Merge 할 때 실수할 수도 있다. -Git에서는 실수해도 된다. 실수해도 (많은 경우 간단하게) 되돌릴 수 있다. +Git에서는 실수해도 된다. 실수해도 (대부분 간단하게) 되돌릴 수 있다. /////////////////// Merge commits are no different. @@ -792,7 +792,7 @@ There are two ways to approach this problem, depending on what your desired outc If the unwanted merge commit only exists on your local repository, the easiest and best solution is to move the branches so that they point where you want them to. In most cases, if you follow the errant `git merge` with `git reset --hard HEAD~`, this will reset the branch pointers so they look like this: /////////////////// -실수로 생긴 Merge 커밋이 로컬 저장소에만 있을 때에는 브랜치를 원하는 커밋을 가리키도록 옮기는 것이 쉽고 빠르다. +실수로 생긴 Merge 커밋이 로컬 저장소에만 있을 때는 브랜치를 원하는 커밋을 가리키도록 옮기는 것이 쉽고 빠르다. 잘못 Merge 하고 나서 `git reset --hard HEAD~` 명령으로 브랜치를 되돌리면 된다. /////////////////// @@ -941,8 +941,8 @@ So far we've covered the normal merge of two branches, normally handled with wha First of all, there is another useful thing we can do with the normal ``recursive'' mode of merging. We've already seen the `ignore-all-space` and `ignore-space-change` options which are passed with a `-X` but we can also tell Git to favor one side or the other when it sees a conflict. /////////////////// -먼저 일반적인 ``recursive'' 전략을 사용하는 Merge 작업을 할 때에 유용한 옵션을 소개한다. -앞에서 `ignore-all-space`와 `ignore-space-change` 기능을 `-X` 옵션에 붙여 쓰는 것을 보았다. 이 `-X` 옵션은 충돌이 났을 때 어떤 한 쪽을 선택할 때에도 사용한다. +먼저 일반적인 ``recursive'' 전략을 사용하는 Merge 작업을 할 때 유용한 옵션을 소개한다. +앞에서 `ignore-all-space`와 `ignore-space-change` 기능을 `-X` 옵션에 붙여 쓰는 것을 보았다. 이 `-X` 옵션은 충돌이 났을 때 어떤 한 쪽을 선택할 때도 사용한다. /////////////////// By default, when Git sees a conflict between two branches being merged, it will add merge conflict markers into your code and mark the file as conflicted and let you resolve it. diff --git a/book/07-git-tools/sections/bundling.asc b/book/07-git-tools/sections/bundling.asc index 19250d59..e612c1c8 100644 --- a/book/07-git-tools/sections/bundling.asc +++ b/book/07-git-tools/sections/bundling.asc @@ -17,7 +17,7 @@ Perhaps you're working somewhere offsite and don't have access to the local netw Maybe your wireless/ethernet card just broke. Maybe you don't have access to a shared server for the moment, you want to email someone updates and you don't want to transfer 40 commits via `format-patch`. /////////// -Git에는 ``Bundle''이란 것이 있다. 데이터를 하나의 파일에 몰아넣는 것이다. +Git에는 ``Bundle''이란 것이 있다. 데이터를 한 파일에 몰아넣는 것이다. 이 방법은 다양한 경우 유용하게 사용할 수 있다. 예를 들어 네트워크가 불통인데 변경사항을 동료에게 보낼 때, 출장을 나갔는데 보안상의 이유로 로컬 네트워크에 접속하지 못할 때, @@ -29,7 +29,7 @@ This is where the `git bundle` command can be helpful. The `bundle` command will package up everything that would normally be pushed over the wire with a `git push` command into a binary file that you can email to someone or put on a flash drive, then unbundle into another repository. /////////// 바로 이럴 때 `git bundle`이 한 줄기 빛이 되어준다. -`bundle` 명령은 보통 `git push`명령으로 올려 보낼 모든 것을 감싸서 하나의 바이너리 파일로 만든다. 이 파일을 이메일로 보내거나 USB로 다른 사람에게 보내서 다른 저장소에 풀어서(Unbundle) 사용한다. +`bundle` 명령은 보통 `git push`명령으로 올려 보낼 모든 것을 감싸서 한 바이너리 파일로 만든다. 이 파일을 이메일로 보내거나 USB로 다른 사람에게 보내서 다른 저장소에 풀어서(Unbundle) 사용한다. /////////// Let's see a simple example. @@ -109,7 +109,7 @@ Bundle 파일에 HEAD Refs를 포함하지 않으려면 `-b master` 옵션을 /////////// Now let's say you do three commits on it and want to send the new commits back via a bundle on a USB stick or email. /////////// -이제 새 커밋 세 개를 추가해서 채운 저장소를 다시 원래 Bundle을 만들었던 저장소로 USB든 메일이든 Bundle로 보내 새 커밋을 옮겨보기로 한다. +이제 새 커밋 세 개를 추가해서 채운 저장소를 다시 원래 Bundle을 만들었던 저장소로 USB든 메일이든 Bundle로 보내 새 커밋을 옮겨보자. [source,console] ---- @@ -253,4 +253,4 @@ $ git log --oneline --decorate --graph --all /////////// So, `git bundle` can be really useful for sharing or doing network-type operations when you don't have the proper network or shared repository to do so. /////////// -`git bundle` 명령으로 데이터를 전송할 네트워크 상황이 여의치 않거나 쉽게 공유할 수 있는 저장소를 준비하기 어려울 때에도 히스토리를 쉽게 공유할 수 있다. +`git bundle` 명령으로 데이터를 전송할 네트워크 상황이 여의치 않거나 쉽게 공유할 수 있는 저장소를 준비하기 어려울 때도 히스토리를 쉽게 공유할 수 있다. diff --git a/book/07-git-tools/sections/credentials.asc b/book/07-git-tools/sections/credentials.asc index 653c3421..31091e50 100644 --- a/book/07-git-tools/sections/credentials.asc +++ b/book/07-git-tools/sections/credentials.asc @@ -99,7 +99,7 @@ Helper를 여러개 섞어서 쓸 수도 있다. How does this all work? Git's root command for the credential-helper system is `git credential`, which takes a command as an argument, and then more input through stdin. //////////////////// -실제로는 어떻게 동작하는지 살펴보기로 한다. +실제로는 어떻게 동작하는지 살펴보자. Git의 Credential-Helper 시스템의 기본 명령은 `git credential` 이다. 이 명령이 하위 명령이나 옵션, 표준입력으로 필요한 정보를 입력받아 전달한다. //////////////////// diff --git a/book/07-git-tools/sections/rerere.asc b/book/07-git-tools/sections/rerere.asc index 2ad5649c..eff48d28 100644 --- a/book/07-git-tools/sections/rerere.asc +++ b/book/07-git-tools/sections/rerere.asc @@ -308,7 +308,7 @@ We saw an example of this in <<_advanced_merging>>. For now though, let's re-resolve it by just running `rerere` again: /////////////////// <<_advanced_merging>>에서 이러한 명령을 사용하는 예제를 보았다. -이때에 `rerere` 명령을 실행하면 충돌이 발생한 코드를 자동으로 다시 해결한다. +이때 `rerere` 명령을 실행하면 충돌이 발생한 코드를 자동으로 다시 해결한다. [source,console] ---- diff --git a/book/07-git-tools/sections/reset.asc b/book/07-git-tools/sections/reset.asc index e626f910..0103ff13 100644 --- a/book/07-git-tools/sections/reset.asc +++ b/book/07-git-tools/sections/reset.asc @@ -13,7 +13,7 @@ For this, we recommend a simple metaphor. Git의 다른 특별한 도구를 더 살펴보기 보기 전에 `reset`과 `checkout`에 대해 이야기를 해보자. 이 두 명령은 Git을 처음 사용하는 사람을 가장 헷갈리게 하는 부분이다. 제대로 이해하고 사용할 수 없을 것으로 보일 정도로 많은 기능을 지녔다. -이해하기 쉽게 간단한 비유를 들어 설명해보기로 한다. +이해하기 쉽게 간단한 비유를 들어 설명해보자. ////////////////////////// ==== The Three Trees @@ -100,7 +100,7 @@ The Index is your *proposed next commit*. We've also been referring to this concept as Git's ``Staging Area'' as this is what Git looks at when you run `git commit`. ////////////////////////// Index는 *바로 다음에 커밋할* 것들이다. -이미 앞에서 우리는 이런 개념을 ``Stagin Area''라고 배운 바 있다. ``Staging Area''는 사용자가 `git commit` 명령을 실행했을 때 Git이 처리할 것들이 있는 곳이다. +이미 앞에서 우리는 이런 개념을 ``Staging Area''라고 배운 바 있다. ``Staging Area''는 사용자가 `git commit` 명령을 실행했을 때 Git이 처리할 것들이 있는 곳이다. ////////////////////////// Git populates this index with a list of all the file contents that were last checked out into your working directory and what they looked like when they were originally checked out. @@ -172,7 +172,7 @@ Let's visualize this process: say you go into a new directory with a single file We'll call this *v1* of the file, and we'll indicate it in blue. Now we run `git init`, which will create a Git repository with a HEAD reference which points to an unborn branch (`master` doesn't exist yet). ////////////////////////// -이 과정을 시각화해보자. 하나의 파일이 있는 디렉토리로 이동한다. +이 과정을 시각화해보자. 파일이 하나 있는 디렉토리로 이동한다. 이걸 파일의 **v1**이라고 하고 파란색으로 표시한다. `git init` 명령을 실행하면 Git 저장소가 생기고 HEAD는 아직 없는 브랜치를 가리킨다(`master`는 아직 없다). @@ -471,7 +471,7 @@ So you can selectively unstage or revert content. ////////////////////////// Let's look at how to do something interesting with this newfound power – squashing commits. ////////////////////////// -여러 커밋을 하나의 커밋으로 합치는 재밌는 도구를 알아보자. +여러 커밋을 커밋 하나로 합치는 재밌는 도구를 알아보자. ////////////////////////// Say you have a series of commits with messages like ``oops.'', ``WIP'' and ``forgot this file''. @@ -580,7 +580,7 @@ The other way to run `checkout` is with a file path, which, like `reset`, does n It is just like `git reset [branch] file` in that it updates the index with that file at that commit, but it also overwrites the file in the working directory. It would be exactly like `git reset --hard [branch] file` (if `reset` would let you run that) – it's not working-directory safe, and it does not move HEAD. ////////////////////////// -`checkout` 명령을 실행할 때에 파일 경로를 줄 수도 있다. `reset` 명령과 비슷하게 HEAD는 움직이지 않는다. +`checkout` 명령을 실행할 때 파일 경로를 줄 수도 있다. `reset` 명령과 비슷하게 HEAD는 움직이지 않는다. 동작은 `git reset [branch] file` 명령과 비슷하다. Index의 내용이 해당 커밋 버전으로 변경될 뿐만 아니라 워킹 디렉토리의 파일도 해당 커밋 버전으로 변경된다. 완전히 `git reset --hard [branch] file` 명령의 동작이랑 같다. 워킹 디렉토리가 안전하지도 않고 HEAD도 움직이지 않는다. diff --git a/book/07-git-tools/sections/revision-selection.asc b/book/07-git-tools/sections/revision-selection.asc index 62ab26f4..c3a84947 100644 --- a/book/07-git-tools/sections/revision-selection.asc +++ b/book/07-git-tools/sections/revision-selection.asc @@ -234,7 +234,7 @@ $ git show master@{yesterday} That shows you where the branch tip was yesterday. This technique only works for data that’s still in your reflog, so you can’t use it to look for commits older than a few months. ////////////////////////// -이 명령은 어제 master 브랜치가 가리키고 있던 것이 무엇인지 보여준다. Reflog에 남아있을 때에만 조회할 수 있기 때문에 너무 오래된 커밋은 조회할 수 없다. +이 명령은 어제 master 브랜치가 가리키고 있던 것이 무엇인지 보여준다. Reflog에 남아있을 때만 조회할 수 있기 때문에 너무 오래된 커밋은 조회할 수 없다. ////////////////////////// To see reflog information formatted like the `git log` output, you can run `git log -g`: @@ -444,7 +444,7 @@ This is useful if you want to keep the `experiment` branch up to date and previe Another very frequent use of this syntax is to see what you’re about to push to a remote: ////////////////////////// `experiment` 브랜치를 Merge 할 때마다 Merge 하기 전에 무엇이 변경됐는지 확인해보고 싶을 것이다. -그리고 리모트 저장소에 Push 할 때에도 마찬가지로 차이점을 확인해보고 싶을 것이다. 이럴 때 굉장히 유용하다. +그리고 리모트 저장소에 Push 할 때도 마찬가지로 차이점을 확인해보고 싶을 것이다. 이럴 때 굉장히 유용하다. [source,console] ---- @@ -488,7 +488,7 @@ This is nice because with this syntax you can specify more than two references i For instance, if you want to see all commits that are reachable from `refA` or `refB` but not from `refC`, you can type one of these: ////////////////////////// 이 옵션들은 Double Dot으로는 할 수 없는, 세 개 이상의 Refs에 사용할 수 있는 장점이 있다. -예를 들어 `refA`나 `refB`에는 있지만 `refC`에는 없는 커밋을 보려면 아래 중 하나의 명령을 사용한다. +예를 들어 `refA`나 `refB`에는 있지만 `refC`에는 없는 커밋을 보려면 아래 중 한 명령을 사용한다. [source,console] ---- diff --git a/book/07-git-tools/sections/rewriting-history.asc b/book/07-git-tools/sections/rewriting-history.asc index 1544aa5e..068ac40a 100644 --- a/book/07-git-tools/sections/rewriting-history.asc +++ b/book/07-git-tools/sections/rewriting-history.asc @@ -13,7 +13,7 @@ This can involve changing the order of the commits, changing messages or modifyi Git으로 일하다 보면 어떤 이유로든 커밋 히스토리를 수정해야 할 때가 있다. 결정을 나중으로 미룰 수 있던 것은 Git의 장점이다. Staging Area로 커밋할 파일을 고르는 일을 커밋하는 순간으로 미룰 수 있고 Stash 명령으로 하던 일을 미룰 수 있다. 게다가 이미 커밋해서 결정한 내용을 수정할 수 있다. 그리고 수정할 수 있는 것도 매우 다양하다. -커밋들의 순서도 변경할 수 있고 커밋 메시지와 커밋한 파일도 변경할 수 있다. 여러 개의 커밋을 하나로 합치거나 반대로 하나의 커밋을 여러 개로 분리할 수도 있다. 아니면 커밋 전체를 삭제할 수도 있다. 하지만, 이 모든 것은 다른 사람과 코드를 공유하기 전에 해야 한다. +커밋들의 순서도 변경할 수 있고 커밋 메시지와 커밋한 파일도 변경할 수 있다. 여러 개의 커밋을 하나로 합치거나 반대로 커밋 하나를 여러 개로 분리할 수도 있다. 아니면 커밋 전체를 삭제할 수도 있다. 하지만, 이 모든 것은 다른 사람과 코드를 공유하기 전에 해야 한다. ////////////////////////// In this section, you’ll cover how to accomplish these very useful tasks so that you can make your commit history look the way you want before you share it with others. @@ -270,7 +270,7 @@ You effectively change the order of those commits and remove the ``added cat-fil It’s also possible to take a series of commits and squash them down into a single commit with the interactive rebasing tool. The script puts helpful instructions in the rebase message: ////////////////////////// -대화형 Rebase 명령을 이용하여 여러 개의 커밋을 꾹꾹 눌러서 하나의 커밋으로 만들어 버릴 수 있다. +대화형 Rebase 명령을 이용하여 여러 개의 커밋을 꾹꾹 눌러서 커밋 하나로 만들어 버릴 수 있다. Rebase 스크립트에 자동으로 포함된 도움말에 설명이 있다. [source,console] @@ -330,7 +330,7 @@ added cat-file ////////////////////////// When you save that, you have a single commit that introduces the changes of all three previous commits. ////////////////////////// -이 메시지를 저장하면 3개의 커밋이 모두 합쳐진 하나의 커밋만 남는다. +이 메시지를 저장하면 3개의 커밋이 모두 합쳐진 커밋 한 개만 남는다. ////////////////////////// ==== Splitting a Commit @@ -462,7 +462,7 @@ Suppose you’ve done an import from another source control system and have subd 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 디렉토리가 포함된다. -모든 커밋에 대해 `trunk` 디렉토리를 프로젝트 루트 디렉토리로 만들 때에도 `filter-branch` 명령이 유용하다. +모든 커밋에 대해 `trunk` 디렉토리를 프로젝트 루트 디렉토리로 만들 때도 `filter-branch` 명령이 유용하다. [source,console] ---- diff --git a/book/07-git-tools/sections/searching.asc b/book/07-git-tools/sections/searching.asc index 2a410b75..2b0023df 100644 --- a/book/07-git-tools/sections/searching.asc +++ b/book/07-git-tools/sections/searching.asc @@ -11,7 +11,7 @@ We'll go through a few of them. ////////////////////////// 프로젝트가 크든 작든 함수의 정의나 함수가 호출되는 곳을 검색해야 하는 경우가 많다. 함수의 히스토리를 찾아보기도 한다. Git은 데이터베이스에 저장된 코드나 커밋에서 원하는 부분을 빠르고 쉽게 검색하는 도구가 여러 가지 있으며 -앞으로 함께 살펴보기로 한다. +앞으로 함께 살펴보자. [[_git_grep]] ==== Git Grep @@ -21,7 +21,7 @@ Git ships with a command called `grep` that allows you to easily search through For these examples, we'll look through the Git source code itself. ////////////////////////// Git의 `grep` 명령을 이용하면 커밋 트리의 내용이나 워킹 디렉토리의 내용을 문자열이나 정규표현식을 이용해 쉽게 찾을 수 있다. -Git 소스를 예로 들어 명령을 어떻게 사용하는지 알아보기로 한다. +Git 소스를 예로 들어 명령을 어떻게 사용하는지 알아보자. ////////////////////////// By default, it will look through the files in your working directory. diff --git a/book/07-git-tools/sections/signing.asc b/book/07-git-tools/sections/signing.asc index c9c90888..1e531c9d 100644 --- a/book/07-git-tools/sections/signing.asc +++ b/book/07-git-tools/sections/signing.asc @@ -224,7 +224,7 @@ In Git 1.8.3 and later, "git merge" and "git pull" can be told to inspect and re ////////////////////////// If you use this option when merging a branch and it contains commits that are not signed and valid, the merge will not work. ////////////////////////// -Merge 할 때에 `--verify-signatures` 옵션을 붙이면 Merge 할 커밋 중 서명하지 않았거나 신뢰할 수 없는 사람이 서명한 커밋이 있으면 Merge 되지 않는다. +Merge 할 때 `--verify-signatures` 옵션을 붙이면 Merge 할 커밋 중 서명하지 않았거나 신뢰할 수 없는 사람이 서명한 커밋이 있으면 Merge 되지 않는다. [source,console] ---- @@ -278,6 +278,6 @@ Signing tags and commits is great, but if you decide to use this in your normal If you don't, you'll end up spending a lot of time helping people figure out how to rewrite their commits with signed versions. Make sure you understand GPG and the benefits of signing things before adopting this as part of your standard workflow. ////////////////////////// -태그와 커밋에 서명하는 것은 멋지지만 일을 할 때에 서명 기능을 사용하려면 팀의 모든 사람이 서명 기능을 이해하고 사용해야만 한다. +태그와 커밋에 서명하는 것은 멋지지만 실제로 서명 기능을 사용하려면 팀의 모든 사람이 서명 기능을 이해하고 사용해야만 한다. 만약 그렇지 않으면 팀원들에게 커밋을 어떻게 서명된 커밋으로 재생성하는지 가르치느라 세월을 보내게 될 것이다. 반드시 작업에 적용하기 전에 GPG 서명 기능을 이해하고 이 기능이 가지는 장점을 완전히 파악하고 있어야만 한다. diff --git a/book/07-git-tools/sections/stashing-cleaning.asc b/book/07-git-tools/sections/stashing-cleaning.asc index 591210cc..e11d01eb 100644 --- a/book/07-git-tools/sections/stashing-cleaning.asc +++ b/book/07-git-tools/sections/stashing-cleaning.asc @@ -120,7 +120,7 @@ You can also have modified and uncommitted files in your working directory when Git은 Stash에 저장할 때 수정했던 파일들을 복원해준다. 복원할 때의 워킹 디렉토리는 Stash 할 때의 그 브랜치이고 워킹 디렉토리도 깨끗한 상태였다. 하지만, 꼭 깨끗한 워킹 디렉토리나 Stash 할 때와 같은 브랜치에 적용해야 하는 것은 아니다. 어떤 브랜치에서 Stash 하고 다른 브랜치로 옮기고서 거기에 Stash를 복원할 수 있다. -그리고 꼭 워킹 디렉토리가 깨끗한 상태일 필요도 없다. 워킹 디렉토리에 수정하고 커밋하지 않은 파일들이 있을 때에도 Stash를 적용할 수 있다. 만약 충돌이 있으면 알려준다. +그리고 꼭 워킹 디렉토리가 깨끗한 상태일 필요도 없다. 워킹 디렉토리에 수정하고 커밋하지 않은 파일들이 있을 때도 Stash를 적용할 수 있다. 만약 충돌이 있으면 알려준다. ////////////////////////// The changes to your files were reapplied, but the file you staged before wasn’t restaged. diff --git a/book/07-git-tools/sections/submodules.asc b/book/07-git-tools/sections/submodules.asc index 3c0116e8..0d403dc4 100644 --- a/book/07-git-tools/sections/submodules.asc +++ b/book/07-git-tools/sections/submodules.asc @@ -45,7 +45,7 @@ Git 저장소 안에 다른 Git 저장소를 디렉토리로 분리해 넣는 /////////// We'll walk through developing a simple project that has been split up into a main project and a few sub-projects. /////////// -예제로 하위 프로젝트 여러 개를 가지는 하나의 프로젝트를 만들어 서브모듈의 기능을 살펴보자. +예제로 하위 프로젝트 여러 개를 가지는 프로젝트를 하나 만들어 서브모듈의 기능을 살펴보자. /////////// Let's start by adding an existing Git repository as a submodule of the repository that we're working on. @@ -272,7 +272,7 @@ There is another way to do this which is a little simpler, however. If you pass `--recursive` to the `git clone` command, it will automatically initialize and update each submodule in the repository. /////////// 하지만, 같은 과정을 더 간단하게 실행하는 방법도 있다. -메인 프로젝트를 Clone 할 때에 `git clone` 명령 뒤에 `--recursive` 옵션을 붙이면 서브모듈을 자동으로 초기화하고 업데이트한다. +메인 프로젝트를 Clone 할 때 `git clone` 명령 뒤에 `--recursive` 옵션을 붙이면 서브모듈을 자동으로 초기화하고 업데이트한다. [source,console] ---- @@ -773,7 +773,7 @@ As you can see there, Git went into the DbConnector module and pushed it before If you change a submodule reference at the same time as someone else, you may run into some problems. That is, if the submodule histories have diverged and are committed to diverging branches in a superproject, it may take a bit of work for you to fix. /////////// -다른 누군가와 동시에 서브모듈을 수정하면 몇 가지 문제에 봉착하게 된다. 서브모듈의 히스토리가 갈라져서 상위 프로젝트에 커밋했다면 사태를 바로잡는 조처를 해야 한다. +다른 누군가와 동시에 서브모듈을 수정하면 몇 가지 문제에 봉착하게 된다. 서브모듈의 히스토리가 갈라져서 상위 프로젝트에 커밋했다면 사태를 바로잡아야 한다. /////////// If one of the commits is a direct ancestor of the other (a fast-forward merge), then Git will simply choose the latter for the merge, so that works fine. diff --git a/book/07-git-tools/sections/subtree-merges.asc b/book/07-git-tools/sections/subtree-merges.asc index e8d459b0..62c843ec 100644 --- a/book/07-git-tools/sections/subtree-merges.asc +++ b/book/07-git-tools/sections/subtree-merges.asc @@ -133,8 +133,8 @@ It is nice in some ways, for example all the code is committed to a single place However, it has other drawbacks in that it's a bit more complex and easier to make mistakes in reintegrating changes or accidentally pushing a branch into an unrelated repository. /////////////////// 이런 방식은 서브모듈(<<_git_submodules>>에서 자세하게 다룬다)을 사용하지 않고 서브모듈을 관리하는 또 다른 Workflow이다. -하나의 저장소 안에 다른 프로젝트까지 유지하면서 서브트리 Merge 전략으로 업데이트도 할 수 있다. -프로젝트에 필요한 코드를 하나의 저장소에서 관리할 수 있다. +한 저장소 안에 다른 프로젝트까지 유지하면서 서브트리 Merge 전략으로 업데이트도 할 수 있다. +프로젝트에 필요한 코드를 한 저장소에서 관리할 수 있다. 다만, 이렇게 저장소를 관리하는 방법은 저장소를 다루기 좀 복잡하고 통합할 때 실수하기 쉽다. 엉뚱한 저장소로 Push 해버릴 가능성도 있다. /////////////////// diff --git a/book/08-customizing-git/sections/attributes.asc b/book/08-customizing-git/sections/attributes.asc index fc7e1487..4fa3d8b9 100644 --- a/book/08-customizing-git/sections/attributes.asc +++ b/book/08-customizing-git/sections/attributes.asc @@ -61,7 +61,7 @@ To tell Git to treat all `pbxproj` files as binary data, add the following line ////////////////////////// Now, Git won't try to convert or fix CRLF issues; nor will it try to compute or print a diff for changes in this file when you run `git show` or `git diff` on your project. ////////////////////////// -이제 `pbxproj` 파일은 CRLF 변환이 적용되지 않는다. `git show`나 `git diff` 같은 명령을 실행할 때에도 통계를 계산하거나 diff를 출력하지 않는다. +이제 `pbxproj` 파일은 CRLF 변환이 적용되지 않는다. `git show`나 `git diff` 같은 명령을 실행할 때도 통계를 계산하거나 diff를 출력하지 않는다. ////////////////////////// ===== Diffing Binary Files @@ -427,7 +427,7 @@ When you design these filters, they should be able to fail gracefully and have t ////////////////////////// Git attribute data also allows you to do some interesting things when exporting an archive of your project. ////////////////////////// -프로젝트를 익스포트해서 아카이브를 만들 때에도 Git Attribute가 유용하다. +프로젝트를 익스포트해서 아카이브를 만들 때도 Git Attribute가 유용하다. ===== `export-ignore` @@ -461,7 +461,7 @@ Now, when you run git archive to create a tarball of your project, that director When exporting files for deployment you can apply `git log`'s formatting and keyword-expansion processing to selected portions of files marked with the `export-subst` attribute. ////////////////////////// -아카이브를 만들어서 배포할 때에도 `git log` 같은 포맷 규칙을 적용할 수 있다. `export-subst` Attribute로 설정한 파일들의 +아카이브를 만들어서 배포할 때도 `git log` 같은 포맷 규칙을 적용할 수 있다. `export-subst` Attribute로 설정한 파일들의 키워드가 치환된다. ////////////////////////// diff --git a/book/08-customizing-git/sections/config.asc b/book/08-customizing-git/sections/config.asc index 99c6d230..d16587a6 100644 --- a/book/08-customizing-git/sections/config.asc +++ b/book/08-customizing-git/sections/config.asc @@ -447,7 +447,7 @@ This takes a number of custom settings: `merge.tool` to tell Git what strategy t So, you can either run four config commands ////////////////////////// Git config 파일에 이 스크립트를 모두 추가한다. 설정해야 하는 옵션이 좀 많다. -`merge.tool`로 무슨 Merge 도구를 사용할지, `mergetool.*.cmd`로 실제로 어떻게 명령어를 실행할지, `mergetool.trustExitCode`로 Merge 도구가 반환하는 exit 코드가 Merge 의 성공 여부를 나타내는지, `diff.external`은 diff 할 때 실행할 명령어가 무엇인지를 설정할 때 사용한다. +`merge.tool`로 무슨 Merge 도구를 사용할지, `mergetool.*.cmd`로 실제로 어떻게 명령어를 실행할지, `mergetool.trustExitCode`로 Merge 도구가 반환하는 exit 코드가 Merge의 성공 여부를 나타내는지, `diff.external`은 diff 할 때 실행할 명령어가 무엇인지를 설정할 때 사용한다. 모두 `git config` 명령으로 설정한다. [source,console] diff --git a/book/08-customizing-git/sections/hooks.asc b/book/08-customizing-git/sections/hooks.asc index 41ccca0d..dee2ff4e 100644 --- a/book/08-customizing-git/sections/hooks.asc +++ b/book/08-customizing-git/sections/hooks.asc @@ -94,7 +94,7 @@ You may use it in conjunction with a commit template to programmatically insert ////////////////////////// `prepare-commit-msg` 훅은 Git이 커밋 메시지를 생성하고 나서 편집기를 실행하기 전에 실행된다. 이 훅은 사람이 커밋 메시지를 수정하기 전에 먼저 프로그램으로 손보고 싶을 때 사용한다. -이 훅은 커밋 메시지가 들어 있는 파일의 경로, 커밋의 종류를 아규먼트로 받는다. 그리고 최근 커밋을 수정할 때에는(Amending 커밋) SHA-1 값을 추가 아규먼트로 더 받는다. +이 훅은 커밋 메시지가 들어 있는 파일의 경로, 커밋의 종류를 아규먼트로 받는다. 그리고 최근 커밋을 수정할 때는(Amending 커밋) SHA-1 값을 추가 아규먼트로 더 받는다. 사실 이 훅은 일반 커밋에는 별로 필요 없고 커밋 메시지를 자동으로 생성하는 커밋에 좋다. 커밋 메시지에 템플릿을 적용하거나, Merge 커밋, Squash 커밋, Amend 커밋일 때 유용하다. 이 스크립트로 커밋 메시지 템플릿에 정보를 삽입할 수 있다. diff --git a/book/09-git-and-other-scms/1-git-and-other-scms.asc b/book/09-git-and-other-scms/1-git-and-other-scms.asc index d9c622f9..063051ab 100644 --- a/book/09-git-and-other-scms/1-git-and-other-scms.asc +++ b/book/09-git-and-other-scms/1-git-and-other-scms.asc @@ -19,7 +19,7 @@ At some point, you may want to convert your existing project to Git. The second part of this chapter covers how to migrate your project into Git from several specific systems, as well as a method that will work if no pre-built import tool exists. ////////////////////////// 언젠가 기존 프로젝트 환경을 Git으로 변경하고 싶게 될 것이다. -이 장의 나머지 부분에서 프로젝트를 Git으로 변경하는 방법에 대해 다룬다. 미리 만들어진 도구가 없더라도 스크립트를 직접 만들어서 옮기는 방법도 설명한다. 그래서 잘 쓰지 않는 VCS를 사용하고 있더라도 Git으로 옮길 수 있을 것이다. +이 장의 뒷 부분에서는 프로젝트를 Git으로 변경하는 방법에 대해 다룬다. 미리 만들어진 도구가 없더라도 스크립트를 직접 만들어서 옮기는 방법도 설명한다. 그래서 잘 쓰지 않는 VCS를 사용하고 있더라도 Git으로 옮길 수 있을 것이다. ////////////////////////// === Git as a Client @@ -32,7 +32,7 @@ Git provides such a nice experience for developers that many people have figured There are a number of these adapters, called ``bridges,'' available. Here we'll cover the ones you're most likely to run into in the wild. ////////////////////////// -Git은 배운 많은 사람들은 만족스러워 한다. 다른 모든 팀원들이 Git 아닌 다른 VCS 시스템을 사용하고 홀로 Git을 사용하더라도 만족스럽다. +Git을 배운 많은 사람들은 만족스러워 한다. 다른 모든 팀원들이 Git 아닌 다른 VCS 시스템을 사용하고 홀로 Git을 사용하더라도 만족스럽다. Git은 이렇게 다른 VCS 시스템과 연결해 주는 여러 ``bridge''를 제공한다. 이어지는 내용을 통해 하나씩 둘러보자. 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 3f983d2c..b4f65129 100644 --- a/book/09-git-and-other-scms/sections/client-p4.asc +++ b/book/09-git-and-other-scms/sections/client-p4.asc @@ -252,7 +252,7 @@ When converting the other way, the default is to look up the Perforce user with In most cases, this behavior will do just fine, but consider the following mapping file: ////////////////////////// 마지막으로 살펴볼 설정파일은 `users/p4gf_usermap` 파일로 Perforce 사용자를 Git 사용자로 매핑하는 역할을 하는데 때에 따라서는 필요하지 않을 수도 있다. -Perforce Changeset을 Git의 커밋으로 변환할 때 Git Fusion은 Perforce 사용자의 이름과 이메일 주소를 가지고 Git 커밋의 저자와 커미터 정모를 입력한다. +Perforce Changeset을 Git의 커밋으로 변환할 때 Git Fusion은 Perforce 사용자의 이름과 이메일 주소를 가지고 Git 커밋의 저자와 커미터 정보를 입력한다. 반대로 Git 커밋을 Perforce Changeset으로 변환할 때는 Git 커밋에 저장된 이름과 이메일 정보를 가져와 Changeset에 기록하고 이 정보로 권한을 확인한다. 보통은 리모트 저장소에 동일한 정보가 등록 돼있어서 문제없겠지만 정보가 다르다면 아래와 같이 매핑 정보를 설정해야 한다. @@ -387,7 +387,7 @@ You wouldn't know it from this view, but the `6afeb15` commit was actually creat It just looks like another commit from Git's point of view, which is exactly the point. Let's see how the Perforce server deals with a merge commit: ////////////////////////// -그새 누군가 부지런히 일을 했나보다(역주 - 물론 저자가 했겠지). +그새 누군가 부지런히 일을 했나보다. 정확히 누가 어떤 일을 했는지는 커밋을 까봐야 알겠지만 어쨋든 Git Fusion은 서버로부터 새로 가져온 Changeset을 변환해서 `6afeb15` 커밋을 만들어놨다. 여태 Git에서 본 여타 커밋이랑 다르지 않다. 이제 Perforce 서버가 Merge 커밋을 어떻게 다루는지 살펴보자. @@ -469,7 +469,7 @@ You can even use Git submodules (though they'll look strange to Perforce users), ////////////////////////// Perforce 서버에 권한이 있다면 Git Fusion은 Git과 Perforce 서버간에 데이터를 주고받는 도구로 매우 유용하다. 물론 좀 설정해야 하는 부분도 있지만 익히는게 그리 어렵지는 않다. -이 절에서는 Git의 강력한 기능 조심하라고 말하지 않는다. 이 장의 몇몇 절에서는 조심하라고 말하지 않는다. +이 절에서는 Git을 조심해서 사용하라고 말하지 않는다. 이 절은 그런 절이다. 그렇다고 Perforce 서버가 아무거나 다 받아 주지 않는다. 이미 Push 한 히스토리를 재작성하고 Push 하면 Git Fusion이 거절한다. 이런 경우에도 Git Fusion은 열심히 노력해서 Perforce를 마치 Git 처럼 다룰 수 있게 도와준다. (Perforce 사용자에게는 생소하겠지만) Git 서브모듈도 사용할 수 있고 브랜치(Perforce 쪽에는 Integration으로 기록된다)를 Merge 할 수도 있다. @@ -718,7 +718,7 @@ For example, if the Git commit you're importing was written by a contributor who ////////////////////////// 이 내용은 `p4 submit`을 실행했을 때 보이는 내용과 같다. 다만 git-p4는 아래쪽에 도움이 될 만한 내용을 덧 붙여 준다. git-p4는 커밋이나 Changeset을 생성할 때 최대한 Git과 Perforce에 있는 정보를 이용한다. 하지만 경우에 따라 변환할 때 직접 입력해줘야 할 수도 있다. -보녀래고 하는 커밋의 저자가 Perforce에 계정이 없을 때에도 그 저자가 작성한 Changeset으로 기록되길 바랄 것이다. +보내려고 하는 커밋의 저자가 Perforce에 계정이 없을 때도 그 저자가 작성한 Changeset으로 기록되길 바랄 것이다. ////////////////////////// Git-p4 has helpfully imported the message from the Git commit as the content for this Perforce changeset, so all we have to do is save and quit, twice (once for each commit). diff --git a/book/09-git-and-other-scms/sections/client-svn.asc b/book/09-git-and-other-scms/sections/client-svn.asc index 58a39800..9c99e85d 100644 --- a/book/09-git-and-other-scms/sections/client-svn.asc +++ b/book/09-git-and-other-scms/sections/client-svn.asc @@ -396,7 +396,7 @@ Resetting to the latest refs/remotes/origin/trunk Note that unlike Git, which requires you to merge upstream work you don't yet have locally before you can push, `git svn` makes you do that only if the changes conflict (much like how Subversion works). If someone else pushes a change to one file and then you push a change to another file, your `dcommit` will work fine: ////////////////////////// -Push 하기 전에 Upstream과 Merge 해야 하는 Git과 달리 `git svn`은 충돌이 날때에만 서버에 업데이트할 것이 있다고 알려 준다(Subversion 처럼). 이 점을 꼭 기억해야 한다. +Push 하기 전에 Upstream과 Merge 해야 하는 Git과 달리 `git svn`은 충돌이 날때만 서버에 업데이트할 것이 있다고 알려 준다(Subversion 처럼). 이 점을 꼭 기억해야 한다. 만약 다른 사람이 한 파일을 수정하고 내가 그 사람과 다른 파일을 수정한다면 `dcommit`은 성공적으로 수행된다. [source,console] @@ -459,7 +459,7 @@ If you're pushing to a Subversion server via `git svn`, you may want to rebase y The reason to prefer rebasing is that Subversion has a linear history and doesn't deal with merges like Git does, so `git svn` follows only the first parent when converting the snapshots into Subversion commits. ////////////////////////// Git에 익숙한 사람이면 일을 할 때 먼저 토픽 브랜치를 만들고, 일을 끝낸 다음에, Merge 하는 방식을 쓰려고 할 것이다. -하지만, `git svn`으로 Subversion 서버에 Push 할 때에는 브랜치를 Merge 하지 않고 Rebase 해야 한다. +하지만, `git svn`으로 Subversion 서버에 Push 할 때는 브랜치를 Merge 하지 않고 Rebase 해야 한다. Subversion은 일직선 히스토리 밖에 모르고 Git의 Merge 도 알지 못한다. 그래서 `git svn`은 첫 번째 부모 정보만 사용해서 Git 커밋을 Subversion 커밋으로 변경한다. ////////////////////////// diff --git a/book/09-git-and-other-scms/sections/client-tfs.asc b/book/09-git-and-other-scms/sections/client-tfs.asc index d897197a..22116470 100644 --- a/book/09-git-and-other-scms/sections/client-tfs.asc +++ b/book/09-git-and-other-scms/sections/client-tfs.asc @@ -274,7 +274,7 @@ TFVC와 TFS의 기능 중에서 Workflow를 복잡하게 만드는 게 있다. . TFVC에 표시되지 않는 Feature 브랜치는 복잡성을 높인다. 이점이 TFVC와 Git이 매우 다른 방식으로 브랜치를 표현하게 만든다. . TFVC는 사용자가 서버에서 파일을 ``Checkout''받아서 아무도 수정하지 못하도록 잠글 수 있다는 것을 명심해야 한다. - 서버에서 파일을 잠갔더라도 파일을 수정할 수 있다. 하지만 TFVC 서버로 Push 할 때에 방해될 수 있다. + 서버에서 파일을 잠갔더라도 파일을 수정할 수 있다. 하지만 TFVC 서버로 Push 할 때 방해될 수 있다. . TFS는 ``Gated'' 체크인이라는 기능이 있다. 체크인하기 하려면 TFS의 빌드-테스트 사이클을 성공해야 체크인된다. 이 기능은 TFVC의 ``Shelve''라는 기능으로 구현됐다. 이 기능은 여기서 다루지 않는다. git-tf으로는 수동으로 맞춰 줘야 하고, git-tfs는 Gated 체크인을 인식하는 +checkintool+ 명령어를 제공한다. diff --git a/book/09-git-and-other-scms/sections/import-p4.asc b/book/09-git-and-other-scms/sections/import-p4.asc index fb95ccd6..5036d911 100644 --- a/book/09-git-and-other-scms/sections/import-p4.asc +++ b/book/09-git-and-other-scms/sections/import-p4.asc @@ -107,7 +107,7 @@ However, if you'd like to remove the identifier, now is the time to do so – be ////////////////////////// 로그를 살펴보면 커밋마다 `git-p4` 라는 ID 항목이 들어가 있다. 나중에 Perforce Change Number가 필요해질 수도 있으니 커밋에 그대로 유지하는 편이 좋다. -하지만 ID를 지우고자 한다면 공유하기 전인 이 단계에서 지우는 것이 좋다. +하지만 ID를 지우고자 한다면 공유하기 전인 이 단계에서 지운다. (((git commands, filter-branch))) ////////////////////////// diff --git a/book/10-git-internals/sections/maintenance.asc b/book/10-git-internals/sections/maintenance.asc index 422e70a4..8308b7dd 100644 --- a/book/10-git-internals/sections/maintenance.asc +++ b/book/10-git-internals/sections/maintenance.asc @@ -282,7 +282,7 @@ This can be a huge problem when you're converting Subversion or Perforce reposit Because you don't download the whole history in those systems, this type of addition carries few consequences. If you did an import from another system or otherwise find that your repository is much larger than it should be, here is how you can find and remove large objects. ////////////////////////// -이 문제는 Subversion이나 Perforce 저장소를 Git으로 변환할 때에 큰 문제가 된다. +이 문제는 Subversion이나 Perforce 저장소를 Git으로 변환할 때 큰 문제가 된다. Subversion이나 Perforce 시스템은 전체 히스토리를 내려받는 것이 아니므로 해당 파일이 여러 번 추가될 수 있다. 혹은 다른 VCS에서 Git 저장소로 임포트하려고 하는데 Git 저장소의 공간이 충분하지 않으면 너무 큰 개체는 찾아서 삭제해야 한다. diff --git a/book/10-git-internals/sections/objects.asc b/book/10-git-internals/sections/objects.asc index bfd5854e..41aa5048 100644 --- a/book/10-git-internals/sections/objects.asc +++ b/book/10-git-internals/sections/objects.asc @@ -16,7 +16,7 @@ First, you initialize a new Git repository and verify that there is nothing in t Git은 Content-addressable 파일시스템이다. 이게 무슨 말이냐 하면 -Git의 핵심은 단순한 Key-Value(역주 - 예, 파일이름과 파일데이터) 데이터 저장소라는 것이다. +Git의 핵심은 단순한 Key-Value(역주 - 예, 파일 이름과 파일 데이터) 데이터 저장소라는 것이다. 어떤 형식의 데이터라도 집어넣을 수 있고 해당 Key로 언제든지 데이터를 다시 가져올 수 있다. Plumbing 명령어를 예로 들면 `hash-object` 명령에 데이터를 주면 `.git` 디렉토리에 저장하고 그 key를 알려준다. 우선 Git 저장소를 새로 만들고 `objects` 디렉토리에 뭐가 들어 있는지 확인한다: diff --git a/book/A-git-in-other-environments/sections/guis.asc b/book/A-git-in-other-environments/sections/guis.asc index 1ff04dc3..1fc0aef6 100644 --- a/book/A-git-in-other-environments/sections/guis.asc +++ b/book/A-git-in-other-environments/sections/guis.asc @@ -219,7 +219,7 @@ If you already have a local repository, just drag its directory from the Finder ////////////////////////// 저장소를 추가해보자. 이 클라이언트는 GitHub에서 접근 가능한 저장소들의 목록을 보여주고 한번에 Clone 할 수 있도록 안내한다. -이미 로컬 저장소가 있으면 간단히 'Mac Finder'나 'Windows Explorer'에서 끓어다(Drag) 놓으면 왼쪽 저장소 목록에 추가된다. +이미 로컬 저장소가 있으면 간단히 'Mac Finder'나 'Windows Explorer'에서 끌어다(Drag) 놓으면 왼쪽 저장소 목록에 추가된다. ////////////////////////// ===== Recommended Workflow diff --git a/book/C-git-commands/1-git-commands.asc b/book/C-git-commands/1-git-commands.asc index 3907f5bc..8ee9d18e 100644 --- a/book/C-git-commands/1-git-commands.asc +++ b/book/C-git-commands/1-git-commands.asc @@ -321,7 +321,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 <<_unstaging>>, where we use it to unstage a file we had run `git add` on. ////////////////////////// -`git reset`은 무엇보다도 `git add`로 추가한 파일을 Unstage 하는 사용한다. <<_unstaging>>에서 설명한다. +`git reset`은 무엇보다도 `git add`로 추가한 파일을 Unstage 하는데 사용한다. <<_unstaging>>에서 설명한다. ////////////////////////// We then cover it in quite some detail in <<_git_reset>>, which is entirely devoted to explaining this command. @@ -513,7 +513,7 @@ We introduce the command and cover it in some depth in <<_viewing_history>>. There we look at the `-p` and `--stat` option to get an idea of what was introduced in each commit and the `--pretty` and `--oneline` options to view the history more concisely, along with some simple date and author filtering options. ////////////////////////// <<_viewing_history>>에서 이 명령을 깊게 다뤘다. -`-p`와 `--stat` 옵션을 주면 각 커밋 사이에 상긴 변화를 확인할 수 있다. `--pretty`와 `--oneline` 옵션을 주면 히스토리를 좀 더 깔끔하게 볼 수 있다. 이 옵션은 Author나 날짜를 중심으로 히스토리를 보여준다. +`-p`와 `--stat` 옵션을 주면 각 커밋 사이에 생긴 변화를 확인할 수 있다. `--pretty`와 `--oneline` 옵션을 주면 히스토리를 좀 더 깔끔하게 볼 수 있다. 이 옵션은 Author나 날짜를 중심으로 히스토리를 보여준다. ////////////////////////// In <<_create_new_branch>> 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. @@ -791,7 +791,7 @@ We showed how to use it to create a nice changelog in <<_the_shortlog>>. The `git describe` command is used to take anything that resolves to a commit and produces a string that is somewhat human-readable and will not change. It's a way to get a description of a commit that is as unambiguous as a commit SHA-1 but more understandable. ////////////////////////// -`git describe` 명령은 커밋과 관련된 정보를 잘 조합해서 사람이 읽을 수 있는 문자로 결과를 만든다. +`git describe` 명령은 커밋과 관련된 정보를 잘 조합해서 사람이 읽을 수 있는 스트링을 만들어 준다. 커밋 SHA-1처럼 식별 가능하고 사람이 이해할 수 있는 정보가 필요할 때 사용한다. //////////////////////////