Permalink
Browse files

[ko] fix punctuations for figure

  • Loading branch information...
1 parent 7a42599 commit 93acb40f9d23330d2df89e3259b01ae4a3ec0772 @pismute pismute committed Dec 20, 2013
@@ -15,7 +15,7 @@
이런 이유로 프로그래머들은 오래전에 로컬 VCS라는 걸 만들었다. 이 VCS는 아주 간단한 데이터베이스를 사용해서 파일의 변경 정보를 관리했다.
Insert 18333fig0101.png
-그림 1-1 로컬 버전 관리 다이어그램
+그림 1-1. 로컬 버전 관리 다이어그램
많이 쓰는 VCS 도구 중에 rcs라고 부르는 것이 있는데 오늘날까지도 아직 많은 회사가 사용하고 있다. Mac OS X 운영체제에서도 개발 도구를 설치하면 RCS가 함께 설치된다. RCS는 기본적으로 Patch Set(파일에서 변경되는 부분)을 관리한다. 이 Patch Set은 특별한 형식의 파일로 저장한다. 그리고 일련의 Patch Set을 적용해서 모든 파일을 특정 시점으로 되돌릴 수 있다.
@@ -24,7 +24,7 @@ Insert 18333fig0101.png
프로젝트를 진행하다 보면 다른 개발자와 함께 작업해야 하는 경우가 많다. 이럴 때 생기는 문제를 해결하기 위해 CVCS(중앙집중식 VCS)가 개발됐다. CVS, Subversion, Perforce 같은 시스템은 파일을 관리하는 서버가 별도로 있고 클라이언트가 중앙 서버에서 파일을 받아서 사용(Checkout)한다. 수년 동안 이러한 시스템들이 많은 사랑을 받았다.
Insert 18333fig0102.png
-그림 1-2 중앙집중식 버전 관리(CVCS) 다이어그램
+그림 1-2. 중앙집중식 버전 관리(CVCS) 다이어그램
CVCS 환경은 로컬 VCS에 비해 장점이 많다. 프로젝트에 참여한 사람이면 누가 무엇을 하고 있는지 알 수 있다. 관리자는 누가 무엇을 할 수 있는지 꼼꼼하게 관리할 수 있다. 모든 클라이언트의 로컬 데이터베이스를 관리하는 것보다 VCS 하나를 관리하기가 훨씬 쉽다.
@@ -35,7 +35,7 @@ CVCS 환경은 로컬 VCS에 비해 장점이 많다. 프로젝트에 참여한
DVCS(분산 버전 관리 시스템)을 설명할 차례다. Git, Mecurial, Bazaar, Darcs 같은 DVCS에서는 클라이언트가 파일의 마지막 스냅샷을 Checkout하지 않는다. 그냥 저장소를 전부 복제한다. 서버에 문제가 생기면 이 복제물로 다시 작업을 시작할 수 있다. 클라이언트 중에서 아무거나 골라도 서버를 복원할 수 있다. 모든 Checkout은 모든 데이터를 가진 진정한 백업이다.
Insert 18333fig0103.png
-그림 1-3 분산 버전 관리 시스템(DVCS) 다이어그램
+그림 1-3. 분산 버전 관리 시스템(DVCS) 다이어그램
게다가 대부분의 DVCS 환경에서는 리모트 저장소가 존재한다. 리모트 저장소가 많을 수도 있다. 그래서 사람들은 동시에 다양한 그룹과 다양한 방법으로 협업할 수 있다. 계층 모델 같은 중앙집중식 시스템으로는 할 수 없는 몇 가지 워크플로우를 사용할 수 있다.
@@ -62,12 +62,12 @@ Git의 핵심은 뭘까? 이 질문은 Git을 이해하는데 굉장히 중요
Subversion과 Subversion 비슷한 놈들과 Git의 가장 큰 차이점은 데이터를 다루는 방법에 있다. 큰 틀에서 봤을 때 대부분의 VCS 시스템이 관리하는 정보는 파일들의 목록이다. CVS, Subversion, Perforce, Bazaar 등의 시스템은 파일의 집합으로 정보를 관리한다. 각 파일의 변화를 그림 1-4처럼 시간순으로 관리한다.
Insert 18333fig0104.png
-그림 1-4 각 파일에 대한 변화(델타)를 저장하는 시스템들
+그림 1-4. 각 파일에 대한 변화(델타)를 저장하는 시스템들
Git은 이런 식으로 데이터를 저장하지도 취급하지도 않는다. 대신 Git의 데이터는 파일 시스템의 스냅샷이라 할 수 있으며 크기가 아주 작다. Git은 커밋하거나 프로젝트의 상태를 저장할 때마다 파일이 존재하는 그 순간을 중요하게 여긴다. 파일이 달라지지 않았으면 Git은 성능을 위해서 파일을 저장하지 않는다. 단지 이전 상태의 파일에 대한 링크만 저장한다. Git은 그림 1-5처럼 동작한다.
Insert 18333fig0105.png
-그림 1-5 Git은 시간순으로 프로젝트의 스냅샷을 저장한다
+그림 1-5. Git은 시간순으로 프로젝트의 스냅샷을 저장한다
이것이 Git이 다른 VCS와 구분되는 점이다. 이점 때문에 Git는 다른 시스템들이 과거로부터 답습해왔던 버전 컨트롤의 개념과 다르다는 것이고 많은 부분을 새로운 관점에서 바라본다. Git은 강력한 도구를 지원하는 작은 파일시스템이다. Git은 단순한 VCS가 아니다. 이제 3장에서 설명할 Git 브랜치를 사용하면 얻게 되는 이득이 무엇인지 설명한다.
@@ -102,7 +102,7 @@ Git을 사용하면 프로젝트가 심각하게 망가질 걱정 없이 매우
이 세 가지 상태는 Git 프로젝트의 세 가지 단계와 연결돼 있다. Git 디렉토리, 워킹 디렉토리, Staging Area 이렇게 세 가지 단계를 이해하고 넘어가자.
Insert 18333fig0106.png
-그림 1-6 워킹 디렉토리, Staging Area, Git 디렉토리
+그림 1-6. 워킹 디렉토리, Staging Area, Git 디렉토리
Git 디렉토리는 Git이 프로젝트의 메타데이터와 객체 데이터베이스를 저장하는 곳을 말한다. Git 디렉토리가 Git의 핵심이다. 다른 컴퓨터에 있는 저장소를 Clone 할 때 Git 디렉토리가 만들어진다.
@@ -166,7 +166,7 @@ Mac에 Git을 쉽게 설치하는 방법은 두 가지가 있다. GUI 인스톨
http://code.google.com/p/git-osx-installer
Insert 18333fig0107.png
-그림 1-7 OS X Git 인스톨러
+그림 1-7. OS X Git 인스톨러
MacPorts(`http://www.macports.org`)를 사용하는 방법도 있다. MacPorts가 설치돼 있으면 아래와 같이 Git을 설치한다:
@@ -47,7 +47,7 @@ Git은 다양한 프로토콜을 지원한다. 이제까지는 `git://` 프로
마지막 커밋 이후 아직 아무것도 수정하지 않은 상태에서 어떤 파일이 수정되면 Git은 그 즉시 파일을 *Modified* 상태로 인식한다. 그리고 이 수정한 파일을 Stage하고 *Staged* 상태인 파일을 커밋한다. 이 라이프사이클을 그림 2-1처럼 계속 반복한다.
Insert 18333fig0201.png
-그림 2-1 파일의 라이프사이클
+그림 2-1. 파일의 라이프사이클
### 파일의 상태 확인하기 ###
@@ -669,7 +669,7 @@ The lines must be formatted as follows
GUI 도구로 커밋 히스토리를 시각화하고 싶다면 gitk를 사용할 수 있다. gitk는 Tcl/Tk 프로그램이고 `git log` 명령을 시각화해주는 도구다. gitk는 `git log` 명령이 지원하는 필터링 옵션을 거의 모두 지원한다. 프로젝트 디렉토리에서 gitk를 실행하면 그림 2-2처럼 보일 것이다.
Insert 18333fig0202.png
-그림 2-2 gitk의 히스토리
+그림 2-2. gitk의 히스토리
위쪽 반을 차지하는 윈도에서는 히스토리를 그래프로 예쁘게 보여준다. 아래쪽 반을 차지하는 윈도는 diff 결과를 보여주는데 위쪽 윈도에서 선택한 커밋에 대한 diff 결과를 보여준다.
Oops, something went wrong.

0 comments on commit 93acb40

Please sign in to comment.