From bdb40e293764fd776291aa98313848dbfc27ce95 Mon Sep 17 00:00:00 2001 From: "Yoon, Hyunho" Date: Sun, 6 Mar 2016 14:11:50 +0900 Subject: [PATCH 1/3] fix typo errors --- book/04-git-server/sections/protocols.asc | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/book/04-git-server/sections/protocols.asc b/book/04-git-server/sections/protocols.asc index 3cee0818..8c0b9344 100644 --- a/book/04-git-server/sections/protocols.asc +++ b/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 포트도 열어야 한다. From a292799821b0ff02f315010031b4d21e4d28f1f0 Mon Sep 17 00:00:00 2001 From: "Yoon, Hyunho" Date: Sun, 6 Mar 2016 21:34:36 +0900 Subject: [PATCH 2/3] improve translation - fix typo errors - fix untranslated words --- book/04-git-server/1-git-server.asc | 2 +- .../sections/git-on-a-server.asc | 22 +-- book/04-git-server/sections/gitlab.asc | 6 +- book/04-git-server/sections/gitweb.asc | 22 +-- .../sections/setting-up-server.asc | 30 ++-- book/04-git-server/sections/smart-http.asc | 12 +- .../sections/contributing.asc | 140 +++++++++--------- .../sections/maintaining.asc | 56 +++---- .../sections/1-setting-up-account.asc | 8 +- book/06-github/sections/2-contributing.asc | 4 +- book/06-github/sections/3-maintaining.asc | 30 ++-- book/06-github/sections/5-scripting.asc | 20 +-- .../sections/advanced-merging.asc | 4 +- .../sections/revision-selection.asc | 12 +- 14 files changed, 184 insertions(+), 184 deletions(-) diff --git a/book/04-git-server/1-git-server.asc b/book/04-git-server/1-git-server.asc index 7ec8775f..58a64b8e 100644 --- a/book/04-git-server/1-git-server.asc +++ b/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. ////////////////////////// -필요에 따라 둘 중 하나를 선택하던지 두 방법을 적절히 섞어서 사용하는 것이 좋다. +필요에 따라 둘 중 하나를 선택하든지, 아니면 두 방법을 적절히 섞어서 사용하는 것이 좋다. diff --git a/book/04-git-server/sections/git-on-a-server.asc b/book/04-git-server/sections/git-on-a-server.asc index 91fea2e4..71b787ad 100644 --- a/book/04-git-server/sections/git-on-a-server.asc +++ b/book/04-git-server/sections/git-on-a-server.asc @@ -28,7 +28,7 @@ In order to clone your repository to create a new bare repository, you run the c By convention, bare repository directories end in `.git`, like so: ////////////////////////// 어떤 서버를 설치하더라도 일단 저장소를 Bare 저장소로 만들어야 한다. -다시 말하지만, Bare 저장소는 워킹 디렉토리가 없는 저장소이다. +다시 말하지만, Bare 저장소는 작업 디렉토리가 없는 저장소이다. `--bare` 옵션을 주고 Clone 하면 새로운 Bare 저장소가 만들어진다. Bare 저장소 디렉토리는 관례에 따라 .git 확장자로 끝난다. @@ -58,8 +58,8 @@ $ 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 저장소인 데다가 별도의 디렉토리도 하나 만들었다는 점에서는 같다. +물론 설정상의 미세한 차이가 있지만, 저장소의 내용만 고려한다면 같다고 볼 수 있다. +작업 디렉토리가 없는 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 인증 메커니즘 중 아무거나 하나 이용할 수 있으면 사용자는 그 서버에 접근할 수 있다. diff --git a/book/04-git-server/sections/gitlab.asc b/book/04-git-server/sections/gitlab.asc index 77930da7..c2137dff 100644 --- a/book/04-git-server/sections/gitlab.asc +++ b/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로 서버에 접속할 일이 별로 없다는 것이다. 대부분 관리는 웹 브라우저로 가능하다. diff --git a/book/04-git-server/sections/gitweb.asc b/book/04-git-server/sections/gitweb.asc index bae91825..4d3698b1 100644 --- a/book/04-git-server/sections/gitweb.asc +++ b/book/04-git-server/sections/gitweb.asc @@ -16,8 +16,8 @@ Git은 웹에서 저장소를 조회할 수 있는 GitWeb이라는 CGI 스크립 .The GitWeb web-based user interface. image::images/git-instaweb.png[The GitWeb web-based user interface.] ////////////////////////// -.Git 웹용 UI, GitWeb -image::images/git-instaweb.png[Git 웹용 UI] +.Git 웹 기반 UI, GitWeb +image::images/git-instaweb.png[Git 웹 기반 UI] ////////////////////////// If you want to check out what GitWeb would look like for your project, Git comes with a command to fire up a temporary instance if you have a lightweight server on your system like `lighttpd` or `webrick`. @@ -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 항목에 설정해야 한다. +이제 아파치가 이 스크립트를 사용하도록 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/`에 접속하여 온라인으로 저장소를 확인할 수 있다. diff --git a/book/04-git-server/sections/setting-up-server.asc b/book/04-git-server/sections/setting-up-server.asc index cdad8659..91a18f17 100644 --- a/book/04-git-server/sections/setting-up-server.asc +++ b/book/04-git-server/sections/setting-up-server.asc @@ -13,7 +13,7 @@ First, you create a 'git' user and a `.ssh` directory for that user. 서버에서 설정하는 일을 살펴보자. 일단 Ubuntu같은 표준 Linux 배포판을 사용한다고 가정한다. 사용자들은 아마도 `authorized_keys` 파일로 인증할 것이다. -먼저 `git` 계정을 만들고 사용자 홈 디렉토리에 .ssh 디렉토리를 만든다: +먼저 `git` 계정을 만들고 사용자 홈 디렉토리에 `.ssh` 디렉토리를 만든다: [source,console] ---- @@ -59,7 +59,7 @@ $ cat /tmp/id_rsa.jessica.pub >> ~/.ssh/authorized_keys ////////////////////////// Now, you can set up an empty repository for them by running `git init` with the `--bare` option, which initializes the repository without a working directory:(((git commands, init, bare))) ////////////////////////// -`--bare` 옵션을 주고 `git init`을 실행해서 워킹 디렉토리가 없는 빈 저장소를 하나 만든다.(((git commands, init, bare))) +`--bare` 옵션을 주고 `git init`를 실행해서 작업 디렉토리가 없는 빈 저장소를 하나 만든다.(((git commands, init, bare))) [source,console] ---- @@ -76,10 +76,10 @@ Note that someone must shell onto the machine and create a bare repository every Let's use `gitserver` as the hostname of the server on which you've set up your 'git' user and repository. If you're running it internally, and you set up DNS for `gitserver` to point to that server, then you can use the commands pretty much as is (assuming that `myproject` is an existing project with files in it): ////////////////////////// -이제 John씨, Josie씨, Jessica씨는 이 저장소를 리모트 저장소로 등록하고 나서 브랜치를 Push 할 수 있다. +이제 John, Josie, Jessica는 이 저장소를 리모트 저장소로 등록하고 나서 브랜치를 Push 할 수 있다. 프로젝트마다 적어도 한 명은 서버에 접속해서 Bare 저장소를 만들어야 한다. git 계정과 저장소를 만든 서버의 호스트 이름이 `gitserver`라고 하자. -만약 이 서버가 내부망에 있고 `gitserver`가 그 서버를 가리키도록 DNS에 설정하면 아래와 같은 명령을 사용할 수 있다(`myproject` 프로젝트가 이미 있다고 가정한다) +만약 이 서버가 내부망에 있고 `gitserver`가 그 서버를 가리키도록 DNS에 설정하면 아래와 같은 명령을 사용할 수 있다(`myproject` 프로젝트가 이미 있다고 가정한다). [source,console] ---- @@ -115,8 +115,8 @@ With this method, you can quickly get a read/write Git server up and running for You should note that currently all these users can also log into the server and get a shell as the ``git'' user. If you want to restrict that, you will have to change the shell to something else in the `passwd` file. ////////////////////////// -이 개발자들은 서버에 git 계정으로 로그인할 수 있다. -이를 막으려면 passwd 파일에서 로그인 쉘을 바꿔야한다. +이 개발자들은 서버에 _git_ 계정으로 로그인할 수 있다. +이를 막으려면 `passwd` 파일에서 로그인 셸을 바꿔야한다. ////////////////////////// You can easily restrict the 'git' user to only doing Git activities with a limited shell tool called `git-shell` that comes with Git. @@ -124,9 +124,9 @@ If you set this as your 'git' user's login shell, then the 'git' user can't have To use this, specify `git-shell` instead of bash or csh for your user's login shell. To do so, you must first add `git-shell` to `/etc/shells` if it's not already there: ////////////////////////// -단순히 로그인 쉘을 `git-shell`로 바꾸기만 하면 _git_ 계정으로는 git만 사용할 수 있다. -이 로그인 쉘은 서버의 다른 부분은 건들 수 없도록 돼있다. -`git-shell`을 사용자의 로그인 쉘로 지정해야 한다. +단순히 로그인 셸을 `git-shell`로 바꾸기만 하면 _git_ 계정으로는 git만 사용할 수 있다. +이 로그인 셸은 서버의 다른 부분은 건들 수 없도록 돼있다. +`git-shell`을 사용자의 로그인 셸로 지정해야 한다. `/etc/shells`에 `git-shell`를 추가한다. 아래를 보자. [source,console] @@ -146,7 +146,7 @@ $ sudo vim /etc/shells # 바로 위 명령으로 확인한 git-shell 실행파 ////////////////////////// Now you can edit the shell for a user using `chsh `: ////////////////////////// -`chsh <계정 이름>`명령어를 이용해서 특정 계정의 쉘을 바꿀 수 있다. +`chsh <계정 이름>` 명령어를 이용해서 특정 계정의 셸을 바꿀 수 있다. [source,console] ////////////////////////// @@ -162,8 +162,8 @@ $ sudo chsh git # git-shell 경로를 입력, 보통 /usr/bin/git-shell 임 Now, the 'git' user can only use the SSH connection to push and pull Git repositories and can't shell onto the machine. If you try, you'll see a login rejection like this: ////////////////////////// -이제 _git_계정으로 Push와 Pull을 할 수 있지만 서버의 쉘은 가질 수 없다. -그냥 로그인하려고 하면 아래와 같이 로그인 불가능 메시지만 보게 될 것이다. +이제 _git_ 계정으로 Push 와 Pull 할 수 있지만 서버의 셸은 가질 수 없다. +로그인하려고 하면 아래와 같이 로그인 불가능 메시지만 보게 될 것이다. [source,console] ---- @@ -179,7 +179,7 @@ As the output states, you can also set up a directory in the ``git'' user's home For instance, you can restrict the Git commands that the server will accept or you can customize the message that users see if they try to SSH in like that. Run `git help shell` for more information on customizing the shell.(((git commands, help))) ////////////////////////// -비로소 Git은 제대로 동작하면서 개발자들이 쉘을 얻지 못하게 되었다. -위의 출력에서 볼 수 있듯이 `git` 계정의 홈 디렉토리에 git-shell-commands 디렉토리를 만들어 `git-shell`의 동작을 조금 바꿀 수 있다. +이제 Git은 제대로 동작하면서 개발자들이 셸을 얻지 못하게 되었다. +위의 출력에서 볼 수 있듯이 _git_ 계정의 홈 디렉토리에 `git-shell-commands` 디렉토리를 만들어 `git-shell`의 동작을 조금 바꿀 수 있다. 예를 들면 서버에서 사용할 수 있는 Git 명령어를 제한할 수 있다. 또 명령어를 실행했을 때 나오는 메시지도 변경 할 수 있다. -`git help shell` 명령어를 실행하면 Git 쉘을 꾸미는 데에 필요한 정보를 얻을 수 있다. (((git commands, help))) +`git help shell` 명령어를 실행하면 Git 셸을 꾸미는 데에 필요한 정보를 얻을 수 있다. (((git commands, help))) diff --git a/book/04-git-server/sections/smart-http.asc b/book/04-git-server/sections/smart-http.asc index 3c5efaae..c9a736f8 100644 --- a/book/04-git-server/sections/smart-http.asc +++ b/book/04-git-server/sections/smart-http.asc @@ -36,7 +36,7 @@ This also enables the `mod_cgi`, `mod_alias`, `mod_env`, and `mod_rewrite` modul ////////////////////////// You’ll also need to set the Unix user group of the `/opt/git` directories to `www-data` so your web server can read- and write-access the repositories, because the Apache instance running the CGI script will (by default) be running as that user: ////////////////////////// -`/opt/git` 디렉토리의 Unix 사용자 그룹도 `www-data`로 설정해야 한다. 그래야 웹 서버가 저장소를 읽고 쓸 수 있다. Apache 인스턴스는 CGI 스크립트를 이 사용자로 실행시킨다(기본 설정이다). +`/opt/git` 디렉토리의 Unix 사용자 그룹도 `www-data`로 설정해야 한다. 그래야 웹 서버가 저장소를 읽고 쓸 수 있다. 아파치 인스턴스는 CGI 스크립트를 이 사용자로 실행시킨다(기본 설정이다). [source,console] ---- @@ -58,12 +58,12 @@ ScriptAlias /git/ /usr/lib/git-core/git-http-backend/ ////////////////////////// If you leave out `GIT_HTTP_EXPORT_ALL` environment variable, then Git will only serve to unauthenticated clients the repositories with the `git-daemon-export-ok` file in them, just like the Git daemon did. ////////////////////////// -`GIT_HTTP_EXPORT_ALL` 환경 변수를 설정하지 않으면 `git-daemon-export-ok` 파일이 있는 저장소에는 아무나 다 접근할 수 있게 된다. 그냥 데몬 동작과 똑같다. +`GIT_HTTP_EXPORT_ALL` 환경 변수를 설정하지 않으면 `git-daemon-export-ok` 파일이 있는 저장소에는 아무나 다 접근할 수 있게 된다. 그냥 Git 데몬의 동작과 똑같다. ////////////////////////// Finally you'll want to tell Apache to allow requests to `git-http-backend` and make writes be authenticated somehow, possibly with an Auth block like this: ////////////////////////// -마지막으로 Apache가 `git-http-backend`에 요청하는 것을 허용하고 쓰기 접근 시 인증하게 한다. +마지막으로 아파치가 `git-http-backend`에 요청하는 것을 허용하고 쓰기 접근 시 인증하게 한다. [source,console] ---- @@ -100,9 +100,9 @@ There are tons of ways to have Apache authenticate users, you'll have to choose This is just the simplest example we could come up with. You'll also almost certainly want to set this up over SSL so all this data is encrypted. ////////////////////////// -아파치에는 사용자 인증방법이 많다. +아파치에는 사용자 인증 방법이 많다. 그중 하나를 골라 사용해야 하는데 위에 설명한 방법이 가장 간단한 방법의 하나다. -이 방법을 이용할 때는 대부분 SSL을 이용해 통신한다. +그리고 이렇게 사용자 인증 설정을 할 때는 보안을 위해 SSL로 접속해 작업하는 것이 좋다. ////////////////////////// We don't want to go too far down the rabbit hole of Apache configuration specifics, since you could well be using a different server or have different authenication needs. @@ -112,7 +112,7 @@ You can do this with nearly any CGI-capable web server, so go with the one that ////////////////////////// 웹 서버는 아파치 말고도 다른 서버를 사용할 수도 있고, 인증 방식도 다르므로 아파치 설정에 대해서 길게 이야기하지 않는다. 대신 이것만 알아두었으면 한다. HTTP를 이용한 모든 통신에서는 `git http-backend`와 Git을 함께 사용한다는 것이다. -Git 그 자체로는 인증 기능을 가지고 있지 않다. 하지만 웹 서버의 인증 레이어와 손쉽게 연동할 수 있게 돼있다. +Git 그 자체로는 인증 기능을 가지고 있지 않다. 하지만 웹 서버의 인증 레이어와 손쉽게 연동할 수 있다. CGI를 실행할 수 있는 웹 서버라면 어떤 서버든지 붙일 수 있다. 가장 좋아하는 서버를 사용하길 바란다. [NOTE] diff --git a/book/05-distributed-git/sections/contributing.asc b/book/05-distributed-git/sections/contributing.asc index 8515cc8c..18285474 100644 --- a/book/05-distributed-git/sections/contributing.asc +++ b/book/05-distributed-git/sections/contributing.asc @@ -79,7 +79,7 @@ The Git project provides a document that lays out a number of good tips for crea ////////////////////////// 다른 것보다 먼저 커밋 메시지에 대한 주의사항을 알아보자. 커밋 메시지를 잘 작성하는 가이드라인을 알아두면 다른 개발자와 함께 일하는 데 도움이 많이 된다. -Git 프로젝트에 보면 커밋 메시지를 작성하는데 참고할 만한 좋은 팁이 많다. Git 프로젝트의 'Documentation/SubmittingPatches' 문서를 참고하자. +Git 프로젝트에 보면 커밋 메시지를 작성하는데 참고할 만한 좋은 팁이 많다. Git 프로젝트의 `Documentation/SubmittingPatches` 문서를 참고하자. (((git commands, diff, check))) ////////////////////////// @@ -130,12 +130,12 @@ Here is a template originally written by Tim Pope: ////////////////////////// 마지막으로 명심해야 할 점은 커밋 메시지 자체다. 좋은 커밋 메시지를 작성하는 습관은 Git을 사용하는 데 도움이 많이 된다. -일반적으로 커밋 메시지를 작성할 때 사용하는 규칙이 있다. 메시지의 첫 라인에 50자가 넘지 않는 아주 간략한 메시지를 적어 해당 커밋을 요약한다. 다음 한 라인은 비우고 그다음 라인부터 커밋을 자세히 설명한다. -예를 들어 Git 개발 프로젝트에서는 개발 동기와 구현 상황의 제약조건이나 상황 등을 자세하게 요구한다. 이런 점은 따를 만한 좋은 가이드라인이다. +일반적으로 커밋 메시지를 작성할 때 사용하는 규칙이 있다. 메시지의 첫 라인에 50자가 넘지 않는 아주 간략한 메시지를 적어 해당 커밋을 요약한다. 다음 한 라인은 비우고 그 다음 라인부터 커밋을 자세히 설명한다. +예를 들어 Git 개발 프로젝트에서는 개발 동기와 구현 상황의 제약 조건이나 상황 등을 자세하게 요구한다. 이런 점은 따를 만한 좋은 가이드라인이다. 그리고 현재형 표현을 사용하는 것이 좋다. 명령문으로 시작하는 것도 좋은 방법이다. 예를 들어 ``I added tests for (테스트를 추가함)'' 보다는 ``Add tests for (테스트 추가)'' 와 같은 메시지를 작성한다. -아래 예제는 Tim Pope이 작성한 커밋 메시지이다. +아래 내용은 Tim Pope가 작성한 커밋 메시지의 템플릿이다. [source,text] ////////////////////////// @@ -175,7 +175,7 @@ Further paragraphs come after blank lines. - 보통 '-' 나 '*' 표시를 사용해서 목록을 표현하고 표시 앞에 공백 하나, 각 목록 사이에는 빈 라인 - 하나를 넣는데 상황에 따라 다르다. + 하나를 넣는데, 이건 상황에 따라 다르다. ---- ////////////////////////// @@ -190,7 +190,7 @@ In the following examples, and throughout most of this book, for the sake of bre Do as we say, not as we do. ////////////////////////// 이 책에서 설명하는 예제의 커밋 메시지는 시간 관계상 위와 같이 아주 멋지게 쓰지 않았다. `git commit` 명령에서 `-m` 옵션을 사용하여 간단하게 적는다. -하지만! 저자처럼 하지 말고 시키는 대로 하셔야 한다. +하지만! 저자처럼 하지 말고 시키는 대로 하는 것이 좋다. [[_private_team]] ////////////////////////// @@ -218,8 +218,8 @@ The first developer, John, clones the repository, makes a change, and commits lo 이런 환경에서는 보통 Subversion 같은 중앙집중형 버전 관리 시스템에서 사용하던 방식을 사용한다. 물론 Git이 가진 오프라인 커밋 기능이나 브랜치 Merge 기능을 이용하긴 하지만 크게 다르지 않다. 가장 큰 차이점은 서버가 아닌 클라이언트 쪽에서 Merge 한다는 점이다. 두 개발자가 저장소를 공유하는 시나리오를 살펴보자. -개발자 John씨는 저장소를 Clone 하고 파일을 수정하고 나서 로컬에 커밋한다 -(예제에서 Git이 출력하는 메시지중 일부는 `...`으로 줄이고 생략했다). +개발자인 John은 저장소를 Clone 하고 파일을 수정하고 나서 로컬에 커밋한다 +(예제에서 Git이 출력하는 메시지 중 일부는 `...`으로 줄이고 생략했다). [source,console] ---- @@ -237,7 +237,7 @@ $ git commit -am 'removed invalid default value' ////////////////////////// The second developer, Jessica, does the same thing – clones the repository and commits a change: ////////////////////////// -개발자 Jessica씨도 저장소를 Clone 하고 나서 파일을 하나 새로 추가하고 커밋한다. +개발자인 Jessica도 저장소를 Clone 하고 나서 파일을 하나 새로 추가하고 커밋한다. [source,console] ---- @@ -255,7 +255,7 @@ $ git commit -am 'add reset task' ////////////////////////// Now, Jessica pushes her work up to the server: ////////////////////////// -Jessica씨는 서버에 커밋을 Push 한다. +Jessica는 서버에 커밋을 Push 한다. [source,console] ---- @@ -269,7 +269,7 @@ To jessica@githost:simplegit.git ////////////////////////// John tries to push his change up, too: ////////////////////////// -John씨도 서버로 커밋을 Push 하려고 한다. +John도 서버로 커밋을 Push 하려고 한다. [source,console] ---- @@ -286,10 +286,10 @@ This is especially important to understand if you're used to Subversion, because Although Subversion automatically does such a merge on the server if different files are edited, in Git you must merge the commits locally. John has to fetch Jessica's changes and merge them in before he will be allowed to push: ////////////////////////// -Jessica씨의 Push는 성공했지만, John씨의 커밋은 서버에서 거절된다. +Jessica의 Push는 성공했지만, John의 커밋은 서버에서 거절된다. Subversion을 사용했던 사람은 이 부분을 이해하는 것이 중요하다. 같은 파일을 수정한 것도 아닌데 왜 Push가 거절되는 걸까? Subversion에서는 서로 다른 파일을 수정하는 이런 Merge 작업은 자동으로 서버가 처리한다. 하지만, Git은 로컬에서 먼저 Merge 해야 한다. -John씨는 Push 하기 전에 Jessica씨가 수정한 커밋을 Fetch 하고 Merge 한다. +John은 Push 하기 전에 Jessica가 수정한 커밋을 Fetch 하고 Merge 한다. [source,console] ---- @@ -302,19 +302,19 @@ From john@githost:simplegit ////////////////////////// At this point, John's local repository looks something like this: ////////////////////////// -Fetch 하고 나면 John씨의 로컬 저장소는 아래와 같이 된다. +Fetch 하고 나면 John의 로컬 저장소는 아래와 같이 된다. ////////////////////////// .John's divergent history. image::images/small-team-1.png[John's divergent history.] ////////////////////////// -.Fetch 하고 난 John씨의 저장소. -image::images/small-team-1.png[Fetch 하고 난 John씨의 저장소.] +.Fetch 하고 난 John의 저장소. +image::images/small-team-1.png[Fetch 하고 난 John의 저장소.] ////////////////////////// John has a reference to the changes Jessica pushed up, but he has to merge them into his own work before he is allowed to push: ////////////////////////// -John씨는 Jessica씨가 저장소로 Push 했던 코드를 로컬 저장소에 가져왔다. 하지만, Push 하기 전에 Fetch 한 브랜치를 Merge 해야 한다. +John은 Jessica가 저장소로 Push 했던 코드를 로컬 저장소에 가져왔다. 하지만, Push 하기 전에 Fetch 한 브랜치를 Merge 해야 한다. [source,console] ---- @@ -327,19 +327,19 @@ Merge made by recursive. ////////////////////////// The merge goes smoothly – John's commit history now looks like this: ////////////////////////// -Merge가 잘 이루어지면 John씨의 브랜치는 아래와 같은 상태가 된다. +Merge가 잘 이루어지면 John의 브랜치는 아래와 같은 상태가 된다. ////////////////////////// .John's repository after merging `origin/master`. image::images/small-team-2.png[John's repository after merging `origin/master`.] ////////////////////////// -.`origin/master` 브랜치를 Merge 하고 난 후 John씨의 저장소. -image::images/small-team-2.png[`origin/master` 브랜치를 Merge 하고 난 후 John씨의 저장소.] +.`origin/master` 브랜치를 Merge 하고 난 후 John의 저장소. +image::images/small-team-2.png[`origin/master` 브랜치를 Merge 하고 난 후 John의 저장소.] ////////////////////////// Now, John can test his code to make sure it still works properly, and then he can push his new merged work up to the server: ////////////////////////// -John씨는 Merge 하고 나서 자신이 작업한 코드가 제대로 동작하는지 확인한다. 그 후에 공유하는 저장소에 Push 한다. +John은 Merge 하고 나서 자신이 작업한 코드가 제대로 동작하는지 확인한다. 그 후에 공유하는 저장소에 Push 한다. [source,console] ---- @@ -352,35 +352,35 @@ To john@githost:simplegit.git ////////////////////////// Finally, John's commit history looks like this: ////////////////////////// -이제 John씨의 저장소는 아래와 같이 되었다. +이제 John의 저장소는 아래와 같이 되었다. ////////////////////////// .John's history after pushing to the `origin` server. image::images/small-team-3.png[John's history after pushing to the `origin` server.] ////////////////////////// -.Push 하고 난 후 John씨의 저장소. -image::images/small-team-3.png[Push 하고 난 후 John씨의 저장소.] +.Push 하고 난 후 John의 저장소. +image::images/small-team-3.png[Push 하고 난 후 John의 저장소.] ////////////////////////// In the meantime, Jessica has been working on a topic branch. She's created a topic branch called `issue54` and done three commits on that branch. She hasn't fetched John's changes yet, so her commit history looks like this: ////////////////////////// -동시에 Jessica씨는 토픽 브랜치를 하나 만든다. +동시에 Jessica는 토픽 브랜치를 하나 만든다. issue54 브랜치를 만들고 세 번에 걸쳐서 커밋한다. -아직 John씨의 커밋을 Fetch 하지 않은 상황이기 때문에 아래와 같은 상황이 된다. +아직 John의 커밋을 Fetch 하지 않은 상황이기 때문에 아래와 같은 상황이 된다. ////////////////////////// .Jessica's topic branch. image::images/small-team-4.png[Jessica's topic branch.] ////////////////////////// -.Jessica씨 저장소의 토픽 브랜치. -image::images/small-team-4.png[Jessica씨 저장소의 토픽 브랜치.] +.Jessica의 토픽 브랜치. +image::images/small-team-4.png[Jessica의 토픽 브랜치.] ////////////////////////// Jessica wants to sync up with John, so she fetches: ////////////////////////// -Jessica씨는 John씨의 작업을 적용하려면 Fetch 해야 한다. +Jessica는 John의 작업을 적용하려면 Fetch 해야 한다. [source,console] ---- @@ -395,22 +395,22 @@ From jessica@githost:simplegit That pulls down the work John has pushed up in the meantime. Jessica's history now looks like this: ////////////////////////// -위 명령으로 John씨가 Push 한 커밋을 모두 내려받는다. -그러면 Jessica씨의 저장소는 아래와 같은 상태가 된다. +위 명령으로 John이 Push 한 커밋을 모두 내려받는다. +그러면 Jessica의 저장소는 아래와 같은 상태가 된다. ////////////////////////// .Jessica's history after fetching John's changes. image::images/small-team-5.png[Jessica's history after fetching John's changes.] ////////////////////////// -.John씨의 커밋을 Fetch 한 후 Jessica씨의 저장소. -image::images/small-team-5.png[John씨의 커밋을 Fetch 한 후 Jessica씨의 저장소.] +.John의 커밋을 Fetch 한 후 Jessica의 저장소. +image::images/small-team-5.png[John의 커밋을 Fetch 한 후 Jessica의 저장소.] ////////////////////////// Jessica thinks her topic branch is ready, but she wants to know what she has to merge into her work so that she can push. She runs `git log` to find out: ////////////////////////// -이제 orgin/master와 Merge 할 차례다. -Jessica씨는 토픽 브랜치 작업을 마치고 어떤 내용이 Merge 되는지 `git log` 명령으로 확인한다. +이제 `orgin/master`와 Merge 할 차례다. +Jessica는 토픽 브랜치에서의 작업을 마치고 어떤 내용이 Merge 되는지 `git log` 명령으로 확인한다. [source,console] ---- @@ -433,14 +433,14 @@ We'll go over this syntax in detail in <<_commit_ranges>>. For now, we can see from the output that there is a single commit that John has made that Jessica has not merged in. If she merges `origin/master`, that is the single commit that will modify her local work. ////////////////////////// -앞의 명령에 따라 히스토리를 검색한 결과 John씨가 생성하고 Jessica씨가 Merge 하지 않은 커밋을 하나 찾았다. +앞의 명령에 따라 히스토리를 검색한 결과 John이 생성하고 Jessica가 Merge 하지 않은 커밋을 하나 찾았다. `origin/master` 브랜치를 Merge 하게 되면 검색된 커밋 하나가 로컬 작업에 Merge 될 것이다. ////////////////////////// Now, Jessica can merge her topic work into her master branch, merge John's work (`origin/master`) into her `master` branch, and then push back to the server again. First, she switches back to her master branch to integrate all this work: ////////////////////////// -Merge 할 내용을 확인한 Jessica씨는 자신이 작업한 내용과 John씨가 Push 한 작업(`origin/master`)을 `master` 브랜치에 Merge 하고 Push 한다. +Merge 할 내용을 확인한 Jessica는 자신이 작업한 내용과 John이 Push 한 작업(`origin/master`)을 `master` 브랜치에 Merge 하고 Push 한다. 모든 내용을 합치기 전에 우선 `master` 브랜치를 Checkout 한다. [source,console] @@ -457,7 +457,7 @@ She chooses to merge in `issue54` first: ////////////////////////// `origin/master`, `issue54` 모두 Upstream 브랜치이기 때문에 둘 중에 무엇을 먼저 Merge 하든 상관이 없다. 물론 어떤 것을 먼저 Merge 하느냐에 따라 히스토리 순서는 달라지지만, 최종 결과는 똑같다. -Jessica씨는 먼저 `issue54` 브랜치를 Merge 한다. +Jessica는 먼저 `issue54` 브랜치를 Merge 한다. [source,console] ---- @@ -474,7 +474,7 @@ No problems occur; as you can see it was a simple fast-forward. Now Jessica merges in John's work (`origin/master`): ////////////////////////// 보다시피 Fast-forward Merge 이기 때문에 별 문제 없이 실행된다. -다음은 John씨의 커밋(`origin/master`)을 Merge 한다. +다음은 John의 커밋(`origin/master`)을 Merge 한다. [source,console] ---- @@ -494,13 +494,13 @@ Everything merges cleanly, and Jessica's history looks like this: .Jessica's history after merging John's changes. image::images/small-team-6.png[Jessica's history after merging John's changes.] ////////////////////////// -.John씨의 커밋을 Merge 후 Jessica씨의 저장소. -image::images/small-team-6.png[John씨의 커밋을 Merge 후 Jessica씨의 저장소.] +.John의 커밋을 Merge 후 Jessica의 저장소. +image::images/small-team-6.png[John의 커밋을 Merge 후 Jessica의 저장소.] ////////////////////////// Now `origin/master` is reachable from Jessica's `master` branch, so she should be able to successfully push (assuming John hasn't pushed again in the meantime): ////////////////////////// -`origin/master` 브랜치가 Jessica씨의 `master` 브랜치로 나아갈(reachable) 수 있기 때문에 Push는 성공한다(물론 John씨가 그 사이에 Push 하지 않았다면). +`origin/master` 브랜치가 Jessica의 `master` 브랜치로 나아갈(reachable) 수 있기 때문에 Push는 성공한다(물론 John이 그 사이에 Push 하지 않았다면). [source,console] ---- @@ -519,8 +519,8 @@ Each developer has committed a few times and merged each other's work successful .Jessica's history after pushing all changes back to the server. image::images/small-team-7.png[Jessica's history after pushing all changes back to the server.] ////////////////////////// -.Jessica씨가 서버로 Push 하고 난 후의 저장소. -image::images/small-team-7.png[Jessica씨가 서버로 Push 하고 난 후의 저장소.] +.Jessica가 서버로 Push 하고 난 후의 저장소. +image::images/small-team-7.png[Jessica가 서버로 Push 하고 난 후의 저장소.] ////////////////////////// That is one of the simplest workflows. @@ -558,7 +558,7 @@ Let's say that John and Jessica are working together on one feature, while Jessi In this case, the company is using a type of integration-manager workflow where the work of the individual groups is integrated only by certain engineers, and the `master` branch of the main repo can be updated only by those engineers. In this scenario, all work is done in team-based branches and pulled together by the integrators later. ////////////////////////// -John씨와 Jessica씨는 어떤 기능을 함께 작업하게 됐다. 물론 각각 다른 일도 한다. +John과 Jessica는 어떤 기능을 함께 작업하게 됐다. 물론 각각 다른 일도 한다. 이런 상황이라면 회사는 Integration-manager 워크플로를 선택하는 게 좋다. 작은 팀이 수행한 결과물은 Integration-Manager가 Merge 하고 공유 저장소의 master 브랜치를 업데이트한다. 팀마다 브랜치를 하나씩 만들고 Integration-Manager는 그 브랜치를 Pull 해서 Merge 한다. @@ -567,8 +567,8 @@ Let's follow Jessica's workflow as she works on her two features, collaborating Assuming she already has her repository cloned, she decides to work on `featureA` first. She creates a new branch for the feature and does some work on it there: ////////////////////////// -두 팀에 모두 속한 Jessica씨의 작업 순서를 살펴보자. -우선 Jessica씨는 저장소를 Clone 하고 `featureA` 작업을 먼저 한다. +두 팀에 모두 속한 Jessica의 작업 순서를 살펴보자. +우선 Jessica는 저장소를 Clone 하고 `featureA` 작업을 먼저 한다. `featureA` 브랜치를 만들고 수정하고 커밋한다. [source,console] @@ -586,7 +586,7 @@ $ git commit -am 'add limit to log function' At this point, she needs to share her work with John, so she pushes her `featureA` branch commits up to the server. Jessica doesn't have push access to the `master` branch – only the integrators do – so she has to push to another branch in order to collaborate with John: ////////////////////////// -이 수정한 부분을 John씨와 공유해야 한다. 공유하려면 우선 `featureA` 브랜치를 서버로 Push 한다. +이 수정한 부분을 John과 공유해야 한다. 공유하려면 우선 `featureA` 브랜치를 서버로 Push 한다. Integration-Manager만 `master` 브랜치를 업데이트할 수 있기 때문에 master 브랜치로 Push를 할 수 없고 다른 브랜치로 John과 공유한다. [source,console] @@ -602,8 +602,8 @@ Jessica emails John to tell him that she's pushed some work into a branch named While she waits for feedback from John, Jessica decides to start working on `featureB` with Josie. To begin, she starts a new feature branch, basing it off the server's `master` branch: ////////////////////////// -Jessica씨는 자신이 한 일을 `featureA` 라는 브랜치로 Push 했다는 이메일을 John씨에게 보낸다. -John씨의 피드백을 기다리는 동안 Jessica씨는 Josie씨와 함께 하는 `featureB` 작업을 하기로 한다. +Jessica는 자신이 한 일을 `featureA` 라는 브랜치로 Push 했다는 이메일을 John에게 보낸다. +John의 피드백을 기다리는 동안 Jessica는 Josie와 함께 하는 `featureB` 작업을 하기로 한다. 서버의 `master` 브랜치를 기반으로 새로운 브랜치를 하나 만든다. [source,console] @@ -634,22 +634,22 @@ $ git commit -am 'add ls-files' ////////////////////////// Jessica's repository looks like this: ////////////////////////// -그럼 Jessica씨의 저장소는 그림 아래와 같다. +그럼 Jessica의 저장소는 그림 아래와 같다. ////////////////////////// .Jessica's initial commit history. image::images/managed-team-1.png[Jessica's initial commit history.] ////////////////////////// -.Jessica씨의 저장소. -image::images/managed-team-1.png[Jessica씨의 저장소.] +.Jessica의 저장소. +image::images/managed-team-1.png[Jessica의 저장소.] ////////////////////////// She's ready to push up her work, but gets an email from Josie that a branch with some initial work on it was already pushed to the server as `featureBee`. Jessica first needs to merge those changes in with her own before she can push to the server. She can then fetch Josie's changes down with `git fetch`: ////////////////////////// -작업을 마치고 Push 하려고 하는데 Jesie씨가 이미 일부 작업을 하고 서버에 `featureBee` 브랜치로 Push 했다는 이메일을 보내왔다. -Jessica씨는 Jesie씨의 작업을 먼저 Merge 해야만 Push 할 수 있다. +작업을 마치고 Push 하려고 하는데 Jesie가 이미 일부 작업을 하고 서버에 `featureBee` 브랜치로 Push 했다는 이메일을 보내왔다. +Jessica는 Jesie의 작업을 먼저 Merge 해야만 Push 할 수 있다. Merge 하기 위해서 우선 `git fetch`로 Fetch 한다. [source,console] @@ -678,7 +678,7 @@ Merge made by recursive. There is a bit of a problem – she needs to push the merged work in her `featureB` branch to the `featureBee` branch on the server. She can do so by specifying the local branch followed by a colon (:) followed by the remote branch to the `git push` command: ////////////////////////// -Push 하려고 하는데 작은 문제가 생겼다. Jessica씨는 `featureB` 브랜치에서 작업을 했는데 서버에는 브랜치가 `featureBee` 라는 이름으로 되어 있다. +Push 하려고 하는데 작은 문제가 생겼다. Jessica는 `featureB` 브랜치에서 작업을 했는데 서버에는 브랜치가 `featureBee` 라는 이름으로 되어 있다. 그래서 `git push` 명령으로 Push 할 때 로컬 브랜치 featureB 뒤에 콜론(:)과 함께 서버 브랜치 이름을 직접 지정해 준다. [source,console] @@ -696,14 +696,14 @@ Also notice the `-u` flag; this is short for `--set-upstream`, which configures ////////////////////////// 이것은 _refspec_ 이란 것을 사용하는 것인데 <<_refspec>> 에서 자세하게 설명한다. -명령에서 사용한 `-u` 옵션은 `--set-upstream` 옵션의 짧은 표현인데 브랜치를 추적하도록 설정해서 이후 Push 나 Pull을 할 때 좀 더 편하게 사용할 수 있다. +명령에서 사용한 `-u` 옵션은 `--set-upstream` 옵션의 짧은 표현인데 브랜치를 추적하도록 설정해서 이후 Push 나 Pull 할 때 좀 더 편하게 사용할 수 있다. ////////////////////////// Next, John emails Jessica to say he's pushed some changes to the `featureA` branch and ask her to verify them. She runs a `git fetch` to pull down those changes: ////////////////////////// -John씨가 몇 가지 작업을 하고 나서 `featureA` 에 Push 했고 확인해 달라는 내용의 이메일을 보내왔다. -Jessica씨는 `git fetch`로 Push 한 작업을 Fetch 한다. +John이 몇 가지 작업을 하고 나서 `featureA` 에 Push 했고 확인해 달라는 내용의 이메일을 보내왔다. +Jessica는 `git fetch`로 Push 한 작업을 Fetch 한다. [source,console] ---- @@ -747,7 +747,7 @@ Fast forward ////////////////////////// Jessica wants to tweak something, so she commits again and then pushes this back up to the server: ////////////////////////// -Jessica씨는 일부 수정하고, 수정한 내용을 다시 서버로 Push 한다. +Jessica는 일부 수정하고, 수정한 내용을 다시 서버로 Push 한다. [source,console] ---- @@ -763,14 +763,14 @@ To jessica@githost:simplegit.git ////////////////////////// Jessica's commit history now looks something like this: ////////////////////////// -위와 같은 작업을 마치고 나면 Jessica씨의 저장소는 아래와 같은 모습이 된다. +위와 같은 작업을 마치고 나면 Jessica의 저장소는 아래와 같은 모습이 된다. ////////////////////////// .Jessica's history after committing on a feature branch. image::images/managed-team-2.png[Jessica's history after committing on a feature branch.] ////////////////////////// -.마지막 Push 하고 난 후의 Jessica씨의 저장소. -image::images/managed-team-2.png[마지막 Push 하고 난 후의 Jessica씨의 저장소.] +.마지막 Push 하고 난 후의 Jessica의 저장소. +image::images/managed-team-2.png[마지막 Push 하고 난 후의 Jessica의 저장소.] ////////////////////////// Jessica, Josie, and John inform the integrators that the `featureA` and `featureBee` branches on the server are ready for integration into the mainline. @@ -891,7 +891,7 @@ The `request-pull` command takes the base branch into which you want your topic For instance, if Jessica wants to send John a pull request, and she's done two commits on the topic branch she just pushed up, she can run this: ////////////////////////// `request-pull` 명령은 아규먼트를 두 개 입력받는다. 첫 번째 아규먼트는 작업한 토픽 브랜치의 Base 브랜치이다. 두 번째는 토픽 브랜치가 위치한 저장소 URL인데 위에서 등록한 리모트 저장소 이름을 적을 수 있다. 이 명령은 토픽 브랜치 수정사항을 요약한 내용을 결과로 보여준다. -예를 들어 Jessica씨가 John씨에게 Pull 요청을 보내는 상황을 살펴보자. Jessica씨는 토픽 브랜치에 두 번 커밋을 하고 Fork 한 저장소에 Push 했다. 그리고 아래와 같이 실행한다. +예를 들어 Jessica가 John에게 Pull 요청을 보내는 상황을 살펴보자. Jessica는 토픽 브랜치에 두 번 커밋을 하고 Fork 한 저장소에 Push 했다. 그리고 아래와 같이 실행한다. [source,console] ---- @@ -915,7 +915,7 @@ Jessica Smith (2). ////////////////////////// The output can be sent to the maintainer–it tells them where the work was branched from, summarizes the commits, and tells where to pull this work from. ////////////////////////// -관리자에게 이 내용을 보낸다. 이 내용에는 토픽 브랜치가 어느 시점에 갈라져 나온 것인지, 어떤 커밋이 있는 지, Pull 하려면 어떤 저장소에 접근해야 하는지에 대한 내용이 들어 있다. +관리자에게 이 내용을 보낸다. 이 내용에는 토픽 브랜치가 어느 시점에 갈라져 나온 것인지, 어떤 커밋이 있는지, Pull 하려면 어떤 저장소에 접근해야 하는지에 대한 내용이 들어 있다. ////////////////////////// On a project for which you're not the maintainer, it's generally easier to have a branch like `master` always track `origin/master` and to do your work in topic branches that you can easily discard if they're rejected. @@ -952,8 +952,8 @@ image::images/public-small-1.png[featureB 수정작업이 끝난 직후 저장 Let's say the project maintainer has pulled in a bunch of other patches and tried your first branch, but it no longer cleanly merges. In this case, you can try to rebase that branch on top of `origin/master`, resolve the conflicts for the maintainer, and then resubmit your changes: ////////////////////////// -프로젝트 관리자가 사람들의 수정사항을 Merge 하고 나서 Jessica씨의 브랜치를 Merge 하려고 할 때 충돌이 날 수도 있다. -그러면 Jessica씨가 자신의 브랜치를 `origin/master`에 Rebase 해서 충돌을 해결하고 다시 Pull Request을 보낸다. +프로젝트 관리자가 사람들의 수정 사항을 Merge 하고 나서 Jessica의 브랜치를 Merge 하려고 할 때 충돌이 날 수도 있다. +그러면 Jessica가 자신의 브랜치를 `origin/master`에 Rebase 해서 충돌을 해결하고 다시 Pull Request을 보낸다. [source,console] ---- @@ -973,7 +973,7 @@ This rewrites your history to now look like <>. image::images/public-small-2.png[Commit history after `featureA` work.] ////////////////////////// .FeatureA에 대한 Rebase가 적용된 후의 모습. -image::images/public-small-2.png[CFeatureA에 대한 Rebase가 적용된 후의 모습.] +image::images/public-small-2.png[FeatureA에 대한 Rebase가 적용된 후의 모습.] ////////////////////////// Because you rebased the branch, you have to specify the `-f` to your push command in order to be able to replace the `featureA` branch on the server with a commit that isn't a descendant of it. @@ -987,7 +987,7 @@ Let's look at one more possible scenario: the maintainer has looked at work in y You'll also take this opportunity to move the work to be based off the project's current `master` branch. You start a new branch based off the current `origin/master` branch, squash the `featureB` changes there, resolve any conflicts, make the implementation change, and then push that up as a new branch: ////////////////////////// -또 다른 시나리오를 하나 더 살펴보자. 프로젝트 관리자는 `featureB` 브랜치의 내용은 좋지만, 상세 구현은 다르게 하고 싶다. 관리자는 `featureB` 담당자에게 상세구현을 다르게 해달라고 요청한다. +또 다른 시나리오를 하나 더 살펴보자. 프로젝트 관리자는 `featureB` 브랜치의 내용은 좋지만, 상세 구현은 다르게 하고 싶다. 관리자는 `featureB` 담당자에게 상세 구현을 다르게 해달라고 요청한다. `featureB` 담당자는 하는 김에 `featureB` 브랜치를 프로젝트의 최신 `master` 브랜치 기반으로 옮긴다. 먼저 `origin/master` 브랜치에서 `featureBv2` 브랜치를 새로 하나 만들고, `featureB`의 커밋들을 모두 Squash 해서 Merge 하고, 만약 충돌이 나면 해결하고, 상세 구현을 수정하고, 새 브랜치를 Push 한다. @@ -1117,7 +1117,7 @@ You can also edit these patch files to add more information for the email list t If you add text between the `---` line and the beginning of the patch (the `diff --git` line), then developers can read it; but applying the patch excludes it. ////////////////////////// 메일링리스트에 이메일을 보내기 전에 각 Patch 파일을 손으로 고칠 수 있다. -`---` 라인과 Patch가 시작되는 라인(`diff --git`로 시작하는 라인) 사이에 내용을 추가하면 개발자는 읽을 수 있지만, 나중에 Patch에 적용되지는 않는다. +`---` 라인과 Patch가 시작되는 라인(`diff --git`로 시작하는 라인) 사이에 내용을 추가하면 다른 개발자들은 읽을 수 있지만, 나중에 Patch에 적용되지는 않는다. ////////////////////////// To email this to a mailing list, you can either paste the file into your email program or send it via a command-line program. diff --git a/book/05-distributed-git/sections/maintaining.asc b/book/05-distributed-git/sections/maintaining.asc index 7ba0c378..054d2a7b 100644 --- a/book/05-distributed-git/sections/maintaining.asc +++ b/book/05-distributed-git/sections/maintaining.asc @@ -75,7 +75,7 @@ Patch를 적용하는 방법은 `git apply` 명령을 사용하는 것과 `git a If you received the patch from someone who generated it with the `git diff` or a Unix `diff` command (which is not recommended; see the next section), you can apply it with the `git apply` command. Assuming you saved the patch at `/tmp/patch-ruby-client.patch`, you can apply the patch like this: ////////////////////////// -`git diff`나 Unix의 `diff` 명령(다음 절에서 다루겠지만 추천하지 않는 방법)으로 만든 Patch파일을 적용할 때는 `git apply` 명령을 사용한다. +`git diff`나 Unix의 `diff` 명령(다음 절에서 다루겠지만 추천하지 않는 방법)으로 만든 Patch 파일을 적용할 때는 `git apply` 명령을 사용한다. Patch 파일이 `/tmp/patch-ruby-client.patch`라고 하면 아래와 같은 명령으로 Patch를 적용할 수 있다. [source,console] @@ -92,11 +92,11 @@ Finally, `git apply` is an ``apply all or abort all'' model where either everyth It won't create a commit for you – after running it, you must stage and commit the changes introduced manually. ////////////////////////// 위 명령을 실행하면 Patch 파일 내용에 따라 현재 디렉토리의 파일들을 변경한다. -위 명령은 `patch -p1` 명령과 거의 같다. 하지만, 이 명령이 patch 명령보다 훨씬 더 꼼꼼하게 비교한다. -`git diff`로 생성한 Patch 파일에 파일을 추가하거나, 파일을 삭제하고, 파일의 이름을 변경하는 내용이 들어 있으면 그대로 적용된다. 이런 것은 patch 명령으로 할 수 없다. +위 명령은 `patch -p1` 명령과 거의 같다. 하지만, 이 명령이 `patch` 명령보다 훨씬 더 꼼꼼하게 비교한다. +`git diff`로 생성한 Patch 파일에 파일을 추가하거나, 파일을 삭제하고, 파일의 이름을 변경하는 내용이 들어 있으면 그대로 적용된다. 이런 것은 `patch` 명령으로 할 수 없다. 그리고 `git apply`는 ``모두 적용, 아니면 모두 취소'' 모델을 사용하기 때문에 Patch를 적용하는 데 실패하면 Patch를 적용하기 이전 상태로 전부 되돌려 놓는다. -Patch 명령은 여러 파일에 적용하다가 중간에 실패하면 거기서 그대로 중단하기 때문에 깔끔하지 못하다. -`git apply`는 Patch보다 훨씬 결벽증적이다. 이 명령은 자동으로 커밋해 주지 않기 때문에 변경된 파일을 직접 Staging Area에 추가하고 커밋해야 한다. +`patch` 명령은 여러 파일에 적용하다가 중간에 실패하면 거기서 그대로 중단하기 때문에 깔끔하지 못하다. +`git apply`는 `patch` 명령보다 훨씬 보수적이다. 이 명령은 자동으로 커밋해 주지 않기 때문에 변경된 파일을 직접 Staging Area에 추가하고 커밋해야 한다. ////////////////////////// You can also use git apply to see if a patch applies cleanly before you try actually applying it – you can run `git apply --check` with the patch: @@ -131,16 +131,16 @@ You should only have to use `git apply` for legacy patches and things like that. ////////////////////////// 프로젝트 기여자가 Git의 format-patch 명령을 잘 사용하면 관리자의 작업은 훨씬 쉬워진다. format-patch 명령으로 만든 Patch 파일은 기여자의 정보와 커밋 정보가 포함되어 있기 때문이다. 그래서 기여자가 diff보다 format-patch를 사용하도록 권해야 한다. -`git apply`는 기존의 Patch파일에만 사용한다. +`git apply`는 기존 Patch 파일에만 사용한다. ////////////////////////// To apply a patch generated by `format-patch`, you use `git am`. Technically, `git am` is built to read an mbox file, which is a simple, plain-text format for storing one or more email messages in one text file. It looks something like this: ////////////////////////// -format-patch 명령으로 생성한 Patch 파일은 `git am` 명령으로 적용한다. -`git am`은 이메일 여러 통이 들어 있는 mbox파일을 읽어서 Patch 한다. -mbox파일은 간단한 텍스트 파일이고 그 내용은 아래와 같다. +`format-patch` 명령으로 생성한 Patch 파일은 `git am` 명령으로 적용한다. +`git am`은 mbox 파일을 읽어 그 안에 이메일 메시지가 한 개가 있든 여러 개가 있든 처리할 수 있다. +mbox 파일은 간단한 텍스트 파일이고 그 내용은 아래와 같다. [source,console] ---- @@ -201,8 +201,8 @@ CommitDate: Thu Apr 9 09:19:06 2009 -0700 The `Commit` information indicates the person who applied the patch and the time it was applied. The `Author` information is the individual who originally created the patch and when it was originally created. ////////////////////////// -`Commit` 부분의 커밋 정보는 누가 언제 Patch 했는 지 알려 준다. -`Author` 정보는 실제로 누가 언제 Patch파일을 만들었는지 알려 준다. +`Commit` 부분의 커밋 정보는 누가 언제 Patch 했는지 알려 준다. +`Author` 정보는 실제로 누가 언제 Patch 파일을 만들었는지 알려 준다. ////////////////////////// But it's possible that the patch won't apply cleanly. @@ -247,7 +247,7 @@ If you do have that commit – if the patch was based on a public commit – the ////////////////////////// 충돌이 났을 때 Git에게 좀 더 머리를 써서 Patch를 적용하도록 하려면 `-3` 옵션을 사용한다. 이 옵션은 Git에게 3-way Patch를 적용해 보라고 하는 것이다. Patch가 어느 시점에서 갈라져 나온 것인지 알 수 없기 때문에 이 옵션은 기본적으로 비활성화돼 있다. -하지만 같은 프로젝트의 커밋이라면 기본옵션보다 훨씬 똑똑하게 충돌 상황을 해결한다. +하지만 같은 프로젝트의 커밋이라면 기본 옵션보다 훨씬 똑똑하게 충돌 상황을 해결한다. [source,console] ---- @@ -307,7 +307,7 @@ If your contribution came from a Git user who set up their own repository, pushe ////////////////////////// For instance, if Jessica sends you an email saying that she has a great new feature in the `ruby-client` branch of her repository, you can test it by adding the remote and checking out that branch locally: ////////////////////////// -예를 들어 Jessica씨는 `ruby-client` 브랜치에 엄청난 기능을 만들어 놨다고 이메일을 보내왔다. 이 리모트 브랜치를 등록하고 Checkout 해서 테스트한다. +예를 들어 Jessica가 `ruby-client` 브랜치에 엄청난 기능을 만들어 놨다고 이메일을 보내왔다. 이 리모트 브랜치를 등록하고 Checkout 해서 테스트한다. [source,console] ---- @@ -319,7 +319,7 @@ $ git checkout -b rubyclient jessica/ruby-client ////////////////////////// If she emails you again later with another branch containing another great feature, you can fetch and check out because you already have the remote setup. ////////////////////////// -후에 Jessiaca씨가 이메일로 또 다른 엄청난 기능을 개발한 브랜치를 보내오면 이미 저장소를 등록했기 때문에 간단히 Fetch 하고 Checkout 할 수 있다. +나중에 Jessiaca가 이메일로 또 다른 엄청난 기능을 개발한 브랜치를 보내오면 이미 저장소를 등록했기 때문에 간단히 Fetch 하고 Checkout 할 수 있다. ////////////////////////// This is most useful if you're working with a person consistently. @@ -337,7 +337,7 @@ The other advantage of this approach is that you get the history of the commits Although you may have legitimate merge issues, you know where in your history their work is based; a proper three-way merge is the default rather than having to supply a `-3` and hope the patch was generated off a public commit to which you have access. ////////////////////////// 리모트 저장소로 등록하면 커밋의 히스토리도 알 수 있다. -Merge 할 때 어디서 부터 커밋이 갈라졌는지 알 수 있기 때문에 `-3` 옵션을 주지 않아도 자동으로 3-way Merge가 적용된다. +Merge 할 때 어디서부터 커밋이 갈라졌는지 알 수 있기 때문에 `-3` 옵션을 주지 않아도 자동으로 3-way Merge가 적용된다. ////////////////////////// If you aren't working with a person consistently but still want to pull from them in this way, you can provide the URL of the remote repository to the `git pull` command. @@ -366,7 +366,7 @@ Now you have a topic branch that contains contributed work. At this point, you can determine what you'd like to do with it. This section revisits a couple of commands so you can see how you can use them to review exactly what you'll be introducing if you merge this into your main branch. ////////////////////////// -기여물이 포함된 토픽 브랜치가 있으니 이제 그 기여물을 Merge 할지 말지 결정야 한다. +기여물이 포함된 토픽 브랜치가 있으니 이제 그 기여물을 Merge 할지 말지 결정해야 한다. 이번 절에서는 메인 브랜치에 Merge 할 때 필요한 명령어를 살펴본다. 주로 토픽 브랜치를 검토하는데 필요한 명령이다. @@ -423,7 +423,7 @@ For example, if you've added a line in a file on the `master` branch, a direct c 이 명령은 diff 내용을 보여주긴 하지만 잘못된 것을 보여줄 수도 있다. 토픽 브랜치에서 작업하는 동안 `master` 브랜치에 새로운 커밋이 추가될 수도 있다. 그렇기 때문에 기대하는 diff 결과가 아닐 수 있다. 위 명령은 토픽 브랜치의 마지막 커밋과 `master` 브랜치의 마지막 커밋을 비교한다. -`master` 브랜치에 한 줄을 추가되면 토픽 브랜치에서 한 라인 삭제한 것으로 보여 준다. +`master` 브랜치에 한 줄을 추가되면 토픽 브랜치에서 한 줄 삭제한 것으로 보여 준다. ////////////////////////// If `master` is a direct ancestor of your topic branch, this isn't a problem; but if the two histories have diverged, the diff will look like you're adding all the new stuff in your topic branch and removing everything unique to the `master` branch. @@ -453,8 +453,8 @@ $ git diff 36c7db However, that isn't convenient, so Git provides another shorthand for doing the same thing: the triple-dot syntax. In the context of the `diff` command, you can put three periods after another branch to do a `diff` between the last commit of the branch you're on and its common ancestor with another branch: ////////////////////////// -이 방법으로 원하는 결과를 얻을 수 있지만, 사용법이 불편하다. Git은 Triple-Dot으로 간단하게 위와 같이 비교하는 방법을 지원한다. -`diff` 명령을 사용할 때 두 브랜치 사이에 ...를 쓰면, 두 브랜치의 공통 조상과 브랜치의 마지막 커밋을 비교한다. +이 방법으로 원하는 결과를 얻을 수 있지만, 사용법이 불편하다. Git은 Triple-Dot 구문으로 간단하게 위와 같이 비교하는 방법을 지원한다. +`diff` 명령을 사용할 때 두 브랜치 사이에 `...`를 쓰면, 두 브랜치의 공통 조상과 브랜치의 마지막 커밋을 비교한다. [source,console] ---- @@ -562,7 +562,7 @@ You can also continue this concept, having an integrate branch where all the wor 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. ////////////////////////// 이 워크플로를 사용하면 프로젝트 저장소를 Clone 하고 나서 개발자가 안정 버전이 필요하면 master 브랜치를 빌드하고 안정적이지 않더라도 좀 더 최신 버전이 필요하면 develop 브랜치를 Checkout 하여 빌드한다. -이 개념을 좀 더 확장해서 사용할 수 있다. 토픽 브랜치를 검증하기 위한 integrate 브랜치를 만들어 Merge 하고 토픽 브랜치가 검증되면 develop 브랜치에 머지한다. +이 개념을 좀 더 확장해서 사용할 수 있다. 토픽 브랜치를 검증하기 위한 integrate 브랜치를 만들어 Merge 하고 토픽 브랜치가 검증되면 develop 브랜치에 Merge 한다. 그리고 develop 브랜치에서 충분히 안정하다는 것이 증명되면 그때 master 브랜치에 Merge 한다. ////////////////////////// @@ -642,7 +642,7 @@ For example, suppose you have a project that looks like this: 한 브랜치에서 다른 브랜치로 작업한 내용을 옮기는 또 다른 방식으로 Cherry-pick이란 것도 있다. Git의 Cherry-pick은 커밋 하나만 Rebase 하는 것이다. 커밋 하나로 Patch 내용을 만들어 현재 브랜치에 적용을 하는 것이다. -토픽 브랜치에 있는 커밋중에서 하나만 고르거나 토픽 브랜치에 커밋이 하나밖에 없을 때 Rebase 보다 유용하다. +토픽 브랜치에 있는 커밋 중에서 하나만 고르거나 토픽 브랜치에 커밋이 하나밖에 없을 때 Rebase 보다 유용하다. 아래와 같은 예를 들어보자. ////////////////////////// @@ -699,7 +699,7 @@ If you're doing lots of merging and rebasing, or you're maintaining a long-lived Rerere stands for ``reuse recorded resolution'' – it's a way of shortcutting manual conflict resolution. When rerere is enabled, Git will keep a set of pre- and post-images from successful merges, and if it notices that there's a conflict that looks exactly like one you've already fixed, it'll just use the fix from last time, without bothering you with it. ////////////////////////// -Rerere의 뜻은 ``reuse recorded reolution''(충돌 해결방법 재사용)으로 수작업으로 충돌 해결하던 것을 쉽게 해준다. +Rerere의 뜻은 ``reuse recorded resolution''(충돌 해결방법 재사용)으로 수작업으로 충돌 해결하던 것을 쉽게 해준다. rerere 기능이 활성화 돼 있으면 Merge가 성공할 때 마다 그 이전과 이후 상태를 저장해둔다. 나중에 충돌이 발생하면 비슷한 상황에서 Merge가 성공한 적이 있었는지 찾아보고 해결이 가능하다면 자동으로 해결한다. ////////////////////////// @@ -726,7 +726,7 @@ There are also subcommands to see what will be recorded, to erase specific resol We will cover rerere in more detail in <<_rerere>>. ////////////////////////// 필요하다면 `git rerere` 명령을 사용하여 저장된 캐시를 바탕으로 대화형 인터페이스를 통해 충돌을 다룰 수도 있다. -`git rerere` 명령을 직접 실행하면 현재 Merge 과정에서 발생한 충돌을 해결하는데 참고할 만한 이전 Merge 기록을 찾아준다(사실 `rerere.enabled` 옵션이 켜져 있다면 자동). +`git rerere` 명령을 직접 실행하면 현재 Merge 과정에서 발생한 충돌을 해결하는데 참고할 만한 이전 Merge 기록을 찾아준다(`rerere.enabled` 옵션이 켜져 있다면 자동). Rerere 기능을 사용할 때 기록할 내용을 세세하게 설정하거나, 기록된 내용 중에 특정 기록을 지운다거나 하는 보조 명령도 제공한다. 자세한 내용은 <<_rerere>> 에서 다루기로 한다. @@ -760,7 +760,7 @@ The maintainer of the Git project has solved this issue by including their publi To do this, you can figure out which key you want by running `gpg --list-keys`: ////////////////////////// 태그에 서명하면 서명에 사용한 PGP 공개키도 배포해야 한다. -Git 개발 프로젝트는 관리자의 PGP 공개키를 Blob 형식으로 Git 저장소에 함께 배포한다. 이 Blob파일을 사용하여 태그에 서명했다. +Git 개발 프로젝트는 관리자의 PGP 공개키를 Blob 형식으로 Git 저장소에 함께 배포한다. 이 Blob 파일을 사용하여 태그에 서명했다. `gpg --list-keys` 명령으로 어떤 PGP 공개키를 포함할지 확인한다. [source,console] @@ -840,7 +840,7 @@ If you're describing a commit that you have directly tagged, it gives you the ta ////////////////////////// 이렇게 사람이 읽을 수 있는 이름으로 스냅샷이나 빌드를 만든다. 만약 저장소에서 Clone 한 후 소스코드로 Git을 설치하면 `git --version` 명령은 이렇게 생긴 빌드넘버를 보여준다. -태그가 달린 커밋에 `git describe`명령을 사용하면 다른 정보 없이 태그 이름만 사용한다. +태그가 달린 커밋에 `git describe` 명령을 사용하면 다른 정보 없이 태그 이름만 사용한다. ////////////////////////// The `git describe` command favors annotated tags (tags created with the `-a` or `-s` flag), so release tags should be created this way if you're using `git describe`, to ensure the commit is named properly when described. @@ -849,7 +849,7 @@ For instance, the Linux kernel recently jumped from 8 to 10 characters to ensure ////////////////////////// `git describe` 명령은 `-a`나 `-s` 옵션을 주고 만든 Annotated 태그가 필요하다. 릴리즈 태그는 `git describe` 명령으로 만드니까 꼭 이름이 적당한지 사전에 확인해야 한다. 그리고 이 값은 checkout이나 show 명령에도 사용할 수 있지만, 전적으로 이름 뒤에 붙은 SHA-1 값을 사용한다. 그래서 이 값으로는 해당 커밋을 못 찾을 수도 있다. -최근 Linux Kernel은 충돌 때문에 축약된 SHA-1가 8자에서 10자로 늘어났다. 이제는 8자일 때 생성한 값은 사용할 수 없다. +최근 리눅스 커널은 충돌 때문에 축약된 SHA-1가 8자에서 10자로 늘어났다. 이제는 8자일 때 생성한 값은 사용할 수 없다. [[_preparing_release]] ////////////////////////// @@ -879,7 +879,7 @@ If someone opens that tarball, they get the latest snapshot of your project unde You can also create a zip archive in much the same way, but by passing the `--format=zip` option to `git archive`: ////////////////////////// 이 압축 파일을 풀면 프로젝트의 가장 마지막 스냅샷이 나온다. -ZIP 형식으로 압축파일을 만들려면 `--format=zip` 옵션을 사용한다. +ZIP 형식으로 압축 파일을 만들려면 `--format=zip` 옵션을 사용한다. [source,console] ---- @@ -889,7 +889,7 @@ $ git archive master --prefix='project/' --format=zip > `git describe master`.zi ////////////////////////// You now have a nice tarball and a zip archive of your project release that you can upload to your website or email to people. ////////////////////////// -이렇게 압축한 스냅샷 파일은 Website나 이메일로 사람들에게 배포할 수 있다. +이렇게 압축한 스냅샷 파일은 웹사이트나 이메일로 사람들에게 배포할 수 있다. [[_the_shortlog]] ////////////////////////// diff --git a/book/06-github/sections/1-setting-up-account.asc b/book/06-github/sections/1-setting-up-account.asc index ae4be902..37014bee 100644 --- a/book/06-github/sections/1-setting-up-account.asc +++ b/book/06-github/sections/1-setting-up-account.asc @@ -24,7 +24,7 @@ GitHub will send you an email to verify the address you provided. Go ahead and do this, it's pretty important (as we'll see later). ////////////////////////// 다음 보이는 화면은 유료 옵션에 대한 안내 페이지인데, 지금은 무시한다. -GitHub은 입력한 이메일 주소로 확인 메일을 보냈을 것이다. +GitHub는 입력한 이메일 주소로 확인 메일을 보냈을 것이다. 메일의 지시를 따르자. 나중에 살펴볼 테지만 이 과정은 매우 중요하다. [NOTE] @@ -155,8 +155,8 @@ 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에 그 이메일을 모두 등록하기만 했으면 GitHub은 잘 처리한다. ``Emails'' 화면에서 모두 등록한다. +GitHub는 Git 커밋에 있는 이메일 주소를 보고 어떤 사용자인지 식별한다. +사용자가 이메일 주소를 여러 개 사용해서 커밋했어도 GitHub에 그 이메일을 모두 등록하기만 했으면 GitHub는 잘 처리한다. ``Emails'' 화면에서 모두 등록한다. [[_add_email_addresses]] ////////////////////////// @@ -208,7 +208,7 @@ image::images/2fa-1.png[Security 탭에 있는 2FA] ////////////////////////// If you click on the ``Set up two-factor authentication'' button, it will take you to a configuration page where you can choose to use a phone app to generate your secondary code (a ``time based one-time password''), or you can have GitHub send you a code via SMS each time you need to log in. ////////////////////////// -``Set up two-factor authentication'' 버튼을 클릭하면 2FA 설정 페이지로 이동한다. ``TOTP(Time based One-Time 비밀번호''를 생성하는 스마트폰 앱을 사용하는 방식을 고르거나 GitHub이 인증 코드를 SMS로 전송해주는 방식을 고를 수 있다. 설정하면 로그인할 때 TOTP나 인증코드가 필요하다. +``Set up two-factor authentication'' 버튼을 클릭하면 2FA 설정 페이지로 이동한다. ``TOTP(Time based One-Time 비밀번호''를 생성하는 스마트폰 앱을 사용하는 방식을 고르거나 GitHub가 인증 코드를 SMS로 전송해주는 방식을 고를 수 있다. 설정하면 로그인할 때 TOTP나 인증코드가 필요하다. ////////////////////////// After you choose which method you prefer and follow the instructions for setting up 2FA, your account will then be a little more secure and you will have to provide a code in addition to your password whenever you log into GitHub. diff --git a/book/06-github/sections/2-contributing.asc b/book/06-github/sections/2-contributing.asc index 0e14566b..4879170d 100644 --- a/book/06-github/sections/2-contributing.asc +++ b/book/06-github/sections/2-contributing.asc @@ -255,7 +255,7 @@ Pull Request는 보통 공개 프로젝트에서 사용한다. 기여자는 수 ////////////////////////// At this point, the project owner can look at the suggested change and merge it, reject it or comment on it. Let's say that he likes the idea, but would prefer a slightly longer time for the light to be off than on. ////////////////////////// -Pull Request가 오면 프로젝트 소유자는 변경 점이 무엇인지 확인한 후, Merge 혹은 거절하거나 코멘트를 달 수 있다. 소유자가 아이디어 자체를 마음에 들어 한다면 빛을 보기까지 좀 더 공을 들여야 한다. +Pull Request가 오면 프로젝트 소유자는 변경점이 무엇인지 확인한 후, Merge 혹은 거절하거나 코멘트를 달 수 있다. 소유자가 아이디어 자체를 마음에 들어 한다면 빛을 보기까지 좀 더 공을 들여야 한다. ////////////////////////// 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. @@ -380,7 +380,7 @@ This is an important distinction, because generally the change is suggested befo ////////////////////////// For instance, if you go back and look again at <<_pr_final>>, you'll notice that the contributor did not rebase his commit and send another Pull Request. Instead they added new commits and pushed them to the existing branch. This way if you go back and look at this Pull Request in the future, you can easily find all of the context of why decisions were made. Pushing the ``Merge'' button on the site purposefully creates a merge commit that references the Pull Request so that it's easy to go back and research the original conversation if necessary. ////////////////////////// -<<_pr_final>>로 돌아가서 다시 보면 기여자가 커밋을 Rebase 하거나 Pull Request를 다시 열지 않았다는 것을 확인할 수 있다. 그냥 기존 브랜치에 좀 더 커밋하고 Push 했을 뿐이다. 나중에 시간이 지나서 이 Pull Request를 다시 읽으면 왜 이런 방향으로 결정했는지에 대한 맥락을 쉽게 알 수 있다. 웹 사이트에서 ``Merge'' 버튼을 누르면 Merge 커밋을 일부러 남기겠다는 뜻이 된다. 이 Merge 커밋에는 Pull Request 정보가 들어가기 때문에 필요하면 언제든지 맥락을 확인할 수 있다. +<<_pr_final>>로 돌아가서 다시 보면 기여자가 커밋을 Rebase 하거나 Pull Request를 다시 열지 않았다는 것을 확인할 수 있다. 그냥 기존 브랜치에 좀 더 커밋하고 Push 했을 뿐이다. 나중에 시간이 지나서 이 Pull Request를 다시 읽으면 왜 이런 방향으로 결정했는지에 대한 맥락을 쉽게 알 수 있다. 웹사이트에서 ``Merge'' 버튼을 누르면 Merge 커밋을 일부러 남기겠다는 뜻이 된다. 이 Merge 커밋에는 Pull Request 정보가 들어가기 때문에 필요하면 언제든지 맥락을 확인할 수 있다. ////////////////////////// ===== Keeping up with Upstream diff --git a/book/06-github/sections/3-maintaining.asc b/book/06-github/sections/3-maintaining.asc index 419df5b6..5beefe8e 100644 --- a/book/06-github/sections/3-maintaining.asc +++ b/book/06-github/sections/3-maintaining.asc @@ -59,7 +59,7 @@ For now, just click the ``Create Repository'' button, and boom – you have a ne Since you have no code there yet, GitHub will show you instructions for how to create a brand-new Git repository, or connect an existing Git project. We won't belabor this here; if you need a refresher, check out <<_git_basics_chapter>>. ////////////////////////// -아직 저장소에 코드가 하나도 없어서, GitHub은 Git 저장소를 만드는 방법이나 기존 Git 프로젝트를 넣는 방법을 보여준다. +아직 저장소에 코드가 하나도 없어서, GitHub는 Git 저장소를 만드는 방법이나 기존 Git 프로젝트를 넣는 방법을 보여준다. 이 내용을 다시 살펴보고 싶다면 <<_git_basics_chapter>>를 보라. 여기서 또 설명하지 않는다. ////////////////////////// @@ -207,7 +207,7 @@ $ curl http://github.com/tonychacon/fade/pull/1.patch | git am ////////////////////////// ===== Collaborating on the Pull Request ////////////////////////// -===== Pull Request로 함께 일하기. +===== Pull Request로 함께 일하기 ////////////////////////// As we covered in <<_github_flow>>, you can now have a conversation with the person who opened the Pull Request. @@ -269,14 +269,14 @@ If you're dealing with a *lot* of Pull Requests and don't want to add a bunch of This is a bit of an advanced trick and we'll go over the details of this a bit more in <<_refspec>>, but it can be pretty useful. ////////////////////////// 일일이 리모트를 등록하고 Pull 하는 것은 Pull Request를 많이 처리하는 사람에게는 고통스럽다. -GitHub은 이럴 때 사용하는 방법을 제공한다. 이 내용은 <<_refspec>>에서 자세히 설명할 거고 조금 어려울 수 있다. +GitHub는 이럴 때 사용하는 방법을 제공한다. 이 내용은 <<_refspec>>에서 자세히 설명할 거고 조금 어려울 수 있다. ////////////////////////// GitHub actually advertises the Pull Request branches for a repository as sort of pseudo-branches on the server. By default you don't get them when you clone, but they are there in an obscured way and you can access them pretty easily. ////////////////////////// -GitHub은 Pull Request의 브랜치를 서버에 있는 가상 브랜치로 노출해준다. -GitHub이 자동으로 해주기 때문에 바로 이용하면 된다. +GitHub는 Pull Request의 브랜치를 서버에 있는 가상 브랜치로 노출해준다. +GitHub가 자동으로 해주기 때문에 바로 이용하면 된다. ////////////////////////// To demonstrate this, we're going to use a low-level command (often referred to as a ``plumbing'' command, which we'll read about more in <<_plumbing_porcelain>>) called `ls-remote`. @@ -462,7 +462,7 @@ Here you can fairly easily specify to merge your new branch into another Pull Re ////////////////////////// GitHub also has a pretty nice notifications system built in that can come in handy when you have questions or need feedback from specific individuals or teams. ////////////////////////// -어떤 팀이나 사람에게 질문하거나 피드백을 받고 싶을 때 GitHub의 알림 시스템이 쉽고 편하다. +GitHub는 어떤 팀이나 사람에게 질문하거나 피드백을 받을 수 있도록 쉽고 편한 알림 시스템을 제공한다. ////////////////////////// In any comment you can start typing a `@` character and it will begin to autocomplete with the names and usernames of people who are collaborators or contributors in the project. @@ -528,7 +528,7 @@ image::images/maint-07-notifications.png[Notifiation center] ////////////////////////// The two choices are to get notifications over ``Email'' and over ``Web'' and you can choose either, niether or both for when you actively participate in things and for activity on repositories you are watching. ////////////////////////// -알림을 Email로 받을지 Web으로 받을지 선택할 수 있다. 물론 두 가지 방법을 동시에 사용해도 된다. 그리고 그냥 대화에 참여하는 경우와 프로젝트를 'Watching'하는 경우를 나누어 선택할 수 있다. +알림을 이메일로 받을지 웹으로 받을지 선택할 수 있다. 물론 두 가지 방법을 동시에 사용해도 된다. 그리고 그냥 대화에 참여하는 경우와 프로젝트를 'Watching' 하는 경우를 나누어 선택할 수 있다. ////////////////////////// ====== Web Notifications @@ -539,7 +539,7 @@ The two choices are to get notifications over ``Email'' and over ``Web'' and you Web notifications only exist on GitHub and you can only check them on GitHub. If you have this option selected in your preferences and a notification is triggered for you, you will see a small blue dot over your notifications icon at the top of your screen as seen in <<_not_center>>. ////////////////////////// -Web 알림은 GitHub에서 제공하는 것으로 GitHub 사이트에서만 확인할 수 있다. +웹 알림은 GitHub에서 제공하는 것으로 GitHub 사이트에서만 확인할 수 있다. 이 옵션을 선택하면 알림이 오면 알림 아이콘에 파란 점을 볼 수 있다. <<_not_center>>을 확인해보자. [[_not_center]] @@ -587,7 +587,7 @@ The emails will also be threaded properly, which is nice if you're using a threa ////////////////////////// There is also a fair amount of metadata embedded in the headers of the emails that GitHub sends you, which can be really helpful for setting up custom filters and rules. ////////////////////////// -GitHub이 보낸 이메일 헤더를 보면 여러 가지 메타데이터가 들어 있다. 그래서 사용자는 이메일 필터나 룰 같은 자동 관리 기능으로 쉽게 관리할 수 있다. +GitHub가 보낸 이메일 헤더를 보면 여러 가지 메타데이터가 들어 있다. 그래서 사용자는 이메일 필터나 룰 같은 자동 관리 기능으로 쉽게 관리할 수 있다. ////////////////////////// For instance, if we look at the actual email headers sent to Tony in the email shown in <<_email_pr>>, we will see the following among the information sent: @@ -636,7 +636,7 @@ It's also worth noting that if you have both email and web notifications enabled ////////////////////////// There are a couple of special files that GitHub will notice if they are present in your repository. ////////////////////////// -저장소에 있는 파일 중에서 GitHub이 사용하는 몇가지 특이한 파일들이 있다. +저장소에 있는 파일 중에서 GitHub가 사용하는 몇 가지 특이한 파일들이 있다. ==== README @@ -645,9 +645,9 @@ The first is the `README` file, which can be of nearly any format that GitHub re For example, it could be `README`, `README.md`, `README.asciidoc`, etc. If GitHub sees a README file in your source, it will render it on the landing page of the project. ////////////////////////// -GitHub은 저장소 랜딩 페이지를 보여줄 때 README 파일을 이용해서 보여준다. +GitHub는 저장소 랜딩 페이지를 보여줄 때 README 파일을 이용해서 보여준다. README 파일 형식에 상관없이 잘 보여준다. -`README` 파일이든 `README.md` 파일이든 `README.asciidoc` 파일이든 GitHub이 자동으로 렌더링해서 보여준다. +`README` 파일이든 `README.md` 파일이든 `README.asciidoc` 파일이든 GitHub가 자동으로 렌더링해서 보여준다. ////////////////////////// Many teams use this file to hold all the relevant project information for someone who might be new to the repository or project. @@ -665,14 +665,14 @@ This generally includes things like: ////////////////////////// * 무슨 프로젝트인지 * 설정하고 설치하는 방법 -* 사용법과 실행결과에 대한 예제 +* 사용법과 실행 결과에 대한 예제 * 프로젝트의 라이센스 * 기여하는 방법 ////////////////////////// Since GitHub will render this file, you can embed images or links in it for added ease of understanding. ////////////////////////// -GitHub은 README 파일을 렌더링하는 것이기 때문에 이미지나 외부 링크를 적어도 된다. +GitHub는 README 파일을 렌더링하는 것이기 때문에 이미지나 외부 링크를 적어도 된다. ==== CONTRIBUTING @@ -680,7 +680,7 @@ GitHub은 README 파일을 렌더링하는 것이기 때문에 이미지나 외 The other special file that GitHub recognizes is the `CONTRIBUTING` file. If you have a file named `CONTRIBUTING` with any file extension, GitHub will show <<_contrib_file>> when anyone starts opening a Pull Request. ////////////////////////// -GitHub은 CONTRIBUTING 파일도 인식한다. +GitHub는 CONTRIBUTING 파일도 인식한다. README와 마찬가지로 원하는 파일 형식을 사용하면 된다. Pull Request를 열 때 이 파일이 있으면 <<_contrib_file>>과 같이 링크를 보여준다. [[_contrib_file]] diff --git a/book/06-github/sections/5-scripting.asc b/book/06-github/sections/5-scripting.asc index 898e46f2..25711392 100644 --- a/book/06-github/sections/5-scripting.asc +++ b/book/06-github/sections/5-scripting.asc @@ -53,7 +53,7 @@ Most of them are for Continuous Integration services, bug and issue trackers, ch We'll walk through setting up a very simple one, the Email hook. If you choose ``email'' from the ``Add Service'' dropdown, you'll get a configuration screen like <<_service_config>>. ////////////////////////// -CI, 버그 트래커, 이슈 트래커, 채팅, 문서 시스템 등등과 연동하는 데 사용하는 서비스가 수십 개 준비돼 있다. +CI, 버그 트래커, 이슈 트래커, 채팅, 문서 시스템 등과 연동하는 데 사용하는 서비스가 수십 개 준비돼 있다. 여기서는 가장 단순한 Email 훅을 살펴본다. ``Add Service'' 메뉴에서 ``email''을 선택하면 <<_service_config>> 같은 설정 화면으로 이동한다. @@ -126,13 +126,13 @@ URL와 보안 키를 입력하고 ``Add webhook'' 버튼을 클릭한다. Let's see a small example of a web service you may set up to handle a web hook. We'll use the Ruby web framework Sinatra since it's fairly concise and you should be able to easily see what we're doing. ////////////////////////// -웹훅을 처리하는 간단한 웹서비스 예제를 하나 살펴보자. +웹훅을 처리하는 간단한 웹 서비스 예제를 하나 살펴보자. 이 웹서비스는 Ruby 웹 프레임워크인 Sinatra를 사용했다. 간략하기 때문에 무엇을 하는 웹 서비스인지 쉽게 이해할 수 있을 것이다. ////////////////////////// Let's say we want to get an email if a specific person pushes to a specific branch of our project modifying a specific file. We could fairly easily do that with code like this: ////////////////////////// -이메일을 보내는 서비스를 만들어 보자. 이 서비스는 누가 어느 브랜치에 어떤 파일을 Push 했는 지를 알려준다. +이메일을 보내는 서비스를 만들어 보자. 이 서비스는 누가 어느 브랜치에 어떤 파일을 Push 했는지를 알려준다. 이런 서비스는 매우 간단하게 만들 수 있다. [source,ruby] @@ -173,7 +173,7 @@ end Here we're taking the JSON payload that GitHub delivers us and looking up who pushed it, what branch they pushed to and what files were touched in all the commits that were pushed. Then we check that against our criteria and send an email if it matches. ////////////////////////// -GitHub은 누가 Push 했는지, 어느 브랜치에 Push 했는지, Push 한 커밋에서 어떤 파일을 수정했는지에 대한 정보를 JSON 페이로드에 담아서 보낸다. +GitHub는 누가 Push 했는지, 어느 브랜치에 Push 했는지, Push 한 커밋에서 어떤 파일을 수정했는지에 대한 정보를 JSON 페이로드에 담아서 보낸다. 여기서는 특정 조건을 검사해서 만족할 때만 이메일을 보낸다. ////////////////////////// @@ -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는 개발하고 테스트할 때 사용하는 개발자 콘솔도 제공한다. 이 콘솔은 혹을 설정한 페이지에 있다. 콘솔에서 해당 웹훅의 최근 히스토리 몇 개를 확인할 수 있다. 어떤 데이터가 전송됐는지 확인할 수 있다. 만약 전송에 성공했으면 요청과 응답의 바디와 헤더를 모두 확인할 수 있다. 이것으로 훅을 쉽게 테스트하고 디버깅할 수 있다. @@ -203,7 +203,7 @@ The other great feature of this is that you can redeliver any of the payloads to ////////////////////////// For more information on how to write webhooks and all the different event types you can listen for, go to the GitHub Developer documentation at https://developer.github.com/webhooks/ ////////////////////////// -어떤 이벤트가 있고 각각 어떻게 웹훅을 만드는지가 자세히 알고 싶다면 GitHub 개발 문서를 봐라: https://developer.github.com/webhooks/ +어떤 이벤트가 있고 각각 어떻게 웹훅을 만드는지가 자세히 알고 싶다면 GitHub 개발 문서를 참고하라. (https://developer.github.com/webhooks/) ////////////////////////// ==== The GitHub API @@ -222,7 +222,7 @@ GitHub has tons of API endpoints for doing nearly anything you can do on the web In this section we'll learn how to authenticate and connect to the API, how to comment on an issue and how to change the status of a Pull Request through the API. ////////////////////////// 이런 일을 위해서 GitHub API가 준비돼 있다. -GitHub이 제공하는 API Endpoint는 매우 많아서 웹 사이트에서 하는 웬만한 일은 자동화할 수 있다. +GitHub가 제공하는 API Endpoint는 매우 많아서 웹사이트에서 하는 웬만한 일은 자동화할 수 있다. 이 절에서는 인증하고 API에 연결하고, 이슈에 코멘트하고, Pull Request의 상태를 변경하는 법을 배운다. ////////////////////////// @@ -382,7 +382,7 @@ image::images/scripting-06-comment.png[API 코멘트] ////////////////////////// You can use the API to do just about anything you can do on the website -- creating and setting milestones, assigning people to Issues and Pull Requests, creating and changing labels, accessing commit data, creating new commits and branches, opening, closing or merging Pull Requests, creating and editing teams, commenting on lines of code in a Pull Request, searching the site and on and on. ////////////////////////// -웹사이트에서 할 수 있는 일은 전부 API로도 할 수 있다. 마일스톤을 만들고 설정하기, 사람들에게 이슈나 Pull Request를 할당하기, 레이블을 만들고 수정하기, 커밋 데이터 사용하기, 커밋을 하거나 브랜치 만들기, Pull Request를 만들고 닫고 Merge 하기, 팀을 만들고 수정하기, Pull Request 코드에 코멘트하기, 사이트에서 검색하기 등등 다 된다. +웹사이트에서 할 수 있는 일은 전부 API로도 할 수 있다. 마일스톤을 만들고 설정하기, 사람들에게 이슈나 Pull Request를 할당하기, 레이블을 만들고 수정하기, 커밋 데이터 사용하기, 커밋을 하거나 브랜치 만들기, Pull Request를 만들고 닫고 Merge 하기, 팀을 만들고 수정하기, Pull Request 코드에 코멘트하기, 사이트에서 검색하기 등 다 된다. ////////////////////////// ==== Changing the Status of a Pull Request @@ -406,7 +406,7 @@ You could also use this to check if the commit message is properly formatted, if ////////////////////////// Let's say you set up a webhook on your repository that hits a small web service that checks for a `Signed-off-by` string in the commit message. ////////////////////////// -커밋 메시지에 `Signed-off-by`라는 스트링이 있는지 검사하는 웹 서비스를 만들어 보자. 먼저 저장소에 이 웹서비스를 호출하는 웹훅을 등록한다. +커밋 메시지에 `Signed-off-by`라는 스트링이 있는지 검사하는 웹 서비스를 만들어 보자. 먼저 저장소에 이 웹 서비스를 호출하는 웹훅을 등록한다. [source,ruby] ---- @@ -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의 워크플로를 최적화할 수 있다. +이 도구로 프로젝트가 요구하는 대로 GitHub의 워크플로를 최적화할 수 있다. 전체 API에 대한 구체적인 문서와 상황별 가이드는 https://developer.github.com[]에서 확인해야 한다. diff --git a/book/07-git-tools/sections/advanced-merging.asc b/book/07-git-tools/sections/advanced-merging.asc index 699479c6..3865bff8 100644 --- a/book/07-git-tools/sections/advanced-merging.asc +++ b/book/07-git-tools/sections/advanced-merging.asc @@ -18,7 +18,7 @@ Therefore, if you wait too long to merge two branches that diverge quickly, you /////////////////// 하지만, 가끔 까다로운 충돌도 발생한다. 다른 버전 관리 시스템과 달리 Git은 충돌이 나면 모호한 상황까지 해결하려 들지 않는다. -Git의 철학은 Merge가 잘될지 아닐지 판단하는 것을 잘 하자이다. 충돌이 나도 자동으로 해결하려고 노력하지 않는다. +Git의 철학은 Merge가 잘될지 아닐지 판단하는 것을 잘하자이다. 충돌이 나도 자동으로 해결하려고 노력하지 않는다. 오랫동안 따로 유지한 두 브랜치를 Merge 하려면 몇 가지 해야 할 일이 있다. /////////////////// @@ -35,7 +35,7 @@ We'll also cover some of the different, non-standard types of merges you can do, /////////////////// While we covered some basics on resolving merge conflicts in <<_basic_merge_conflicts>>, for more complex conflicts, Git provides a few tools to help you figure out what's going on and how to better deal with the conflict. /////////////////// -<<_basic_merge_conflicts>>에서 기초적인 Merge 충돌 해결에 대해서 다뤘다. Git은 복잡한 Merge 충돌이 났을 때 필요한 도구도 가지고 있다. 무슨 일이 일어 났고 어떻게 해결하는 게 나은지 알 수 있다. +<<_basic_merge_conflicts>>에서 기초적인 Merge 충돌 해결에 대해서 다뤘다. Git은 복잡한 Merge 충돌이 났을 때 필요한 도구도 가지고 있다. 무슨 일이 일어났고 어떻게 해결하는 게 나은지 알 수 있다. /////////////////// First of all, if at all possible, try to make sure your working directory is clean before doing a merge that may have conflicts. diff --git a/book/07-git-tools/sections/revision-selection.asc b/book/07-git-tools/sections/revision-selection.asc index c3a84947..b656536f 100644 --- a/book/07-git-tools/sections/revision-selection.asc +++ b/book/07-git-tools/sections/revision-selection.asc @@ -95,7 +95,7 @@ Generally, eight to ten characters are more than enough to be unique within a pr ////////////////////////// As an example, the Linux kernel, which is a pretty large project with over 450k commits and 3.6 million objects, has no two objects whose SHA-1s overlap more than the first 11 characters. ////////////////////////// -꽤 큰 프로젝트인 Linux 커널은 45만 개 이상의 커밋, 360만 개 이상의 오브젝트가 있다. Linux 커널 프로젝트는 해시 값 11개만 사용해도 충돌이 없다. +꽤 큰 프로젝트인 리눅스 커널은 45만 개 이상의 커밋, 360만 개 이상의 오브젝트가 있다. 리눅스 커널 프로젝트는 해시 값 11개만 사용해도 충돌이 없다. [NOTE] ////////////////////////// @@ -130,13 +130,13 @@ Git을 쓰는 사람들은 가능성이 작긴 하지만 언젠가 SHA-1 값이 그러나 해시 값이 중복되는 일은 일어나기 어렵다. SHA-1 값의 크기는 20 바이트(160비트)이다. -해시 값이 중복될 확률이 50%가 되는 데 필요한 개체의 수는 `2^80^`이다. -이 수는 1자 2000해 -('자'는 '경'의 '억'배 - `10^24^`, 충돌 확률을 구하는 공식은 `p=(n(n-1)/2) * (1/2^160)` )이다. -즉, 지구에 존재하는 모래알의 수에 1200을 곱한 수와 맞먹는다. +해시 값이 중복될 확률이 50%가 되는 데 필요한 개체의 수는 2^80^이다. +이 수는 1자 2,000해 +('자'는 '경'의 '억'배 - 10^24^, 충돌 확률을 구하는 공식은 `p = (n(n-1)/2) * (1/2^160)` )이다. +즉, 지구에 존재하는 모래알의 수에 1,200을 곱한 수와 맞먹는다. 아직도 SHA-1 해시 값이 중복될까 봐 걱정하는 사람들을 위해 좀 더 덧붙이겠다. -지구에서 약 6억 5천만 명의 인구가 개발하고 각자 매초 Linux 커널 히스토리 전체와(360만 개) 맞먹는 개체를 쏟아 내고 바로 Push 한다고 가정하자. 이런 상황에서 해시 값의 충돌 날 확률이 50%가 되기까지는 약 2년이 걸린다. +지구에서 약 6억 5천만 명의 인구가 개발하고 각자 매초 리눅스 커널 히스토리 전체와(360만 개) 맞먹는 개체를 쏟아 내고 바로 Push 한다고 가정하자. 이런 상황에서 해시 값의 충돌 날 확률이 50%가 되기까지는 약 2년이 걸린다. 그냥 어느 날 동료가 한순간에 모두 늑대에게 물려 죽을 확률이 훨씬 더 높다. ==== From a1903a3e368b4f6f7e38ad699cb543051bc352b0 Mon Sep 17 00:00:00 2001 From: "Yoon, Hyunho" Date: Mon, 7 Mar 2016 21:02:28 +0900 Subject: [PATCH 3/3] modify previous translation MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - `Linux`, `Apache` 등 고유명사는 원어 사용 - `작업 디렉토리`는 `워킹 디렉토리`로 복구 - 기타 @pismute님의 제안 사항 적용 --- book/04-git-server/sections/git-on-a-server.asc | 4 ++-- book/04-git-server/sections/gitlab.asc | 2 +- book/04-git-server/sections/gitweb.asc | 8 ++++---- book/04-git-server/sections/setting-up-server.asc | 2 +- book/04-git-server/sections/smart-http.asc | 14 +++++++------- book/05-distributed-git/sections/contributing.asc | 4 ++-- book/05-distributed-git/sections/maintaining.asc | 2 +- book/06-github/sections/2-contributing.asc | 2 +- book/07-git-tools/sections/advanced-merging.asc | 2 +- book/07-git-tools/sections/revision-selection.asc | 4 ++-- 10 files changed, 22 insertions(+), 22 deletions(-) diff --git a/book/04-git-server/sections/git-on-a-server.asc b/book/04-git-server/sections/git-on-a-server.asc index 71b787ad..4f06975d 100644 --- a/book/04-git-server/sections/git-on-a-server.asc +++ b/book/04-git-server/sections/git-on-a-server.asc @@ -28,7 +28,7 @@ In order to clone your repository to create a new bare repository, you run the c By convention, bare repository directories end in `.git`, like so: ////////////////////////// 어떤 서버를 설치하더라도 일단 저장소를 Bare 저장소로 만들어야 한다. -다시 말하지만, Bare 저장소는 작업 디렉토리가 없는 저장소이다. +다시 말하지만, Bare 저장소는 워킹 디렉토리가 없는 저장소이다. `--bare` 옵션을 주고 Clone 하면 새로운 Bare 저장소가 만들어진다. Bare 저장소 디렉토리는 관례에 따라 .git 확장자로 끝난다. @@ -59,7 +59,7 @@ There are a couple of minor differences in the configuration file; but for your It takes the Git repository by itself, without a working directory, and creates a directory specifically for it alone. ////////////////////////// 물론 설정상의 미세한 차이가 있지만, 저장소의 내용만 고려한다면 같다고 볼 수 있다. -작업 디렉토리가 없는 Git 저장소인 데다가 별도의 디렉토리도 하나 만들었다는 점에서는 같다. +워킹 디렉토리가 없는 Git 저장소인 데다가 별도의 디렉토리도 하나 만들었다는 점에서는 같다. [[_bare_repo]] ////////////////////////// diff --git a/book/04-git-server/sections/gitlab.asc b/book/04-git-server/sections/gitlab.asc index c2137dff..20e465fa 100644 --- a/book/04-git-server/sections/gitlab.asc +++ b/book/04-git-server/sections/gitlab.asc @@ -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로 서버에 접속할 일이 별로 없다는 것이다. 대부분 관리는 웹 브라우저로 가능하다. diff --git a/book/04-git-server/sections/gitweb.asc b/book/04-git-server/sections/gitweb.asc index 4d3698b1..0354c230 100644 --- a/book/04-git-server/sections/gitweb.asc +++ b/book/04-git-server/sections/gitweb.asc @@ -16,8 +16,8 @@ Git은 웹에서 저장소를 조회할 수 있는 GitWeb이라는 CGI 스크립 .The GitWeb web-based user interface. image::images/git-instaweb.png[The GitWeb web-based user interface.] ////////////////////////// -.Git 웹 기반 UI, GitWeb -image::images/git-instaweb.png[Git 웹 기반 UI] +.Git 웹용 UI, GitWeb +image::images/git-instaweb.png[Git 웹용 UI] ////////////////////////// If you want to check out what GitWeb would look like for your project, Git comes with a command to fire up a temporary instance if you have a lightweight server on your system like `lighttpd` or `webrick`. @@ -26,7 +26,7 @@ If you're running a Mac, Leopard comes preinstalled with Ruby, so `webrick` may 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`를 많이 사용한다. `lighttpd`가 설치되어 있으면 프로젝트 디렉토리에서 그냥 `git instaweb`을 실행하면 바로 실행될 것이다. +Linux에서는 `lighttpd`를 많이 사용한다. `lighttpd`가 설치돼 있으면 프로젝트 디렉토리에서 그냥 `git instaweb`을 실행하면 바로 실행될 것이다. Mac의 Leopard 버전은 Ruby가 미리 설치돼 있기 때문에 `webrick`이 더 나은 선택이다. 사용할 웹 서버가 `lighttpd`가 아니라면 아래와 같이 `--httpd` 옵션을 사용해야 한다.(((git commands, instaweb))) @@ -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 저장소의 위치를 알려준다. -이제 아파치가 이 스크립트를 사용하도록 VirtualHost 항목에 설정한다. +이제 Apache가 이 스크립트를 사용하도록 VirtualHost 항목에 설정한다. [source,console] ---- diff --git a/book/04-git-server/sections/setting-up-server.asc b/book/04-git-server/sections/setting-up-server.asc index 91a18f17..5e2b26b3 100644 --- a/book/04-git-server/sections/setting-up-server.asc +++ b/book/04-git-server/sections/setting-up-server.asc @@ -59,7 +59,7 @@ $ cat /tmp/id_rsa.jessica.pub >> ~/.ssh/authorized_keys ////////////////////////// Now, you can set up an empty repository for them by running `git init` with the `--bare` option, which initializes the repository without a working directory:(((git commands, init, bare))) ////////////////////////// -`--bare` 옵션을 주고 `git init`를 실행해서 작업 디렉토리가 없는 빈 저장소를 하나 만든다.(((git commands, init, bare))) +`--bare` 옵션을 주고 `git init`를 실행해서 워킹 디렉토리가 없는 빈 저장소를 하나 만든다.(((git commands, init, bare))) [source,console] ---- diff --git a/book/04-git-server/sections/smart-http.asc b/book/04-git-server/sections/smart-http.asc index c9a736f8..aea40bc8 100644 --- a/book/04-git-server/sections/smart-http.asc +++ b/book/04-git-server/sections/smart-http.asc @@ -20,7 +20,7 @@ Let's walk though a very basic setup. We'll set this up with Apache as the CGI server. If you don't have Apache setup, you can do so on a Linux box with something like this:(((Apache))) ////////////////////////// -이제 설정해보자. CGI 서버로 아파치를 사용한다. 아파치가 없다면 Linux에서는 아래와 같이 아파치를 설치할 수 있다(((Apache))). +이제 설정해보자. CGI 서버로 Apache를 사용한다. Apache가 없다면 Linux에서는 아래와 같이 Apache를 설치할 수 있다(((Apache))). [source,console] ---- @@ -36,7 +36,7 @@ This also enables the `mod_cgi`, `mod_alias`, `mod_env`, and `mod_rewrite` modul ////////////////////////// You’ll also need to set the Unix user group of the `/opt/git` directories to `www-data` so your web server can read- and write-access the repositories, because the Apache instance running the CGI script will (by default) be running as that user: ////////////////////////// -`/opt/git` 디렉토리의 Unix 사용자 그룹도 `www-data`로 설정해야 한다. 그래야 웹 서버가 저장소를 읽고 쓸 수 있다. 아파치 인스턴스는 CGI 스크립트를 이 사용자로 실행시킨다(기본 설정이다). +`/opt/git` 디렉토리의 Unix 사용자 그룹도 `www-data`로 설정해야 한다. 그래야 웹 서버가 저장소를 읽고 쓸 수 있다. Apache 인스턴스는 CGI 스크립트를 이 사용자로 실행시킨다(기본 설정이다). [source,console] ---- @@ -46,7 +46,7 @@ $ chgrp -R www-data /opt/git ////////////////////////// Next we need to add some things to the Apache configuration to run the `git http-backend` as the handler for anything coming into the `/git` path of your web server. ////////////////////////// -그리고 아파치 설정 파일을 수정한다. 그러면 `git http-backend`를 실행했을 때 모든 요청을 `/git` 경로로 받을 수 있다. +그리고 Apache 설정 파일을 수정한다. 그러면 `git http-backend`를 실행했을 때 모든 요청을 `/git` 경로로 받을 수 있다. [source,console] ---- @@ -63,7 +63,7 @@ If you leave out `GIT_HTTP_EXPORT_ALL` environment variable, then Git will only ////////////////////////// Finally you'll want to tell Apache to allow requests to `git-http-backend` and make writes be authenticated somehow, possibly with an Auth block like this: ////////////////////////// -마지막으로 아파치가 `git-http-backend`에 요청하는 것을 허용하고 쓰기 접근 시 인증하게 한다. +마지막으로 Apache가 `git-http-backend`에 요청하는 것을 허용하고 쓰기 접근 시 인증하게 한다. [source,console] ---- @@ -100,7 +100,7 @@ There are tons of ways to have Apache authenticate users, you'll have to choose This is just the simplest example we could come up with. You'll also almost certainly want to set this up over SSL so all this data is encrypted. ////////////////////////// -아파치에는 사용자 인증 방법이 많다. +Apache에는 사용자 인증 방법이 많다. 그중 하나를 골라 사용해야 하는데 위에 설명한 방법이 가장 간단한 방법의 하나다. 그리고 이렇게 사용자 인증 설정을 할 때는 보안을 위해 SSL로 접속해 작업하는 것이 좋다. @@ -110,7 +110,7 @@ The idea is that Git comes with a CGI called `git http-backend` that when invoke It does not implement any authentication itself, but that can easily be controlled at the layer of the web server that invokes it. You can do this with nearly any CGI-capable web server, so go with the one that you know best. ////////////////////////// -웹 서버는 아파치 말고도 다른 서버를 사용할 수도 있고, 인증 방식도 다르므로 아파치 설정에 대해서 길게 이야기하지 않는다. +웹 서버는 Apache 말고도 다른 서버를 사용할 수도 있고, 인증 방식도 다르므로 Apache 설정에 대해서 길게 이야기하지 않는다. 대신 이것만 알아두었으면 한다. HTTP를 이용한 모든 통신에서는 `git http-backend`와 Git을 함께 사용한다는 것이다. Git 그 자체로는 인증 기능을 가지고 있지 않다. 하지만 웹 서버의 인증 레이어와 손쉽게 연동할 수 있다. CGI를 실행할 수 있는 웹 서버라면 어떤 서버든지 붙일 수 있다. 가장 좋아하는 서버를 사용하길 바란다. @@ -122,5 +122,5 @@ For more information on configuring authentication in Apache, check out the Apac ==== ////////////////////////// ==== -아파치 웹 서버에서 인증 설정에 대해 더 자세히 알아보려면 아파치 문서를 참고하길 바란다.(http://httpd.apache.org/docs/current/howto/auth.html[]) +Apache 웹 서버에서 인증 설정에 대해 더 자세히 알아보려면 Apache 문서를 참고하길 바란다.(http://httpd.apache.org/docs/current/howto/auth.html[]) ==== diff --git a/book/05-distributed-git/sections/contributing.asc b/book/05-distributed-git/sections/contributing.asc index 18285474..e933ba02 100644 --- a/book/05-distributed-git/sections/contributing.asc +++ b/book/05-distributed-git/sections/contributing.asc @@ -130,7 +130,7 @@ Here is a template originally written by Tim Pope: ////////////////////////// 마지막으로 명심해야 할 점은 커밋 메시지 자체다. 좋은 커밋 메시지를 작성하는 습관은 Git을 사용하는 데 도움이 많이 된다. -일반적으로 커밋 메시지를 작성할 때 사용하는 규칙이 있다. 메시지의 첫 라인에 50자가 넘지 않는 아주 간략한 메시지를 적어 해당 커밋을 요약한다. 다음 한 라인은 비우고 그 다음 라인부터 커밋을 자세히 설명한다. +일반적으로 커밋 메시지를 작성할 때 사용하는 규칙이 있다. 메시지의 첫 라인에 50자가 넘지 않는 아주 간략한 메시지를 적어 해당 커밋을 요약한다. 다음 한 라인은 비우고 그다음 라인부터 커밋을 자세히 설명한다. 예를 들어 Git 개발 프로젝트에서는 개발 동기와 구현 상황의 제약 조건이나 상황 등을 자세하게 요구한다. 이런 점은 따를 만한 좋은 가이드라인이다. 그리고 현재형 표현을 사용하는 것이 좋다. 명령문으로 시작하는 것도 좋은 방법이다. @@ -1117,7 +1117,7 @@ You can also edit these patch files to add more information for the email list t If you add text between the `---` line and the beginning of the patch (the `diff --git` line), then developers can read it; but applying the patch excludes it. ////////////////////////// 메일링리스트에 이메일을 보내기 전에 각 Patch 파일을 손으로 고칠 수 있다. -`---` 라인과 Patch가 시작되는 라인(`diff --git`로 시작하는 라인) 사이에 내용을 추가하면 다른 개발자들은 읽을 수 있지만, 나중에 Patch에 적용되지는 않는다. +`---` 라인과 Patch가 시작되는 라인(`diff --git`로 시작하는 라인) 사이에 내용을 추가하면 다른 개발자는 읽을 수 있지만, 나중에 Patch에 적용되지는 않는다. ////////////////////////// To email this to a mailing list, you can either paste the file into your email program or send it via a command-line program. diff --git a/book/05-distributed-git/sections/maintaining.asc b/book/05-distributed-git/sections/maintaining.asc index 054d2a7b..b076ffd2 100644 --- a/book/05-distributed-git/sections/maintaining.asc +++ b/book/05-distributed-git/sections/maintaining.asc @@ -849,7 +849,7 @@ For instance, the Linux kernel recently jumped from 8 to 10 characters to ensure ////////////////////////// `git describe` 명령은 `-a`나 `-s` 옵션을 주고 만든 Annotated 태그가 필요하다. 릴리즈 태그는 `git describe` 명령으로 만드니까 꼭 이름이 적당한지 사전에 확인해야 한다. 그리고 이 값은 checkout이나 show 명령에도 사용할 수 있지만, 전적으로 이름 뒤에 붙은 SHA-1 값을 사용한다. 그래서 이 값으로는 해당 커밋을 못 찾을 수도 있다. -최근 리눅스 커널은 충돌 때문에 축약된 SHA-1가 8자에서 10자로 늘어났다. 이제는 8자일 때 생성한 값은 사용할 수 없다. +최근 Linux 커널은 충돌 때문에 축약된 SHA-1가 8자에서 10자로 늘어났다. 이제는 8자일 때 생성한 값은 사용할 수 없다. [[_preparing_release]] ////////////////////////// diff --git a/book/06-github/sections/2-contributing.asc b/book/06-github/sections/2-contributing.asc index 4879170d..c1f6b93b 100644 --- a/book/06-github/sections/2-contributing.asc +++ b/book/06-github/sections/2-contributing.asc @@ -255,7 +255,7 @@ Pull Request는 보통 공개 프로젝트에서 사용한다. 기여자는 수 ////////////////////////// At this point, the project owner can look at the suggested change and merge it, reject it or comment on it. Let's say that he likes the idea, but would prefer a slightly longer time for the light to be off than on. ////////////////////////// -Pull Request가 오면 프로젝트 소유자는 변경점이 무엇인지 확인한 후, Merge 혹은 거절하거나 코멘트를 달 수 있다. 소유자가 아이디어 자체를 마음에 들어 한다면 빛을 보기까지 좀 더 공을 들여야 한다. +Pull Request가 오면 프로젝트 소유자는 변경 점이 무엇인지 확인한 후, Merge 혹은 거절하거나 코멘트를 달 수 있다. 소유자가 아이디어 자체를 마음에 들어 한다면 빛을 보기까지 좀 더 공을 들여야 한다. ////////////////////////// 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. diff --git a/book/07-git-tools/sections/advanced-merging.asc b/book/07-git-tools/sections/advanced-merging.asc index 3865bff8..00d7b6aa 100644 --- a/book/07-git-tools/sections/advanced-merging.asc +++ b/book/07-git-tools/sections/advanced-merging.asc @@ -18,7 +18,7 @@ Therefore, if you wait too long to merge two branches that diverge quickly, you /////////////////// 하지만, 가끔 까다로운 충돌도 발생한다. 다른 버전 관리 시스템과 달리 Git은 충돌이 나면 모호한 상황까지 해결하려 들지 않는다. -Git의 철학은 Merge가 잘될지 아닐지 판단하는 것을 잘하자이다. 충돌이 나도 자동으로 해결하려고 노력하지 않는다. +Git의 철학은 Merge가 잘될지 아닐지 판단하는 것을 잘 하자이다. 충돌이 나도 자동으로 해결하려고 노력하지 않는다. 오랫동안 따로 유지한 두 브랜치를 Merge 하려면 몇 가지 해야 할 일이 있다. /////////////////// diff --git a/book/07-git-tools/sections/revision-selection.asc b/book/07-git-tools/sections/revision-selection.asc index b656536f..ea851ce1 100644 --- a/book/07-git-tools/sections/revision-selection.asc +++ b/book/07-git-tools/sections/revision-selection.asc @@ -95,7 +95,7 @@ Generally, eight to ten characters are more than enough to be unique within a pr ////////////////////////// As an example, the Linux kernel, which is a pretty large project with over 450k commits and 3.6 million objects, has no two objects whose SHA-1s overlap more than the first 11 characters. ////////////////////////// -꽤 큰 프로젝트인 리눅스 커널은 45만 개 이상의 커밋, 360만 개 이상의 오브젝트가 있다. 리눅스 커널 프로젝트는 해시 값 11개만 사용해도 충돌이 없다. +꽤 큰 프로젝트인 Linux 커널은 45만 개 이상의 커밋, 360만 개 이상의 오브젝트가 있다. Linux 커널 프로젝트는 해시 값 11개만 사용해도 충돌이 없다. [NOTE] ////////////////////////// @@ -136,7 +136,7 @@ SHA-1 값의 크기는 20 바이트(160비트)이다. 즉, 지구에 존재하는 모래알의 수에 1,200을 곱한 수와 맞먹는다. 아직도 SHA-1 해시 값이 중복될까 봐 걱정하는 사람들을 위해 좀 더 덧붙이겠다. -지구에서 약 6억 5천만 명의 인구가 개발하고 각자 매초 리눅스 커널 히스토리 전체와(360만 개) 맞먹는 개체를 쏟아 내고 바로 Push 한다고 가정하자. 이런 상황에서 해시 값의 충돌 날 확률이 50%가 되기까지는 약 2년이 걸린다. +지구에서 약 6억 5천만 명의 인구가 개발하고 각자 매초 Linux 커널 히스토리 전체와(360만 개) 맞먹는 개체를 쏟아 내고 바로 Push 한다고 가정하자. 이런 상황에서 해시 값의 충돌 날 확률이 50%가 되기까지는 약 2년이 걸린다. 그냥 어느 날 동료가 한순간에 모두 늑대에게 물려 죽을 확률이 훨씬 더 높다. ====