Skip to content

fix chapter6 #40

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

Closed
soursop wants to merge 3 commits into from
Closed

fix chapter6 #40

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
2934f6c
fix
Jul 19, 2015
ad8bd0b
fix
soursop Jul 21, 2015
cbfd8eb
Merge branch 'master' of https://github.com/soursop/progit2-ko.git
soursop Jul 21, 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
4 changes: 2 additions & 2 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,7 +173,7 @@ 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은 두 가지 방법의 인증을 요구한다. 둘 중 한 가지 방법만 뚫려서는 공격자가 계정에 접근할 수 없다.

//////////////////////////
You can find the Two-factor Authentication setup under the Security tab of your Account settings.
Expand Down
26 changes: 13 additions & 13 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,7 +245,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.
Expand Down Expand Up @@ -275,7 +275,7 @@ 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>>은 보면 프로젝트 소유자가 코드 코멘트과 일반 코멘트을 달면서 토론하는 것을 보여 준다. 코드 코멘트로 커뮤니케이션 하는 것을 볼 수 있다.

[[_pr_discussion]]
//////////////////////////
Expand All @@ -288,12 +288,12 @@ image::images/blink-05-general-comment.png[PR 토론 페이지]
//////////////////////////
Now the contributor can see what they need to do in order to get their change accepted. Luckily this is also a very simple thing to do. Where over email you may have to re-roll your series and resubmit it to the mailing list, with GitHub you simply commit to the topic branch again and push.
//////////////////////////
이 토론을 보고 기여자는 자신이 무엇을 해야 자신의 코드가 받아들여질지 알 수 있다. 만약 이 일을 이메일로 하고자 한다면 관련 커밋을 다시 말아서 메일링 리스트에 다시 보내야 한다. 하지만, GitHub에서는 해당 토픽 브랜치에 이어서 커밋하고 Push 하면 된다.
이 토론을 보고 기여자는 자신이 무엇을 해야 자신의 코드가 받아들여질지 알 수 있다. 만약 이 일을 이메일로 하고자 한다면 관련 커밋을 다시 묶어서 메일링 리스트에 다시 보내야 한다. 하지만, GitHub에서는 해당 토픽 브랜치에 이어서 커밋하고 Push 하면 된다.

//////////////////////////
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 All @@ -311,7 +311,7 @@ An interesting thing to notice is that if you click on the ``Files Changed'' tab
//////////////////////////
The other thing you'll notice is that GitHub checks to see if the Pull Request merges cleanly and provides a button to do the merge for you on the server. This button only shows up if you have write access to the repository and a trivial merge is possible. If you click it GitHub will perform a ``non-fast-forward'' merge, meaning that even if the merge *could* be a fast-forward, it will still create a merge commit.
//////////////////////////
그 외 알아두면 좋은 것은 GitHub은 Pull Request가 Merge 될 수 있는지 검사해서 서버에서 Merge 할 수 있도록 Merge 버튼을 제공한다. 이 버튼은 저장소에 쓰기 권한이 있는 사람만 볼 수 있고 이 버튼으로 Merge 하면 Merge 커밋이 생긴다(Trivial Merge). ``fast-forward'' Merge가 가능할 때도 ``non-fast-forwrd''로 Merge 한다.
그 외 알아두면 좋은 것은 GitHub는 Pull Request가 Merge 될 수 있는지 검사해서 서버에서 Merge 할 수 있도록 Merge 버튼을 제공한다. 이 버튼은 저장소에 쓰기 권한이 있는 사람만 볼 수 있고 이 버튼으로 Merge 하면 Merge 커밋이 생긴다(Trivial Merge). ``fast-forward'' Merge가 가능할 때도 ``non-fast-forwrd''로 Merge 한다.

//////////////////////////
If you would prefer, you can simply pull the branch down and merge it locally. If you merge this branch into the `master` branch and push it to GitHub, the Pull Request will automatically be closed.
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 All @@ -625,7 +625,7 @@ image::images/markdown-03-task-summary.png[타스크 리스트의 예]
//////////////////////////
These are incredibly useful when you open a Pull Request early and use it to track your progress through the implementation of the feature.
//////////////////////////
Pull Request부터 열어 두고 일을 하면 해당 기능이 얼마나 진행됐는지 쉽게 알 수 있다.
Pull Request을 열어놓은 뒤 해당 기능이 얼마나 진행되었는지 이력관리 용도로 사용할 수 있는데, 상당히 유용하다.

//////////////////////////
====== Code Snippets
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 @@ -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으로 붙여 넣을 수 있다.
기술적으로 GFM은 아니지만, 이미지 기능은 상당히 유용하다. Markdown 형식으로 이미지를 첨부하고 싶을 때 이미지 올리고 그 URL을 찾아서 일일이 입력하기 번거롭다. GitHub에서는 그냥 이미지를 바로 Drag-and-Drop으로 붙여 넣을 수 있다.

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