chapter 7: translate

book/07-git-tools/1-git-tools.asc

@@ -1,10 +1,20 @@
 [[_git_tools]]
+//////////////////////////
 == Git Tools
+//////////////////////////
+== Git 도구
 
+//////////////////////////
 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 저장소를 사용하여 소스코드 관리를 충분히 해낼 수 있을 것이다.
 
+//////////////////////////
 Now you’ll explore a number of very powerful things that Git can do that you may not necessarily use on a day-to-day basis but that you may need at some point.
+//////////////////////////
+이 장에서는 일상적으로 사용하지는 않지만 위급한 상황에서 반드시 필요한 Git 도구들을 살펴본다.
 
 include::sections/revision-selection.asc[]
 
@@ -34,9 +44,18 @@ include::sections/replace.asc[]
 
 include::sections/credentials.asc[]
 
+//////////////////////////
 === Summary
+//////////////////////////
+=== 요약
 
+//////////////////////////
 You’ve seen a number of advanced tools that allow you to manipulate your commits and staging area more precisely.
 When you notice issues, you should be able to easily figure out what commit introduced them, when, and by whom.
 If you want to use subprojects in your project, you’ve learned how to accommodate those needs.
 At this point, you should be able to do most of the things in Git that you’ll need on the command line day to day and feel comfortable doing so.
+//////////////////////////
+커밋과 저장소를 꼼꼼하게 관리하는 도구를 살펴보았다.
+문제가 생기면 바로 누가, 언제, 무엇을 했는지 찾아내야 한다.
+그리고 프로젝트를 쪼개고 싶을 때 사용하는 방법들도 배웠다.
+이제 Git 명령은 거의 모두 배운 것이다. 독자들이 하루빨리 익숙해져서 자유롭게 사용했으면 좋겠다.

book/07-git-tools/sections/bundling.asc

@@ -1,13 +1,28 @@
 [[_bundling]]
+///////////
 === Bundling
+///////////
+=== Bundle
 
+///////////
 Though we've covered the common ways to transfer Git data over a network (HTTP, SSH, etc), there is actually one more way to do so that is not commonly used but can actually be quite useful.
+///////////
+앞에서 Git 데이터를 네트워크를 거쳐 전송하는 일반적인 방법(HTTP, SSH등)을 다루었었다. 일반적으로 사용하진 않지만 꽤 유용한 방법이 하나 더 있다.
 
+///////////
 Git is capable of ``bundling'' it's data into a single file. This can be useful in various scenarios. Maybe your network is down and you want to send changes to your co-workers. Perhaps you're working somewhere offsite and don't have access to the local network for security reasons. 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''이란 것이 있다. 데이터를 하나의 파일에 몰아넣는 것이다. 이 방법은 다양한 경우 유용하게 사용할 수 있다. 예를 들어 네트워크가 불통인데 변경사항을 동료에게 보낼 때, 출장을 나갔는데 보안상의 이유로 로컬 네트워크에 접속하지 못할 때, 통신 인터페이스 장비가 부서졌을 때, 갑자기 잠시 동안 공용 서버에 접근하지 못할 때, 누군가에게 수정사항을 이메일로 보내야 하는데 40개 씩이나 되는 커밋을 `format-patch`로 보내고 싶지 않을 때를 예로 들 수 있다.
 
+///////////
 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) 사용한다.
 
+///////////
 Let's see a simple example. Let's say you have a repository with two commits:
+///////////
+간단한 예제를 보자. 이 저장소에는 커밋 두 개가 있다.
 
 [source,console]
 ----
@@ -25,7 +40,10 @@ Date:   Wed Mar 10 07:34:01 2010 -0800
     first commit
 ----
 
+///////////
 If you want to send that repository to someone and you don't have access to a repository to push to, or simply don't want to set one up, you can bundle it with `git bundle create`.
+///////////
+이 저장소를 다른 사람에게 통째로 보내고 싶은데 그 사람의 저장소에 Push할 권한이 없거나, 그냥 Push 하고 싶지 않을 때, `git bundle create` 명령으로 Bundle을 만들 수 있다.
 
 [source,console]
 ----
@@ -37,11 +55,20 @@ Writing objects: 100% (6/6), 441 bytes, done.
 Total 6 (delta 0), reused 0 (delta 0)
 ----
 
+///////////
 Now you have a file named `repo.bundle` that has all the data needed to re-create the repository's `master` branch. With the `bundle` command you need to list out every reference or specific range of commits that you want to be included. If you intend for this to be cloned somewhere else, you should add HEAD as a reference as well as we've done here.
+///////////
+이렇게 `repo.bundle` 이라는 이름의 파일을 생성할 수 있다. 이 파일에는 이 저장소의 `master`브랜치를 다시 만드는데 필요한 모든 정보가 다 들어있다. `bundle` 명령으로 모든 레퍼런스를 포함시키거나 Bundle에 포함시킬 특정 구간의 커밋을 지정할 수 있다. 이 Bundle을 다른 곳에서 Clone 하려면 위의 명령처럼 HEAD 레퍼런스를 포함해야 한다.
 
+///////////
 You can email this `repo.bundle` file to someone else, or put it on a USB drive and walk it over.
+///////////
+`repo.bundle` 파일을 다른 사람에게 이메일로 전송하거나 USB 드라이브에 담아 가지고 나갈 수 있다.
 
+///////////
 On the other side, say you are sent this `repo.bundle` file and want to work on the project. You can clone from the binary file into a directory, much like you would from a URL.
+///////////
+혹은 `repo.bundle` 파일을 일할 곳으로 어떻게든 보내놓으면 이 Bundle 파일을 마치 URL에서 가져온것 처럼 Clone해서 사용할 수 있다.
 
 [source,console]
 ----
@@ -53,9 +80,15 @@ $ git log --oneline
 b1ec324 first commit
 ----
 
+///////////
 If you don't include HEAD in the references, you have to also specify `-b master` or whatever branch is included because otherwise it won't know what branch to check out.
+///////////
+Bundle 파일에 HEAD 레퍼런스를 포함시키지 않으려면 `-b master` 옵션을 써주거나 어떠한 브랜치든 포함시킨 브랜치를 지정해줘야 한다. 그렇지 않으면 Git은 어떤 브랜치로 Checkout 할지 알 수 없다.
 
+///////////
 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로 보내 새 커밋을 옮겨보기로 한다.
 
 [source,console]
 ----
@@ -67,9 +100,15 @@ c99cf5b fourth commit - second repo
 b1ec324 first commit
 ----
 
+///////////
 First we need to determine the range of commits we want to include in the bundle. Unlike the network protocols which figure out the minimum set of data to transfer over the network for us, we'll have to figure this out manually.  Now, you could just do the same thing and bundle the entire repository, which will work, but it's better to just bundle up the difference - just the three commits we just made locally.
+///////////
+먼저 Bundle 파일에 추가시킬 커밋의 범위를 정해야한다. 전송할 최소한의 데이터를 알아서 인식하는 네트워크 프로토콜과는 달리 Bundle 명령을 사용할 때는 수동으로 지정해야 한다. 전체 저장소를 Bundle 파일로 만들 수도 있지만 차이점만 Bundle로 묶는게 좋다. 예제에서는 로컬에서 만든 세 개의 커밋만 묶는다.
 
+///////////
 In order to do that, you'll have to calculate the difference. As we described in <<_commit_ranges>>, you can specify a range of commits in a number of ways. To get the three commits that we have in our master branch that weren't in the branch we originally cloned, we can use something like `origin/master..master` or `master ^origin/master`. You can test that with the `log` command.
+///////////
+이렇게 Bundle 파일을 만들기 위해 우선 차이점을 찾아내야 한다. <<_commit_ranges>>에서 살펴본대로 숫자를 사용하여 커밋의 범위를 지정할 수 있다. 원래 Clone 한 브랜치인 master에는 없던 세 개의 커밋을 얻어내려면 `origin/master..master` 또는 `master ^origin/master` 파라미터를 쓰면 된다. `log` 명령으로 시험해볼 수 있다.
 
 [source,console]
 ----
@@ -79,7 +118,10 @@ c99cf5b fourth commit - second repo
 7011d3d third commit - second repo
 ----
 
+///////////
 So now that we have the list of commits we want to include in the bundle, let's bundle them up. We do that with the `git bundle create` command, giving it a filename we want our bundle to be and the range of commits we want to go into it.
+///////////
+이제 Bundle 파일에 포함할 커밋을 얻었으니 묶어보자. `git bundle create` 명령에 Bundle 파일의 이름과 묶어넣을 커밋의 범위를 지정한다.
 
 [source,console]
 ----
@@ -91,9 +133,15 @@ Writing objects: 100% (9/9), 775 bytes, done.
 Total 9 (delta 0), reused 0 (delta 0)
 ----
 
+///////////
 Now we have a `commits.bundle` file in our directory. If we take that and send it to our partner, she can then import it into the original repository, even if more work has been done there in the meantime.
+///////////
+이제 디렉토리에 `commits.bundle` 파일이 생겼다. 이 파일을 동료에게 보내면 원래의 저장소에 일이 얼마나 진행되었든 간에 파일 내용을 적용할 수 있다. 
 
+///////////
 When she gets the bundle, she can inspect it to see what it contains before she imports it into her repository.  The first command is the `bundle verify` command that will make sure the file is actually a valid Git bundle and that you have all the neccesary ancestors to reconstitute it properly.
+///////////
+이 Bundle 파일을 동료가 받았으면 원래 저장소에 적용하기 전에 안에 무엇이 들어있는지 살펴볼 수 있다. 우선 `bundle verify` 명령으로 파일이 올바른 Git Bundle인가, 제대로 적용하기 위해 필요한 모든 히스토리가 현재 저장소에 있는가 확인한다.
 
 [source,console]
 ----
@@ -105,7 +153,10 @@ The bundle requires these 1 ref
 ../commits.bundle is okay
 ----
 
+///////////
 If the bundler had created a bundle of just the last two commits they had done, rather than all three, the original repository would not be able to import it, since it is missing requisite history.  The `verify` command would have looked like this instead:
+///////////
+만약 앞에서 Bundle 파일을 만들 때 커밋 세 개로 만들지 않고 마지막 두 커밋으로만 Bundle 파일을 만들면 커밋이 모자르기 때문에 최초에 Bundle을 만들었던 저장소에 새 Bundle 파일을 합칠 수 없다. 이런 문제를 `verify` 명령으로 확인할 수 있다.
 
 [source,console]
 ----
@@ -114,15 +165,21 @@ error: Repository lacks these prerequisite commits:
 error: 7011d3d8fc200abe0ad561c011c3852a4b7bbe95 third commit - second repo
 ----
 
+///////////
 However, our first bundle is valid, so we can fetch in commits from it.  If you want to see what branches are in the bundle that can be imported, there is also a command to just list the heads:
+///////////
+제대로 만든 Bundle 파일이라면 커밋을 가져와서 최초 저장소에 합칠 수 있다. 데이터를 가져올 Bundle 파일에 어떤 브랜치를 포함하고 있는지 살펴보려면 아래와 같은 명령으로 확인할 수 있다.
 
 [source,console]
 ----
 $ git bundle list-heads ../commits.bundle
 71b84daaf49abed142a373b6e5c59a22dc6560dc refs/heads/master
 ----
 
+///////////
 The `verify` sub-command will tell you the heads as well.  The point is to see what can be pulled in, so you can use the `fetch` or `pull` commands to import commits from this bundle.  Here we'll fetch the 'master' branch of the bundle to a branch named 'other-master' in our repository:
+///////////
+앞에서 `verify` 명령을 실행했을 때도 브랜치 정보를 확인할 수 있다. 여기서 중요하게 짚을 부분은 `fetch` 명령이나 `pull` 명령으로 가져올 대상이 되는 브랜치를 Bundle 파일에서 확인하는 것이다. 예를 들어 Bundle 파일의 master 브랜치를 작업하는 저장소의 'other-master' 브랜치로 가져오는 명령은 아래와 같이 실행한다.
 
 [source,console]
 ----
@@ -131,7 +188,10 @@ From ../commits.bundle
  * [new branch]      master     -> other-master
 ----
 
+///////////
 Now we can see that we have the imported commits on the 'other-master' branch as well as any commits we've done in the meantime in our own 'master' branch.
+///////////
+이런 식으로 작업하던 저장소의 'master' 브랜치에 어떤 작업을 했든 상관없이 Bundle 파일로부터 커밋을 독립적으로 'other-master' 브랜치로 가져올 수 있는 것이다.
 
 [source,console]
 ----
@@ -145,4 +205,7 @@ $ git log --oneline --decorate --graph --all
 * b1ec324 first commit
 ----
 
+///////////
 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` 명령으로 데이터를 전송할 네트워크 상황이 여의치 않거나 쉽게 공유할 수 있는 저장소를 준비하기 힘들 때 아주 유용하게 히스토리를 공유할 수 있다.