1.3 시작하기 - Git 기본기

1.3 시작하기 - Git 기본기

Git 기본기

그래서, 간단히 말해서 Git가 무엇인가? 이번 섹션은 정보를 받아들이기 위해서 매우 중요하다. 왜냐하면 당신이 Git가 무엇인지, 그 것이 작동하는 원리를 안다면, Git를 사용하는 것이 분명히 훨씬 쉬워질것이기 때문이다. 당신은 Git를 배웠기 때문에, 다른 VCS(Subversion 그리고 Perforce)들과 무엇이 다른지 구분지을 수 있도록 노력해야한다.; 이렇게 함으로써 당신이 이 툴을 사용할때 생기는 미묘한 혼동들을 피하는데 도움이 될것이다.Git는 유저 인터페이스가 비슷할지라도 다른 시스템에 비해서 정보들을 아주 다르게 생각하고 저장한다.; 이러한 다른점을 이해하는 것 자체가 당신이 이 툴을 사용하는 동안 생길지 모르는 혼동으로부터 당신을 보호해줄것이다.

Snapshots, 차이점이 없다

Git와 다른 VCSs 들과의 가장 큰 다른점은 바로 Git가 데이터를 생각하는 방법이다. 개념적으로 대부분의 다른 시스템은 파일중심의 변경된 리스트들을 정보로 저장한다. 그러한 시스템들은(CVS, Subversion, perforce, Bazaar 기타 등등) 그들이 유지시켜야 하는 정보들을 매번 변경이 이뤄진 파일들의 한 세트 단위들이라고 생각하고 Fiqure1-4와 같이 표현할 수 있다.

                         
Figure 1-4. Other systems tend to store data as changes to a base version of each file.

Git는 이런 데이타들을 이런 방식으로 생각하지도, 저장하지도 않는다. 대신에, Git는 이런 데이터를 미니 파일시스템의 스냅샵같이 취급한다. 매번 커미트를 할때마다, 또는 Git 내 프로젝트의 상태를 저장할 때마다, Git는 기본적으로 그 당시의 파일들의 상태들에 대한 사진을 찍고, 그 스냅샵에 대한 레퍼런스를 저장한다. 그리고 만약에 파일들이 변경이 되지 않았다면,효율을 높이기 위해서 Git는 그 파일을 다시 저장하지 않고 대신 그전에 이미 저장된 똑같은 파일을 연결한다. Git는 데이터를 Figure 1-5 그림처럼 생각한다.

                  
Figure 1-5. Git stores data as snapshots of the project over time.

이것은 Git와 거의 모든 다른 VCSs사이의 매우 중요한 다른 점이다.이러한 점은 Git로 하여금 다른 시스템들이 이전 세대로부터 그대로 복사해온 버젼 컨드롤의 거의 모든 방면을 다시 생각하게 만들었습니다. 이것은 Git를 무엇보다도 매우 강력한 툴을 가진 미니 파일시스템처럼 만들었다. 우리는 3장에서 Git 브런칭을 다루면서 Git가 데이터를 이런방식으로 처리함으로써 얻을 수 있는 몇가지 장점에 대해서 알아볼것이다.

대부분의 작업은 로컬에서 이루어진다.

Git 내 거의 대부분의 작업들은 오직 내부 파일들과 자원들만 필요하다.-보통 다른 네트워크에 있는 다른 컴퓨터들의 정보들은 알필요가 없다. 만약 당신이 네트웍 대기시간의 부하를 줄수 있는 대부분의 작업들을 하는 CVCS를 사용하고 있다면, Git의 이러한 측면은 당신으로 하여금 속도의 신들이 속세의 힘에 관심이 없는 Git를 축복하고 있다고 생각하게 할것이다. 왜냐하면, 당신은 당신의 로컬 디시크에 대부분 즉각적으로 실행된거처럼 보이는 프로젝트의 모든 히스토리를 가지고 있기 때문이다..

예를 들어, 프로젝트의 히스토리를 찾가 위해서, Git는 히스토리를 얻고 화면에 보여주기 위해서 외부서버에 접속할 필요가 없다. 단순히 당신의 로컬 데이타 베이스에 직접 붙어 읽어오면 된다. 이것은 당신이 프로젝트의 히스토리를 거의 실시간적으로 볼 수 있다는 의미이다. 만약 당신이 현재 버젼의 파일들과 몇 달전의 파일들간의 변경사항을 보고 싶다면, Git는 외부의 서버에 요청하거나 예전 버젼의 파일을 리모트 서버로 부터 가져올 필요 없이, 내부적으로 몇달전의 파일들을 찾아서 내부 변경사항을 찾을 수 있다.

이것은 물론 당신의 오프라인이거나 VPN 연결을 하고 있지 않은 상태에서도 제한되는 사항이 거의 없다는 것을 의미한다. 만약 당신이 비행기나 기차에서 어떤 작업을 하고 싶을때 당신은 업로드를 하기 위한 네트웍 연결이 되기 전까지  행복하게 커밋트를 할수 있다. 당신이 집에 가는 길에는 물론 VPN연결이 제대로 되지 않겠지만 작업은 계속 할수 있다. 많은 다른 시스템에서는 이런건 불가능하고 매우 불편한 점이다. Perforce에 경우에는 서버에 연결이 되지 않는 동안 당신은 많은 것을 할수 없다; Subversion과 CVS의 경우엔 파일을 수정을 할수 있지만 커밋을 할 수 없다.(데이터베이스에 연결을 할 수 없기 때문에) 이것은 그다지 큰 문제처럼 보이지 않지만, 당신은 이 큰 다른점이 만들어내는 것들때문에 놀랄것이다.

Git 는 무결성을 보장한다.

Git내 모든 것은 그것들이 저장되거나 참조를 하기 전에 체크요약을 한다. 이말은 Git가 알지 못하는 그 어떤 파일, 디렉토리 그리고 컨텐츠의 변경은 불가능 하다는 의미이다. 이것은 Git의 가장 낮은 레벨에 적용되어 있고 Git의 철학에 필수적인 기능이다. 당신은  Git가 포착할 수 없는 그 어떠한 정보(이동중이거나 문제가 발생했던)도 잃어버릴수 없다.

Git가 CheckSum을 하기위해 사용하는 이 메카니즘은 SHA-1 hash라고 부른다. 그리고 이것은 16진법 캐릭터로 구성된 40개의 캐릭터 문자이고, 이는 Git 내 파일이나 디렉토리구조의 컨텐츠를 기반으로 계산된다. SHA-1 해쉬는 다음과 비슷한 모습이다.

24b9da6552252987aa493b52f8696cd6d3b00373

Git는 해쉬값을 너무나 많이 이용하기 때문에 당신은 Git내에서 이러한 해쉬값을 자주 보게 될것이다. 사실, Git는  Git 데이타베이스안에서 모든것들을 파일기준으로 저장하지 않고, 매 컨텐츠의 해쉬값을 이용한다..

Git는 보통 데이터만 추가한다.

당신이 Git에서 어떤 행동을 취할때면 거의 모든 행동들은 오직 데이터만을 Git 데이터베이스에 추가하게 된다. 시스템으로 하여금 실행할 수 없는 것들을 강제로 하게끔 하거나, 어떤 방법으로도 데이터를 지우게 하는것은 매우 힘들다. 다른 VCS 에서처럼 당신은 당신이 그전에 커밋트하지 않는 변경사항을 잃어버리거나 망쳐버릴수 있다; 그러나 Git에 snapshot을 커밋트한 이후에는 잃어버리기 굉장히 어렵고, 특히 당신은 규칙적으로 당신의 데이터 베이스를 다른 저장소에 넣는다면 더더욱 정보를 잃어버리기 어렵다.

이것은 Git를 이용한다는 것을 즐겁게 만든다. 왜냐하면 우리는 심각하게 망칠수 있다는 위험없이 실험을 할 수 있다는 것을 알고 있기 때문이다. 좀 더 자세하게 Git가 어떻게 데이터를 저장하고 어떻게 데이터를 복구하는지에 알고 싶다면 챕터 9를 참고해라.

세가지 단계 상태

자, 지금부터 집중하도록 해라. 만약에 당신이 앞으로 배워야 할것도 무리없이 진행하고 싶다면 이 부분은 Git에 대해서 기억해야 하는 가장 중요한 것이다. Git는 당신의 파일이 속할 수 있는 3가지 상태를 가지고 있다; 커밋트, 변경(modified) 그리고 스테이지. 커밋트란 데이터가 안전하게 당신의 로컬 데이터 베이스에 저장되었다는 의미이다. 변경(modified)란 당신이 파일을 변경했지만 아직 당신의 데이터베이스에 아직 커미트를 하지 않은 상태이다. 스테이지란 당신이 변경된 파일을 다음 커미트 스냅샵으로 갈 수 있는 현재의 버젼이라고 표시했다는 의미이다.

이것은 우리를 하나의 Git 프로젝트에 3개의 중요 섹션이 있다는 것을 알려준다;  Git 디렉토리, Working 디렉토리 그리고 스테이징 장소.

 
Figure 1-6. Working directory, staging area, and git directory.

Git 디렉토리는 Git가 메타데이터와 객체 데이터베이스를 저장하는 곳이다. 이것은 Git에서 가장 중요한 부분이다. 그리고 이 곳이 당신이 다른 컴퓨터의 저장소를 Clone할때 실제 복사 되는 것들이다.

Working 디렉토리는 그 프로젝트의 한 버젼이 체크아웃되는 곳이다. 이곳의 파일들은 Git 디렉토리안에 압축된 데이터베이스부터 빠져나왔으며 당신이 사용하거나 변경을 할 수있도록 디스크에 위치한다.

스테이징 공간은 간단한 파일이고, 보통 Git 디렉토리안에 포함된다.그리고 무엇이 다음 커밋트 될것인가에 대한 정보들이 저장된다. 가끔은 이것은 인덱스라고하지만, 그것은 준비영역으로 참조 할 표준이 된다.

기본적인 Git 워크플로우는 다음과 같이 된다:

1. 당신은 파일들을 당신의 Working 디렉토리에서 변경한다.
2. 당신은 변경된 파일들을 스냅삽을 추가함으로써 당신의 스테이징 공간으로 올린다.
3. 당신은 커밋트를 한다. 커밋트를 한다는 것은 스테이징에 올라와 있는 파일들을 가지고 와서 그 스냅샵을 Git 디렉토리에 영원토록 저장시킨다는 의미이다.

만약에 특정 버젼의 파일이 git 디렉토리에 있다면 그것들은 이미 커미트 되었다고 할수있다. 그리고 만약 변경된 파일이 스테이징 디렉토리에 추가되었다면 이 파일들은 커미트가 될 준비가 되었고 stage되었다고 한다. 또 만약에 체크 아웃을 한 이후에 변경된 파일이 있고 아직 stage하지 않았다면 이것은 변경이라고 한다.
챕터2에서는 당신은 이런 단계에 대해아여 더 많은 것을 배우게 될것이고 어떻게 그것들의 장점을 사용하는지에 배우고 또 staged 단계를 아예 건너띄는 방법을 배우게 될것이다.