-
Notifications
You must be signed in to change notification settings - Fork 12
/
Copy path03s-using-github.md.erb
141 lines (83 loc) · 8.59 KB
/
03s-using-github.md.erb
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
---
title: Git과 GitHub 사용하기
slug: github
date: 0003/01/02
number: 3.5
sidebar: true
contents: 책을 따라해보며 Github 사용법을 배운다.
paragraphs: 32
---
[GitHub](https://github.com/)는 [Git](http://git-scm.com/) 버전 컨트롤 시스템에 기반한 오픈소스 프로젝트를 위한 소셜 저장소이다. 이것의 주요 기능은 프로젝트에서 코드의 공유와 협업을 쉽게 하는 것이다. 하지만 또한 훌륭한 학습도구이기도 하다. 이 사이드바 장에서는 독자가 *Discover Meteor*를 따라하는 과정에서 GitHub를 사용하는 몇 가지 방법을 빠르게 훑어볼 것이다.
이 사이드바 장은 독자가 Git과 GitHub에 익숙하지 않다고 가정한다. 만약 독자가 이들에 익숙하다면 다음장으로 바로 넘어가도 된다!
### 커밋(Commit)하기
Git 저장소의 기본 작업단위는 *커밋(commit)*이다. 커밋은 주어진 시점에서의 코드 상태에 대한 스냅사진이라고 생각하면 된다.
우리는 단순하게 Microscope에 대한 완성된 코드를 제공하는 대신에, 각 단계별 스냅사진을 만들고 GitHub에서 이 모두를 온라인으로 볼 수 있도록 하였다.
예를 들면, 이것은 [이전 장의 마지막 커밋](https://github.com/DiscoverMeteor/Microscope/commit/chapter3-2)의 모습이다:
<%= screenshot "s3-1", "GitHub에서의 Git 커밋 화면." %>
아래에 보이는 것은 `post_item.js` 파일의 “diff” (“difference”를 의미)로서, 다른 표현으로는 이 커밋에 따른 변경 사항을 의미한다. 이 경우, `post_item.js` 파일은 처음부터 작성되었으므로, 그 내용 전체가 녹색으로 나타난다.
[이 책의 나중 부분](https://github.com/DiscoverMeteor/Microscope/commit/chapter13-1)의 예제와 비교해 보기 바란다:
<%= screenshot "s3-2", "코드 수정." %>
이번에는, 수정된 라인들만 녹색으로 나타난다.
물론, 때로는 코드 라인을 추가하거나 수정하는 것이 아니라 [삭제](https://github.com/DiscoverMeteor/Microscope/commit/chapter12-2)하기도 한다:
<%= screenshot "s3-3", "코드 삭제." %>
이와같이 우리는 GitHub를 처음 사용해보았다: 변경 사항을 한 눈에 보기
### 커밋한 코드 살펴보기
Git의 커밋 뷰는 이 커밋에 반영된 변경사항들을 보여주지만, 때때로 변경되지 않은 파일들을 보고 싶은 경우도 있는데, 이는 그 진행 단계에서 코드가 어떻게 보이는 지를 확인하기 위함이다.
다시 GitHub로 돌아가자. 커밋 페이지에 있을 때, **Browse code** 버튼을 눌러보라:
<%= screenshot "s3-5", "Browse code 버튼." %>
이제 *특정한 커밋상태의* 저장소에 접근할 수 있을 것이다.
<%= screenshot "s3-6", "commit 3-2의 저장소." %>
GitHub에서 우리가 해당 커밋에서 찾는 시각적 단서를 많이 주지는 않지만, “normal” master view와 비교하여 그 파일 구조가 달라진 것을 한 눈에 볼 수 있다.
<%= screenshot "s3-7", "commit 14-2의 저장소." %>
### 로컬로 커밋에 접근하기
지금까지 우리는 GitHub에서 커밋한 전체 코드를 온라인으로 살펴보는 방법을 알아보았다. 그러나 같은 일을 로컬에서 하고 싶다면 어떻게 해야 할까? 예를 들면, 특정한 커밋 상태에서 이것이 어떻게 작동하는 지를 보기 위하여 로컬에서 앱을 실행하고자 하는 경우가 있다.
이를 위해, 우리는 첫 단계(최소한 이 책에서는 그렇다)를 `git` 커맨드 라인 유틸리티로 시작할 것이다. 우선, [Git이 설치된 것을 확인하라](http://git-scm.com/downloads). 그리고 Microscope repository를 **복제**하라(바꾸어 말하면, 복사본을 로컬에 다운로드하라).
~~~bash
$ git clone [email protected]:DiscoverMeteor/Microscope.git github_microscope
~~~
끝부분의 `github_microscope`는 앱을 복제하여 저장할 로컬 디렉토리의 이름이다. 이미 `microscope`라는 이름의 디렉토리가 존재한다면, 그저 다른 이름으로 바꾸면 된다(GitHub repo에 있는 이름과 똑같을 필요는 없다).
`git` 커맨드 라인 유틸리티를 사용할 수 있도록 `cd` 명령으로 저장소 디렉토리로 이동한다:
~~~bash
$ cd github_microscope
~~~
이제 GitHub로부터 저장소를 복제하여 그 앱의 *모든* 코드를 다운로드하였다. 이는 커밋한 마지막 코드를 보고 있다는 의미이다.
고맙게도, 다른 것들에는 영향을 주지 않으면서 시간을 되돌려 특정한 커밋을 “check out” 하는 방법이 있다. 한 번 시도해보자:
~~~bash
$ git checkout chapter3-1
Note: checking out 'chapter3-1'.
You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.
If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:
git checkout -b new_branch_name
HEAD is now at a004b56... Added basic posts list template and static data.
~~~
Git은 우리가 “detached HEAD” 상태에 있다는 것을 알려주고 있는데, 이는 Git에 관한 한, 지나간 커밋을 볼 수는 있지만 수정할 수는 없다는 것을 의미한다. 마치 이것은 유리구슬을 통해서 과거를 보는 마법사에 비유할 수 있다.
(Git에는 과거의 커밋을 *변경할 수 있는* 명령어들도 있다는 점에 유의하기 바란다. 이는 마치 시간 여행자가 과거로 돌아가서 나비를 밟는 것과 같은 일이 일어날 수 있다는 의미이나 이것은 여기서의 간단한 소개의 범위를 넘어선다.)
우리가 단순하게 `chapter3-1`이라고 입력할 수 있었던 이유는 모든 Microscope의 커밋마다 각 장에 대한 표식으로 미리 꼬리표를 달아 놓았기 때문이다. 이렇게 하지 않았다면, 먼저 해당 커밋의 **해시(hash)**나 또는 unique identifier를 찾아야 했을 것이다.
다시 한 번, GitHub는 우리의 삶을 보다 편안하게 해준다. 커밋의 해시는 파란 커밋 헤더 박스의 오른쪽 하단에서 찾을 수 있다:
<%= screenshot "s3-4", "Commit hash 찾기." %>
그러면 태그 대신 해시로 시도해보자:
~~~bash
$ git checkout c7af59e425cd4e17c20cf99e51c8cd78f82c9932
Previous HEAD position was a004b56... Added basic posts list template and static data.
HEAD is now at c7af59e... Augmented the postsList route to take a limit
~~~
그리고 마지막으로, 우리가 마술 유리구슬을 보는 것을 멈추고 현재로 돌아오려면 어떻게 해야 할까? Git에게 **master** branch를 `check out`하고 싶다고 말하면 된다:
~~~bash
$ git checkout master
~~~
이 과정의 어느 시점에서나, “detached HEAD” 상태에서도, 앱을 `meteor` 명령어로 실행시킬 수도 있다. 만약 Meteor가 패키지가 누락되었다는 메시지를 보이면 `meteor update` 명령을 바로 실행시키면 되는데, 이것은 Microscope의 Git 저장소에는 패키지가 포함되어 있지 않기 때문이다.
### History 관점
또 다른 일반적인 시나리오가 있다: 독자가 어떤 파일을 보고 있는데 독자가 전에 보지 못했던 변경 사항이 있는 것을 발견했다. 문제는 *언제* 파일이 변경되었는지 기억을 못한다는 것이다. 그러면 올바른 버전을 찾을 때까지 각 커밋을 하나씩 찾아보려고 할 것이다. 하지만, GitHub의 **History** 기능 덕분에 쉽게 할 수 있다.
우선, GitHub에 있는 저장소의 파일중의 하나에 접근하여, “History” 버튼을 누른다:
<%= screenshot "s3-8", "GitHub의 History 버튼." %>
이제 이 특정한 파일에 영향을 준 모든 커밋 목록이 정돈되어 나타난다.
<%= screenshot "s3-9", "파일의 history 보기." %>
### 책임 공방(Blame Game)
마무리 단계로 **Blame**을 살펴보자:
<%= screenshot "s3-10", "GitHub의 Blame 버튼." %>
이 깔끔한 뷰는 어느 커밋에서, 어떤 파일의 라인마다 누가 수정하였는 지를(바꾸어 말하면, 누구의 잘못으로 작동하지 않는 지를) 보여준다:
<%= screenshot "s3-11", "GitHub의 Blame 열람." %>
Git은 매우 복잡한 도구이다 - GitHub도 그렇다 -, 그러므로 이 단일 장에서 모두 다루기를 기대할 수는 없다. 사실, 이들 도구로 가능한 것들에 대한 겉핥기만 한 것이다. 하지만, 바라건데, 이 정도만으로도 이 책의 나머지를 따라 가는데에 도움이 될 것이다.