Skip to content

#40 and review (chapter 6) #44

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
pismute merged 3 commits into from
Jul 26, 2015
Merged

#40 and review (chapter 6) #44

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
1781b1b
chapter 6: fix and update some translation
soursop Jul 21, 2015
bd9a0b8
chapter 6: fix and update some translation
Jul 19, 2015
e61064f
chapter 6: Review soursop's update
lethee Jul 22, 2015
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 3 additions & 3 deletions book/06-github/sections/1-setting-up-account.asc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -163,7 +163,7 @@ image::images/email-settings.png[이메일 주소를 전부 추가하기.]
//////////////////////////
In <<_add_email_addresses>> we can see some of the different states that are possible. The top address is verified and set as the primary address, meaning that is where you'll get any notifications and receipts. The second address is verified and so can be set as the primary if you wish to switch them. The final address is unverified, meaning that you can't make it your primary address. If GitHub sees any of these in commit messages in any repository on the site, it will be linked to your user now.
//////////////////////////
<<_add_email_addresses>>의 이메일 주소는 각각 다른 상태다. 첫 번째 주소는 주(Primary) 주소고 이미 확인됐다. 알림이나 영수증 메일은 주 주소로 간다. 두 번째 주소는 확인한 상태라서 주 주소로 바꿀 수 있는 상태다. 마지막 주소는 아직 확인되지 않아 주 주소로 변경할 수 없다. GitHub은 저장소의 커밋 메시지에 이 주소 세 개 중의 하나가 있으면 해당 사용자 계정 페이지로 링크를 걸어준다.
<<_add_email_addresses>>의 이메일 주소는 각각 다른 상태다. 첫 번째 주소는 이미 확인을 한 주(Primary) 주소이다. 알림이나 영수증 메일은 주 주소로 간다. 두 번째 주소도 확인한 주소로 주 주소로 변경 할 수 있는 상태다. 마지막 주소는 아직 확인이 안되어 주 주소로 변경할 수 없다. 저장소의 커밋 메시지에 이 주소 세 개 중 하나라도 있으면 GitHub가 해당 사용자 계정 페이지로 링크를 걸어준다.

//////////////////////////
==== Two Factor Authentication
Expand All @@ -173,12 +173,12 @@ In <<_add_email_addresses>> we can see some of the different states that are pos
//////////////////////////
Finally, for extra security, you should definitely set up Two-factor Authentication or ``2FA''. Two-factor Authentication is an authentication mechanism that is becoming more and more popular recently to mitigate the risk of your account being compromised if your password is stolen somehow. Turning it on will make GitHub ask you for two different methods of authentication, so that if one of them is compromised, an attacker will not be able to access your account.
//////////////////////////
더 안전한 보안을 위해서 ``2FA''(2 팩터 인증)을 설정한다. 2FA는 최근 들어 인기가 높아지는 인증 메커니즘이다. 암호를 도둑맞았을 때 위험을 완화하기 위해 사용한다. 2FA를 켜면 GitHub은 두 가지 방법으로 인증받도록 요구한다. 둘 중 한 가지 방법만 뚫려서는 공격자가 계정에 접근할 수 없다.
더 안전한 보안을 위해서 ``2FA''(2 팩터 인증)을 설정한다. 2FA는 최근 들어 인기가 높아지는 인증 메커니즘이다. 암호를 도둑맞았을 때 위험을 완화하기 위해 사용한다. 2FA를 활성화 시키면 GitHub에 로그인 할 때 인증수단이 두 가지 필요하다(역주 - 기존 로그인 방식에 OTP나 SMS를 추가). 둘 중 한 가지 방법만 뚫려서는 공격자가 계정에 접근할 수 없다.

//////////////////////////
You can find the Two-factor Authentication setup under the Security tab of your Account settings.
//////////////////////////
2FA 설정 화면은 계정 설정 페이지의 Security tab에 있다.
2FA 설정 화면은 계정 설정 페이지의 Security 탭에 있다.

//////////////////////////
.2FA in the Security Tab
Expand Down
28 changes: 14 additions & 14 deletions book/06-github/sections/2-contributing.asc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -72,7 +72,7 @@ This flow works whether you're collaborating with a tightly-knit team in a singl
It is centered on the <<_topic_branch>> workflow covered in <<_git_branching>>.
//////////////////////////
GitHub은 Pull Request가 중심인 협업 Workflow를 위주로 설계됐다.
이 Workflow는 Fork 해서 프로젝트에 기여하는 것인데 단일 저장소를 사용하는 긴밀한 팀에서도 유용하고 전 세계에서 흩어져서 일하는 회사나 한 번도 본 적 없는 사람들 사이에서도 유용하다.
이 Workflow는 Fork 해서 프로젝트에 기여하는 것인데 단일 저장소만 사용하는 작은 팀이나 전 세계에서 흩어져서 일하는 회사, 혹은 한 번도 본 적 없는 사람들 사이에서도 유용하다.
<<_git_branching>> 에서 설명했던 <<_topic_branch>> 중심으로 일하는 방식이다.

//////////////////////////
Expand Down Expand Up @@ -245,12 +245,12 @@ 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.
//////////////////////////
이런 소통을 이메일로 하는 Workflow는 <<_distributed_git>>에 설명했었다. GitHub에서는 온라인에서 한다. 프로젝트 소유자는 'unified diff' 형식의 변경사항을 검토하고 즉각 해당 라인에 코멘트을 달 수 있다.
이런 소통을 이메일로 하는 Workflow는 <<_distributed_git>>에 설명했었다. GitHub에서는 온라인에서 한다. 프로젝트 소유자는 'unified diff' 형식의 변경사항을 검토하고 즉각 해당 라인에 코멘트를 달 수 있다.

//////////////////////////
.Comment on a specific line of code in a Pull Request
Expand All @@ -262,20 +262,20 @@ image::images/blink-04-pr-comment.png[PR 라인 코멘트]
//////////////////////////
Once the maintainer makes this comment, the person who opened the Pull Request (and indeed, anyone else watching the repository) will get a notification. We'll go over customizing this later, but if he had email notifications turned on, Tony would get an email like this:
//////////////////////////
관리자가 코멘트을 달면 Pull Request를 만든 사람에게 알림이 간다. 실제로는 저장소를 'Watch'하는 사람 모두에게 알림이 간다. 알림 정책은 설정할 수 있지만, 다음에 검토한다. 알림을 받는 Tony가 이메일 알림을 켜놨다면 이메일 알림도 받는다.
관리자가 코멘트를 달면 Pull Request를 만든 사람에게 알림이 간다. 실제로는 저장소를 'Watch'하는 사람 모두에게 알림이 간다. 알림 정책은 설정할 수 있지만, 다음에 검토한다. 알림을 받는 Tony가 이메일 알림을 켜놨다면 이메일 알림도 받는다.

[[_email_notification]]
//////////////////////////
.Comments sent as email notifications
image::images/blink-04-email.png[Email notification]
//////////////////////////
.코멘트이 이메일 알림으로 온다.
.코멘트가 이메일 알림으로 온다.
image::images/blink-04-email.png[이메일 알림]

//////////////////////////
Anyone can also leave general comments on the Pull Request. In <<_pr_discussion>> we can see an example of the project owner both commenting on a line of code and then leaving a general comment in the discussion section. You can see that the code comments are brought into the conversation as well.
//////////////////////////
누구나 Pull Request에 코멘트을 달 수 있다. <<_pr_discussion>>은 보면 프로젝트 소유자가 코드 코멘트과 일반 코멘트을 달면서 토론하는 것을 보여 준다. 코드 코멘트로 대화의 맥락을 이끌어 간다는 것을 볼 수 있다.
누구나 Pull Request에 코멘트를 달 수 있다. <<_pr_discussion>>를 보면 프로젝트 소유자가 코드에 코멘트를 달거나 Pull Request 자체에 코멘트를 달면서 토론하는 것을 보여 준다. 코드 코멘트도 맥락을 이루어 커뮤니케이션 할 수 있다.

[[_pr_discussion]]
//////////////////////////
Expand All @@ -293,7 +293,7 @@ Now the contributor can see what they need to do in order to get their change ac
//////////////////////////
If the contributor does that then the project owner will get notified again and when they visit the page they will see that it's been addressed. In fact, since a line of code changed that had a comment on it, GitHub notices that and collapses the outdated diff.
//////////////////////////
기여자가 Push 하면 프로젝트 소유자에게 다시 알림이 간다. 다시 토론 페이지에 가면 해당 내용을 알 수 있다. 코멘트이 달린 코드를 수정했기 때문에 Github은 이점을 보여주고 때 지난 diff는 숨긴다.
기여자가 Push 하면 프로젝트 소유자에게 다시 알림이 간다. 다시 토론 페이지에 가면 해당 내용을 알 수 있다. 코멘트가 달린 코드를 수정했기 때문에 Github은 이점을 보여주고 때 지난 diff는 숨긴다.

[[_pr_final]]
//////////////////////////
Expand Down Expand Up @@ -491,7 +491,7 @@ Your next question may be ``How to I reference the old Pull Request?''. It turns
//////////////////////////
Let's start with how to cross-reference another Pull Request or an Issue. All Pull Requests and Issues are assigned numbers and they are unique within the project. For example, you can't have Pull Request #3 _and_ Issue #3. If you want to reference any Pull Request or Issue from any other one, you can simply put `#<num>` in any comment or description. You can also be more specific if the Issue or Pull request lives somewhere else; write `username#<num>` if you're referring to an Issue or Pull Request in a fork of the repository you're in, or `username/repo#<num>` to reference something in another repository.
//////////////////////////
먼저 Issue와 Pull Request를 서로 참조시키는 방법부터 살펴보자. 모든 Pull Request와 Issue에는 번호가 할당되며 프로젝트 내에서는 유일하다. 예를 들어, #3인 Pull Request와 #3인 Issue는 동시에 있을 수 없다. `#<num>`과 같은 형태로 코멘트이나 설명에 Pull Request와 Issue를 참조시킬 수 있다. 이 방법은 한 프로젝트 내에서만 가능하다. Fork 저장소의 Issue나 Pull Request를 참조시키려고 한다면 `username#<num>`라고 쓰고 아예 다른 저장소면 `username/repo#<num>`라고 써야 한다.
먼저 Issue와 Pull Request를 서로 참조시키는 방법부터 살펴보자. 모든 Pull Request와 Issue에는 프로젝트 내에서 유일한 번호를 하나 할당한다. 예를 들어, #3인 Pull Request와 #3인 Issue는 동시에 있을 수 없다. `#<num>`과 같은 형태로 코멘트가나 설명에 Pull Request와 Issue를 참조시킬 수 있다. 이 방법은 단일 프로젝트 범위에서만 유효하다. Fork 저장소의 Issue나 Pull Request를 참조시키려고 한다면 `username#<num>`라고 쓰고 아예 다른 저장소면 `username/repo#<num>`라고 써야 한다.

//////////////////////////
Let's look at an example. Say we rebased the branch in the previous example, created a new pull request for it, and now we want to reference the old pull request from the new one. We also want to reference an issue in the fork of the repository and an issue in a completely different project. We can fill out the description just like <<_pr_references>>.
Expand Down Expand Up @@ -540,14 +540,14 @@ image::images/mentions-03-closed.png[닫은 PR의 트랙백]
//////////////////////////
In addition to issue numbers, you can also reference a specific commit by SHA. You have to specify a full 40 character SHA, but if GitHub sees that in a comment, it will link directly to the commit. Again, you can reference commits in forks or other repositories in the same way you did with issues.
//////////////////////////
이슈뿐만 아니라 커밋의 SHA도 참조할 수 있다. 40자 SHA를 적으면 GitHub은 자동으로 해당 커밋에 링크시켜 준다. Fork 저장소나 아예 다른 저장소의 커밋도 이슈와 동일한 방식으로 링크시킬 수 있다.
이슈뿐만 아니라 커밋의 SHA도 참조할 수 있다. 40자 SHA를 적으면 GitHub은 자동으로 해당 커밋에 링크를 걸어 준다. Fork 저장소나 아예 다른 저장소의 커밋도 이슈와 동일한 방식으로 링크시킬 수 있다.

==== Markdown

//////////////////////////
Linking to other Issues is just the beginning of interesting things you can do with almost any text box on GitHub. In Issue and Pull Request descriptions, comments, code comments and more, you can use what is called ``GitHub Flavored Markdown''. Markdown is like writing in plain text but which is rendered richly.
//////////////////////////
다른 이슈를 링크하는 것은 GitHub 글쓰기의 첫걸음에 불과하다. 이슈나 Pull Request의 설명, 코멘트, 코드 주석 등등에서 ``GitHub Flavored Markdown''이라는 형식으로 글을 쓸 수 있다. Markdown 형식으로 글을 쓰면 그냥 텍스트 형식으로 글을 쓰는 것 같지만 미끈하고 아름답게 렌더링된다.
다른 이슈를 링크하는 것은 GitHub 글쓰기의 첫걸음에 불과하다. ``GitHub Flavored Markdown''이라는 형식으로 이슈나 Pull Request의 설명, 코멘트, 코드 주석 등에서 글을 쓸 수 있다. Markdown 형식으로 글을 쓰면 그냥 텍스트로 쓴 글이지만 형식을 갖춰 미끈하고 아름답게 렌더링된다.

//////////////////////////
See <<_example_markdown>> for an example of how comments or text can be written and then rendered using Markdown.
Expand Down Expand Up @@ -607,7 +607,7 @@ image::images/markdown-02-tasks.png[타스크 리스트]
//////////////////////////
This is often used in Pull Requests to indicate what all you would like to get done on the branch before the Pull Request will be ready to merge. The really cool part is that you can simply click the checkboxes to update the comment -- you don't have to edit the Markdown directly to check tasks off.
//////////////////////////
Pull Request를 Merge 하기 전에 꼭 처리해야 하는 일의 목록을 표현할 때 타스크 리스트를 사용한다. 그리고 이게 좋은 게 Markdown을 직접 고치지 않고 체크박스만 클릭해도 해당 타스크가 완료됐다고 업데이트된다.
Pull Request를 Merge 하기 전에 꼭 처리해야 하는 일의 목록을 표현할 때 타스크 리스트를 사용한다. Markdown을 직접 고치지 않고 체크박스만 클릭해도 해당 타스크가 완료됐다고 업데이트되기 때문에 상당히 좋은 기능이다.

//////////////////////////
What's more, GitHub will look for task lists in your Issues and Pull Requests and show them as metadata on the pages that list them out. For example, if you have a Pull Request with tasks and you look at the overview page of all Pull Requests, you can see how far done it is. This helps people break down Pull Requests into subtasks and helps other people track the progress of the branch. You can see an example of this in <<_task_list_progress>>.
Expand Down Expand Up @@ -673,7 +673,7 @@ image::images/markdown-04-fenced-code.png[미끈한 코드]
//////////////////////////
If you're responding to a small part of a long comment, you can selectively quote out of the other comment by preceding the lines with the `>` character. In fact, this is so common and so useful that there is a keyboard shortcut for it. If you highlight text in a comment that you want to directly reply to and hit the `r` key, it will quote that text in the comment box for you.
//////////////////////////
아주 긴 글에서 딱 한 부분만 집어서 논의하고 싶을 때 `>` 문자로 해당 부분을 인용하고 그 밑에 코멘트을 단다. 이 방법은 매우 유용해서 흔히 사용하는 방법이고 단축키도 있다. 인용하고 싶은 텍스트를 선택하고 `r` 키를 누르면 바로 코멘트 상자에 해당 텍스트가 인용된다.
아주 긴 글에서 딱 한 부분만 집어서 논의하고 싶을 때 `>` 문자로 해당 부분을 인용하고 그 밑에 코멘트를 단다. 이 방법은 매우 흔히 사용하는 방법이라, 상당히 유용하고, 단축키도 지원한다. 인용하고 싶은 텍스트를 선택하고 `r` 키를 누르면 바로 코멘트 상자에 해당 텍스트가 인용된다.

//////////////////////////
The quotes look something like this:
Expand Down Expand Up @@ -706,7 +706,7 @@ image::images/markdown-05-quote.png[인용 예제]
//////////////////////////
Finally, you can also use emoji in your comments. This is actually used quite extensively in comments you see on many GitHub Issues and Pull Requests. There is even an emoji helper in GitHub. If you are typing a comment and you start with a `:` character, an autocompleter will help you find what you're looking for.
//////////////////////////
마지막으로 소개하는 것은 글에 Emoji를 넣을 수 있다는 것이다. Emoji는 GitHub 이슈나 Pull Request에서 정말 많이 사용된다. GitHub은 Emoji를 쉽게 사용할 수 있도록 돕는다. 코멘트을 쓸 때 `:` 문자로 Emoji 입력을 시작하면 선택해서 자동완성할 수 있도록 Emoji 목록을 보여준다.
마지막으로 소개하는 것은 글에 Emoji를 넣을 수 있다는 것이다. Emoji는 GitHub 이슈나 Pull Request에서 정말 많이 사용된다. GitHub은 Emoji를 쉽게 사용할 수 있도록 돕는다. 코멘트를 쓸 때 `:` 문자로 Emoji 입력을 시작하면 선택해서 자동완성할 수 있도록 Emoji 목록을 보여준다.

[[_md_emoji_auto]]
//////////////////////////
Expand Down Expand Up @@ -772,7 +772,7 @@ http://www.emoji-cheat-sheet.com
//////////////////////////
This isn't technically GitHub Flavored Markdown, but it is incredibly useful. In addition to adding Markdown image links to comments, which can be difficult to find and embed URLs for, GitHub allows you to drag and drop images into text areas to embed them.
//////////////////////////
GFM은 이미지까지 확장하지 않았지만 GitHub에서 이미지 첨부는 매우 쉽다. Markdown 형식으로 이미지를 첨부하고 싶을 때 이미지 올리고 그 URL을 찾아서 일일이 입력하기 번거롭다. GitHub에서는 그냥 이미지를 바로 Drag-and-Drop으로 붙여 넣을 수 있다.
GitHub이 제공하는 글에 이미지를 포함시키는 기능은 기술적으로 GFM이 아니지만 엄청 유용하다. Markdown 형식으로 이미지를 첨부하고 싶을 때 일반적인 방법으로는 이미지를 올리고 그 URL을 찾아서 일일이 입력해야 하는데 번거롭다. GitHub에서는 그냥 이미지를 바로 Drag-and-Drop으로 붙여 넣을 수 있다.

[[_md_drag]]
//////////////////////////
Expand Down
Loading