Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP
Browse files

it's my first try about 01

  • Loading branch information...
commit 185295c370d60992b1158e28786f0293b1b09fb7 1 parent db4ab4c
@pismute pismute authored
Showing with 364 additions and 144 deletions.
  1. +364 −144 ko/01-introduction/01-chapter1.markdown
View
508 ko/01-introduction/01-chapter1.markdown
@@ -1,257 +1,477 @@
-# 시작하기 #
+# Getting Started #
+시작하기
-이 장에서는 힘내와 함께 시작에 관한 것입니다. 우리는 버전 제어 도구에 대한 몇 가지 배경 설명에 의해 처음에 다음이 시작됩니다 힘내 어떻게 귀하의 시스템에서 실행 마지막으로 어떻게 설치 작업을 시작 들어가야에 이동합니다. 왜 망할놈의 주위에, 왜 당신이 그것을 사용해야 이해해야한다이 장의 끝에 당신의 모든 설정을 그렇게되어야합니다.
+이 챕터는 Git을 처음 사용하는 법에 대해 다룰 것이다. 나는 버전 관리 도구들에 대한 지식들을 먼저 설명한 후에 git을 설치하는 방법을 다루고 마지막으로 설정해서 사용하는 방법에 대해 다룰 것이다. 이 장을 다 읽고 나면 Git의 탄생배경, Git을 사용하는 이유, Git을 설정하고 사용하는 방법을 알게 될 것이다.
-## 버전 제어 란 ##
+This chapter will be about getting started with Git. We will begin at the beginning by explaining some background on version control tools, then move on to how to get Git running on your system and finally how to get it setup to start working with. At the end of this chapter you should understand why Git is around, why you should use it and you should be all setup to do so.
-어떤 버전 제어, 그리고 왜 상관해야 하나요? 버전 관리 시스템입니다 파일에 레코드를 변경하거나 파일의 시간이 너무 이상하면 나중에 특정 버전의 설정 리콜 수있습니다. 당신 파일을 받고 버전 제어 소프트웨어의 소스 코드를 사용하여이 책에 예제, 비록 현실에 대한 당신의 컴퓨터에있는 파일의 거의 모든 유형이 할 수있습니다.
+## About Version Control ##
+버전 컨트롤이란?
-경우 또는 웹 디자이너 및 그래픽 이미지 또는 레이아웃의 모든 버전을 계속하고 싶어합니다 (이는 가장 확실하게하려면), 버전 제어 시스템 (VCS는)를 사용하여 아주 현명한 일이 원하는 것이다. 그것은 다시 이전의 상태로 되돌리려면 파일을 다시 이전 상태로 되돌리려면 전체 프로젝트, 시간이 지남에 변경 사항을, 마지막으로 바뀌었습니다 누가 뭔가가 문제의 원인이 될 수도 비교해 볼 수 있도록, 누가 문제와 때, 그리고 더 많은 도입했다. VCS는 사용하는 경우도 일반적으로 당신이 일을 망치거나 파일이 손실은, 당신은 쉽게 복구할 수있습니다. 또한, 당신은 매우 작은 오버헤드가 모든이에게 갖다.
+버전 컨트롤은 뭐고 왜 알아야 할까? 버전 컨트롤은 파일들의 변화를 시간에 따라 기록하는 시스템을 말한다. 이 책에 있는 모든 예제들은 모두 버전 컨트롤 시스템을 사용한다. 실제로 컴퓨터에서 사용하는 거의 모든 종류의 파일들은 버전 컨트롤할 수 있다.
-### 로컬 버전 제어 시스템 ###
+What is version control, and why should you care? Version control is a system that records changes to a file or set of files over time so that you can recall specific versions later. For the examples in this book you will use software source code as the files being version controlled, though in reality you can do this with nearly any type of file on a computer.
-많은 사람들이 선택의 여지는 버전 제어 방식을 다른 디렉토리에 (아마도 시간이 찍혀 디렉토리에 그들이 똑똑한 경우) 파일을 복사하는 것입니다. 이유는 너무 간단하다 이러한 접근 방식은 매우 일반적이지만, 그것도 엄청난 오류가 발생하기 쉬운입니다. 그것은 당신과 우연히이야 잘못된 파일 또는 복사에 쓸 디렉토리를 잊기 쉬운 파일, 당신에게 말은하지 않습니다.
+당신이 그래픽 디자이너이거나 웹 디자이너라면 이미지나 레이아웃의 모든 버전을 관리하고 싶을때 VCS(Version Control System)을 사용하는 것이 현명하다. VCS를 사용하면 파일을 이전 상태로 되돌릴 수도 있고, 프로젝트 전체를 이전 상태로 되돌릴 수도 있고, 수정내역을 계속 비교해 볼 수도 있고, 누가 문제를 만들었는지도 추적할 수 있고, 이슈를 누가 언제 제기했는지도 알 수 있다. VCS를 사용하면 파일을 잃거나 잘못 고쳤을 때 쉽게 복구할 수 있다. 이 모든 것을 얻는데 드는 오버헤드도 별로 없다.
-이 문제를 해결하려면, 프로그래머는 오래 전 (그림 1-1 참조) 그 개정을 통제 아래에있는 파일에 대한 모든 변경 사항을 계속 간단한 데이터베이스를 가지고 지역 VCSs 개발했다.
+If you are a graphic or web designer and want to keep every version of an image or layout (which you would most certainly want to), a Version Control System (VCS) is a very wise thing to use. It allows you to revert files back to a previous state, revert the entire project back to a previous state, compare changes over time, see who last modified something that might be causing a problem, who introduced an issue and when, and more. Using a VCS also generally means that if you screw things up or lose files, you can easily recover. In addition, you get all this for very little overhead.
-Insert 18333fig0101.png
-그림 1-1. 로컬 버전 제어 다이어그램.
+### Local Version Control Systems ###
+로컬 버전 컨트롤 시스템
-하나는 더 많은 인기를 VCS는 도구는 여전히 많은 컴퓨터에 분산되어 오늘날 시스템 RCS라는 기록했다. 심지어 인기있는 맥 OS X 운영 체제를하면 개발자 도구를 설치 RCS 명령을 포함합니다. 이 도구는 기본적으로 패치 세트를 유지하는 작품 (즉, 디스크에 특별한 형식이 다른 하나의 변화에서 파일 사이의 차이점); 말하면 그 다음에 다시하실 수있습니다 언제 어느 시점에서처럼 추가하여 파일을 만들려면 어떻게 생겼는지를 모두 패치.
+많은 사람들이 버전을 관리하는 방법으로 다른 디렉토리로 파일을 복사하는 방법이 있다(현명한 사람이라면 디렉토리 이름에 시간을 활용했을 것이다). 이 방법은 간단하기 때문에 자주 사용한다. 그렇지만 정말 에러나기 쉽니다. 작업하고 있는 디렉토리를 잃어버리거나 실수로 파일을 잘못 고칠 수도 있고 잘못 복사할 수도 있다.
-### 중앙 집중식 버전 제어 시스템 ###
+Many people’s version-control method of choice is to copy files into another directory (perhaps a time-stamped directory, if they’re clever). This approach is very common because it is so simple, but it is also incredibly error prone. It is easy to forget which directory you’re in and accidentally write to the wrong file or copy over files you don’t mean to.
-다음의 주요 문제는 사람들이 그들이 발생하는 다른 시스템에서 개발자와 협력이 필요합니다. 이 문제를 처리하기 위해, 중앙 집중식 버전 제어 시스템 (CVCSs)을 개발했다. CVS는, Subversion은 등과 같은 이러한 시스템, 그리고 퍼포, 그리고 고객의 숫자가 모든 버전의 파일이 들어있는 단일 서버가 그 중앙 장소에서 파일을 체크 아웃. 수년 동안,이 (그림 1-2 참조) 버전 제어를위한 표준되었습니다.
+이런 이유로 프로그래머들은 오래전에 로컬 VCS를 만들었다. 그 VCS는 버전 컨트롤중인 파일의 변경 정보를 저장하기 위해 아주 간단한 데이터베이스을 사용했다.
-Insert 18333fig0102.png
-그림 1-2. 중앙 버전 제어 다이어그램.
+To deal with this issue, programmers long ago developed local VCSs that had a simple database that kept all the changes to files under revision control (see Figure 1-1).
-이 설정을 로컬 VCSs, 특히 많은 이점을 제공한다. 예를 들어, 모든 프로젝트에 다른 사람들은 뭐하고있다가 어느 정도 알고 있죠. 누가 무엇을, 그리고 그것보다 훨씬 그것을 모든 클라이언트에 로컬 데이터베이스와 거래를하는 것입니다 CVCS 관리를 쉽게 할 수있는 이상의 관리자가 세부적으로 제어할 수있습니다.
+Insert 18333fig0101.png
+Figure 1-1. Local version control diagram.
+그림 1-1. 로컬 버전 컨트롤 다이어그램.
-그러나,이 설정도 몇 가지 심각한 단점이있다. 가장 명백한 실패의 중앙 서버를 나타내는 단일 지점입니다. 만약 서버가 1 시간 동안 아무도 그 시간 모두에서 협업할 수 또는 그들이 최선을 다하고있습니다 뭐든 버전의 변경 내용을 저장하는 동안갑니다. 만약 중앙 데이터베이스가 손상된 경우에 하드 디스크, 그리고 적절한 백업을 보관하지 않은, 당신은 절대적으로 모든 것을 원하는 사람들을 제외하고 하나의 스냅샷이 프로젝트의 전체 역사를 잃고 자신의 로컬 컴퓨터에서이 일어날. 지역 VCS는 시스템이 동일한 문제를 겪고 때마다 당신이 한 장소에서 프로젝트의 전체 역사를 가지고, 당신은 모든 걸 잃을 위험.
+인기있는 VCS 도구 중에 rcs라고 부르는 것이 있는데 오늘날까지도 아직 많은 회사들이 배포 하고 있다. 심지어 인기있는 Mac OS X 운영체제에서 Developer Tools를 설치할때에도 rcs는 함께 설치된다. 이 툴은 기본적으로 patch set(파일의 다른 부분만)을 관리한다. 이 patch set을 위한 특수한 포멧이 있고 디스크에 저장한다. 일련의 patch set을 적용하므로써 모든 파일을 특정 시점으로 되돌릴 수 있다.
-### 버전 제어 시스템 분산 ###
+One of the more popular VCS tools was a system called rcs, which is still distributed with many computers today. Even the popular Mac OS X operating system includes the rcs command when you install the Developer Tools. This tool basically works by keeping patch sets (that is, the differences between files) from one change to another in a special format on disk; it can then re-create what any file looked like at any point in time by adding up all the patches.
-여기서 버전 컨트롤 시스템 (DVCSs) DVCS 단계에서 안으로 힘내, 의욕, 바자 또는 Darcs (예)로, 고객이 단지 파일의 최신 스냅샷을 선택하지 마십시오 : 그들은 완전히 거울을 분산 저장소입니다. 따라서 서버에있는 경우, 그리고 죽으면 이러한 시스템을 그것을 통해 모든 클라이언트가 저장소의 백업 서버로 복원하는 방법을 복사할 수있습니다 협업했다. 모든 결제 정말 모든 데이터의 전체 백업 (그림 1-3 참조)입니다.
+### Centralized Version Control Systems ###
+중앙집중식 버전콘트롤 시스템
-Insert 18333fig0103.png
-그림 1-3. 분산 버전 관리 다이어그램.
+다른 개발자와 협업해야만 하는 경우도 많다. 이런 경우에 생기는 문제를 해결하기 위해 CVCS(Centralized Version Control System)가 개발됐다. CVS, Subversion, Perforce같은 시스템들은 모든 파일을 관리하는 서버가 별도로 있고 다수의 클라이언트들이 중앙 서버에서 파일을 체크아웃한다. 몇 년 동안 이러한 시스템들이 많은 사랑을 받았다.
-또한, 이러한 시스템의 많은 꽤 잘 그들이 작업을 수있는 몇 가지 원격 저장소를 갖는, 그래서 다른 방법으로 사람들이 다른 그룹과 같은 프로젝트 내에서 동시에 협업할 수있는 거래. 이것은 당신이 계층 모델과 같은 중앙 집중화된 시스템에서 가능하지 않습니다 워크플로우의 여러 유형을 설정할 수있습니다.
+The next major issue that people encounter is that they need to collaborate with developers on other systems. To deal with this problem, Centralized Version Control Systems (CVCSs) were developed. These systems, such as CVS, Subversion, and Perforce, have a single server that contains all the versioned files, and a number of clients that check out files from that central place. For many years, this has been the standard for version control (see Figure 1-2).
-## 망할놈의 짧은 역사 ##
+Insert 18333fig0102.png
+Figure 1-2. Centralized version control diagram.
+그림 1-2. 중앙집중식 버전 컨트롤 다이어그램.
-인생에서 많은 좋은 것들과 마찬가지로, 망할놈의 창조적 파괴와 불타는 논쟁의 비트와 함께 시작했다. 리눅스 커널은 상당히 큰 범위의 오픈 소스 소프트웨어 프로젝트입니다. 리눅스 커널의 유지 보수 (1991에서 2002 사이), 소프트웨어에 대한 변경 사항의 일생의 대부분을위한 패치 및 보관된 파일을 주변에 전달했다. 2002 년, 리눅스 커널 프로젝트는 독자적인 시스템이라는 DVCS 비트 키퍼를 사용하기 시작했다.
+이 환경은 로컬 VCS비해 많은 장점이 있다. 예를 들어, 누가 무었을 하고 있는지 프로젝트에 참여하고 있는 사람 모두 알 수 있다. 관리자는 누가 무었을 할 수 있는지 세세히 관리할 수 있다. 모든 클라이언트의 로컬 데이터페이스를 관리하는 것보다 CVS 하나를 관리하는 것이 훨씬 쉽다.
-2005 년, 리눅스 커널을 개발하고 비트 키퍼가 고장이 회사가 개발한 상용 사회 사이의 관계, 그리고 자유의 도구의 충전 상태를 취소했다. 이것은 (특히 리누스 토발즈, 리눅스의 창시자)에 자신의 도구를 개발하는 몇 가지 비트 키퍼를 사용하는 동안 그들이 배운 교훈을 바탕으로 리눅스 개발 커뮤니티하라는 메시지가 나타나면. 일부는 새로운 시스템의 목표였다는 다음과 같습니다 :
+This setup offers many advantages, especially over local VCSs. For example, everyone knows to a certain degree what everyone else on the project is doing. Administrators have fine-grained control over who can do what; and it’s far easier to administer a CVCS than it is to deal with local databases on every client.
+
+그러나 이런 환경은 몇 가지 치명적인 결점이 있다. 가장 대표되는 것은 중앙 서버에서 생기는 문제다. 만약 서버가 한 시간 동안 다운된다면 그동안 아무도 다른 사람과 협업을 할 수 없고 사람들이 하고 있는 일을 백업할 수 있는 방법도 마땅히 찾을 수 없다. 그리고 중앙 데이터베이스가 있는 하드디스크에 문제가 생긴다면 프로젝트의 모든 히스토리를 잃게 된다. 물론 사람들마다 하나씩 가지고 있는 snapshot은 괜찮다. 로컬 VCS 시스템도 비슷하다. 만약 같은 문제가 발생하면 모든 것을 잃게 된다.
+
+However, this setup also has some serious downsides. The most obvious is the single point of failure that the centralized server represents. If that server goes down for an hour, then during that hour nobody can collaborate at all or save versioned changes to anything they’re working on. If the hard disk the central database is on becomes corrupted, and proper backups haven’t been kept, you lose absolutely everything—the entire history of the project except whatever single snapshots people happen to have on their local machines. Local VCS systems suffer from this same problem—whenever you have the entire history of the project in a single place, you risk losing everything.
+
+### Distributed Version Control Systems ###
+DVCS(Distributed Version Control Systems)
+
+이제 DVCS 차례다. Git, Mecurial, Bazaar, Darcs같은 DVCS에서는 클라이언트가 파일의 마지막 snapshot을 체크아웃하지 않는다. 단지 repository를 전부 복제할 뿐이다. 서버가 죽으면 그 복제물로 다시 작업을 시작할 수 있다. 클라이언트 중에서 아무거나 골라도 서버를 복원할 수 있다. 모든 체크아웃은 모든 데이터를 가지고 있는 진정한 백업이다.
+
+This is where Distributed Version Control Systems (DVCSs) step in. In a DVCS (such as Git, Mercurial, Bazaar or Darcs), clients don’t just check out the latest snapshot of the files: they fully mirror the repository. Thus if any server dies, and these systems were collaborating via it, any of the client repositories can be copied back up to the server to restore it. Every checkout is really a full backup of all the data (see Figure 1-3).
+
+Insert 18333fig0103.png
+Figure 1-3. Distributed version control diagram.
+그림 1-3. 분산 버전 컨트롤 다이어그램.
+
+게다가 대부분의 DVCS들은 다 수의 원격 레파지토리가 존재할 수 있다. 원격 레파지토리가 여러개라고 해도 아무 문제 없다. 그래서 사람들은 동시에 다양한 그룹과 다양한 방법으로 협업할 수 있다. 계층 모델같은 중앙집중식 시스템으로는 할 수 없는 몇 가지 워크플로우를 사용할 수 있다.
+
+Furthermore, many of these systems deal pretty well with having several remote repositories they can work with, so you can collaborate with different groups of people in different ways simultaneously within the same project. This allows you to set up several types of workflows that aren’t possible in centralized systems, such as hierarchical models.
+
+## A Short History of Git ##
+Git의 역사
+
+인생은 길다. Git은 창조적인 파괴와 모순속에서 가지고 태어났다. 리눅스 커널은 괭장히 규모가 큰 오픈소스 프로젝트이다. 리눅스 커널의 일생에서 대부분의 시절은 패치와 단순 파일*archived file*로만 관리했다. 2002년에 드디어 리눅스 커널은 BitKeeper라고 불리는 상용 DVCS를 사용하기 시작했다.
+
+As with many great things in life, Git began with a bit of creative destruction and fiery controversy. The Linux kernel is an open source software project of fairly large scope. For most of the lifetime of the Linux kernel maintenance (1991–2002), changes to the software were passed around as patches and archived files. In 2002, the Linux kernel project began using a proprietary DVCS system called BitKeeper.
+
+2005년 커뮤니티가 만드는 리눅스 커널과 사익을 추구하는 회사가 개발한 BitKeeper의 관계는 틀어졌다. BitKeeper의 무료 사용이 제고된 것이다. 이것은 리눅스 개발 커뮤니티(특히 리눅스 창시자 리누스 토발즈)가 자체 도구를 만들도록 만들었다. Git은 BitKeeper를 사용하면서 배운 교훈을 기초로 다음과 같은 목표를 표방했다:
* 속도
-* 심플한 디자인
-* 이외의 강력한 지원 선형 개발을 병렬로 지점 (수천)
-* 완전 분산
-* 에이블 리눅스 커널과 같은 대형 프로젝트를 효율적으로 처리 (속도와 데이터 크기)
+* 단순한 설계
+* 비선형적인 개발(수 천개의 동시 다발적인 브랜치)
+* 완벽한 분산
+* 리눅스 커널같이 대형 프로젝트에도 유용할 것(속도나 데이터 크기 면에서)
+
+In 2005, the relationship between the community that developed the Linux kernel and the commercial company that developed BitKeeper broke down, and the tool’s free-of-charge status was revoked. This prompted the Linux development community (and in particular Linus Torvalds, the creator of Linux) to develop their own tool based on some of the lessons they learned while using BitKeeper. Some of the goals of the new system were as follows:
+
+* Speed
+* Simple design
+* Strong support for non-linear development (thousands of parallel branches)
+* Fully distributed
+* Able to handle large projects like the Linux kernel efficiently (speed and data size)
+
+Git은 2005년 탄생한 후에 아직 초기 지향점을 그대로 유지하고 있으면서도 사용하기 쉽게 진화, 성숙했다. 이건 미친듯이 빠르고 대형 프로젝트에도 굉장히 유용하다. 이 것은 동시다발적인 브랜치에도 끄떡없은 슈퍼 울트라 브랜칭 시스템이다.
+
+Since its birth in 2005, Git has evolved and matured to be easy to use and yet retain these initial qualities. It’s incredibly fast, it’s very efficient with large projects, and it has an incredible branching system for non-linear development (See Chapter 3).
+
+## Git Basics ##
+Git의 기초
+
+그래서 Git의 핵심은 뭘까? 이 질문은 Git을 이해하는데 굉장히 중요하다. Git이 무엇이고 어떻게 동작하는지 이해한다면 쉽게 Git을 효과적으로 사용할 수 있다. Git을 배우고 있다면 Subversion이나 Perforce같은 다른 VCS를 사용하던 경험을 지워버려야 한다. Git은 미묘하게 달라서 기존의 경험을 조금 혼란스럽게 만들어 버릴 것이다. 사용자 인터페이스는 매우 비슷하지만 Git은 다른 시스템과는 정보를 다른게 취급한다. 이 차이들을 이해 한다면 Git을 사용하는 것이 어렵지 않을 것이다.
+
+So, what is Git in a nutshell? This is an important section to absorb, because if you understand what Git is and the fundamentals of how it works, then using Git effectively will probably be much easier for you. As you learn Git, try to clear your mind of the things you may know about other VCSs, such as Subversion and Perforce; doing so will help you avoid subtle confusion when using the tool. Git stores and thinks about information much differently than these other systems, even though the user interface is fairly similar; understanding those differences will help prevent you from becoming confused while using it.
+
+### Snapshots, Not Differences ###
+Snapshot은 모두 똑같다.
+
+Subversion, Subversion의 친구들과 Git의 가장 큰 차이점은 데이터를 다루는 방법에 있다. 개념적으로 대부분의 다른 시스템들이 관리하는 정보는 파일들을 목록이다. CVS, Subversion, Perforce, BaZaar등의 시스템들은 파일의 집합으로 정보를 관리한다. 각 파일들의 변화를 그림 1-4처럼 시간순으로 관리한다.
+
+The major difference between Git and any other VCS (Subversion and friends included) is the way Git thinks about its data. Conceptually, most other systems store information as a list of file-based changes. These systems (CVS, Subversion, Perforce, Bazaar, and so on) think of the information they keep as a set of files and the changes made to each file over time, as illustrated in Figure 1-4.
+
+Insert 18333fig0104.png
+Figure 1-4. Other systems tend to store data as changes to a base version of each file.
+그림 1-4. 각파일에 대한 변화를 저장하는 시스템들.
+
+Git은 이런 식으로 데이터를 저장하지도 취급하지도 않는다. 대신 Git의 데이터는 아주 작은 파일 시스템의 snapshot이라고 할 수 있다. Git은 커밋하거나 프로젝트의 상태를 저장할 때마다 파일이 존재하고 있는 그 순간을 중요하게 여긴다. 성능을 위해서 파일이 달라지지 않았으면 Git은 저장하지 않는다. 단지 이전 상태의 파일에 대한 링크만 저장한다. Git은 그림 1-5처럼 동작한다.
+
+Git doesn’t think of or store its data this way. Instead, Git thinks of its data more like a set of snapshots of a mini filesystem. Every time you commit, or save the state of your project in Git, it basically takes a picture of what all your files look like at that moment and stores a reference to that snapshot. To be efficient, if files have not changed, Git doesn’t store the file again—just a link to the previous identical file it has already stored. Git thinks about its data more like Figure 1-5.
+
+Insert 18333fig0105.png
+Figure 1-5. Git stores data as snapshots of the project over time.
+그림 1-5. Git은 시간순으로 프로젝트의 snapshot을 저장한다.
+
+이 것은 Git과 다른 VCS를 구분하는 중요한 점이다. Git은 이전 버전을 복사하는 다른 버전 컨트롤 시스템을 바보로 만든다. Git은 마치 작은 독자적인 파일시스템처럼 보이게 만든다. 물론 강력한 도구도 있다. Git은 단순한 VCS가 아니다. 이제 3장에서 설명할 Git 브랜칭을 사용할 때 얻을 수 있는 이득에 대해 설명할 것이다.
+
+This is an important distinction between Git and nearly all other VCSs. It makes Git reconsider almost every aspect of version control that most other systems copied from the previous generation. This makes Git more like a mini filesystem with some incredibly powerful tools built on top of it, rather than simply a VCS. We’ll explore some of the benefits you gain by thinking of your data this way when we cover Git branching in Chapter 3.
+
+### Nearly Every Operation Is Local ###
+거의 모든 명령은 로컬에서 실행된다.
+
+거의 모든 명령은 로컬 파일과 자원만을 사용한다. 보통 네트웍에 있는 다른 컴퓨터의 정보는 필요하지 않다. 대부분의 명령어가 네트워크의 레이턴시에 영향을 받는 CVCS에 익숙하다면 Git이 매우 놀라울 것이다. Git의 이런 특징은 이런 빛의 속도는 Git신만이 구사할 수 있는 초인적인 능력이라고 생각하게 만들 것이다. 프로젝트의 모든 히스토리를 로컬 디스크에 가지고 있기 때문에 모든 명령어는 순식같에 실행된다.
+
+Most operations in Git only need local files and resources to operate — generally no information is needed from another computer on your network. If you’re used to a CVCS where most operations have that network latency overhead, this aspect of Git will make you think that the gods of speed have blessed Git with unworldly powers. Because you have the entire history of the project right there on your local disk, most operations seem almost instantaneous.
+
+예를 들어 프로젝트의 히스토리를 조회하려 할때 Git은 서버가 필요없다. 그냥 로컬 데이터베이스에서 히스토리를 읽어서 보여 준다. 이 것은 당신이 눈깜짝할 사이에 히스토리를 조회할 수 있도록 만들어 준다. 어떤 파일의 현재버전과 한달전의 상태를 비교해보고 싶다면 git은 그냥 한달전의 파일과 지금의 파일을 찾는다. 로컬에서 비교하기 위해 원격에 있는 서버에 접근한 후 예전 버전을 가져올 필요가 없다.
+
+For example, to browse the history of the project, Git doesn’t need to go out to the server to get the history and display it for you—it simply reads it directly from your local database. This means you see the project history almost instantly. If you want to see the changes introduced between the current version of a file and the file a month ago, Git can look up the file a month ago and do a local difference calculation, instead of having to either ask a remote server to do it or pull an older version of the file from the remote server to do it locally.
+
+즉 오프라인 상태에서도 비교할 수 있다. 비행기나 기차등에서 작업하고 네트워크에 접속하고 있지 않아도 커밋할 수 있다. 다른 시스템에서는 불가능한 일이다. 예를 들어 Perforce에서는 서버에 연결할 수 없을 때 할 수 있는 일이 별로 없다. Subversion이나 CVS에서도 마찬가지다. 데이터베이스에 접근할 수 없기 때문에 파일을 편집할 수 있지만 커밋할 수는 없다. 이 것이 매우 사소해 보일지라도 격어보면 매우 큰 차이를 느낄 수 있을 것이다.
+
+This also means that there is very little you can’t do if you’re offline or off VPN. If you get on an airplane or a train and want to do a little work, you can commit happily until you get to a network connection to upload. If you go home and can’t get your VPN client working properly, you can still work. In many other systems, doing so is either impossible or painful. In Perforce, for example, you can’t do much when you aren’t connected to the server; and in Subversion and CVS, you can edit files, but you can’t commit changes to your database (because your database is offline). This may not seem like a huge deal, but you may be surprised what a big difference it can make.
+
+### Git Has Integrity ###
+Git은 일관적이다.
+
+Git은 모든 것을 저장하기 전에 체크섬을 구한 후 그 체크섬으로 관리한다. 때문에 체크섬없이 모든 파일의 내용과 디렉토리를 바꾸는 것이 불가능하다. 체크섬은 Git에서 사용하는 원자적인 데이터 단위이고 Git의 기본 철학도 이에 따른다. Git없이 작업 내용을 잃어버릴 수도 파일의 상태를 알 수도 없다. 모든 것에는 Git이 필요하다.
+
+Everything in Git is check-summed before it is stored and is then referred to by that checksum. This means it’s impossible to change the contents of any file or directory without Git knowing about it. This functionality is built into Git at the lowest levels and is integral to its philosophy. You can’t lose information in transit or get file corruption without Git being able to detect it.
+
+Git이 SHA-1 해시를 사용하여 체크섬을 만든다. 이 것은 40자 길이의 16진수 스트링이다. 파일의 내용이나 디렉토리 구조를 이용하여 체크섬을 구한다. SHA-1은 다음과 같이 생겼다.
+
+ 24b9da6552252987aa493b52f8696cd6d3b00373
+
+The mechanism that Git uses for this checksumming is called a SHA-1 hash. This is a 40-character string composed of hexadecimal characters (0–9 and a–f) and calculated based on the contents of a file or directory structure in Git. A SHA-1 hash looks something like this:
+
+ 24b9da6552252987aa493b52f8696cd6d3b00373
+
+Git은 모든 것을 해시값으로 사용하기 때문에 눈으로 확인할 수 있다. 실제로 Git은 파일 이름으로 저장하지 않기 때문에 해당 파일의 해시값으로만 접근 할 수 있다.
+
+You will see these hash values all over the place in Git because it uses them so much. In fact, Git stores everything not by file name but in the Git database addressable by the hash value of its contents.
+
+### Git Generally Only Adds Data ###
+Git은 일반적으로 데이터를 추가할 뿐이다.
+
+Git으로 무엇인가를 할때 Git은 데이터를 추가할 뿐이다. 어떤 방법으로든 되돌리거나 데이터를 삭제할 수 없다. 다른 VCS에서 처럼 Git에서도 커밋하지 않았기 때문에 변경사항을 잃어버리거나 망쳐버릴 수 있다. 하지만 Git으로 snapshot을 커밋한 후에 데이터를 동일한 프로젝트의 다른 레파지토리로 푸시할 수 있다.
+
+When you do actions in Git, nearly all of them only add data to the Git database. It is very difficult to get the system to do anything that is not undoable or to make it erase data in any way. As in any VCS, you can lose or mess up changes you haven’t committed yet; but after you commit a snapshot into Git, it is very difficult to lose, especially if you regularly push your database to another repository.
+
+심각하게 회손시킬 걱정없이 실험할 수 있기 때문에 Git을 사용하는 것은 매우 신난다. Git이 데이터를 어떻게 저장하고 손실을 복구할 수 있는지 좀 더 알아보려면 9장의 'Under the Covers'를 보아라.
+
+This makes using Git a joy because we know we can experiment without the danger of severely screwing things up. For a more in-depth look at how Git stores its data and how you can recover data that seems lost, see “Under the Covers” in Chapter 9.
+
+### The Three States ###
+세가지 상태
+
+이제 집중해야 한다. Git을 큰 어려움없이 계속 공부하기위해 반드시 기억해야 할 부분이다. Git에서 파일은 세가지 상태를 가질 수 있다. Commited, Modified, Staged가 그 세가지 상태이다. Commited는 데이터가 로컬 데이터베이스에 안전하게 저장됐다는 것을 의미한다. Modified는 수정한 파일이 아직 로컬 데이터베이스에 커밋되지 않은 것을 말한다. Staged는 현재 수정한 파일을 곧 커밋할 것이라고 마킹된 상태를 의미한다.
+
+Now, pay attention. This is the main thing to remember about Git if you want the rest of your learning process to go smoothly. Git has three main states that your files can reside in: committed, modified, and staged. Committed means that the data is safely stored in your local database. Modified means that you have changed the file but have not committed it to your database yet. Staged means that you have marked a modified file in its current version to go into your next commit snapshot.
+
+그러니까 당연히 Git 프로젝트의 세가지 단계 Git 디렉토리, 워킹 디렉토리, Staging Area를 알아야 한다.
+
+This leads us to the three main sections of a Git project: the Git directory, the working directory, and the staging area.
+
+Insert 18333fig0106.png
+Figure 1-6. Working directory, staging area, and git directory.
+그림 1-5. 워킹 디렉토리, Staging Area, Git 디렉토리
+
+Git 디렉토리는 Git이 해당 프로젝트의 메타데이터와 객체 데이터베이스를 저장하는 곳을 말한다. 이 것은 Git의 가장 중요한 부분이다. 다른 컴퓨터에서 레파지토리를 Clone할 때 생성된다.
+
+The Git directory is where Git stores the metadata and object database for your project. This is the most important part of Git, and it is what is copied when you clone a repository from another computer.
+
+워킹 디렉토리는 프로젝트의 특정 버전을 체크아웃한 곳을 말한다. 이 파일들은 Git 디렉토리에 있는 압축된 데이터베이스에서 가져온다. 이 것은 지금 작업하려는 디스크에 있다.
+
+The working directory is a single checkout of one version of the project. These files are pulled out of the compressed database in the Git directory and placed on disk for you to use or modify.
+
+Staging Area는 보통 Git 디렉토리에 있는 단순한 파일이다. 여기에 곧 커밋할 파일에 대한 정보를 저장한다. 하나의 인덱스와 비슷하지만 단순히 Staging Area에 파일을 참조시키는 것에 불과하다.
+
+The staging area is a simple file, generally contained in your Git directory, that stores information about what will go into your next commit. It’s sometimes referred to as the index, but it’s becoming standard to refer to it as the staging area.
+
+기본적인 Git의 워크플로우는 다음과 같다:
+
+1. 워킹 디렉토리에서 파일을 수정한다.
+2. 파일을 Stage해서 Staging area에 있는 snapshot에 그 파일을 추가한다.
+3. Staging Area에 있는 파일들을 커밋해서 Git 디렉토리에 영구적인 snapshot으로 저장한다.
+
+The basic Git workflow goes something like this:
+
+1. You modify files in your working directory.
+2. You stage the files, adding snapshots of them to your staging area.
+3. You do a commit, which takes the files as they are in the staging area and stores that snapshot permanently to your Git directory.
+
+Git 디렉토리에서 파일을 수정했는데 그 것이 그 자체로 의미를 갖는다면 커밋하라. 파일을 수정하고 Staging Area에 추가했다면 단지 Stage했을 뿐이다. 체크아웃한 후에 파일을 수정하고 Stage하지 않았다면 그냥 Modified 상태가 된다. 2장에서 이 상태들에 대해서 좀 더 배울 수 있을 것이다. 거기서에서는 이 상태들의 활용법과 staged 단계를 사용하지 않는 방법도 배운다.
+
+If a particular version of a file is in the git directory, it’s considered committed. If it’s modified but has been added to the staging area, it is staged. And if it was changed since it was checked out but has not been staged, it is modified. In Chapter 2, you’ll learn more about these states and how you can either take advantage of them or skip the staged part entirely.
+
+## Installing Git ##
+Git 설치하기
+
+Git을 실제로 한 번 사용해 보려면 우선 설치해야 한다. 다양한 방법으로 Git을 설치할 수 있다. 그렇지만 가장 일반적인 방법은 두 가지가 있는데 하나는 소스로 설치하는 것이고 다른 하나는 각 플랫폼의 패키지로 설치하는 것이다.
+
+Let’s get into using some Git. First things first—you have to install it. You can get it a number of ways; the two major ones are to install it from source or to install an existing package for your platform.
+
+### Installing from Source ###
+소스로 설치하기
+
+가장 최신 버전을 설치할 수 있기 때문에 여력이 되면 소스로 Git을 설치하는게 유용하다. Git은 계속 UI를 개선 하고 있다. 소스를 가지고 Git을 컴파일할 수 있다면 최신 버전을 사용할 수 있다. 많은 리눅스 배포판의 패키지들은 조금 옜날 버전이다. 그래서 Backport를 사용하거나 최근 버전의 배포판을 사용하고 있지 않다면 소스로 설치하는 것이 최선일 수 있다.
+
+If you can, it’s generally useful to install Git from source, because you’ll get the most recent version. Each version of Git tends to include useful UI enhancements, so getting the latest version is often the best route if you feel comfortable compiling software from source. It is also the case that many Linux distributions contain very old packages; so unless you’re on a very up-to-date distro or are using backports, installing from source may be the best bet.
+
+Git을 설치하려면 다음과 같은 라이브러리 들이 필요하다. Git은 curl, zlib, openssl, expat, libiconv에 의존한다. 예를 들어 Fedora처럼 yum을 가지고 있는 시스템을 사용하고 있거나 apt-get이 있는 데비안 기반 시스템을 사용하고 있다면 다음의 명령어를 실행하여 의존 패키지들을 설치할 수 있다:
+
+ $ yum install curl-devel expat-devel gettext-devel \
+ openssl-devel zlib-devel
+
+ $ apt-get install libcurl4-gnutls-dev libexpat1-dev gettext \
+ libz-dev libssl-dev
+
+
+To install Git, you need to have the following libraries that Git depends on: curl, zlib, openssl, expat, and libiconv. For example, if you’re on a system that has yum (such as Fedora) or apt-get (such as a Debian based system), you can use one of these commands to install all of the dependencies:
-2005 년 탄생 이래, 망할놈의 발전 및 성숙 쉽게 사용할 수와 아직은 이러한 초기 자질을 보유합니다. 그것은 매우 빨리, 아주 큰 프로젝트를 효율적이고, 그 이외의 놀라운 분기 시스템 선형 개발하고있다 () 제 3 장 참조하십시오.
+ $ yum install curl-devel expat-devel gettext-devel \
+ openssl-devel zlib-devel
-## 망할놈의 기본 ##
+ $ apt-get install libcurl4-gnutls-dev libexpat1-dev gettext \
+ libz-dev libssl-dev
-그래서, 무슨 말도 안되는 소리 같지만 힘내 무엇입니까? 만약 당신이 어떤 망할놈의 작동 방법의 기초, 그리고 효과적으로 아마 훨씬 쉬울 것입니다 힘내 사용하는 이해이 흡수하는 중요한 부분이다 당신을 위해. 보시다시피, 망할놈의 내용은 당신이 서브와 퍼포 같은 다른 VCSs에 대해 알고있을 것을 당신의 마음을 비우려고; 일을 이렇게하면 도구를 사용하여 섬세하고 혼동을 피하기 위해 도움이됩니다. 그것을 사용하는 동안 힘내 매장과 생각에 대한 정보를 많이 다르게 이러한 다른 시스템에 비해, 비록 사용자 인터페이스가 매우 유사합니다; 그 차이를 이해 해지고 혼란스러워하지 못하도록 도움이됩니다.
+필요한 의존성을 다 해결하고 다음 단계를 진행한다. Git 웹 사이트에서 최신 snapshot을 가져온다:
-### 스냅샷, 아니 차이점 ###
+ http://git-scm.com/download
+
+When you have all the necessary dependencies, you can go ahead and grab the latest snapshot from the Git web site:
-힘내 및 기타 VCS는 사이에 큰 차이 (Subversion을 친구 포함) 방식으로 힘내이며 데이터에 대해 생각한다. 개념, 파일의 변경 사항 목록을 기반으로 대부분의 다른 시스템 정보를 저장합니다. 이러한 시스템 (CVS는, Subversion을, 퍼포, 바자 등) 그들은 파일의 설정 및 변경 시간이 지남에 따라 각 파일에 만들어진만큼 그림 1-4에서 그림과 같이 계속 정보를 같아요.
+ http://git-scm.com/download
-Insert 18333fig0104.png
-그림 1-4. 다른 시스템의 각 파일의 기본 버전을 변경 데이터를 저장하는 경향이있다.
+그리고 컴파일하고 설치한다:
+
+ $ tar -zxf git-1.7.2.2.tar.gz
+ $ cd git-1.7.2.2
+ $ make prefix=/usr/local all
+ $ sudo make prefix=/usr/local install
-힘내 생각하지 않습니다 이런식으로 데이터를 저장할 수있습니다. 대신, 힘내 자사의 데이터를 미니 파일 시스템의 스냅샷을 설정처럼 생각한다. 매번 당신은, 커밋 또는 힘내에서 귀하의 프로젝트의 상태를 저장하면 기본적으로 모든 파일을 그 순간에 매장이 스냅샷에 대한 참조를 어떻게 생겼는지 사진 걸립니다. 효율적으로, 만약 파일이 변경되지 않은, 힘내 파일을 다시 저장하지 않습니다 단지 링크가 이미 저장된 파일은 이전과 동일. 힘내 그림 1-5처럼 데이터에 대해 생각한다.
+Then, compile and install:
-Insert 18333fig0105.png
-그림 1-5. 시간의 경과에 프로젝트의 스냅샷으로 망할놈의 데이터를 저장합니다.
+ $ tar -zxf git-1.7.2.2.tar.gz
+ $ cd git-1.7.2.2
+ $ make prefix=/usr/local all
+ $ sudo make prefix=/usr/local install
-이 망할놈의 거의 모든 다른 VCSs 사이에 중요한 차이가있습니다. 그 망할놈의 대부분의 다른 시스템에 이전 세대에서 복사한 버전 제어의 거의 모든 측면을 재고해 수있습니다. 이것은 약간의 대단히 강력한 도구를 꼭대기에 지어진 것이 아니라 단순히 VCS는 함께 미니 파일 시스템을 더 힘내 수있습니다. 귀하의 데이터를 이런식으로 우리가 제 3 분기 망할놈의 덮개를 생각하여 이득의 일부 혜택을 탐험합니다.
+그 다음부터는 Git을 사용하여 Git 자체를 업데이트할 수 있다:
-### 거의 모든 작업 로컬 ###
+ $ git clone git://git.kernel.org/pub/scm/git/git.git
+
+After this is done, you can also get Git via Git itself for updates:
-힘내에서 대부분의 작업에만 작동하도록 - 일반적으로 어떠한 정보도 네트워크상의 다른 컴퓨터에서 필요한 로컬 파일과 리소스를 필요합니다. 만약 당신이 CVCS를 사용하는지, 어디에 대부분의 작업, 망할놈의 관점에서 그 속도의 신들이 속세를 떠난 능력이 망할놈의 축복을 생각하게됩니다 네트워크 지연 오버헤드가있다. 왜냐하면 당신이 로컬 디스크에있는 프로젝트는 바로 거기의 전체 역사를 가지고 대부분의 작업을 거의 즉각 보인다.
+ $ git clone git://git.kernel.org/pub/scm/git/git.git
+
+### Installing on Linux ###
+리눅스에 설치하기
-예를 들어, 힘내 서버로 가서 역사를 그리고 당신을위한 표시가 필요하지 않습니다 그것은 단순한 직접 로컬 데이터베이스에서 읽습 프로젝트의 역사를 탐색할 수있습니다. 이렇게하면 거의 즉시 프로젝트 역사를 볼 것을 의미합니다. 만약 변경 사항을 파일의 현재 버전 개월 전 파일 사이의 도입을보고 싶어, 힘내 개월 전 파일을 로컬 차이를 계산을 할 대신하거나 원격 서버에 요청하는 데 그것을 어떻게 찾아볼 수있습니다 또는 로컬로 그것을 할 원격 서버에서 파일의 이전 버전을 당겨.
+리눅스에서 인스톨러로 Git을 설치할 때에는 보통 각 배포판에서 사용하는 패키지 관리도구를 사용하여 설치한다. Fedora에서는 다음과 같이 한다:
-이것은 또한 당신이 오프라인을 켜거나 VPN에 매우 당신이 할 수 없어 조금 남아있는 것을 의미합니다. 만약 당신이 비행 기나 기차를 타고 가서 일을 좀하려면, 당신이 행복까지 업로드 네트워크 연결에 도착 커밋 수있습니다. 만약 당신이 집에 가서 귀하의 VPN 클라이언트가 올바르게 작동 얻을 수 없다, 당신은 여전히 사용할 수있습니다. 많은 다른 시스템에서는, 이렇게하면 하나 또는 고통스러운 것은 불가능하다. 퍼포스 있음, 예를 들면, 당신은 당신이 서버에 연결되지 않은 할 수 없어, 그리고 CVS에서 Subversion을 그리고, 당신이 파일을 편집할 수 있지만 귀하의 데이터베이스 (되었기 때문에 데이터베이스)가 오프라인 상태 변경 내용을 커밋 수없습니다 . 이것은 큰 거래를 보이되지 않을 수도있습니다,하지만 당신은 그것을 큰 차이가 무엇을 할 수 놀랄 수있습니다.
+ $ yum install git-core
-### 망할놈의 무결성가 ###
+If you want to install Git on Linux via a binary installer, you can generally do so through the basic package-management tool that comes with your distribution. If you’re on Fedora, you can use yum:
-힘내에서 모든 체크하기 전에 그것 저장되어 다음에 그 체크섬에 의해 참조된입니다 요약될. 이렇게 힘내하지 않고 그것에 대해 아는 모든 파일이나 디렉토리의 내용을 변경 불가능을 의미합니다. 이 기능은 GIT에 최저 수준에와 철학에 필수적인 부분입니다 내장되어있습니다. 당신은 교통 정보를 잃을 수 없거나 힘내 그것을 감지할 수없이 손상이 파일을 가져올.
+ $ yum install git-core
-망할놈의 메커니즘이 checksumming에 대한은 SHA - 1 해시 전화를 사용합니다. 이것은 40 - 문자 문자열을 16 진수 문자 (0-9 및 구성되어 - f 옵션) 및 힘내에서 파일이나 디렉토리 구조의 내용을 기반으로 계산됩니다. 은 SHA - 1 해시는 다음과 같이 보입니다 :
+Ubuntu같은 데비안 기반 배포판이라면 apt-get을 사용한다:
-24b9da6552252987aa493b52f8696cd6d3b00373
+ $ apt-get install git-core
-너 때문에 너무 많이 사용 그들이 해시는 망할놈의 여기저기 값을 볼 수있습니다. 사실, 파일 이름을하지 않음으로써 힘내 상점 빼고는 다 망할놈의 데이터베이스에있는 내용의 해시 값에 의해 처리할 수.
+Or if you’re on a Debian-based distribution like Ubuntu, try apt-get:
-### 힘내 일반적으로 데이터만 추가 ###
+ $ apt-get install git-core
-하면, 힘내에서 작업을 할 거의 모든 그들의 유일한 망할놈의 데이터베이스에 데이터를 추가할 수있습니다. 그것은 매우 취소할 수 없거나 어떤 방식으로 데이터를 지울 수 있도록 아무것도 할 시스템 어렵습니다. 모든 VCS는 마찬가지로, 당신은 잃을 수있다 또는 당신이 아직 커밋되지 않은 변경 사항을 엉망으로,하지만 후에 GIT에 스냅샷을 커밋, 그것은 매우 어렵습니다 잃고, 특히 만일 당신이 정기적으로 다른 저장소 데이터베이스를 밀어.
+### Installing on Mac ###
+Mac에 설치하기
-우리가 심각하게 일을 망쳐의 위험없이 할 수있는 실험을 아는 기쁨이 망할놈를 사용합니다. 힘내 저장하는 방법에 자사의 데이터를 심도 좀 더 당신이 어떻게 볼 것 잃어버린 데이터를 복구할 수있다 "덮어 아래에서"제 9있습니다.
+Mac에 Git을 설치하는 방법은 두 가지다. 가장 쉬운 방법은 GUI 인스톨러를 사용하는 방법이다. 이 것은 Google Code 페이지에서 다운받을 수 있다:
-### 3 미국 ###
+ http://code.google.com/p/git-osx-installer
-자, 주목을 지불해야합니다. 이렇게하면 원활하게 이동하여 학습 과정의 나머지 원하는 힘내 대한 기억 중요한 건입니다. 망할놈의 세 가지 기본 상태는 귀하의 파일에 거주하고있습니다 :이,, 수정 및 개최 헌신. 최선을 다하고 뜻을 안전하게 데이터를 로컬 데이터베이스에 저장됩니다. 수정된 것을 의미하지만 그 파일을 변경하여 데이터베이스에 아직 커밋되지 않은있습니다. 즉, 당신이 옆에있는 스냅샷을 커밋에 들어가 현재 버전에서 수정된 파일을 표시한 연출한.
+There are two easy ways to install Git on a Mac. The easiest is to use the graphical Git installer, which you can download from the Google Code page (see Figure 1-7):
-이 망할놈의 프로젝트의 세 가지 주요 섹션에 우리가 리드 : 망할놈의 디렉토리, 작업 디렉토리, 그리고 준비 영역입니다.
+ http://code.google.com/p/git-osx-installer
-Insert 18333fig0106.png
-그림 1-6. 작업 디렉토리, 지역의 준비, 그리고 자식 디렉터리에있습니다.
+Insert 18333fig0107.png
+Figure 1-7. Git OS X installer.
+그림 1-7. OS X Git 인스톨러.
-힘내 힘내 디렉토리는 어디에 저장하여 프로젝트에 대한 메타 데이터 및 개체를 데이터베이스. 이 망할놈의 가장 중요한 부분이며, 무엇을하면 다른 컴퓨터에서 저장소를 복제 복사입니다.
+다른 방법은 MacPorts(`http://www.macports.org`)를 사용한 방법이다. MacPorts가 설치돼 있으면 다음과 같이 Git을 설치한다:
-작업 디렉토리 프로젝트의 버전 중 하나 하나 체크 아웃됩니다. 이러한 파일은 망할놈의 디렉토리에 압축 데이터베이스의 철수하고 당신을 사용하거나 수정하여 디스크에 배치.
+ $ sudo port install git-core +svn +doc +bash_completion +gitweb
-준비 영역에 파일을 간단하고, 일반적으로 여러분 힘내 디렉토리에, 그게 다음 커밋에 들어갈 예정에 대해 정보 저장소에 포함되어있습니다. 그것은 때때로 지수라고도했지만, 그것을 위해 표준을 준비 영역으로 참조되고 있어요.
+The other major way is to install Git via MacPorts (`http://www.macports.org`). If you have MacPorts installed, install Git via
-기본 힘내 워크플로우 이런 식입니다 :
+ $ sudo port install git-core +svn +doc +bash_completion +gitweb
-1. 귀하의 작업 디렉토리에있는 파일을 수정할 수있습니다.
-2. 당신은 당신의 준비 영역에 그들의 스냅샷 파일을 추가 단계입니다.
-3. 당신, 이는 그들이 준비 지역 상점에있는 파일을 커밋 할 필요가 스냅샷을 여러분 힘내 디렉터리를 영구적으로합니다.
+이제 설치에 대한 모든 것은 알아봤다. 그렇지만 만약 Subversion 레파지토리를 Git과 함께 사용해야 하는 경우라면 svn도 필요할 것이다.
-만약 파일의 특정 버전의 자식 디렉터리에있는 경우, 그것을 최선을 다하고 고려됩니다. 하지만, 만약 수정이 준비 영역에 추가되었습니다, 그것을 개최합니다. 그리고 이후지만, 체크 아웃 개최되지 않은 경우가 변경되었습니다, 그것을 수정합니다. 제 2 장, 당신은 이러한 상태에 대해 자세히 살펴보겠습니다 방법 중 하나를 그들을 활용할 수 있으며 완전히 연출된 부분을 건너 뛰십시오.
+You don’t have to add all the extras, but you’ll probably want to include +svn in case you ever have to use Git with Subversion repositories (see Chapter 8).
-### 설치 힘내 ###
+### Installing on Windows ###
+윈도우에 설치하기
-좀 힘내을 사용하여 들어가 보자. 중요한 것부터 먼저 - 당신이 그것을 설치해야합니다. 당신은 여러 가지 방법으로 얻을 수 있으며 두 가지 중요한 것들 원본하거나 설치하는 데 필요한 플랫폼을위한 기존의 패키지를 설치하고있습니다.
+윈도우에 Git을 설치하는 것은 매우 쉽다. msysGit 프로젝트가 가장 쉬운 방법이다. 그냥 구글 코드 페이지에서 인스톨러를 다운받고 실행하면 된다:
-### 설치 소스에서 ###
+ http://code.google.com/p/msysgit
-만약 당신이 할 수 있기 때문에 당신이 가장 최근 버전을받을거야, 일반적으로 원본 망할놈의 설치에 유용합니다. 망할놈의 각 버전에 유용한 UI가 개선을 포함, 그래서 최신 버전을 받고 경향이 종종 느낀다면, 네가 소스로부터 소프트웨어를 컴파일하고 편안하게 최상의 경로입니다. 또한 많은 리눅스 배포판은 아주 오래된 패키지를 포함하는 경우; 그렇게하지 않으면 매우 올라있어 - 최고의 내기있을 수있습니다 - 최신 배포판 또는 백포트를 사용하는 경우 소스에서 다시 설치하십시오.
+Installing Git on Windows is very easy. The msysGit project has one of the easier installation procedures. Simply download the installer exe file from the Google Code page, and run it:
-힘내 설치하려면, 당신은 그 망할놈에 따라 다음과 같은 라이브러리 :,,, expat하려면 openssl zlib을 곱슬 곱슬하게 가지고, 필요 libiconv. 예를 들어, 만약 당신이 시스템에 냠 페도라 (예) 또는 apt - get을 가지고있어 (데비안 기반의 시스템과 같은), 당신의 모든 종속성을 설치하려면 다음 명령 중 하나를 사용할 수있습니다 :
+ http://code.google.com/p/msysgit
-$ 냠 곱슬 곱슬 - devel expat - devel로 gettext - devel \ 설치
-zlib을하려면 openssl - devel - devel
+설치가 완료되면 CLI와 GUI 둘 다 사용할 수 있다. CLI에는 유용할게 사용할 수 있는 SSH 클라이언트가 포함돼 있다.
-$는 apt - dev에 gettext를 \ - gnutls - dev에 설치 얻을 libexpat1 libcurl4
-libz - dev에
+After it’s installed, you have both a command-line version (including an SSH client that will come in handy later) and the standard GUI.
-때 필요한 모든 종속성을 가지고 가서 수 망할놈의 웹 사이트에서 최신 스냅샷을 잡으 :
+## First-Time Git Setup ##
+처음으로 Git을 설정하기.
-http://git-scm.com/download
+Git을 설치했다면 Git의 사용 환경을 원하는 대로 설정하고 싶을 것이다. 단 한번만 설정하면 된다. 업그레이드를 해도 유지된다. 그리고 그냥 명령어를 다시 실행해서 언제든지 바꿀 수 있다.
-그럼, 컴파일 및 설치 :
+Now that you have Git on your system, you’ll want to do a few things to customize your Git environment. You should have to do these things only once; they’ll stick around between upgrades. You can also change them at any time by running through the commands again.
-$ 타르 - zxf 이눔아 - 1.6.0.5.tar.gz
-$ CD를 이눔아 - 1.6.0.5
-$ 접두어 =는 / usr / 모든 지역을
-$ sudo를 =는 / usr / 설치 로컬 접두사를 확인
+Git은 'git config'라는 쓸만한 도구를 가지고 있다. 이 도구로 설정 변수를 확인하거나 변경할 수 있다. 이 변수를 통해 Git이 어떻게 동작해야 할지를 제어할 수 있다. 이 변수들은 세가지 위치에 저장된다.
-후에이 완료되면, 당신도 힘내 자체를 통해 업데이 트에 대한 힘내 얻을 수있습니다 :
+Git comes with a tool called git config that lets you get and set configuration variables that control all aspects of how Git looks and operates. These variables can be stored in three different places:
-$ 이눔아 이눔아 클론 : / / git.kernel.org / 펍 / SCM에서 / 자식 / git.git
+* `/etc/gitconfig` 파일: 시스템의 모든 사용자와 모든 레파지토리에 적용되는 설정이다. `git config --system` 옵션으로 이 파일을 일고 쓸 수 있다.
+* `~/.gitconfig` 파일: 특정 사용자에게만 적용되는 설정이다. `git config --global` 옵션으로 이 파일을 읽고 쓸 수 있다.
+* Git 디렉토리에 있는 config 파일(`.git/config`): 특정 레파지토리에만 적용되는 설정이다. 각각의 설정은 역순으로 오버라이드된다. 그래서 `.git/config``/etc/gitconfig`보다 우선한다.
-### 설치 Linux에서 ###
+* `/etc/gitconfig` file: Contains values for every user on the system and all their repositories. If you pass the option` --system` to `git config`, it reads and writes from this file specifically.
+* `~/.gitconfig` file: Specific to your user. You can make Git read and write to this file specifically by passing the `--global` option.
+* config file in the git directory (that is, `.git/config`) of whatever repository you’re currently using: Specific to that single repository. Each level overrides values in the previous level, so values in `.git/config` trump those in `/etc/gitconfig`.
-만약 당신이 리눅스에서 바이너리 설치를 통해 힘내 설치하려면, 일반적으로 너무 기본적인 패키지를 통해 할 수있는 관리 도구는 귀하의 배포와 함께 제공됩니다. 만약 당신이 페도 라에있는거야, 당신은 냠 사용할 수있습니다 :
+윈도우에서 Git은 `$HOME` 디렉토리(`C:\Documents and Settings\$USER`)에 있는 `.gitconfig` 파일을 찾는다. 물론 msysGit은 /etc/gitconfig도 사용한다. 경로는 MSys 루트에 따른 상대 경로다. 인스톨러로 msysGit을 설치할 때 설치 경로를 선택할 수 있다.
-$ 냠 자식을 설치 코어
+On Windows systems, Git looks for the `.gitconfig` file in the `$HOME` directory (`C:\Documents and Settings\$USER` for most people). It also still looks for /etc/gitconfig, although it’s relative to the MSys root, which is wherever you decide to install Git on your Windows system when you run the installer.
-아니면 당신이 데비안에 있어요 - 우분투 같은 배포판을 기반으로, 시도는 apt - get은 :
+### Your Identity ###
+아이덴터티
-$는 apt - 이눔아 설치 얻을 코어
+Git을 설치한 후에 가장 처음으로 해야 하는 것은 이름과 이메일 주소를 설정하는 것이다. 이 것은 매우 중요하다. Git은 커밋할 때마다 이 정보를 사용한다. 커밋한 후에는 정보를 변경할 수 없다.
-### 설치 Mac에서 ###
+ $ git config --global user.name "John Doe"
+ $ git config --global user.email johndoe@example.com
-저기 힘내 Mac에서 설치하는 두 가지 간단한 방법입니다. 가장 쉬운 방법 (그림 1-7 참조) : 당신이 구글 코드 페이지로부터 다운로드할 수있습니다 그래픽 망할놈의 설치, 사용하는 것입니다
+The first thing you should do when you install Git is to set your user name and e-mail address. This is important because every Git commit uses this information, and it’s immutably baked into the commits you pass around:
-http://code.google.com/p/git-osx-installer
+ $ git config --global user.name "John Doe"
+ $ git config --global user.email johndoe@example.com
-Insert 18333fig0107.png
-그림 1-7. 힘내 OS X의 설치.
+다시 말하지만 `--global` 옵션으로 설정한 것은 단 한번만 하면 된다. Git은 해당 시스템에서 항상 이 정보를 사용한다. 만약 프로젝트마다 다른 이름과 이메일 주소를 사용하고 싶으면 `--global` 옵션을 빼고 명령을 실행하면 된다.
-다른 주요 방법을 통해 힘내 MacPorts를 설치하는 것입니다 (``) http://www.macports.org. 만약 당신이 망할놈의 설치를 통해 MacPorts 설치
+Again, you need to do this only once if you pass the `--global` option, because then Git will always use that information for anything you do on that system. If you want to override this with a different name or e-mail address for specific projects, you can run the command without the `--global` option when you’re in that project.
-$ sudo를 포트에 자식을 설치 코어 + svn + 의사 + bash_completion + gitweb
+### Your Editor ###
+편집기
-모든 엑스트라를 추가할 필요는 없지만, 아마 당신을 포함하기를 원할거야 + svn 경우 혹시 Subversion은 저장소와 (제 8 장 참조) 힘내 사용해야합니다.
+내가 누구인지를 설정했다. 이제는 Git에서 사용할 텍스트 편집기를 고를 차례다. Git은 시스템의 기본 편집기를 사용한다. 일반적으로는 Vi나 Vim이다. 하지만 Emacs같은 다른 텍스트 편집기를 사용하고 싶으면 다음과 같이 실행한다:
-### 설치 윈도우에서 ###
+ $ git config --global core.editor emacs
-힘내 Windows에서 설치 매우 간단합니다. msysGit 프로젝트는 하나 쉽게 설치 절차했다. 간단히 말하면, 구글 코드 페이지에서 설치 프로그램을 exe 파일을 다운로드하고 실행합니다 :
+Now that your identity is set up, you can configure the default text editor that will be used when Git needs you to type in a message. By default, Git uses your system’s default editor, which is generally Vi or Vim. If you want to use a different text editor, such as Emacs, you can do the following:
-http://code.google.com/p/msysgit
+ $ git config --global core.editor emacs
+
+### Your Diff Tool ###
+Diff
-후에 설치되어있는 경우 (즉, 들어올 것입니다 SSH 클라이언트를 포함하여 모두 명령줄 버전 이상) 및 표준 GUI를 편리.
+머지 충돌*conflict*을 해결하기 위해 사용하는 Diff 툴을 변경할 수 있다. vimdiff를 사용하고 싶으면 다음과 같이 실행한다:
-### 처음 힘내 설치 ###
+ $ git config --global merge.tool vimdiff
-이제 여러분의 시스템에 힘내 가지고 여러분 힘내 환경을 사용자 정의하는 몇 가지 일을하고 싶어합니다. 너 한번만 이런 일을해야한다; 그들은 업그레이 드를 사이에 제 곁에 계셔야합니다. 또한 명령을 다시 실행하여 언제든지 변경할 수있습니다.
+Another useful option you may want to configure is the default diff tool to use to resolve merge conflicts. Say you want to use vimdiff:
-망할놈의 도구를 함께 데려 및 구성 변수를 설정할 수있습니다 전화 오면 자식 구성하는 방법을 망할놈의 외모와 운영의 모든 측면을 통제. 이러한 변수는 세 가지 다른 위치에 저장되어있을 수있습니다 :
+ $ git config --global merge.tool vimdiff
-*`은 / etc /`파일을 gitconfig : 시스템에있는 모든 사용자와 모든 리포지 토리에 대한 값이 포함되어있습니다. 만일 당신이 옵션`을 통과 - 시스템`에`config를 자식, 그것을 읽고 해당 파일을 구체적으로부터 씁니다.
-*`~ /.`파일을 gitconfig : 사용자에게 특정. 넌 망할놈의 읽기 및이 파일에 특별히`-`글로벌 옵션을 전달하여 작성 할 수있습니다.
-자식 디렉터리에 * config 파일 (즉 .git,`은 /`설정) 현재 사용하고 계시는 어떤 저장소의 종류 : 단일 저장소에 특정. 각 단계는 이전 단계에있어서`.git 값을 값을 무시 /`트럼프의 이러한 설정은 / etc / gitconfig`.
+kdiff3, tkdiff, meld, xxdif, emerge, vimdiff, gvimdiff, ecmerge, opendiff를 사용할 수 있다. 물론 다른 도구도 사용할 수 있다. 7장에서 좀 더 자세하게 다룬다.
-Windows 시스템에서, 힘내````$ 홈 디렉토리에 (`에 C : \ 문서 및 설정 \ $ 사용자`대부분의 사람들에게) 파일 gitconfig. 찾습니다. 비록 그것이 어디에 있든 당신이 Windows 시스템에 설치하면 실행 망할놈의 설치를 결정합니다 MSys 루트, 상대의 그것은 여전히 / 용 등 / gitconfig 보인다.
+Git accepts kdiff3, tkdiff, meld, xxdiff, emerge, vimdiff, gvimdiff, ecmerge, and opendiff as valid merge tools. You can also set up a custom tool; see Chapter 7 for more information about doing that.
-### 귀하의 신원을 ###
+### Checking Your Settings ###
+설정 확인하기
-힘내하면 설치해야합니까 우선 사용자 이름과 전자 메일 주소를 설정하는 것입니다. 왜냐하면 모든 힘내 커밋이 중요한이 정보를 사용합니다, 그리고 그것을 immutably 당신 주위에 패스를 저지른에 덜떨어진 :
+내 설정을 확인하려면 `git config --list` 명령을 실행한다. 그러면 모든 설정 내역을 확인할 수 있다:
-$ 자식 설정 - 글로벌 user.name "John Doe의"
-$ 자식 설정 - 글로벌 user.email johndoe@example.com
+ $ git config --list
+ user.name=Scott Chacon
+ user.email=schacon@gmail.com
+ color.status=auto
+ color.branch=auto
+ color.interactive=auto
+ color.diff=auto
+ ...
-다시 말하지만, 당신이 한 번만 그 때문에 항상 힘내 시스템에서하는 일은 그 정보를 사용할 것입니다 만약 당신이`-`글로벌 옵션을 통과 이렇게해야합니다. 만약 당신이 다른 이름 또는 특정 프로젝트에 대한 전자 메일 주소와 함께이 오버 라이드하고 싶다면, 당신은`-`글로벌 옵션을 선택하지 않고 당신이 그 프로젝트에있어 명령을 실행할 수있습니다.
+If you want to check your settings, you can use the `git config --list` command to list all the settings Git can find at that point:
-### 당신의 에디터 ###
+ $ git config --list
+ user.name=Scott Chacon
+ user.email=schacon@gmail.com
+ color.status=auto
+ color.branch=auto
+ color.interactive=auto
+ color.diff=auto
+ ...
-이제 귀하의 신원을 구성할 수있습니다 힘내 입력하면 메시지에 당신을 필요로하는 데 사용됩니다 기본 텍스트 편집기 설정됩니다. 기본적으로, 힘내 일반적으로 귀하의 시스템의 기본 편집기를 사용 바이올렛 또는 Vim은. 만약 당신이 emacs와 같은 다른 텍스트 편집기를 사용하려면 다음 작업을 수행할 수있습니다 :
+Git은 같은 키를 여러 파일(`/etc/gitconfig` and `~/.gitconfig`같은)에서 읽기 때문에 같은 키가 하나 이상 나올 수도 있다. 이 경우에 Git은 나중 값을 사용한다.
-$ 자식 설정 - 글로벌 core.editor 이맥스
+You may see keys more than once, because Git reads the same key from different files (`/etc/gitconfig` and `~/.gitconfig`, for example). In this case, Git uses the last value for each unique key it sees.
-### 당신 Diff 도구 ###
+`git config {key}` 명령을 실행시켜 Git이 특정키에 대해 어떤 값을 사용하는지 확인할 수 있다:
-당신을 구성할 수있습니다 또 다른 유용한 옵션이 충돌 병합을 해결하는 데 사용하는 기본은 diff 도구입니다. 당신 vimdiff 사용하고자하는 말 :
+ $ git config user.name
+ Scott Chacon
-$ 자식 설정 - 글로벌 merge.tool vimdiff
+You can also check what Git thinks a specific key’s value is by typing `git config {key}`:
-힘내, kdiff3, tkdiff, xxdiff, vimdiff, gvimdiff, ecmerge 등장할 융합 수용 및 병합 도구를 유효로 opendiff. 당신은 또한 사용자 정의 도구를 설정할 수있습니다; 뭐하는 대한 자세한 내용은 제 7 장 보입니다.
+ $ git config user.name
+ Scott Chacon
-### 귀하의 설정 확인 ###
+## Getting Help ##
+도움말 보기
-만약 당신이 설정을 확인하려면, 당신이 망할놈의 그 지점에서 찾을 수있는 모든 환경 설정 목록에`명령`자식 설정 - 목록을 사용할 수있습니다 :
+명령어에 대한 도움말이 필요할 때 도움말을 볼 수 있는 방법은 세가지이다:
-$ 자식 설정 - 목록
-user.name = 스콧 Chacon
-user.email = schacon@gmail.com
-color.status = 자동
-color.branch = 자동
-color.interactive = 자동
-color.diff = 자동
-...
+ $ git help <verb>
+ $ git <verb> --help
+ $ man git-<verb>
-힘내 있기 때문에 다른 파일에서 읽습니다 키와 동일한 키를 두 번 이상 (`은 / etc / gitconfig`와`~ /.`gitconfig 볼 수있습니다, 예를 들면). 이 경우, 각각의 고유한 망할놈의 열쇠를보고 그것에 대한 마지막 값을 사용합니다.
+If you ever need help while using Git, there are three ways to get the manual page (manpage) help for any of the Git commands:
-또한, 망할놈의 특정 키 값을 ()`열쇠`config를 입력하여 자식이 무슨 생각을 확인할 수있습니다 :
+ $ git help <verb>
+ $ git <verb> --help
+ $ man git-<verb>
-$ 이눔아 설정 user.name
-스콧 Chacon
+예를 들어 다음과 같이 실행하면 config 명령에 대한 도움말을 볼 수 있다:
-### 도움말 얻기 ###
+ $ git help config
-힘내 사용하는 동안 있으면 도움이 절대 필요, 거기 매뉴얼 페이지 () 어떤 망할놈의 명령에 대한 도움을 맨페이지 : 얻을 세 가지 방법이있습니다
+For example, you can get the manpage help for the config command by running
-$ 이눔아 도움이 <verb>
-$ <verb> 이눔아 - 도움말
-$ 남자 이눔아 - <verb>
+ $ git help config
-예를 들어, 실행하여 설정 명령에 대한 맨페 도움을받을 수
+이 도움말은 언제 어디서나 볼 수 있다. 오프라인 상태에서도 가능하다. 도움말과 이 책으로도 충분하지 않으면 다른 사람의 도움이 필요할 것이다. Freenode IRC 서버(irc.freenode.net)에 있는 `#git`이나 `#github` 채널로 찾아가라. 이 채널은 보통 수 백명의 사람들이 접속해 있다. 이 사람들은 모두 Git에 대해 잘 알고 있다. 기꺼히 도와줄 것이다.
-$ 이눔아 도움이 구성
+These commands are nice because you can access them anywhere, even offline.
+If the manpages and this book aren’t enough and you need in-person help, you can try the `#git` or `#github` channel on the Freenode IRC server (irc.freenode.net). These channels are regularly filled with hundreds of people who are all very knowledgeable about Git and are often willing to help.
-당신이 아무데도 오프라인에서 액세스할 수있는 이러한 명령은 잘됩니다.
-만약 man 페이지이 책은 충분하지하고 필요하면 freenode IRC 서버 (irc.freenode.net)에`# 자식`이나`# github`채널을 시도할 수있습니다 - 사람 도움이있습니다. 이러한 채널을 정기적으로 사람 모두 힘내 대해 자주 도움을하고자하는 지식입니다 수백명의 사람들이 가득합니다.
+## Summary ##
+요약
-## 요약 ##
+당신은 Git이 무엇이고 당신이 지금까지 사용해 왔던 다른 CVCS와 어떻게 다른지 배웠다. 또 당신의 시스템에 Git을 성공적으로 설치하고 아이덴티티도 설정했다. 이제는 Git의 기초에 대해 배울 차례이다.
-당신은 어떻게 당신이 사용되었을 수도있습니다 CVCS 다른 무엇이 망할놈의 기본적인 이해해야합니다. 당신은 또한 현재 여러분의 시스템에 대한 사용자의 개인 신원을 함께 설정이 망할놈의 작업 버전이 있어야합니다. 지금은 어떤 망할놈의 기초를 배울 시간이야.
+You should have a basic understanding of what Git is and how it’s different from the CVCS you may have been using. You should also now have a working version of Git on your system that’s set up with your personal identity. It’s now time to learn some Git basics.
Please sign in to comment.
Something went wrong with that request. Please try again.