diff --git a/book/01-introduction/sections/about-version-control.asc b/book/01-introduction/sections/about-version-control.asc index 26b032b1..2c5beb4b 100644 --- a/book/01-introduction/sections/about-version-control.asc +++ b/book/01-introduction/sections/about-version-control.asc @@ -138,4 +138,4 @@ Furthermore, many of these systems deal pretty well with having several remote r This allows you to set up several types of workflows that aren't possible in centralized systems, such as hierarchical models. ////////////////////////// 게다가 대부분의 DVCS 환경에서는 리모트 저장소가 존재한다. 리모트 저장소가 많을 수도 있다. 그래서 사람들은 동시에 다양한 그룹과 다양한 방법으로 협업할 수 있다. -계층 모델 같은 중앙집중식 시스템으로는 할 수 없는 Workflow를 다양하게 사용할 수 있다. +계층 모델 같은 중앙집중식 시스템으로는 할 수 없는 워크플로를 다양하게 사용할 수 있다. diff --git a/book/01-introduction/sections/basics.asc b/book/01-introduction/sections/basics.asc index 82b80e32..ac466f90 100644 --- a/book/01-introduction/sections/basics.asc +++ b/book/01-introduction/sections/basics.asc @@ -159,7 +159,7 @@ This makes using Git a joy because we know we can experiment without the danger For a more in-depth look at how Git stores its data and how you can recover data that seems lost, see <<_undoing>>. ////////////////////////// Git을 사용하면 프로젝트가 심각하게 망가질 걱정 없이 매우 즐겁게 여러 가지 실험을 해 볼 수 있다. -<<_undoing>>을 보면 Git이 데이터를 어떻게 저장하고 손실을 어떻게 복구해야 할지 알 수 있다. +<<_undoing>>을 보면 Git에서 데이터를 어떻게 저장하고 손실을 어떻게 복구하는지 알 수 있다. ////////////////////////// ==== The Three States diff --git a/book/01-introduction/sections/command-line.asc b/book/01-introduction/sections/command-line.asc index de4ba72b..6c0d43f6 100644 --- a/book/01-introduction/sections/command-line.asc +++ b/book/01-introduction/sections/command-line.asc @@ -16,7 +16,7 @@ CLI로 사용할 수도 있고 GUI를 사용할 수도 있다. 이 책에서는 Git CLI 사용법을 설명한다. Git의 *모든* 기능을 지원하는 것은 CLI 뿐이다. GUI 프로그램의 대부분은 Git 기능 중 일부만 구현하기 때문에 비교적 단순하다. CLI를 사용할 줄 알면 GUI도 사용할 수 있지만 반대는 성립하지 않는다. -GUI를 선호하는 사람이 있다고 하더라도, CLI는 _모든_ 사람의 컴퓨터에 설치돼 있어서 바로 사용할 수 있을 것이다. +GUI를 사용하고 싶더라도 CLI가 기본으로 설치되는 도구이기 때문에 CLI기준으로 설명하겠다. ////////////////////////// So we will expect you to know how to open Terminal in Mac or Command Prompt or Powershell in Windows. diff --git a/book/01-introduction/sections/first-time-setup.asc b/book/01-introduction/sections/first-time-setup.asc index 3a3ac64a..ca19a35c 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 1831cb66..8ad15ce8 100644 --- a/book/01-introduction/sections/installing.asc +++ b/book/01-introduction/sections/installing.asc @@ -124,7 +124,7 @@ You can download this from the GitHub for Windows website, at http://windows.git 윈도에서도 'GitHub for Windows'를 설치할 수 있다. 이 인스톨러는 CLI와 GUI를 모두 설치해준다. 설치하면 Git을 Powershell에서 사용할 수 있다. 인증정보(Credential) 캐싱과 CRLF 설정까지 잘 된다.(((Powershell)))(((CRLF)))(((credential caching))) -이런 것들은 차차 배우게 될 것인데, 하나하나가 다 필요하다는 것을 알게 될 것이다. +이런 것들은 차차 배우게 될 것인데, Git 사용자라면 쓰게 될 기능들이다. 'GitHub for Windows'는 http://windows.github.com[]에서 내려받는다. ////////////////////////// diff --git a/book/02-git-basics/sections/getting-a-repository.asc b/book/02-git-basics/sections/getting-a-repository.asc index 609e6b82..86fe4168 100644 --- a/book/02-git-basics/sections/getting-a-repository.asc +++ b/book/02-git-basics/sections/getting-a-repository.asc @@ -10,7 +10,7 @@ The first takes an existing project or directory and imports it into Git. The second clones an existing Git repository from another server. ////////////////////////// Git 저장소를 만드는 방법은 두 가지다. -기존 프로젝트를 Git 저장소로 만드는 방법이 있고, +기존 프로젝트나 디렉토리를 Git 저장소로 만드는 방법이 있고, 다른 서버에 있는 저장소를 Clone 하는 방법이 있다. ////////////////////////// diff --git a/book/02-git-basics/sections/recording-changes.asc b/book/02-git-basics/sections/recording-changes.asc index e0f19139..c15d4507 100644 --- a/book/02-git-basics/sections/recording-changes.asc +++ b/book/02-git-basics/sections/recording-changes.asc @@ -141,8 +141,8 @@ The `git add` command takes a path name for either a file or a directory; if it' ////////////////////////// ``Changes to be committed'' 에 들어 있는 파일은 Staged 상태라는 것을 의미한다. 커밋하면 `git add`를 실행한 시점의 파일이 커밋되어 저장소 히스토리에 남는다. -앞에서 `git init` 명령을 실행했을 때, 그 다음 `git add (files)` 명령을 실행했던 걸 기억할 것이다. 이 명령을 통해 디렉토리에 있는 파일을 추적하고 관리하도록 한다.(((git commands, init)))(((git commands, add))) -`git add` 명령은 파일 또는 디렉토리의 경로명을 아규먼트로 받는다. 만일 디렉토리를 아규먼트로 줄 경우, 그 디렉토리 아래에 있는 모든 파일을 재귀적으로 추가한다. +앞에서 `git init` 명령을 실행한 후, `git add (files)` 명령을 실행했던 걸 기억할 것이다. 이 명령을 통해 디렉토리에 있는 파일을 추적하고 관리하도록 한다.(((git commands, init)))(((git commands, add))) +`git add` 명령은 파일 또는 디렉토리의 경로를 아규먼트로 받는다. 디렉토리면 아래에 있는 모든 파일들까지 재귀적으로 추가한다. ////////////////////////// ==== Staging Modified Files @@ -736,12 +736,12 @@ To remove a file from Git, you have to remove it from your tracked files (more a The `git rm` command does that, and also removes the file from your working directory so you don't see it as an untracked file the next time around. ////////////////////////// Git에서 파일을 제거하려면 `git rm` 명령으로 Tracked 상태의 파일을 삭제한 후에(정확하게는 Staging Area에서 삭제하는 것) 커밋해야 한다. -이 명령은 워킹 디렉토리에 있는 파일도 삭제하기 때문에 실제로 지워진다. +이 명령은 워킹 디렉토리에 있는 파일도 삭제하기 때문에 실제로 파일도 지워진다. ////////////////////////// If you simply remove the file from your working directory, it shows up under the ``Changed but not updated'' (that is, _unstaged_) area of your `git status` output: ////////////////////////// -만약 Git없이 그냥 파일을 삭제하고 `git status` 명령으로 상태를 확인하면 ``Changes not staged for commit''(즉, Unstaged) 에 속한다는 것을 확인할 수 있다. +Git 명령을 사용하지 않고 단순히 워킹 디렉터리에서 파일을 삭제하고 git status 명령으로 상태를 확인하면 Git은 현재 "Changes not staged for commit"(즉, Unstaged 상태)라고 표시해준다. [source,console] ---- @@ -781,7 +781,7 @@ This is a safety feature to prevent accidental removal of data that hasn't yet b ////////////////////////// 커밋하면 파일은 삭제되고 Git은 이 파일을 더는 추적하지 않는다. 이미 파일을 수정했거나 Index에(역주 - Staging Area을 Git Index라고도 부른다) 추가했다면 `-f`옵션을 주어 강제로 삭제해야 한다. -이 점은 실수로 데이터를 삭제하지 못하도록 하는 안전장치다. 한 번도 커밋한적 없는 데이터는 Git으로 복구할 수 없다. +이 점은 실수로 데이터를 삭제하지 못하도록 하는 안전장치다. 커밋 하지 않고 수정한 데이터는 Git으로 복구할 수 없기 때문이다. ////////////////////////// Another useful thing you may want to do is to keep the file in your working tree but remove it from your staging area. diff --git a/book/02-git-basics/sections/undoing.asc b/book/02-git-basics/sections/undoing.asc index b3705329..663b0f26 100644 --- a/book/02-git-basics/sections/undoing.asc +++ b/book/02-git-basics/sections/undoing.asc @@ -129,7 +129,7 @@ While `git reset` _can_ be a dangerous command if you call it with `--hard`, in ===== ////////////////////////// ===== -`git reset` 명령을 `--hard` 옵션과 함께 사용하면 워킹 디렉토리의 파일이 수정돼서 을 조심해야 한다. `--hard` 옵션만 사용하지 않는다면 `git reset` 명령은 Staging Area의 파일만 조작하기 때문에 위험하지 않다. +`git reset` 명령을 `--hard` 옵션과 함께 사용하면 워킹 디렉토리의 파일까지 수정돼서 조심해야 한다. `--hard` 옵션만 사용하지 않는다면 `git reset` 명령은 Staging Area의 파일만 조작하기 때문에 위험하지 않다. ===== ////////////////////////// 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 29982a47..05a2c8c8 100644 --- a/book/03-git-branching/sections/basic-branching-and-merging.asc +++ b/book/03-git-branching/sections/basic-branching-and-merging.asc @@ -92,7 +92,7 @@ You work on your web site and do some commits. Doing so moves the `iss53` branch forward, because you have it checked out (that is, your `HEAD` is pointing to it): ////////////////////////// `iss53` 브랜치를 Checkout 했기 때문에(즉, `HEAD`는 `iss53` 브랜치를 가리킨다) -뭔가 일을 하고 커밋하면 `iss53` 브랜치가 앞으로 진행한다. +뭔가 일을 하고 커밋하면 `iss53` 브랜치가 앞으로 나아간다. [source,console] ---- @@ -114,7 +114,7 @@ All you have to do is switch back to your `master` branch. ////////////////////////// 다른 상황을 가정해보자. 만드는 사이트에 문제가 생겨서 즉시 고쳐야 한다. 버그를 해결한 Hotfix에 `iss53`이 섞이는 것을 방지하기 위해 `iss53`과 관련된 코드를 어딘가에 저장해두고 원래 운영 환경의 소스로 복구해야 한다. -Git을 사용하면 이런 노력을 들일 필요 없이 그냥 `master` 브랜치로 옮기면 된다. +Git을 사용하면 이런 노력을 들일 필요 없이 그냥 `master` 브랜치로 돌아가면 된다. ////////////////////////// However, before you do that, note that if your working directory or staging area has uncommitted changes that conflict with the branch you're checking out, Git won't let you switch branches. @@ -189,8 +189,8 @@ Because the commit pointed to by the branch you merged in was directly upstream 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 방식을 'Fast forward'라고 부른다. 다시 말해서 A 브랜치에서 다른 B 브랜치를 Merge 할 때 B가 A 이후의 커밋을 가리키고 있으면 그저 A가 B의 커밋을 가리키게 할 뿐이다. +Merge 할 브랜치가 가리키는 커밋이 현 브랜치 커밋의 Upstream 브랜치이기 때문에 master 브랜치 포인터는 Merge 과정 없이 그저 최신 커밋으로 이동한다. +이런 Merge 방식을 'Fast forward'라고 부른다. 다시 말해 A 브랜치에서 다른 B 브랜치를 Merge 할 때 B 브랜치가 A 브랜치 이후의 커밋을 가리키고 있으면 그저 A 브랜치가 B 브랜치와 동일한 커밋을 가리키도록 이동시킬 뿐이다. ////////////////////////// Your change is now in the snapshot of the commit pointed to by the `master` branch, and you can deploy the fix. diff --git a/book/03-git-branching/sections/nutshell.asc b/book/03-git-branching/sections/nutshell.asc index b4cc57e8..36d23152 100644 --- a/book/03-git-branching/sections/nutshell.asc +++ b/book/03-git-branching/sections/nutshell.asc @@ -72,9 +72,9 @@ As you start making commits, you're given a `master` branch that points to the l Every time you commit, it moves forward automatically. ////////////////////////// Git의 브랜치는 커밋 사이를 가볍게 이동할 수 있는 어떤 포인터 같은 것이다. -기본적으로 Git은 `master` 브랜치를 만든다. -최초로 커밋하면 Git은 master라는 이름의 브랜치를 만든다. -커밋을 만들 때 마다 브랜치가 자동으로 가장 마지막 커밋을 가리키게 한다. +기본적으로 Git은 master 브랜치를 만든다. +처음 커밋하면 이 master 브랜치가 생성된 커밋을 가리킨다. +이후 커밋을 만들면 브랜치는 자동으로 가장 마지막 커밋을 가리킨다. [NOTE] ////////////////////////// diff --git a/book/03-git-branching/sections/rebasing.asc b/book/03-git-branching/sections/rebasing.asc index 6a1edfb9..59e898c2 100644 --- a/book/03-git-branching/sections/rebasing.asc +++ b/book/03-git-branching/sections/rebasing.asc @@ -478,4 +478,4 @@ Git은 매우 강력한 도구고 기능이 많아서 히스토리를 잘 쌓을 ////////////////////////// In general the way to get the best of both worlds is to rebase local changes you've made but haven't shared yet before you push them in order to clean up your story, but never rebase anything you've pushed somewhere. ////////////////////////// -일반적인 해답을 굳이 드리자면 로컬 브랜치에서 작업할 때는 히스토리를 정리하기 위해서 Rebase 할 수도 있지만, Push로 리모트에든 밖으로 내보낸 커밋에 대해서는 절대 Rebase 하지 말아야 한다. +일반적인 해답을 굳이 드리자면 로컬 브랜치에서 작업할 때는 히스토리를 정리하기 위해서 Rebase 할 수도 있지만, 리모트 등 어딘가에 Push로 내보낸 커밋에 대해서는 절대 Rebase 하지 말아야 한다. diff --git a/book/03-git-branching/sections/remote-branches.asc b/book/03-git-branching/sections/remote-branches.asc index 31482220..4b5205f3 100644 --- a/book/03-git-branching/sections/remote-branches.asc +++ b/book/03-git-branching/sections/remote-branches.asc @@ -326,7 +326,7 @@ So if you're on the `master` branch and it's tracking `origin/master`, you can s ////////////////////////// .Upstream 별명 ==== -추적 브랜치를 설정했다면 추적 브랜치를 `@{upstream}`이나 `@{u}`로 짧게 대체하여 사용할 수 있다. +추적 브랜치를 설정했다면 추적 브랜치 이름을 `@{upstream}`이나 `@{u}`로 짧게 대체하여 사용할 수 있다. `master` 브랜치가 `origin/master` 브랜치를 추적하는 경우라면 `git merge origin/master` 명령과 `git merge @{u}` 명령을 똑같이 사용할 수 있다.(((+++@{u}+++)))(((+++@{upstream}+++))) ==== diff --git a/book/03-git-branching/sections/workflows.asc b/book/03-git-branching/sections/workflows.asc index 93248d82..07a2119e 100644 --- a/book/03-git-branching/sections/workflows.asc +++ b/book/03-git-branching/sections/workflows.asc @@ -1,14 +1,14 @@ ////////////////////////// === Branching Workflows ////////////////////////// -=== 브랜치 Workflow +=== 브랜치 워크플로 ////////////////////////// Now that you have the basics of branching and merging down, what can or should you do with them? In this section, we'll cover some common workflows that this lightweight branching makes possible, so you can decide if you would like to incorporate it into your own development cycle. ////////////////////////// 브랜치를 만들고 Merge 하는 것을 어디에 써먹어야 할까. -이 절에서는 Git 브랜치가 유용한 몇 가지 Workflow를 살펴본다. 여기서 설명하는 Workflow를 개발에 적용하면 도움이 될 것이다. +이 절에서는 Git 브랜치가 유용한 몇 가지 워크플로를 살펴본다. 여기서 설명하는 워크플로를 개발에 적용하면 도움이 될 것이다. ////////////////////////// ==== Long-Running Branches @@ -28,7 +28,7 @@ Many Git developers have a workflow that embraces this approach, such as having They have another parallel branch named `develop` or `next` that they work from or use to test stability – it isn't necessarily always stable, but whenever it gets to a stable state, it can be merged into `master`. It's used to pull in topic branches (short-lived branches, like your earlier `iss53` branch) when they're ready, to make sure they pass all the tests and don't introduce bugs. ////////////////////////// -이런 접근법에 따라서 Git 개발자가 많이 선호하는 Workflow가 하나 있다. 배포했거나 배포할 코드만 `master` 브랜치에 Merge 해서 안정 버전의 코드만 `master` 브랜치에 둔다. +이런 접근법에 따라서 Git 개발자가 많이 선호하는 워크플로가 하나 있다. 배포했거나 배포할 코드만 `master` 브랜치에 Merge 해서 안정 버전의 코드만 `master` 브랜치에 둔다. 개발을 진행하고 안정화하는 브랜치는 `develop`이나 `next`라는 이름으로 추가로 만들어 사용한다. 이 브랜치는 언젠가 안정 상태가 되겠지만, 항상 안정 상태를 유지해야 하는 것이 아니다. 테스트를 거쳐서 안정적이라고 판단되면 `master` 브랜치에 Merge 한다. 토픽 브랜치(앞서 살펴본 `iss53` 브랜치 같은 짧은 호흡 브랜치)에도 적용할 수 있는데, 해당 토픽을 처리하고 테스트해서 버그도 없고 안정적이면 그때 Merge 한다. @@ -36,7 +36,7 @@ It's used to pull in topic branches (short-lived branches, like your earlier `is In reality, we're talking about pointers moving up the line of commits you're making. The stable branches are farther down the line in your commit history, and the bleeding-edge branches are farther up the history. ////////////////////////// -사실 우리가 얘기하는 것은 커밋을 가리키는 포인터에 대한 얘기다. +사실 우리가 얘기하는 것은 커밋을 가리키는 포인터에 대한 얘기다. 커밋 포인터를 만들고 수정하고 분리하고 합치는지에 대한 것이다. 개발 브랜치는 공격적으로 히스토리를 만들어 나아가고 안정 브랜치는 이미 만든 히스토리를 뒤따르며 나아간다. ////////////////////////// @@ -132,7 +132,7 @@ image::images/topic-branches-2.png[`dumbidea`와 `iss91v2` 브랜치를 Merge ////////////////////////// We will go into more detail about the various possible workflows for your Git project in <<_distributed_git>>, so before you decide which branching scheme your next project will use, be sure to read that chapter. ////////////////////////// -<<_distributed_git>>에서 프로젝트를 Git으로 관리할 때 브랜치를 이용하여 만들 수 있는 여러 Workflow에 대해 살펴본다. 관련 부분을 살펴보면 프로젝트에 어떤 형태로 응용할수 있을 지 감이 올 것이다. +<<_distributed_git>>에서 프로젝트를 Git으로 관리할 때 브랜치를 이용하여 만들 수 있는 여러 워크플로에 대해 살펴본다. 관련 부분을 살펴보면 프로젝트에 어떤 형태로 응용할수 있을 지 감이 올 것이다. ////////////////////////// It's important to remember when you're doing all this that these branches are completely local. diff --git a/book/04-git-server/sections/generating-ssh-key.asc b/book/04-git-server/sections/generating-ssh-key.asc index 5fcc86f6..c6f4fbb5 100644 --- a/book/04-git-server/sections/generating-ssh-key.asc +++ b/book/04-git-server/sections/generating-ssh-key.asc @@ -79,4 +79,4 @@ NrRFi9wrf+M7Q== schacon@mylaptop.local ////////////////////////// For a more in-depth tutorial on creating an SSH key on multiple operating systems, see the GitHub guide on SSH keys at https://help.github.com/articles/generating-ssh-keys[]. ////////////////////////// -다른 운영 체제에서 SSH 키를 만드는 방법이 궁금하면 https://help.github.com/articles/generating-ssh-keys[]에 있는 Github 설명서를 찾아보는 게 좋다. +다른 운영 체제에서 SSH 키를 만드는 방법이 궁금하면 https://help.github.com/articles/generating-ssh-keys[]에 있는 GitHub 설명서를 찾아보는 게 좋다. diff --git a/book/04-git-server/sections/gitweb.asc b/book/04-git-server/sections/gitweb.asc index 18e10cc4..bae91825 100644 --- a/book/04-git-server/sections/gitweb.asc +++ b/book/04-git-server/sections/gitweb.asc @@ -60,7 +60,7 @@ First, you need to get the Git source code, which GitWeb comes with, and generat 자신의 프로젝트에서 언제나 웹 인터페이스를 운영하려면 먼저 웹서버에 이 CGI 스크립트를 설치해야 한다. `apt`나 `yum`으로도 `gitweb`을 설치할 수 있지만, 여기에서는 수동으로 설치한다. GitWeb을 수동으로 설치하는 방법을 간단히 살펴보자. -먼저 GitWeb이 포함된 Git 소스 코드를 구한 아래의 CGI 스크립트를 빌드한다. +먼저 GitWeb이 포함된 Git 소스 코드를 구한 다음 아래의 CGI 스크립트를 빌드한다. [source,console] ---- diff --git a/book/04-git-server/sections/protocols.asc b/book/04-git-server/sections/protocols.asc index eea0f8b1..b4b9993e 100644 --- a/book/04-git-server/sections/protocols.asc +++ b/book/04-git-server/sections/protocols.asc @@ -169,7 +169,7 @@ If you try to push and the repository requires authentication (which it normally ////////////////////////// 아마 지금은 Git에서 가장 많이 사용하는 프로토콜일 것이다. `git://` 프로토콜처럼 익명으로 사용할 수도 있고, SSH처럼 인증을 거쳐 Push 할 수도 있기 때문이다. 이 두 가지 동작을 다른 URL로 나눌 필요없이 하나의 URL로 통합해서 사용할 수 있다. -그냥 인증기능을 켜놓은 저장소에 Push를 하면 서버는 사용자 이름과 비밀번호를 물어본다. 그리고 Fetch 나 Pull 같은 읽기도 같은 URL을 사용한다. +그냥 인증기능을 켜놓은 저장소에 Push를 하면 서버는 사용자 이름과 비밀번호를 물어본다. 그리고 Fetch나 Pull 같은 읽기 작업에서도 같은 URL을 사용한다. ////////////////////////// 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. diff --git a/book/05-distributed-git/sections/contributing.asc b/book/05-distributed-git/sections/contributing.asc index afc7f4ee..8515cc8c 100644 --- a/book/05-distributed-git/sections/contributing.asc +++ b/book/05-distributed-git/sections/contributing.asc @@ -12,7 +12,7 @@ Some of the variables involved are active contributor count, chosen workflow, yo ////////////////////////// 프로젝트에 기여하는 방식을 설명하는데 가장 어려운 점은 그 방식이 매우 다양하다는 점이다. Git이 워낙 유연하게 설계됐기 때문에 사람들은 여러 가지 방식으로 사용할 수 있다. 게다가 프로젝트마다 환경이 달라서 프로젝트에 기여하는 방식을 쉽게 설명하기란 정말 어렵다. -기여하는 방식에 영향을 끼치는 몇 가지 변수가 있다. 활발히 기여하는 개발자의 수가 얼마인지, 선택한 Workflow가 무엇인지, 각 개발자에게 접근 권한을 어떻게 부여했는지, 외부에서도 기여할 수 있는지 등이 변수다. +기여하는 방식에 영향을 끼치는 몇 가지 변수가 있다. 활발히 기여하는 개발자의 수가 얼마인지, 선택한 워크플로가 무엇인지, 각 개발자에게 접근 권한을 어떻게 부여했는지, 외부에서도 기여할 수 있는지 등이 변수다. ////////////////////////// The first variable is active contributor count – how many users are actively contributing code to this project, and how often? @@ -37,11 +37,11 @@ Are all the patches peer-reviewed and approved? Are you involved in that process? Is a lieutenant system in place, and do you have to submit your work to them first? ////////////////////////// -두 번째 변수는 프로젝트에서 선택한 저장소 운영 방식(Workflow)이다. -메인 저장소에 개발자 모두가 쓰기 권한을 가지는 중앙집중형 방식인가? +두 번째 변수는 프로젝트에서 선택한 워크플로다. +개발자 모두가 메인 저장소에 쓰기 권한을 갖는 중앙집중형 방식인가? 프로젝트에 모든 Patch를 검사하고 통합하는 관리자가 따로 있는가? 모든 수정사항을 개발자끼리 검토하고 승인하는가? -자신도 기여 이상의 역할을 하고 있는지? +자신이 그저 돕는게 아니라 어떤 책임을 맡고 있는지? 중간 관리자가 있어서 그들에게 먼저 알려야 하는가? ////////////////////////// @@ -63,8 +63,8 @@ How often do you contribute? All these questions can affect how you contribute effectively to a project and what workflows are preferred or available to you. 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]] ////////////////////////// @@ -166,9 +166,8 @@ Further paragraphs come after blank lines. 라인 바꿈을 하고 이어지는 내용을 작성한다. 특정 상황에서는 첫 번째 라인이 이메일 메시지의 제목이 되고 나머지는 메일 -내용이 된다. 간략하게 요약하고 넣는 빈 -라인은 자세한 설명을 아예 쓰지 않는 한 -매우 중요하다. +내용이 된다. 빈 라인은 본문과 요약을 +구별해주기에 중요하다(본문 전체를 생략하지 않는 한). 이어지는 내용도 한 라인 띄우고 쓴다. @@ -532,14 +531,14 @@ The general sequence is something like this: 매우 간단한 상황의 예제를 살펴보았다. 토픽 브랜치에서 수정하고 로컬의 `master` 브랜치에 Merge 한다. 작업한 내용을 프로젝트의 공유 저장소에 Push 하고자 할 때는 우선 `origin/master` 브랜치를 Fetch 하고 Merge 한다. 그리고 나서 Merge 한 결과를 다시 서버로 Push 한다. -이런 Workflow가 일반적이며 아래와 같이 나타낼 수 있다. +이런 워크플로가 일반적이며 아래와 같이 나타낼 수 있다. ////////////////////////// .General sequence of events for a simple multiple-developer Git workflow. image::images/small-team-flow.png[General sequence of events for a simple multiple-developer Git workflow.] ////////////////////////// -.여러 개발자가 Git을 사용하는 Workflow. -image::images/small-team-flow.png[여러 개발자가 Git을 사용하는 Workflow.] +.여러 개발자가 Git을 사용하는 워크플로. +image::images/small-team-flow.png[여러 개발자가 Git을 사용하는 워크플로.] ////////////////////////// ==== Private Managed Team @@ -560,7 +559,7 @@ In this case, the company is using a type of integration-manager workflow where In this scenario, all work is done in team-based branches and pulled together by the integrators later. ////////////////////////// John씨와 Jessica씨는 어떤 기능을 함께 작업하게 됐다. 물론 각각 다른 일도 한다. -이런 상황이라면 회사는 Integration-manager Workflow를 선택하는 게 좋다. 작은 팀이 수행한 결과물은 Integration-Manager가 Merge 하고 공유 저장소의 master 브랜치를 업데이트한다. +이런 상황이라면 회사는 Integration-manager 워크플로를 선택하는 게 좋다. 작은 팀이 수행한 결과물은 Integration-Manager가 Merge 하고 공유 저장소의 master 브랜치를 업데이트한다. 팀마다 브랜치를 하나씩 만들고 Integration-Manager는 그 브랜치를 Pull 해서 Merge 한다. ////////////////////////// @@ -794,14 +793,14 @@ The sequence for the workflow you saw here is something like this: ////////////////////////// 수많은 팀의 작업을 동시에 진행하고 나중에 Merge 하는 기능을 사용하려고 다른 버전 관리 시스템에서 Git으로 바꾸는 조직들이 많아지고 있다. 팀은 자신의 브랜치로 작업하지만, 메인 브랜치에 영향을 끼치지 않는다는 점이 Git의 장점이다. -아래는 이런 Workflow을 나타내고 있다. +아래는 이런 워크플로를 나타내고 있다. ////////////////////////// .Basic sequence of this managed-team workflow. image::images/managed-team-flow.png[Basic sequence of this managed-team workflow.] ////////////////////////// -.Managed 팀의 Workflow. -image::images/managed-team-flow.png[Managed 팀의 Workflow.] +.Managed 팀의 워크플로. +image::images/managed-team-flow.png[Managed 팀의 워크플로.] [[_public_project]] ////////////////////////// @@ -820,7 +819,7 @@ The next section deals with projects that prefer to accept contributed patches v 비공개 팀을 운영하는 것과 공개 팀을 운영하는 것은 약간 다르다. 공개 팀을 운영할 때는 모든 개발자가 프로젝트의 공유 저장소에 직접적으로 쓰기 권한을 가지지는 않는다. 그래서 프로젝트의 관리자는 몇 가지 일을 더 해줘야 한다. Fork를 지원하는 Git 호스팅에서 Fork를 통해 프로젝트에 기여하는 법을 예제를 통해 살펴본다. -Git 호스팅 사이트(Github, BitBucket, Google Code, repo.or.cz 등) 대부분은 Fork 기능을 지원하며 프로젝트 관리자는 보통 Fork 하는 것으로 프로젝트를 운영한다. +Git 호스팅 사이트(GitHub, BitBucket, Google Code, repo.or.cz 등) 대부분은 Fork 기능을 지원하며 프로젝트 관리자는 보통 Fork 하는 것으로 프로젝트를 운영한다. 다른 방식으로 이메일과 Patch를 사용하는 방식도 있는데 뒤이어 살펴본다. ////////////////////////// @@ -1237,6 +1236,6 @@ This section has covered a number of common workflows for dealing with several v Next, you'll see how to work the other side of the coin: maintaining a Git project. You'll learn how to be a benevolent dictator or integration manager. ////////////////////////// -이번 절에서는 다양한 Workflow에 따라 Git을 어떻게 사용하는 지 살펴보고 그에 필요한 도구들을 설명했다. +이번 절에서는 다양한 워크플로에 따라 Git을 어떻게 사용하는지 살펴보고 그에 필요한 도구들을 설명했다. 다음 절에서는 동전의 뒷면인 프로젝트를 운영하는 방법에 대하여 살펴본다. 즉 친절한 Dictator나 Integration-Manager가 되어 보는 것이다. diff --git a/book/05-distributed-git/sections/distributed-workflows.asc b/book/05-distributed-git/sections/distributed-workflows.asc index b5aed041..d30c36f0 100644 --- a/book/05-distributed-git/sections/distributed-workflows.asc +++ b/book/05-distributed-git/sections/distributed-workflows.asc @@ -1,7 +1,7 @@ ////////////////////////// === Distributed Workflows ////////////////////////// -=== 분산 환경에서의 Workflow +=== 분산 환경에서의 워크플로 (((workflows))) ////////////////////////// @@ -14,13 +14,13 @@ We'll go over the strengths and possible weaknesses of each design; you can choo 중앙집중형 버전 관리 시스템과는 달리 Git은 분산형이다. Git은 구조가 매우 유연하기 때문에 여러 개발자가 함께 작업하는 방식을 더 다양하게 구성할 수 있다. 중앙집중형 버전 관리 시스템에서 각 개발자는 중앙 저장소를 중심으로 하는 한 노드일 뿐이다. 하지만, Git에서는 각 개발자의 저장소가 하나의 노드이기도 하고 중앙 저장소 같은 역할도 할 수 있다. 즉, 모든 개발자는 다른 개발자의 저장소에 일한 내용을 전송하거나, 다른 개발자들이 참여할 수 있도록 자신이 운영하는 저장소 위치를 공개할 수도 있다. -이런 특징은 프로젝트나 팀이 코드를 운영할 때 다양한 Workflow을 만들 수 있도록 해준다. +이런 특징은 프로젝트나 팀이 코드를 운영할 때 다양한 워크플로를 만들 수 있도록 해준다. 이런 유연성을 살려 저장소를 운영하는 몇 가지 방식을 소개한다. 각 방식의 장단점을 살펴보고 그 방식 중 하나를 고르거나 여러 가지를 적절히 섞어 쓰면 된다. ////////////////////////// ==== Centralized Workflow ////////////////////////// -==== 중앙집중식 Workflow +==== 중앙집중식 워크플로 (((workflows, centralized))) ////////////////////////// @@ -36,8 +36,8 @@ A number of developers are nodes – consumers of that hub – and synchronize t .Centralized workflow. image::images/centralized_workflow.png[Centralized workflow.] ////////////////////////// -.중앙집중식 Workflow. -image::images/centralized_workflow.png[중앙집중식 Workflow.] +.중앙집중식 워크플로. +image::images/centralized_workflow.png[중앙집중식 워크플로.] ////////////////////////// This means that if two developers clone from the hub and both make changes, the first developer to push their changes back up can do so with no problems. @@ -46,7 +46,7 @@ This concept is as true in Git as it is in Subversion(((Subversion))) (or any CV ////////////////////////// 중앙집중식에서 개발자 두 명이 중앙저장소를 Clone 하고 각자 수정하는 상황을 생각해보자. 한 개발자가 자신이 한 일을 커밋하고 나서 아무 문제 없이 서버에 Push 한다. 그러면 다른 개발자는 자신의 일을 커밋하고 Push 하기 전에 첫 번째 개발자가 한 일을 먼저 Merge 해야 한다. Merge를 해야 첫 번째 개발자가 작업한 내용을 덮어쓰지 않는다. -이런 개념은 Subversion과 같은 중앙집중식 버전 관리 시스템에서 사용하는 방식이고 Git에서도 당연히 이런 Workflow를 사용할 수 있다. +이런 개념은 Subversion과 같은 중앙집중식 버전 관리 시스템에서 사용하는 방식이고 Git에서도 당연히 이런 워크플로를 사용할 수 있다. ////////////////////////// If you are already comfortable with a centralized workflow in your company or team, you can easily continue using that workflow with Git. @@ -57,7 +57,7 @@ Then Jessica tries to push her changes, but the server rejects them. She is told that she's trying to push non-fast-forward changes and that she won't be able to do so until she fetches and merges. This workflow is attractive to a lot of people because it's a paradigm that many are familiar and comfortable with. ////////////////////////// -팀이 작거나 이미 중앙집중식에 적응한 상황이라면 이 Workflow에 따라 Git을 도입하여 사용할 수 있다. +팀이 작거나 이미 중앙집중식에 적응한 상황이라면 이 워크플로에 따라 Git을 도입하여 사용할 수 있다. 중앙 저장소를 하나 만들고 개발자 모두에게 Push 권한을 부여한다. 모두에게 Push 권한을 부여해도 Git은 한 개발자가 다른 개발자의 작업 내용을 덮어쓰도록 허용하지 않는다. John과 Jessica가 동시에 같은 부분을 수정하는 상황을 생각해보자. @@ -75,7 +75,7 @@ With Git's branching model, it's possible for hundreds of developers to successf ////////////////////////// ==== Integration-Manager Workflow ////////////////////////// -==== Integration-Manager Workflow +==== Integration-Manager 워크플로 (((workflows, integration manager))) ////////////////////////// @@ -86,7 +86,7 @@ Then, you can send a request to the maintainer of the main project to pull in yo The maintainer can then add your repository as a remote, test your changes locally, merge them into their branch, and push back to their repository. The process works as follows (see <>): ////////////////////////// -Git을 사용하면 리모트 저장소를 여러 개 운영할 수 있다. 다른 개발자는 읽기만 가능하고 자신은 쓰기도 가능한 공개 저장소를 만드는 Workflow도 된다. +Git을 사용하면 리모트 저장소를 여러 개 운영할 수 있다. 다른 개발자는 읽기만 가능하고 자신은 쓰기도 가능한 공개 저장소를 만드는 워크플로도 된다. 이 Worlflow에는 보통 프로젝트를 대표하는 공식 저장소가 있다. 기여자는 우선 공식 저장소를 하나 Clone 하고 수정하고 나서 자신의 저장소에 Push 한다. 그 다음에 프로젝트 Integration-Manager에게 새 저장소에서 Pull 하라고 요청한다. @@ -129,7 +129,7 @@ Contributors don't have to wait for the project to incorporate their changes – ////////////////////////// ==== Dictator and Lieutenants Workflow ////////////////////////// -==== Dictator and Lieutenants Workflow +==== Dictator and Lieutenants 워크플로 (((workflows, dictator and lieutenants))) ////////////////////////// @@ -145,7 +145,7 @@ The process works like this (see <>): 여러 명의 Integration-Manager가 저장소에서 자신이 맡은 부분만을 담당하는데 이들을 Lieutenants라고 부른다. 모든 Lieutenant는 최종 관리자 아래에 있으며 이 최종 관리자를 Dictator라고 부른다. 최종 관리자가 관리하는 저장소를 공식 저장소로 하며 모든 프로젝트 참여자는 이 공식 저장소를 기준으로 작업한다. -이러한 Workflow는 아래와 같다(<>). +이러한 워크플로는 아래와 같다(<>). ////////////////////////// 1. Regular developers work on their topic branch and rebase their work on top of `master`. @@ -178,13 +178,13 @@ It allows the project leader (the dictator) to delegate much of the work and col ////////////////////////// ==== Workflows Summary ////////////////////////// -==== Workflow 요약 +==== 워크플로 요약 ////////////////////////// These are some commonly used workflows that are possible with a distributed system like Git, but you can see that many variations are possible to suit your particular real-world workflow. Now that you can (hopefully) determine which workflow combination may work for you, we'll cover some more specific examples of how to accomplish the main roles that make up the different flows. In the next section, you'll learn about a few common patterns for contributing to a project. ////////////////////////// -이 세 가지 Workflow가 Git 같은 분산 버전 관리 시스템에서 주로 사용하는 것들이다. 사실 이런 Workflow뿐만 아니라 다양한 변종 Workflow가 실제로 사용된다. +이 세 가지 워크플로가 Git 같은 분산 버전 관리 시스템에서 주로 사용하는 것들이다. 사실 이런 워크플로뿐만 아니라 다양한 변종 워크플로가 실제로 사용된다. 어떤 방식을 선택하고 혹은 조합해야 하는 지 살짝 감이 잡힐 것이다. 앞으로 몇 가지 구체적 사례를 들고 우리가 다양한 환경에서 각 역할을 어떻게 수행하는지 살펴본다. 이어지는 내용에서 프로젝트에 참여하고 기여할 때 작업 패턴이 어떠한지 몇 가지 살펴보기로 한다. diff --git a/book/05-distributed-git/sections/maintaining.asc b/book/05-distributed-git/sections/maintaining.asc index 029fac34..7ba0c378 100644 --- a/book/05-distributed-git/sections/maintaining.asc +++ b/book/05-distributed-git/sections/maintaining.asc @@ -465,7 +465,7 @@ $ git diff master...contrib This command shows you only the work your current topic branch has introduced since its common ancestor with master. That is a very useful syntax to remember. ////////////////////////// -이 명령은 master 브랜치로부터 현재 토픽 브랜치의 다른 것들만 보여주기 때문에 +이 명령은 master 브랜치와 현재 토픽 브랜치에서 달라진 것들만 보여주기 때문에 기억해두면 매우 유용하게 사용할 수 있다. ////////////////////////// @@ -486,7 +486,7 @@ You have a number of choices, so we'll cover a few of them. ////////////////////////// ===== Merging Workflows ////////////////////////// -===== Merge 하는 Workflow +===== Merge 하는 워크플로 (((workflows, merging))) ////////////////////////// @@ -496,7 +496,7 @@ When you have work in a topic branch that you've done or that someone has contri If we have a repository with work in two branches named `ruby_client` and `php_client` that looks like <> and merge `ruby_client` first and then `php_client` next, then your history will end up looking like <>. ////////////////////////// 바로 `master` 브랜치에 Merge 하는 것이 가장 간단하다. -이 Workflow에서는 `master` 브랜치가 안전한 코드라고 가정한다. +이 워크플로에서는 `master` 브랜치가 안전한 코드라고 가정한다. 토픽 브랜치를 검증하고 `master` 브랜치로 Merge 할 때마다 토픽 브랜치를 삭제한다. <> 처럼 `ruby_client` 브랜치와 `php_client` 브랜치가 있을 때 `ruby_client` 브랜치를 `master` 브랜치로 Merge 한 후 `php_client` 브랜치를 Merge 하면 <> 같아진다. @@ -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 되지 않을 것이다. +이 워크플로에서 가장 간단한 시나리오다. 프로젝트의 규모가 커지거나 코드를 더 안정적으로 관리할 때는 이렇게 쉽게 Merge 되지 않을 것이다. ////////////////////////// If you have a more important project, you might want to use a two-phase merge cycle. @@ -561,14 +561,14 @@ This way, when people clone your project's repository, they can either check out You can also continue this concept, having an integrate branch where all the work is merged together. Then, when the codebase on that branch is stable and passes tests, you merge it into a develop branch; and when that has proven itself stable for a while, you fast-forward your master branch. ////////////////////////// -이 Workflow을 사용하면 프로젝트 저장소를 Clone 하고 나서 개발자가 안정 버전이 필요하면 master 브랜치를 빌드하고 안정적이지 않더라도 좀 더 최신 버전이 필요하면 develop 브랜치를 Checkout 하여 빌드한다. +이 워크플로를 사용하면 프로젝트 저장소를 Clone 하고 나서 개발자가 안정 버전이 필요하면 master 브랜치를 빌드하고 안정적이지 않더라도 좀 더 최신 버전이 필요하면 develop 브랜치를 Checkout 하여 빌드한다. 이 개념을 좀 더 확장해서 사용할 수 있다. 토픽 브랜치를 검증하기 위한 integrate 브랜치를 만들어 Merge 하고 토픽 브랜치가 검증되면 develop 브랜치에 머지한다. 그리고 develop 브랜치에서 충분히 안정하다는 것이 증명되면 그때 master 브랜치에 Merge 한다. ////////////////////////// ===== Large-Merging Workflows ////////////////////////// -===== 대규모 Merge Workflow +===== 대규모 Merge 워크플로 (((workflows, "merging (large)"))) ////////////////////////// @@ -613,13 +613,13 @@ Thus, when you clone the Git repository, you have four branches that you can che ////////////////////////// 토픽 브랜치가 결국 `master` 브랜치로 Merge 되면 저장소에서 삭제한다. 그리고 이전 릴리즈 버전에 Patch가 필요하면 `maint` 브랜치를 이용해 대응한다. -Git을 개발하는 프로젝트를 Clone 하면 브랜치가 4개 있고 각 브랜치를 이용하여 진행사항을 확인해볼 수 있다. 그래서 새로운 기능을 추가하려면 적당한 브랜치를 보고 고른다. 이 Workflow는 잘 구조화돼 있어서 코드가 새로 추가돼도 테스트하기 쉽다. +Git을 개발하는 프로젝트를 Clone 하면 브랜치가 4개 있고 각 브랜치를 이용하여 진행사항을 확인해볼 수 있다. 그래서 새로운 기능을 추가하려면 적당한 브랜치를 보고 고른다. 이 워크플로는 잘 구조화돼 있어서 코드가 새로 추가돼도 테스트하기 쉽다. [[_rebase_cherry_pick]] ////////////////////////// ===== Rebasing and Cherry Picking Workflows ////////////////////////// -===== Rebase와 Cherry-Pick Workflow +===== Rebase와 Cherry-Pick 워크플로 (((workflows, rebasing and cherry-picking))) ////////////////////////// @@ -627,9 +627,9 @@ Other maintainers prefer to rebase or cherry-pick contributed work on top of the When you have work in a topic branch and have determined that you want to integrate it, you move to that branch and run the rebase command to rebuild the changes on top of your current master (or `develop`, and so on) branch. If that works well, you can fast-forward your `master` branch, and you'll end up with a linear project history. ////////////////////////// -히스토리를 평평하게 관리하려고 Merge 보다 Rebase 나 Cherry-Pick을 더 선호하는 관리자들도 있다. +히스토리를 한 줄로 관리하려고 Merge 보다 Rebase 나 Cherry-Pick을 더 선호하는 관리자들도 있다. 토픽 브랜치에서 작업을 마친 후 master에 통합할 때 master 브랜치를 기반으로 Rebase 한다. 그러면 커밋이 다시 만들어 진다. master 대신 `develop` 등의 브랜치에도 가능하다. -문제가 없으면 `master` 브랜치를 Fast-forward시킨다. 이렇게 평평한 히스토리를 유지할 수 있다. +문제가 없으면 `master` 브랜치를 Fast-forward시킨다. 이렇게 히스토리를 한 줄로 유지할 수 있다. (((git commands, cherry-pick))) ////////////////////////// diff --git a/book/06-github/sections/1-setting-up-account.asc b/book/06-github/sections/1-setting-up-account.asc index d6cba0c2..1cb1aa75 100644 --- a/book/06-github/sections/1-setting-up-account.asc +++ b/book/06-github/sections/1-setting-up-account.asc @@ -155,7 +155,7 @@ Gravatar 서비스에 아바타를 업로드 한 적이 있으면 자동으로 The way that GitHub maps your Git commits to your user is by email address. If you use multiple email addresses in your commits and you want GitHub to link them up properly, you need to add all the email addresses you have used to the Emails section of the admin section. ////////////////////////// -Github은 Git 커밋에 있는 이메일 주소를 보고 어떤 사용자인지 식별한다. +GitHub은 Git 커밋에 있는 이메일 주소를 보고 어떤 사용자인지 식별한다. 사용자가 이메일 주소를 여러 개 사용해서 커밋했어도 GitHub에 그 이메일을 모두 등록하기만 했으면 GitHub은 잘 처리한다. ``Emails'' 화면에서 모두 등록한다. [[_add_email_addresses]] diff --git a/book/06-github/sections/2-contributing.asc b/book/06-github/sections/2-contributing.asc index 55c42fca..0e14566b 100644 --- a/book/06-github/sections/2-contributing.asc +++ b/book/06-github/sections/2-contributing.asc @@ -1,7 +1,7 @@ ////////////////////////// === Contributing to a Project ////////////////////////// -=== 프로젝트에 기여하기 +=== GitHub 프로젝트에 기여하기 ////////////////////////// Now that our account is setup, let's walk through some details that could be useful in helping you contribute to an existing project. @@ -71,8 +71,8 @@ GitHub is designed around a particular collaboration workflow, centered on Pull This flow works whether you're collaborating with a tightly-knit team in a single shared repository, or a globally-distributed company or network of strangers contributing to an project through dozens of forks. It is centered on the <<_topic_branch>> workflow covered in <<_git_branching>>. ////////////////////////// -GitHub은 Pull Request가 중심인 협업 Workflow를 위주로 설계됐다. -이 Workflow는 Fork 해서 프로젝트에 기여하는 것인데 단일 저장소만 사용하는 작은 팀이나 전 세계에서 흩어져서 일하는 회사, 혹은 한 번도 본 적 없는 사람들 사이에서도 유용하다. +GitHub은 Pull Request가 중심인 협업 워크플로를 위주로 설계됐다. +이 워크플로는 Fork 해서 프로젝트에 기여하는 것인데 단일 저장소만 사용하는 작은 팀이나 전 세계에서 흩어져서 일하는 회사, 혹은 한 번도 본 적 없는 사람들 사이에서도 유용하다. <<_git_branching>> 에서 설명했던 <<_topic_branch>> 중심으로 일하는 방식이다. ////////////////////////// @@ -97,12 +97,12 @@ Here's how it generally works: ////////////////////////// This is basically the Integration Manager workflow covered in <<_integration_manager>>, but instead of using email to communicate and review changes, teams use GitHub's web based tools. ////////////////////////// -이 방식은 기본적으로 <<_integration_manager>>에서 설명하는 Integration-Manager Workflow와 같다. 토론이나 리뷰를 이메일이 아니라 GitHub에서 제공하는 웹 기반 도구를 사용하는 것뿐이다. +이 방식은 기본적으로 <<_integration_manager>>에서 설명하는 Integration-Manager 워크플로와 같다. 토론이나 리뷰를 이메일이 아니라 GitHub에서 제공하는 웹 기반 도구를 사용하는 것뿐이다. ////////////////////////// Let's walk through an example of proposing a change to an open source project hosted on GitHub using this flow. ////////////////////////// -GitHub에 있는 오픈소스 프로젝트에 이 Workflow를 이용해서 뭔가 기여하는 예제를 살펴보자. +GitHub에 있는 오픈소스 프로젝트에 이 워크플로를 이용해서 뭔가 기여하는 예제를 살펴보자. ////////////////////////// ===== Creating a Pull Request @@ -260,7 +260,7 @@ Pull Request가 오면 프로젝트 소유자는 변경 점이 무엇인지 확 ////////////////////////// Where this conversation may take place over email in the workflows presented in <<_distributed_git>>, on GitHub this happens online. The project owner can review the unified diff and leave a comment by clicking on any of the lines. ////////////////////////// -이런 소통을 이메일로 하는 Workflow는 <<_distributed_git>>에 설명했었다. GitHub에서는 온라인에서 한다. 프로젝트 소유자는 'unified diff' 형식의 변경사항을 검토하고 즉각 해당 라인에 코멘트를 달 수 있다. +이런 소통을 이메일로 하는 워크플로는 <<_distributed_git>>에 설명했었다. GitHub에서는 온라인에서 한다. 프로젝트 소유자는 'unified diff' 형식의 변경사항을 검토하고 즉각 해당 라인에 코멘트를 달 수 있다. ////////////////////////// .Comment on a specific line of code in a Pull Request @@ -337,7 +337,7 @@ If you would prefer, you can simply pull the branch down and merge it locally. I ////////////////////////// This is the basic workflow that most GitHub projects use. Topic branches are created, Pull Requests are opened on them, a discussion ensues, possibly more work is done on the branch and eventually the request is either closed or merged. ////////////////////////// -이것은 대부분의 GitHub 프로젝트가 사용하는 기본 Workflow이다. 토픽 브랜치를 만들고 Pull Request를 연다. 거시서 토론을 계속 하고 그 브랜치에 커밋도 좀 하고 한다. 최종적으로 일하면 Merge 하고 닫는다. +이런 방식이 대부분의 GitHub 프로젝트가 사용하는 기본 워크플로다. 토픽 브랜치를 만들고 Pull Request를 연다. 거기서 토론을 계속 하고 그 브랜치에 커밋을 하기도 한다. 마지막에는 Merge하고 Request를 닫는다. [NOTE] ////////////////////////// @@ -370,7 +370,7 @@ GitHub에서 프로젝트에 기여하는 방법 중 가장 기본적인 방법 ////////////////////////// It's important to understand that many projects don't really think of Pull Requests as queues of perfect patches that should apply cleanly in order, as most mailing list-based projects think of patch series contributions. Most GitHub projects think about Pull Request branches as iterative conversations around a proposed change, culminating in a unified diff that is applied by merging. ////////////////////////// -보통 프로젝트에서는 Pull Request의 Patch가 완벽하고 큐처럼 꼭 순서대로 적용돼야 한다고 생각하지 않는다. 메일링 리스트를 사용하던 프로젝트에서는 Patch 순서가 의미가 있다고 생각한다. Github의 Pull Request는 어떤 주제를 두고 논의하는 자리다. 논의가 다 무르익으면 Merge 한다. +보통 프로젝트에서는 Pull Request의 Patch가 완벽하고 큐처럼 꼭 순서대로 적용돼야 한다고 생각하지 않는다. 메일링 리스트를 사용하던 프로젝트에서는 Patch 순서가 의미가 있다고 생각한다. GitHub의 Pull Request는 어떤 주제를 두고 논의하는 자리다. 논의가 다 무르익으면 Merge 한다. ////////////////////////// This is an important distinction, because generally the change is suggested before the code is thought to be perfect, which is far more rare with mailing list based patch series contributions. This enables an earlier conversation with the maintainers so that arriving at the proper solution is more of a community effort. When code is proposed with a Pull Request and the maintainers or community suggest a change, the patch series is generally not re-rolled, but instead the difference is pushed as a new commit to the branch, moving the conversation forward with the context of the previous work intact. @@ -423,7 +423,7 @@ Pull Request가 Merge 될 수 있도록 대상 브랜치를 Merge 하려면 먼 ////////////////////////// For example, let's say that in the ``tonychacon'' example we were using before, the original author made a change that would create a conflict in the Pull Request. Let's go through those steps. ////////////////////////// -``tonychacon'' 예제에 이 Workflow를 적용해보자. 원저자가 뭔가 수정을 했는데 Pull Request와 충돌이 난다. 여기부터 살펴보자. +``tonychacon'' 예제에 이 워크플로를 적용해보자. 원저자가 뭔가 수정을 했는데 Pull Request와 충돌이 난다. 여기부터 살펴보자. [source,shell] ---- @@ -543,7 +543,7 @@ GitHub URL을 전부 입력해도 딱 필요한 만큼으로 줄어든다. ////////////////////////// Now if Tony goes back and closes out the original Pull Request, we can see that by mentioning it in the new one, GitHub has automatically created a trackback event in the Pull Request timeline. This means that anyone who visits this Pull Request and sees that it is closed can easily link back to the one that superceded it. The link will look something like <<_pr_closed>>. ////////////////////////// -그리고 원래 있던 Pull Request를 닫으면 새 Pull Request에는 기존 Pull Request가 닫혔다고 언급된다. Github은 Pull Request 타임라인에 트랙백 이벤트를 자동으로 만든다. 그래서 이 Pull Request에 방문하는 사람은 예전 Pull Request가 닫혔는지 알 수 있고 그 링크가 있어서 바로 클릭해서 예전 것을 볼 수 있다. 이 링크는 <<_pr_closed>>처럼 생겼다. +그리고 원래 있던 Pull Request를 닫으면 새 Pull Request에는 기존 Pull Request가 닫혔다고 언급된다. GitHub은 Pull Request 타임라인에 트랙백 이벤트를 자동으로 만든다. 그래서 이 Pull Request에 방문하는 사람은 예전 Pull Request가 닫혔는지 알 수 있고 그 링크가 있어서 바로 클릭해서 예전 것을 볼 수 있다. 이 링크는 <<_pr_closed>>처럼 생겼다. [[_pr_closed]] ////////////////////////// @@ -646,17 +646,17 @@ Pull Request부터 열어 두고 일을 하면 해당 기능이 얼마나 진행 ////////////////////////// ====== Code Snippets ////////////////////////// -====== 코드 스니펫 +====== 코드 조각 ////////////////////////// You can also add code snippets to comments. This is especially useful if you want to present something that you _could_ try to do before actually implementing it as a commit on your branch. This is also often used to add example code of what is not working or what this Pull Request could implement. ////////////////////////// -코멘트에 코드 스니펫도 넣을 수 있다. 실제로 구현해서 브랜치에 커밋하기 전에 뭔가 아이디어를 코드로 표현해 볼 때 좋다. 그 외에도 단순히 코드 예제를 보여주기 위해서 사용하거나 해당 Pull Request에서 구현한 것이 무엇인지 보여줄 때도 사용한다. +코멘트에 코드 조각도 넣을 수 있다. 실제로 구현해서 브랜치에 커밋하기 전에 뭔가 아이디어를 코드로 표현해 볼 때 좋다. 그 외에도 단순히 코드 예제를 보여주기 위해서 사용하거나 해당 Pull Request에서 구현한 것이 무엇인지 보여줄 때도 사용한다. ////////////////////////// To add a snippet of code you have to ``fence'' it in backticks. ////////////////////////// -백틱으로 된 ``Fence'' 안에 코드 스니펫을 넣는다. +백틱으로 된 ``Fence'' 안에 코드 조각을 넣는다. [source] ---- @@ -671,7 +671,7 @@ for(int i=0 ; i < 5 ; i++) ////////////////////////// If you add a language name like we did there with 'java', GitHub will also try to syntax highlight the snippet. In the case of the above example, it would end up rendering like <<_md_code>>. ////////////////////////// -코드 스니펫에 언어 이름을 쓰면 GitHub은 구문강조(Syntax Highlight)도 해준다. <<_md_code>>는 언어 이름을 넣어서 구문 강조된 결과다. +코드 조각에 언어 이름을 쓰면 GitHub은 구문강조(Syntax Highlight)도 해준다. <<_md_code>>는 언어 이름을 넣어서 구문 강조된 결과다. [[_md_code]] ////////////////////////// diff --git a/book/06-github/sections/3-maintaining.asc b/book/06-github/sections/3-maintaining.asc index 011f2b86..419df5b6 100644 --- a/book/06-github/sections/3-maintaining.asc +++ b/book/06-github/sections/3-maintaining.asc @@ -2,7 +2,7 @@ ////////////////////////// === Maintaining a Project ////////////////////////// -=== 프로젝트 관리하기 +=== GitHub 프로젝트 관리하기 ////////////////////////// Now that we're comfortable contributing to a project, let's look at the other side: creating, maintaining and administering your own project. @@ -415,7 +415,7 @@ Switched to a new branch 'pr/2' The eagle-eyed among you would note the `head` on the end of the remote portion of the refspec. There's also a `refs/pull/#/merge` ref on the GitHub side, which represents the commit that would result if you push the ``merge'' button on the site. This can allow you to test the merge before even hitting the button. ////////////////////////// -`head`로 끝나는 Refspec에 대해서 살펴봤고 `refs/pull/#/merge` 처럼 생긴 것을 알아보자. 이 브랜치는 GitHub에서 Merge 버튼으로 Merge 했을 때 적용되는 결과다. GitHub에서 실제로 Merge 하기 전에 로컬로 가져와서 먼저 테스트할 수 있다. +`head`로 끝나는 Refspec에 대해서 살펴봤고 이제 `refs/pull/#/merge` 처럼 생긴 Refspec을 알아보자. 이 브랜치는 GitHub에서 Merge 버튼으로 Merge 했을 때 적용되는 결과다. GitHub에서 실제로 Merge 하기 전에 로컬로 가져와서 먼저 테스트할 수 있다. ////////////////////////// ===== Pull Requests on Pull Requests diff --git a/book/06-github/sections/5-scripting.asc b/book/06-github/sections/5-scripting.asc index 22426b83..898e46f2 100644 --- a/book/06-github/sections/5-scripting.asc +++ b/book/06-github/sections/5-scripting.asc @@ -6,7 +6,7 @@ ////////////////////////// So now we've covered all of the major features and workflows of GitHub, but any large group or project will have customizations they may want to make or external services they may want to integrate. ////////////////////////// -지금까지 GitHub의 주요기능과 Workflow를 모두 살펴봤다. 프로젝트가 크거나 그룹이 크면 매우 꼼꼼하게 설정하거나 다른 서비스를 통합시켜야 할 필요도 있다. +지금까지 GitHub의 주요기능과 워크플로를 모두 살펴봤다. 프로젝트가 크거나 그룹이 크면 매우 꼼꼼하게 설정하거나 다른 서비스를 통합시켜야 할 필요도 있다. ////////////////////////// Luckily for us, GitHub is really quite hackable in many ways. @@ -182,7 +182,7 @@ You can see the last few deliveries that GitHub has tried to make for that webho For each hook you can dig down into when it was delivered, if it was successful and the body and headers for both the request and the response. This makes it incredibly easy to test and debug your hooks. ////////////////////////// -Github은 개발하고 테스트할 때 사용하는 개발자 콘솔도 제공한다. 이 콘솔은 혹을 설정한 페이지에 있다. +GitHub은 개발하고 테스트할 때 사용하는 개발자 콘솔도 제공한다. 이 콘솔은 혹을 설정한 페이지에 있다. 콘솔에서 해당 웹훅의 최근 히스토리 몇 개를 확인할 수 있다. 어떤 데이터가 전송됐는지 확인할 수 있다. 만약 전송에 성공했으면 요청과 응답의 바디와 헤더를 모두 확인할 수 있다. 이것으로 훅을 쉽게 테스트하고 디버깅할 수 있다. @@ -502,5 +502,5 @@ Check out http://github.com/octokit[] for more information on these, as they han Hopefully these tools can help you customize and modify GitHub to work better for your specific workflows. For complete documentation on the entire API as well as guides for common tasks, check out https://developer.github.com[]. ////////////////////////// -이 도구로 프로젝트가 요구하는 데로 GitHub의 Workflow를 최적화할 수 있다. +이 도구로 프로젝트가 요구하는 데로 GitHub의 워크플로를 최적화할 수 있다. 전체 API에 대한 구체적인 문서와 상황별 가이드는 https://developer.github.com[]에서 확인해야 한다. diff --git a/book/07-git-tools/1-git-tools.asc b/book/07-git-tools/1-git-tools.asc index de15075c..5b0c186e 100644 --- a/book/07-git-tools/1-git-tools.asc +++ b/book/07-git-tools/1-git-tools.asc @@ -8,7 +8,7 @@ By now, you’ve learned most of the day-to-day commands and workflows that you need to manage or maintain a Git repository for your source code control. You’ve accomplished the basic tasks of tracking and committing files, and you’ve harnessed the power of the staging area and lightweight topic branching and merging. ////////////////////////// -지금까지 일상적으로 자주 사용하는 명령들과 몇 가지 Workflow를 배웠다. +지금까지 일상적으로 자주 사용하는 명령들과 몇 가지 워크플로를 배웠다. 파일을 추적하고 커밋하는 등의 기본적인 명령뿐만 아니라 Staging Area가 왜 좋은지도 배웠고 가볍게 토픽 브랜치를 만들고 Merge 하는 방법도 다뤘다. 이제는 Git 저장소로 충분히 소스코드를 관리할 수 있을 것이다. ////////////////////////// diff --git a/book/07-git-tools/sections/advanced-merging.asc b/book/07-git-tools/sections/advanced-merging.asc index c24f94d2..699479c6 100644 --- a/book/07-git-tools/sections/advanced-merging.asc +++ b/book/07-git-tools/sections/advanced-merging.asc @@ -70,7 +70,7 @@ hello() In our repository, we create a new branch named `whitespace` and proceed to change all the Unix line endings to DOS line endings, essentially changing every line of the file, but just with whitespace. Then we change the line ``hello world'' to ``hello mundo''. /////////////////// -저장소에 `whitespace` 브랜치를 생성하고 생성한 브랜치 상에서 위의 파일에서 모든 Unix 형식 개행을 DOS 형식 개행으로 바꾸어 커밋한다. 파일의 모든 라인이 바뀌었지만, 공백만 바뀌었다. +저장소에 `whitespace` 브랜치를 생성하고 모든 Unix 개행을 DOS 개행으로 바꾸어 커밋한다. 파일의 모든 라인이 바뀌었지만, 공백만 바뀌었다. 그 후 ``hello world'' 문자열을 ``hello mundo''로 바꾼 다음에 커밋한다. [source,console] diff --git a/book/07-git-tools/sections/reset.asc b/book/07-git-tools/sections/reset.asc index 0103ff13..0259ad97 100644 --- a/book/07-git-tools/sections/reset.asc +++ b/book/07-git-tools/sections/reset.asc @@ -158,7 +158,7 @@ $ tree ////////////////////////// ==== The Workflow ////////////////////////// -==== Workflow +==== 워크플로 ////////////////////////// Git's main purpose is to record snapshots of your project in successively better states, by manipulating these three trees. @@ -437,7 +437,7 @@ image::images/reset-path2.png[] This is why the output of the `git status` command suggests that you run this to unstage a file. (See <<_unstaging>> for more on this.) ////////////////////////// -이것이 `git status` 명령에서 Staging Area에서 파일을 Unstaged 상태로 내리려면 이 명령을 실행하라고 보여주는 이유다. +이것이 git status 명령에서 이 명령을 보여주는 이유다. 이 명령으로 파일을 Unstaged 상태로 만들 수 있다. (더 자세한 내용은 <<_unstaging>>를 참고한다.) ////////////////////////// diff --git a/book/07-git-tools/sections/rewriting-history.asc b/book/07-git-tools/sections/rewriting-history.asc index 068ac40a..8cf1bea4 100644 --- a/book/07-git-tools/sections/rewriting-history.asc +++ b/book/07-git-tools/sections/rewriting-history.asc @@ -196,7 +196,8 @@ Once you’re satisfied with your changes, run These instructions tell you exactly what to do. Type ////////////////////////// -정확히 뭘 해야 하는지 알려준다. 아래와 같은 명령을 실행하고 +명령 프롬프트가 나타날 때 Git은 Rebase 과정에서 현재 정확히 뭘 해야 하는지 메시지로 알려준다. +아래와 같은 명령을 실행하고 [source,console] ---- @@ -207,7 +208,8 @@ $ git commit --amend Change the commit message, and exit the editor. Then, run ////////////////////////// -커밋 메시지를 수정하고 텍스트 편집기를 종료하고 나서 아래 명령을 실행한다. +커밋 메시지를 수정하고 텍스트 편집기를 종료하고 나서 +아래 명령을 실행한다. [source,console] ---- diff --git a/book/07-git-tools/sections/subtree-merges.asc b/book/07-git-tools/sections/subtree-merges.asc index 62c843ec..abf6bd5d 100644 --- a/book/07-git-tools/sections/subtree-merges.asc +++ b/book/07-git-tools/sections/subtree-merges.asc @@ -132,7 +132,7 @@ We can keep branches with other related projects in our repository and subtree m 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이다. +이런 방식은 서브모듈(<<_git_submodules>>에서 자세하게 다룬다)을 사용하지 않고 서브모듈을 관리하는 또 다른 워크플로이다. 한 저장소 안에 다른 프로젝트까지 유지하면서 서브트리 Merge 전략으로 업데이트도 할 수 있다. 프로젝트에 필요한 코드를 한 저장소에서 관리할 수 있다. 다만, 이렇게 저장소를 관리하는 방법은 저장소를 다루기 좀 복잡하고 통합할 때 실수하기 쉽다. 엉뚱한 저장소로 Push 해버릴 가능성도 있다. diff --git a/book/08-customizing-git/1-customizing-git.asc b/book/08-customizing-git/1-customizing-git.asc index 49babcad..7b012e37 100644 --- a/book/08-customizing-git/1-customizing-git.asc +++ b/book/08-customizing-git/1-customizing-git.asc @@ -33,4 +33,4 @@ You should now be able to make Git fit nearly any workflow you can dream up. ////////////////////////// Git을 프로젝트에 맞추는 방법을 배웠다. 주요한 서버/클라이언트 설정 방법, 파일 단위로 설정하는 Git Attributes, 이벤트 훅, 정책을 강제하는 방법을 배웠다. -이제 필요한 Workflow를 만들고 Git을 거기에 맞게 설정할 수 있을 것이다. +이제 필요한 워크플로를 만들고 Git을 거기에 맞게 설정할 수 있을 것이다. diff --git a/book/08-customizing-git/sections/config.asc b/book/08-customizing-git/sections/config.asc index d16587a6..86a3b6e3 100644 --- a/book/08-customizing-git/sections/config.asc +++ b/book/08-customizing-git/sections/config.asc @@ -77,7 +77,7 @@ If you want to see a list of all the options your version of Git recognizes, you ////////////////////////// 설정이 영향을 미치는 대상에 따라 클라이언트 설정과 서버 설정으로 나눠볼 수 있다. 대부분은 개인작업 환경과 관련된 클라이언트 설정이다. -Git에는 설정거리가 매우 많은데, 여기서는 Workflow를 관리하는 데 필요한 것과 주로 많이 사용하는 것만 설명한다. +Git에는 설정거리가 매우 많은데, 여기서는 워크플로를 관리하는 데 필요한 것과 주로 많이 사용하는 것만 설명한다. 한 번도 겪지 못할 상황에서나 유용한 옵션까지 다 포함하면 설정할 게 너무 많다. Git 버전마다 옵션이 조금씩 다른데, 아래와 같이 실행하면 설치한 버전에서 사용할 수 있는 옵션을 모두 보여준다. diff --git a/book/08-customizing-git/sections/hooks.asc b/book/08-customizing-git/sections/hooks.asc index dee2ff4e..c36b97d2 100644 --- a/book/08-customizing-git/sections/hooks.asc +++ b/book/08-customizing-git/sections/hooks.asc @@ -67,7 +67,7 @@ If your intent with these scripts is to enforce a policy, you'll probably want t ////////////////////////// ===== Committing-Workflow Hooks ////////////////////////// -===== 커밋 Workflow 훅 +===== 커밋 워크플로 훅 ////////////////////////// The first four hooks have to do with the committing process. @@ -120,14 +120,14 @@ Generally, this script is used for notification or something similar. ////////////////////////// ===== Email Workflow Hooks ////////////////////////// -===== 이메일 Workflow 훅 +===== 이메일 워크플로 훅 ////////////////////////// You can set up three client-side hooks for an email-based workflow. They're all invoked by the `git am` command, so if you aren't using that command in your workflow, you can safely skip to the next section. If you're taking patches over email prepared by `git format-patch`, then some of these may be helpful to you. ////////////////////////// -이메일 Workflow에 해당하는 클라이언트 훅은 세 가지이다. +이메일 워크플로에 해당하는 클라이언트 훅은 세 가지이다. 이 훅은 모두 `git am` 명령으로 실행된다. 이 명령어를 사용할 일이 없으면 이 절은 읽지 않아도 된다. 하지만, 언젠가는 `git format-patch` 명령으로 만든 Patch를 이메일로 받는 날이 올지도 모른다. diff --git a/book/08-customizing-git/sections/policy.asc b/book/08-customizing-git/sections/policy.asc index 09f4d0b0..71b10868 100644 --- a/book/08-customizing-git/sections/policy.asc +++ b/book/08-customizing-git/sections/policy.asc @@ -9,7 +9,7 @@ In this section, you'll use what you've learned to establish a Git workflow that checks for a custom commit message format, and allows only certain users to modify certain subdirectories in a project. You'll build client scripts that help the developer know if their push will be rejected and server scripts that actually enforce the policies. ////////////////////////// -지금까지 배운 것을 한 번 적용해보자. 나름의 커밋 메시지 규칙으로 검사하고 Fast-forward Push 만 허용하고 디렉토리마다 사용자의 수정 권한을 제어하는 Workflow를 만든다. +지금까지 배운 것을 한 번 적용해보자. 나름의 커밋 메시지 규칙으로 검사하고 Fast-forward Push 만 허용하고 디렉토리마다 사용자의 수정 권한을 제어하는 워크플로를 만든다. 실질적으로 정책을 강제하려면 서버 훅으로 만들어야 한다. 하지만, 개발자들이 Push 할 수 없는 커밋은 아예 만들지 않도록 클라이언트 훅도 만든다. ////////////////////////// diff --git a/book/09-git-and-other-scms/sections/client-hg.asc b/book/09-git-and-other-scms/sections/client-hg.asc index 34a64b2d..1e78b0d6 100644 --- a/book/09-git-and-other-scms/sections/client-hg.asc +++ b/book/09-git-and-other-scms/sections/client-hg.asc @@ -45,7 +45,7 @@ Git-remote-hg has one other dependency: the `mercurial` library for Python. If you have Python installed, this is as simple as: ////////////////////////// 예제에서는 `~/bin` 디렉토리가 `$PATH` 실행경로에 포함되어 있다고 가정한다. -git-remote-hg은 `mercurial` Python 라이브러리를 필요로 한다. +git-remote-hg를 실행하려면 Python 라이브러리 `mercurial` 이 필요하다. Python이 설치되어있다면 아래처럼 Mercurial 라이브러리를 설치한다. [source,console] @@ -197,7 +197,7 @@ The good news is that we mostly don't have to worry about all of this. The typical workflow won't be very different from working with a Git remote. ////////////////////////// 이런 내용은 몰라도 되고 모른다고 걱정할 필요 없다. -일반적인 Workflow에서 Git 리모트를 사용하는 것과 크게 다르지 않다. +일반적인 워크플로에서 Git 리모트를 사용하는 것과 크게 다르지 않다. ////////////////////////// There's one more thing we should attend to before we continue: ignores. @@ -218,7 +218,7 @@ The `.git/info/exclude` file acts just like a `.gitignore`, but isn't included i ////////////////////////// `.git/info/exclude` 파일은 `.gitignore` 파일처럼 동작하지만 커밋할 수 없다. -===== Workflow +===== 워크플로 ////////////////////////// Let's assume we've done some work and made some commits on the `master` branch, and you're ready to push it to the remote repository. 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 b4f65129..84e1118b 100644 --- a/book/09-git-and-other-scms/sections/client-p4.asc +++ b/book/09-git-and-other-scms/sections/client-p4.asc @@ -15,7 +15,7 @@ Perforce는 기업에서 많이 사용하는 버전 관리 시스템이다. 1995년 무렵부터 사용됐으며 이 장에서 다루는 시스템 중에서 가장 오래된 버전 관리 시스템이다. 처음 Perforce를 만든 당시 환경에 맞게 설계했기 때문에 몇 가지 특징이 있다. 언제나 중앙 서버에 연결할 수 있고 로컬에는 한 버전만 저장한다. -Perforce가 잘 맞는 Workflow도 있겠지만 Git을 도입하면 훨씬 나은 Workflow를 적용할 수 있을 것이라 생각한다. +Perforce가 잘 맞는 워크플로도 있겠지만 Git을 도입하면 훨씬 나은 워크플로를 적용할 수 있을 것이라 생각한다. ////////////////////////// There are two options if you'd like to mix your use of Perforce and Git. @@ -44,7 +44,7 @@ Perforce는 Git Fusion(http://www.perforce.com/git-fusion[] 에서 다운로드 For our examples, we'll be using the easiest installation method for Git Fusion, which is downloading a virtual machine that runs the Perforce daemon and Git Fusion. You can get the virtual machine image from http://www.perforce.com/downloads/Perforce/20-User[], and once it's finished downloading, import it into your favorite virtualization software (we'll use VirtualBox). ////////////////////////// -Git Fusion을 가장 쉽게 설치하는 방법으로 Perforce 데몬과 Git Fusion이 포함된 가상 머신 이미지를 내려받을 수 있다. +Perforce 데몬과 Git Fusion이 포함된 가상 머신 이미지를 내려받는 것이 Git Fusion을 가장 쉽게 설치하는 방법이다. 가상머신 이미지는 http://www.perforce.com/downloads/Perforce/20-User[] 의 `Git Fusion` 탭에서 받을 수 있다. VirtualBox 같은 가상화 소프트웨어로 이 이미지를 동작시킬 수 있다. ////////////////////////// @@ -94,7 +94,7 @@ The Git Fusion image comes with a certificate, but it's for a domain that won't If this is going to be a permanent installation, consult the Perforce Git Fusion manual to install a different certificate; for our example purposes, this will suffice: ////////////////////////// 다음으로 해야 할 작업은 클라이언트 환경에서 Git이 SSL 인증서를 검증하지 않도록 설정하는 것이다. -Git Fusion 이미지에 포함된 SSL 인증서는 도메인 이름으로 접속을 검증한다. 여기서는 IP 주소로 접근할 거라서 Git이 HTTPS 인증서를 검증하지 못해 접속할 수 없다. +Git Fusion 이미지에 포함된 SSL 인증서는 도메인 이름으로 접속을 검증한다. 여기서는 IP 주소로 접근할 거라서 Git이 HTTPS 인증서를 검증하지 못한다. 그래서 접속할 수도 없다. 이 Git Fusion 가상머신 이미지를 실제로 사용할 거라면 Perforce Git Fusion 메뉴얼을 참고해서 SSL 인증서를 새로 설치해서 사용하는 것을 권한다. 그냥 해보는 거라면 인증서 검증을 안하면 된다. [source,console] @@ -209,7 +209,7 @@ If you open this file, you'll see a `[@repo]` section with some settings that ar You'll also see sections that look like this: ////////////////////////// 이 책에서는 이 파일 내용 한 줄 한 줄 그 의미를 설명하지는 않는다. Git에서 사용하는 환경설정 파일과 마찬가지로 INI 형식으로 관리된다는 점을 알아두면 된다. -루트 디렉토리에 위치한 이 파일은 전역 설정이다. `repos/Talkhouse/p4gf_config` 처럼 각 저장소마다 설정할 수도 있는데 전역설정을 위에(Override) 적용된다. +루트 디렉토리에 위치한 이 파일은 전역 설정이다. `repos/Talkhouse/p4gf_config` 처럼 각 저장소마다 설정할 수도 있는데 전역설정 위에(Override) 적용된다. 각 저장소별 설정 파일의 내용을 보면 아래와 같이 전역 설정과 다른 섹션이 있다. [source,ini] @@ -281,13 +281,13 @@ This is nice if you want to open-source an internal project, but don't want to p Note that the email addresses and full names should be unique, unless you want all the Git commits to be attributed to a single fictional author. ////////////////////////// 마지막 두 라인은 Perforce 사용자 bob도 joe도 Git 커밋으로 변환할 때는 같은 이름을 쓰도록 설정한 것이다. -내부 프로젝트를 오픈소스로 공개할 때 이름을 드러내지 않고 외부로 오픈할 경우 유용하다. -Changeset을 작성한 사람을 노출하지 않고 Git 커밋은 다른 사람이 작성한 것으로 하려는 게 아니라면 사람 이름과 이메일 주소가 중복되지 않아야 한다. +이는 내부 프로젝트를 오픈 소스로 공개할 때, 내부 개발자 이름을 드러내지 않고 외부로 오픈할 때 유용하다. +Git 커밋을 한 사람이 작성한 것으로 하려는게 아니라면 사람 이름과 이메일 주소는 중복되지 않아야 한다. ////////////////////////// ====== Workflow ////////////////////////// -====== Workflow +====== 워크플로 ////////////////////////// Perforce Git Fusion is a two-way bridge between Perforce and Git version control. @@ -583,7 +583,7 @@ git-p4는 리모트 서버의 상태를 보여주기 위해 몇 가지 Ref를 ////////////////////////// ====== Workflow ////////////////////////// -====== Workflow +====== 워크플로 ////////////////////////// Okay, let's do some work. 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 9c99e85d..c724bca0 100644 --- a/book/09-git-and-other-scms/sections/client-svn.asc +++ b/book/09-git-and-other-scms/sections/client-svn.asc @@ -25,7 +25,7 @@ The Subversion bridge is the gateway drug to the DVCS world. Git이 자랑하는 또 하나의 기능은 `git svn`이라는 양방향 Subversion 지원 도구이다. Git을 Subversion 클라이언트로 사용할 수 있기 때문에 로컬에서는 Git의 기능을 활용하고 Push 할 때는 Subversion 서버에 Push 한다. 로컬 브랜치와 Merge, Staging Area, Rebase, Cherry-pick 등의 Git 기능을 충분히 사용할 수 있다. 같이 일하는 동료는 빛 한줄기 없는 선사시대 동굴에서 일하겠지만 말이다. -`git svn`은 기업에서 git을 사용할 수 있도록 돕는 출발점이다. 우리가 Git을 도입하기 위해 기업내에서 노력하는 동안 동료가 효율적으로 환경을 바꿀 수 있도록 도움을 준다. +`git svn`은 기업에서 git을 사용할 수 있도록 돕는 출발점이다. 회사가 아직 공식적으로 Git을 사용하지 않더라도 동료들과 먼저 Git을 이용해 더 효율적으로 일할 수 있다. 이 Subversion 지원 도구는 우리를 DVCS 세상으로 인도하는 붉은 알약과 같다. ===== `git svn` @@ -210,7 +210,7 @@ $ git branch -a ////////////////////////// Note how this tool manages Subversion tags as remote refs. ////////////////////////// -Subversion 태그를 리모트 브랜치 처럼 관리하는 것을 알아두어야 한다. +Subversion 태그를 리모트 브랜치처럼 관리하는 것을 알아두어야 한다. (((git commands, show-ref))) ////////////////////////// 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 22116470..73c05059 100644 --- a/book/09-git-and-other-scms/sections/client-tfs.asc +++ b/book/09-git-and-other-scms/sections/client-tfs.asc @@ -231,7 +231,7 @@ This has the implication that your Git commits will have a different SHA-1 hash git-tfs에서는 태그 대신에 TFVC Changeset과 Git 커밋의 관계를 이렇게 표시한다. TFVC에 Push 하면 이 표시가 변경되고 Git 커밋의 SHA-1 해시값도 바뀐다. -===== Git-tf[s] Workflow +===== Git-tf[s] 워크플로 [NOTE] //////////// @@ -260,7 +260,7 @@ The obvious next thing you're going to want to do is work on the project. TFVC and TFS have several features that may add complexity to your workflow: //////////// 다음으로 할 일은 실제로 프로젝트를 진행하는 것이다. -TFVC와 TFS의 기능 중에서 Workflow를 복잡하게 만드는 게 있다. +TFVC와 TFS의 기능 중에서 워크플로를 복잡하게 만드는 게 있다. //////////// . Feature branches that aren't represented in TFVC add a bit of complexity. @@ -275,7 +275,7 @@ TFVC와 TFS의 기능 중에서 Workflow를 복잡하게 만드는 게 있다. 이점이 TFVC와 Git이 매우 다른 방식으로 브랜치를 표현하게 만든다. . TFVC는 사용자가 서버에서 파일을 ``Checkout''받아서 아무도 수정하지 못하도록 잠글 수 있다는 것을 명심해야 한다. 서버에서 파일을 잠갔더라도 파일을 수정할 수 있다. 하지만 TFVC 서버로 Push 할 때 방해될 수 있다. -. TFS는 ``Gated'' 체크인이라는 기능이 있다. 체크인하기 하려면 TFS의 빌드-테스트 사이클을 성공해야 체크인된다. +. TFS는 ``Gated'' 체크인이라는 기능이 있다. TFS의 빌드-테스트 사이클을 성공해야만 체크인이 허용된다. 이 기능은 TFVC의 ``Shelve''라는 기능으로 구현됐다. 이 기능은 여기서 다루지 않는다. git-tf으로는 수동으로 맞춰 줘야 하고, git-tfs는 Gated 체크인을 인식하는 +checkintool+ 명령어를 제공한다. @@ -284,7 +284,7 @@ In the interest of brevity, what we'll cover here is the happy path, which sides //////////// 여기서는 잘되는 시나리오만 보여준다. 돌 다리를 두두리는 방법은 다루지 않는다. 간결함을 위해서다. -===== Workflow: `git-tf` +===== 워크플로: `git-tf` //////////// Let's say you've done some work, made a couple of Git commits on `master`, and you're ready to share your progress on the TFVC server. @@ -415,7 +415,7 @@ It's important to note that not every Git commit needs to have an exact counterp That's the main workflow. There are a couple of other considerations you'll want to keep in mind: //////////// -이것이 주 Workflow다. +이것이 주 워크플로다. 아래의 고려사항은 가슴속에 새겨야 한다. //////////// @@ -431,7 +431,7 @@ There are a couple of other considerations you'll want to keep in mind: git-tf로 TFVC 저장소의 Clone 할 때마다 SHA-1 해시를 새로 생성한다. SHA-1가 다르기 때문에 두고두고 골치가 아프게 된다. * 협업은 Git으로 하고 TFVC와는 주기적으로 동기화만 하고 싶다면 TFVC와 통신하는 Git 저장소를 딱 하나만 둬라. -===== Workflow: `git-tfs` +===== 워크플로: `git-tfs` //////////// Let's walk through the same scenario using git-tfs. 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 c0a9cb2b..3dc80114 100644 --- a/book/09-git-and-other-scms/sections/import-svn.asc +++ b/book/09-git-and-other-scms/sections/import-svn.asc @@ -126,7 +126,7 @@ $ rm -Rf .git/refs/remotes/origin/tags ////////////////////////// This takes the references that were remote branches that started with `remotes/origin/tags/` and makes them real (lightweight) tags. ////////////////////////// -`remotes/origin/tags/`로 시작하는 리모트 브랜치를 가져다 (Lightweight) 태그로 만들었다. +`remotes/origin/tags/`로 시작하는 리모트 브랜치를 가져다 Lightweight 태그로 만들었다. ////////////////////////// Next, move the rest of the references under `refs/remotes` to be local branches: diff --git a/book/10-git-internals/1-git-internals.asc b/book/10-git-internals/1-git-internals.asc index e7ecc253..41dd356a 100644 --- a/book/10-git-internals/1-git-internals.asc +++ b/book/10-git-internals/1-git-internals.asc @@ -64,7 +64,7 @@ Understanding how Git works at a lower level should make it easier to understand ////////////////////////// Git이 내부적으로 어떻게 동작하는지 뿐만 아니라 어떻게 구현됐는지까지 잘 알게 됐을 것이다. 이 장에서는 저수준 명령어인 Plumbing 명령어를 설명했다. 다른 장에서 우리가 배웠던 Porcelain 명령어보다는 단순하다. -Git이 내부적으로 어떻게 동작하는지 알면 Git이 왜 그렇게 하는가를 더 쉽게 이해할 수 있을 뿐만 아니라 개인적으로 필요한 도구나 스크립트를 만들어 자신의 Workflow를 개선할 수 있다. +Git이 내부적으로 어떻게 동작하는지 알면 Git이 왜 그렇게 하는가를 더 쉽게 이해할 수 있을 뿐만 아니라 개인적으로 필요한 도구나 스크립트를 만들어 자신의 워크플로를 개선할 수 있다. ////////////////////////// Git as a content-addressable filesystem is a very powerful tool that you can easily use as more than just a VCS. diff --git a/book/10-git-internals/sections/objects.asc b/book/10-git-internals/sections/objects.asc index 0173a6f3..d2a4d6bf 100644 --- a/book/10-git-internals/sections/objects.asc +++ b/book/10-git-internals/sections/objects.asc @@ -564,7 +564,7 @@ Then, open the file with `File.open()` and write out the previously zlib-compres ////////////////////////// 마지막으로 zlib으로 압축한 내용을 개체로 저장한다. SHA-1 값 중에서 맨 앞에 있는 두 자를 가져다 하위 디렉토리 이름으로 사용하고 나머지 38자를 그 디렉토리 안에 있는 파일이름으로 사용한다. -Ruby에서는 `FileUtils.mkdir_p()`로 하위 디렉토리의 존재를 보장하고 나서 `File.open()`으로 파일을 연다. +Ruby에서는 `FileUtils.mkdir_p()`로 디렉토리를 (없으면) 만들고 `File.open()`으로 파일을 연다. 그리고 그 파일에 zlib으로 압축한 내용을 `write()` 함수로 저장한다. [source,console] diff --git a/book/10-git-internals/sections/packfiles.asc b/book/10-git-internals/sections/packfiles.asc index 43010560..538fbd72 100644 --- a/book/10-git-internals/sections/packfiles.asc +++ b/book/10-git-internals/sections/packfiles.asc @@ -63,7 +63,7 @@ $ git cat-file -p master^{tree} ////////////////////////// You can then use `git cat-file` to see how big that object is: ////////////////////////// -`git cat-file` 명령으로 개체의 크기는 아래와 같이 확인한다. +`git cat-file` 명령으로 개체의 크기를 아래와 같이 확인한다. [source,console] ---- @@ -125,7 +125,7 @@ To see what happens, you can manually ask Git to pack up the objects by calling 가능하다. Git이 처음 개체를 저장하는 형식은 ``Loose'' 개체 포맷이라고 부른다. 나중에 이 개체를 파일 하나로 압축(Pack)할 수 있다. 이렇게 하여 공간을 절약하고 효율을 높일 수 있다. -Git이 이렇게 압축하는 때는 Loose 개체가 너무 많을 때, `git gc` 명령을 실행했을 때, 리모트 서버로 Push 할 때 압축한다. +Git은 Loose 개체가 너무 많을 때, git gc 명령을 실행했을 때, 리모트 서버로 Push할 때 이렇게 압축한다. `git gc` 명령을 실행해서 어떻게 압축하는지 살펴보자. [source,console] diff --git a/book/A-git-in-other-environments/sections/guis.asc b/book/A-git-in-other-environments/sections/guis.asc index 1fc0aef6..c6f71da8 100644 --- a/book/A-git-in-other-environments/sections/guis.asc +++ b/book/A-git-in-other-environments/sections/guis.asc @@ -19,7 +19,7 @@ Some clients expose only a carefully curated subset of Git functionality, in ord When viewed in this light, none of these tools can be called ``better'' than any of the others, they're simply more fit for their intended purpose. Also note that there's nothing these graphical clients can do that the command-line client can't; the command-line is still where you'll have the most power and control when working with your repositories. ////////////////////////// -무슨 인터페이스를 사용하느냐는 중요하지 않지만, 인터페이스에 따라 Workflow도 달라져야 한다. +무슨 인터페이스를 사용하느냐는 중요하지 않지만, 인터페이스에 따라 워크플로도 달라져야 한다. Git의 기능을 엄선해서 제공하는 클라이언트 프로그램이 있는데 이런 도구에서는 지원하는 방법으로만 Git을 사용해야 한다. 이런 맥락으로 각 도구를 서로 비교하고 줄 세울 수 없다. 도구마다 고유의 목적이 있다. 하지만 CLI로는 뭐든 다 할 수 있다. GUI 클라이언트로 할 수 있는 일 중 CLI로 못 하는 일은 없다. @@ -151,7 +151,7 @@ These clients are a good example of workflow-oriented tools – rather than expo They look like this: ////////////////////////// GitHub은 'GitHub for Mac'과 'GitHub for Windows'라는 Git 클라이언트를 만들었다. -이 클라이언트는 Git의 모든 기능을 지원하지 않는다. 사람들이 많이 사용하는 Workflow를 따르도록 만들었다. +이 클라이언트는 Git의 모든 기능을 지원하지 않는다. 사람들이 많이 사용하는 워크플로를 따르도록 만들었다. 어떻게 생겼는지 한번 보자. .GitHub for Mac. @@ -187,8 +187,8 @@ While they're designed to highlight GitHub's service and recommended workflow, t ==== ////////////////////////// ==== -Github 계정이 없어도 이 툴을 사용할 수 있다. -GitHub 서비스와 GitHub이 제안하는 Workflow에 초점을 맞춘 툴이지만 다른 호스트나 저장소에도 사용할 수 있다. +GitHub 계정이 없어도 이 툴을 사용할 수 있다. +GitHub 서비스와 GitHub이 제안하는 워크플로에 초점을 맞춘 툴이지만 다른 호스트나 저장소에도 사용할 수 있다. ==== ////////////////////////// @@ -224,7 +224,7 @@ If you already have a local repository, just drag its directory from the Finder ////////////////////////// ===== Recommended Workflow ////////////////////////// -===== 권장 Workflow +===== 권장 워크플로 ////////////////////////// Once it's installed and configured, you can use the GitHub client for many common Git tasks. @@ -302,8 +302,8 @@ These tools are very well-suited for the workflow they're designed for. Developers and non-developers alike can be collaborating on a project within minutes, and many of the best practices for this kind of workflow are baked into the tools. However, if your workflow is different, or you want more control over how and when network operations are done, we recommend you use another client or the command line. ////////////////////////// -이 툴은 툴이 원하는 특정 Workflow에 적합하도록 설계했다. -개발자든 비개발자든 조금만 배우면 바로 프로젝트에 참여할 수 있다. 이 Workflow와 비슷하게 일하고 있다면 이 툴을 사용하는 것이 가장 최선이다. +이 툴은 툴이 원하는 특정 워크플로에 적합하도록 설계했다. +개발자든 비개발자든 조금만 배우면 바로 프로젝트에 참여할 수 있다. 이 워크플로와 비슷하게 일하고 있다면 이 툴을 사용하는 것이 가장 최선이다. ////////////////////////// ==== Other GUIs diff --git a/book/A-git-in-other-environments/sections/visualstudio.asc b/book/A-git-in-other-environments/sections/visualstudio.asc index a99269c1..5e5900f4 100644 --- a/book/A-git-in-other-environments/sections/visualstudio.asc +++ b/book/A-git-in-other-environments/sections/visualstudio.asc @@ -11,7 +11,7 @@ Visual Studio 2013's Git support has been separated from this older feature, and ////////////////////////// Visual Studio 2013 Update 1부터 Git 클라이언트가 Visual Studio에 들어갔다. Visual Studio에도 오랫동안 버전관리 기능이 들어 있었다. 이 버전관리 시스템은 Git과는 방식이 다르다. 중앙 집중식이고 파일을 잠그는 방식이다. -Visual Studio 2013은 Git에 어울리는 Workflow를 따를 수 있도록 Git을 지원한다. +Visual Studio 2013은 Git에 어울리는 워크플로를 따를 수 있도록 Git을 지원한다. ////////////////////////// To locate the feature, open a project that's controlled by Git (or just `git init` an existing project), and select View > Team Explorer from the menu. diff --git a/book/C-git-commands/1-git-commands.asc b/book/C-git-commands/1-git-commands.asc index 842f8de4..0eed26a7 100644 --- a/book/C-git-commands/1-git-commands.asc +++ b/book/C-git-commands/1-git-commands.asc @@ -174,7 +174,7 @@ Though it's used in many other places through the book, these are the ones that ////////////////////////// For the basic workflow of staging content and committing it to your history, there are only a few basic commands. ////////////////////////// -Stage 하고 커밋하는 정도의 아주 기본적인 Workflow는 명령어 몇 개만 알면 된다. +Stage 하고 커밋하는 정도의 아주 기본적인 워크플로는 명령어 몇 개만 알면 된다. ==== git add @@ -531,8 +531,8 @@ In <<_commit_ranges>> we go through this fairly extensively. In <<_merge_log>> and <<_triple_dot>> we cover using the `branchA...branchB` format and the `--left-right` syntax to see what is in one branch or the other but not in both. In <<_merge_log>> we also look at how to use the `--merge` option to help with merge conflict debugging as well as using the `--cc` option to look at merge commit conflicts in your history. ////////////////////////// -<<_merge_log>>와 <<_triple_dot>>에서 `branchA...branchB` 포맷을 사용하는 방법을 설명한다. 이 문법은 서로 한 쪽에만 속한 커밋만 보여준다. `--left-right` 옵션을 주면 각각 어느 쪽에 속한 것인지도 보여준다. -<<_merge_log>>에서는 충돌을 해결할 때 유용한 `--merge` 옵션도 설명한다. `--cc` 옵션을 사용하면 충돌을 히스토리에 보여준다. +<<_merge_log>>와 <<_triple_dot>>에서 `branchA...branchB` 포맷을 사용하는 방법을 설명한다. 이 문법은 둘 중 한쪽에 속한 커밋만 보여준다. +`--left-right` 옵션을 주면 각각 어느 쪽에 속한 것인지도 보여준다. <<_merge_log>>에서는 충돌을 해결할 때 유용한 `--merge` 옵션도 설명한다. `--cc` 옵션을 사용하면 충돌을 히스토리에 보여준다. ////////////////////////// In <<_git_reflog>> we use the `-g` option to view the Git reflog through this tool instead of doing branch traversal. @@ -960,7 +960,7 @@ There are also a number of hooks you can use to help with the workflow around `g ////////////////////////// We also use it to apply patch formatted GitHub Pull Request changes in <<_email_notifications>>. ////////////////////////// -이 명령으로 Github Pull Request의 Patch도 적용할 수 있는데 <<_email_notifications>>에서 설명한다. +이 명령으로 GitHub Pull Request의 Patch도 적용할 수 있는데 <<_email_notifications>>에서 설명한다. ==== git format-patch diff --git a/book/introduction.asc b/book/introduction.asc index 75a87538..25d9e0a4 100644 --- a/book/introduction.asc +++ b/book/introduction.asc @@ -54,7 +54,7 @@ them with Git. When you are done with this chapter, you should be able to work e multiple remote repositories, use Git over email and deftly juggle numerous remote branches and contributed patches. //////////////// -**5장**에서는 다양한 분산환경에서의 Workflow에 대해 알아보고 Git으로 어떻게 Workflow를 달성하는지 알아본다. +**5장**에서는 다양한 분산환경에서의 워크플로에 대해 알아보고 Git으로 어떻게 워크플로를 달성하는지 알아본다. 5장을 읽고나면 여러 리모트 저장소를 두고 전문가처럼 작업할 수 있다. 이메일로도 Git 작업을 할 수 있고, 많은 수의 리모트 브랜치나 기여 받은 패치를 다룰 수 있다. @@ -62,7 +62,7 @@ and contributed patches. //////////////// *Chapter 6* covers the GitHub hosting service and tooling in depth. We cover signing up for and managing an account, creating and using Git repositories, common workflows to contribute to projects and to accept contributions to yours, GitHub's programmatic interface and lots of little tips to make your life easier in general. //////////////// -**6장**에서는 GitHub 호스팅 서비스와 GitHub에서 제공하는 도구를 자세히 알아본다. 가입하고 계정을 관리하는 방법부터 Git 저장소를 생성하고 다른 프로젝트에 기여하고 반대로 기여받는 Workflow를 살펴본다. GitHub이 제공하는 프로그래밍 가능한 인터페이스와 알아두면 피가되고 살이되는 팁도 소개한다. +**6장**에서는 GitHub 호스팅 서비스와 GitHub에서 제공하는 도구를 자세히 알아본다. 가입하고 계정을 관리하는 방법부터 Git 저장소를 생성하고 다른 프로젝트에 기여하고 반대로 기여받는 워크플로를 살펴본다. GitHub이 제공하는 프로그래밍 가능한 인터페이스와 알아두면 피가되고 살이되는 팁도 소개한다. //////////////// *Chapter 7* is about advanced Git commands. Here you will learn about topics like mastering the scary 'reset' command, using binary