improve translation

book/04-git-server/1-git-server.asc

@@ -84,4 +84,4 @@ If you place your data on a hosted server, it's easy to set up and maintain; how
 //////////////////////////
 It should be fairly straightforward to determine which solution or combination of solutions is appropriate for you and your organization.
 //////////////////////////
-필요에 따라 둘 중 하나를 선택하던지 두 방법을 적절히 섞어서 사용하는 것이 좋다.
+필요에 따라 둘 중 하나를 선택하든지, 아니면 두 방법을 적절히 섞어서 사용하는 것이 좋다.

book/04-git-server/sections/git-on-a-server.asc

@@ -58,7 +58,7 @@ $ cp -Rf my_project/.git my_project.git
 There are a couple of minor differences in the configuration file; but for your purpose, this is close to the same thing.
 It takes the Git repository by itself, without a working directory, and creates a directory specifically for it alone.
 //////////////////////////
-물론 설정 상의 미세한 차이가 있지만, 저장소의 내용만 고려한다면 같다고 볼 수 있다.
+물론 설정상의 미세한 차이가 있지만, 저장소의 내용만 고려한다면 같다고 볼 수 있다.
 워킹 디렉토리가 없는 Git 저장소인 데다가 별도의 디렉토리도 하나 만들었다는 점에서는 같다.
 
 [[_bare_repo]]
@@ -73,8 +73,8 @@ Let's say you've set up a server called `git.example.com` that you have SSH acce
 Assuming that `/opt/git` exists on that server, you can set up your new repository by copying your bare repository over:
 //////////////////////////
 Bare 저장소는 이제 만들었으니까 서버에 넣고 프로토콜을 설정한다.
-`git.example.com`라는 이름의 서버를 하나 준비하자. 그리고 그 서버에 SSH로 접속할 수 있게 만들고 Git 저장소를 /opt/git에 저장할 것이다.
-서버에 /opt/git이 있다고 가정하고 아래와 같이 Bare 저장소를 복사한다.
+`git.example.com`라는 이름의 서버를 하나 준비하자. 그리고 그 서버에 SSH로 접속할 수 있게 만들고 Git 저장소를 `/opt/git` 디렉토리에 저장할 것이다.
+서버에 `/opt/git` 디렉토리가 있다고 가정하고 아래와 같이 Bare 저장소를 복사한다.
 
 [source,console]
 ----
@@ -128,7 +128,7 @@ This discussion will include not having to create user accounts for each user, a
 However, keep in mind that to collaborate with a couple of people on a private project, all you _need_ is an SSH server and a bare repository.
 //////////////////////////
 다음 절에서는 좀 더 정교하게 설정하는 법을 살펴볼 것이다.
-사용자에게 계정을 만들어 주는 법, 저장소를 읽고 쓸 수 있게 하는 법, Web UI를 설정하는 법 등은 여기에서 설명하지 않는다.
+사용자에게 계정을 만들어 주는 법, 저장소를 읽고 쓸 수 있게 하는 법, 웹 UI를 설정하는 법 등은 여기에서 설명하지 않는다.
 동료와 함께 개발할 때 꼭 필요한 것은 SSH 서버와 Bare 저장소뿐이라는 것만은 꼭 기억하자.
 
 //////////////////////////
@@ -172,20 +172,20 @@ You may not want to run `adduser` and set temporary passwords for every user.
 //////////////////////////
 팀원들이 접속할 수 있도록 하는 방법은 몇 가지가 있다.
 첫째로 모두에게 계정을 만들어 주는 방법이 있다. 이 방법이 제일 단순하지만 다소 귀찮다.
-팀원마다 adduser를 실행시키고 임시 암호를 부여해야 하기 때문에 보통 이 방법을 쓰고 싶어 하지 않는다.
+팀원마다 `adduser`를 실행시키고 임시 암호를 부여해야 하기 때문에 보통 이 방법을 쓰고 싶어 하지 않는다.
 
 //////////////////////////
 A second method is to create a single 'git' user on the machine, ask every user who is to have write access to send you an SSH public key, and add that key to the `~/.ssh/authorized_keys` file of your new 'git' user.
 At that point, everyone will be able to access that machine via the 'git' user.
 This doesn't affect the commit data in any way – the SSH user you connect as doesn't affect the commits you've recorded.
 //////////////////////////
-둘째로 서버마다 git이라는 계정을 하나씩 만드는 방법이 있다. 쓰기 권한이 필요한 사용자의 SSH 공개키를 모두 모아서 git 계정의 `~/.ssh/authorized_keys` 파일에 모든 키를 입력한다.
-그러면 모두 git 계정으로 그 서버에 접속할 수 있다.
-이 git 계정은 커밋 데이터에는 아무런 영향을 끼치지 않는다. 다시 말해서 접속하는 데 사용한 SSH 계정과 커밋에 저장되는 사용자는 아무 상관없다.
+둘째로 서버마다 'git'이라는 계정을 하나씩 만드는 방법이 있다. 쓰기 권한이 필요한 사용자의 SSH 공개키를 모두 모아서 'git' 계정의 `~/.ssh/authorized_keys` 파일에 모든 키를 입력한다.
+그러면 모두 'git' 계정으로 그 서버에 접속할 수 있다.
+이 'git' 계정은 커밋 데이터에는 아무런 영향을 끼치지 않는다. 다시 말해서 접속하는 데 사용한 SSH 계정과 커밋에 저장되는 사용자는 아무 상관없다.
 
 //////////////////////////
 Another way to do it is to have your SSH server authenticate from an LDAP server or some other centralized authentication source that you may already have set up.
 As long as each user can get shell access on the machine, any SSH authentication mechanism you can think of should work.
 //////////////////////////
-SSH 서버 인증을 LDAP 서버를 이용할 수도 있다. 이미 사용하고 있는 중앙집중식 인증소스가 있으면 해당 인증을 이용하여 SSH 서버에 인증하도록 할 수도 있다.
+SSH 서버 인증을 LDAP 서버를 이용할 수도 있다. 이미 사용하고 있는 중앙집중식 인증 소스가 있으면 해당 인증을 이용하여 SSH 서버에 인증하도록 할 수도 있다.
 SSH 인증 메커니즘 중 아무거나 하나 이용할 수 있으면 사용자는 그 서버에 접근할 수 있다.

book/04-git-server/sections/gitlab.asc

@@ -11,7 +11,7 @@ As GitLab is one of the more popular ones, we'll cover installing and using it a
 This is a bit more complex than the GitWeb option and likely requires more maintainance, but it is a much more fully featured option.
 //////////////////////////
 간단하게 쓰기엔 GitWeb이 꽤 좋다.
-근데 좀 더 기능이 많은 Git 서버를 쓰려면 다른 서버를 찾아 설치해야 한다.
+그런데 좀 더 기능이 많은 Git 서버를 쓰려면 다른 서버를 찾아 설치해야 한다.
 GitLab은 널리 사용하는 서버 중 하나이다. 여기서 예제를 통해 설치하고 사용하는 것을 배워보자.
 GitLab은 기능이 많은 만큼 설정도 복잡하고 유지보수를 위해 해야 할 것도 많다.
 
@@ -256,7 +256,7 @@ Users with direct access can simply create a branch, push commits to it, and ope
 Users who don't have push permissions for a repository can ``fork'' it (create their own copy), push commits to _that_ copy, and open a merge request from their fork back to the main project.
 This model allows the owner to be in full control of what goes into the repository and when, while allowing contributions from untrusted users.
 //////////////////////////
-Merge 요청을 하도록 해서 통제권을 유지한채로 협업하는 방법도 있다.
+Merge 요청을 하도록 해서 통제권을 유지한 채로 협업하는 방법도 있다.
 프로젝트에 접근할 수 있는 모든 사용자가 프로젝트에 기여할 수 있다.
 사용자는 마음껏 브랜치를 만들고 커밋, Push 하고 나서 이 브랜치를 `master`나 다른 브랜치에 Merge 해달라고 요청한다.
 Push 권한이 없는 사용자는 저장소를 ``fork''한 다음에 ``fork''한 _자신의 저장소_에 Push 한다. 그리고는 원래 저장소에 내 저장소에 있는 브랜치를 Merge 해달라고 요청하면 된다.
@@ -277,5 +277,5 @@ These include project wikis, discussion ``walls'', and system maintenance tools.
 One benefit to GitLab is that, once the server is set up and running, you'll rarely need to tweak a configuration file or access the server via SSH; most administration and general usage can be accomplished through the in-browser interface.
 //////////////////////////
 이 섹션에서는 GitLab의 Git과 맞닿은 부분만 설명했지만 이게 전부가 아니다. GitLab은 굉장히 성숙했다.
-이 외에도 프로젝트 위키나 토론용 ``walls'', 시스템 관리 도구 등등 협업용 기능이 많다.
+이 외에도 프로젝트 위키나 토론용 ``walls'', 시스템 관리 도구 등 협업용 기능이 많다.
 GitLab의 장점은 일단 서버가 돌아가면 SSH로 서버에 접속할 일이 별로 없다는 것이다. 대부분 관리는 웹 브라우저로 가능하다.

book/04-git-server/sections/gitweb.asc

@@ -25,10 +25,10 @@ On Linux machines, `lighttpd` is often installed, so you may be able to get it t
 If you're running a Mac, Leopard comes preinstalled with Ruby, so `webrick` may be your best bet.
 To start `instaweb` with a non-lighttpd handler, you can run it with the `--httpd` option.(((git commands, instaweb)))
 //////////////////////////
-Git은 GitWeb을 쉽게 사용해 볼 수 있도록 서버를 즉시 띄우는 명령을 제공한다. 시스템에 `lighttpd`나 `webrick` 같은 경량 웹서버가 설치돼 있어야 이 명령을 사용할 수 있다.
-Linux에서는 `lighttpd`가 설치돼 있을 확률이 높아서 프로젝트 디렉토리에서 그냥 `git instaweb`을 실행하면 바로 실행될 것이다.
+Git은 GitWeb을 쉽게 사용해 볼 수 있도록 서버를 즉시 띄우는 명령을 제공한다. 시스템에 `lighttpd`나 `webrick` 같은 경량 웹 서버가 설치돼 있어야 이 명령을 사용할 수 있다.
+Linux에서는 `lighttpd`를 많이 사용한다. `lighttpd`가 설치돼 있으면 프로젝트 디렉토리에서 그냥 `git instaweb`을 실행하면 바로 실행될 것이다.
 Mac의 Leopard 버전은 Ruby가 미리 설치돼 있기 때문에 `webrick`이 더 나은 선택이다.
-lighttpd이 아니라면 아래와 같이 `--httpd` 옵션을 사용해야 한다.(((git commands, instaweb)))
+사용할 웹 서버가 `lighttpd`가 아니라면 아래와 같이 `--httpd` 옵션을 사용해야 한다.(((git commands, instaweb)))
 
 [source,console]
 ----
@@ -42,7 +42,7 @@ That starts up an HTTPD server on port 1234 and then automatically starts a web
 It's pretty easy on your part.
 When you're done and want to shut down the server, you can run the same command with the `--stop` option:
 //////////////////////////
-1234 포트로 HTTPD 서버를 시작하고 이 페이지를 여는 웹브라우저를 자동으로 실행시킨다.
+이렇게 하면 1234 포트로 HTTPD 서버를 시작하고 이 페이지를 여는 웹 브라우저를 자동으로 실행시킨다.
 사용자에게는 꽤 편리하다.
 필요한 일을 모두 마치고 나서 같은 명령어에 `--stop` 옵션을 추가하여 서버를 중지한다:
 
@@ -57,9 +57,9 @@ Some Linux distributions have a `gitweb` package that you may be able to install
 We'll walk though installing GitWeb manually very quickly.
 First, you need to get the Git source code, which GitWeb comes with, and generate the custom CGI script:
 //////////////////////////
-자신의 프로젝트에서 언제나 웹 인터페이스를 운영하려면 먼저 웹서버에 이 CGI 스크립트를 설치해야 한다.
-`apt`나 `yum`으로도 `gitweb`을 설치할 수 있지만, 여기에서는 수동으로 설치한다.
-GitWeb을 수동으로 설치하는 방법을 간단히 살펴보자.
+자신의 프로젝트에서 언제나 웹 인터페이스를 운영하려면 먼저 웹 서버에 이 CGI 스크립트를 설치해야 한다.
+몇몇 리눅스 배포판에서는 `apt`나 `yum`으로 설치할 수 있게 `gitweb` 패키지를 제공한다. 그러니 패키지로 설치할 수 있는지 확인해 보는 것이 좋다.
+여기에서는 GitWeb을 수동으로 설치하는 방법을 간단히 살펴보자.
 먼저 GitWeb이 포함된 Git 소스 코드를 구한 다음 아래의 CGI 스크립트를 빌드한다.
 
 [source,console]
@@ -80,7 +80,7 @@ Notice that you have to tell the command where to find your Git repositories wit
 Now, you need to make Apache use CGI for that script, for which you can add a VirtualHost:
 //////////////////////////
 빌드할 때 `GITWEB_PROJECTROOT` 변수로 Git 저장소의 위치를 알려준다.
-이제 Apache가 이 스크립트를 사용하도록 VirtualHost 항목에 설정해야 한다.
+이제 Apache가 이 스크립트를 사용하도록 VirtualHost 항목에 설정한다.
 
 [source,console]
 ----
@@ -102,5 +102,5 @@ Now, you need to make Apache use CGI for that script, for which you can add a Vi
 Again, GitWeb can be served with any CGI or Perl capable web server; if you prefer to use something else, it shouldn't be difficult to set up.
 At this point, you should be able to visit `http://gitserver/` to view your repositories online.
 //////////////////////////
-다시 말해서 GitWeb은 CGI나 Perl을 지원하는 웹서버라면 아무거나 사용할 수 있다.
+다시 말해서 GitWeb은 CGI나 Perl을 지원하는 웹 서버라면 아무거나 사용할 수 있다.
 이제 `http://gitserver/`에 접속하여 온라인으로 저장소를 확인할 수 있다.

book/04-git-server/sections/protocols.asc

@@ -297,7 +297,7 @@ A common transport protocol for Git when self-hosting is over SSH.
 This is because SSH access to servers is already set up in most places – and if it isn't, it's easy to do.
 SSH is also an authenticated network protocol; and because it's ubiquitous, it's generally easy to set up and use.
 //////////////////////////
-Git의 대표 프로토콜은 SSH이다. SSH를 이용하면 아무런 외부 도구 없이 Git 서버를 구출할 수 있다.
+Git의 대표 프로토콜은 SSH이다. SSH를 이용하면 아무런 외부 도구 없이 Git 서버를 구축할 수 있다.
 대부분 서버는 SSH로 접근할 수 있도록 설정돼 있다. 뭐, 설정돼 있지 않더라도 쉽게 설정할 수 있다.
 그리고 SSH는 인증 기능이 있고 어디에서든 사용할 수 있으며 사용하기도 쉽다.
 
@@ -314,7 +314,7 @@ $ git clone ssh://user@server/project.git
 //////////////////////////
 Or you can use the shorter scp-like syntax for the SSH protocol:
 //////////////////////////
-아래와 같은 SCP 형태의 구문으로 줄여 쓸 수도있다.
+아래와 같은 SCP 형태의 구문으로 줄여 쓸 수도 있다.
 
 [source,console]
 ----
@@ -338,7 +338,7 @@ Next, access over SSH is secure – all data transfer is encrypted and authentic
 Last, like the HTTP/S, Git and Local protocols, SSH is efficient, making the data as compact as possible before transferring it.
 //////////////////////////
 SSH 장점은 정말 많다.
-첫째, SSH는 상대적으로 설정하기 쉽다. SSH 데몬은 정말 흔하다. 많은 네트워크 관리자들은 SSH 데몬을 다루어본 경험이 있고 대부분의 OS 배포판에는 SSH 데몬과 관리도구들이 모두 들어 있다.
+첫째, SSH는 상대적으로 설정하기 쉽다. SSH 데몬은 정말 흔하다. 많은 네트워크 관리자들은 SSH 데몬을 다루어 본 경험이 있고 대부분의 OS 배포판에는 SSH 데몬과 관리도구들이 모두 들어 있다.
 둘째, SSH를 통해 접근하면 보안에 안전하다. 모든 데이터는 암호화되어 인증된 상태로 전송된다.
 마지막으로 SSH는 전송 시 데이터를 가능한 압축하기 때문에 효율적이다.
 
@@ -408,9 +408,9 @@ It must run its own daemon, which requires `xinetd` configuration or the like, w
 It also requires firewall access to port 9418, which isn't a standard port that corporate firewalls always allow.
 Behind big corporate firewalls, this obscure port is commonly blocked.
 //////////////////////////
-Git 프로토콜의 단점은 인증 메커니즘이 없는 거다.
+Git 프로토콜의 단점은 인증 메커니즘이 없다는 것이다.
 Git 프로토콜만으로 접근할 수 있는 프로젝트는 바람직하지 못하다.
-일반적으로 SSH 나 HTTPS 프로토콜과 함께 사용한다. 소수의 개발자만 Push 할 수 있고 대다수 사람은 `git://`을 사용하여 읽을 수만 있게 하는 것이다.
+일반적으로 SSH나 HTTPS 프로토콜과 함께 사용한다. 소수의 개발자만 Push 할 수 있고 대다수 사람은 `git://`을 사용하여 읽을 수만 있게 하는 것이다.
 어쩌면 가장 설치하기 어려운 방법일 수도 있다.
 별도의 데몬이 필요하고 프로젝트에 맞게 설정해야 한다.
 자원을 아낄 수 있도록 xinetd 같은 것도 설정해야 하고 방화벽을 통과할 수 있도록 9418 포트도 열어야 한다.