[GIT] GIT을 선택하다. - 1편 GIT에 대하여

GIT에 대하여 ...

• 버전관리시스템(version control system, VCS)는 사용자 프로젝트에 포함된 파일의 변경사항을 추적할 수 있도록 돕는 방법론이나 도구를 말합니다.
• 분산 버전관리 시스템(Distributed version control system, DVCS)도 위와 같은 점에서 기존 버전관리 시스템과 차이가 없습니다. 다만 버전관리 시스템과 분산 버전관리 시스템은 개발자들 간의 변경사항을 반영하고 공유하는 방식이 다르다고 보면 됩니다.

저장소(Repository)

버전관리 시스템에서 저장소(Repository)는 사용자가 변경한 모든 내용을 추적하는 특별한 공간입니다. 대부분의 버전관리 시스템은 코드의 현재상태는 물론이고 변경이 언제 발생했는지, 누가 변경했는지, 변경사항을 설명하는 로그메시지까지 저장할 수 있습니다. CVS나 서브버전 같은 시스템은 중앙 집중식 저장소 모델을 따릅니다. 하나의 중앙 저장소가 있고 모두가 이 중앙 저장소에 변경사항을 전송 하게 됩니다. 각 개발자는 저장소의 최신버전을 복사해서 가지고 있고 이 본사본을 변경한 후에는 변경된 부분을 다시 중앙 저장소에 전송합니다. 이러한 중앙 집중식 저장소는 아래와 같은 한계가 있습니다.

• 사용자는 최신 버전의 코드만 가지고 있습니다. 변경이력을 보려한다면 저장소에  필요한 정보를 요청해야 합니다.
• 네트워크를 이용하여 원격 저장소로 접근해야 합니다.

위의 가장 큰 한계는 네트워크 부재시 기능 접근 제한에 있습니다. 인터넷에 연결할 수 없는 환경이라면 GIT이 따르는 분산 버전 관리 시스템의 가장 큰 장점 중 하나를 부각시키게 됩니다.

 

작업트리(Working Tree)

모든 변경은 작업트리에서 이루어 진다라고 보시면 되겠습니다. 작업트리란 저장소를 바라보는 자신의 현재 시점을 말합니다. 이 작업트리는 소스코드, 빌드파일, 단위테스트 등 프로젝트의 모든 파일을 가지고 있습니다. 몇몇 버전관리시스템에서는 작업트리를 작업 복사본(Working copy)이라 합니다.

git에서 작업트리는 로컬 컴퓨터의 프로젝트 디렉토리에 있는 .git/ 디렉토리에 존재합니다. 이 작업트리로 인해 저장소의 이력, 변경사항을 다른 서버에 있는 저장소와 통신 작업 없이 살펴 볼 수 있습니다.

 

파일컨트롤, 동기화

버전관리 시스템을 사용하는 주된 이유는 변경을 계속해서 추적하기 위함 입니다. 개발자는 소스코드를 변경하고, 잘못된 영향을(side effect)끼치지는 않았는지 단위테스트를 수행한 다음 커밋합니다. 변경사항을 커밋하면서 저장소에 새로운 리비전을 추가하고, 무엇을 변경했는지 설명하는 로그 메시지를 저장합니다. 바뀐 내용을 다른 개발자가 이용하게 하려면 먼저 변경사항을 공유해야 한다. 상위저장소(upstream repository)에 변경사항을 푸싱하면 바뀐 내용을 다른 개발자와 공유 할 수 있습니다.
상위저장소는 공용저장소로 다른 개발자 들도 변경사항을 푸싱할 수 있습니다. 푸싱은 데이터를 다른 개발자들과 공유하기 위해서 이거나 다른 저장소에 전송하려고 사용합니다. 변경사항을 푸싱하면 동기화에 필요한 작업의 절반을 수행한 것이며 나머지 절반은 다른 팀 멤버의 변경사항을 가져와 최신사항으로 갱신하여 완료합니다. 원격 git저장소에서 변경사항을 이용하려면 두 단계를 거쳐야 합니다.

1. 먼저 변경사항을 가져옵니다. 변경사항을 가져오면 원격 저장소에 있는 변경사항의 복사본이 생성됩니다. 이 단계는 푸싱의 반대 개념으로 볼 수 있습니다.

2. 그다음 변경사항을 지역이력과 병합합니다. git은 병합할때 훌륭한 도구를 제공합니다. 앞서 설명한 두 단계를 한번에 하도록 풀링이라는 기능을 지원합니다.

 

프로젝트, 디렉토리, 파일추적

최하위 계층에서 git은 저장소에 저장한 파일을 내용단위로 추적합니다. 이런 점에서 파일을 추적하는 여타 버전관리시스템과는 다르다고 볼 수 있습니다. git은 파일을 추적하는 대신 파일에 있는 변수나 함수 등을 구성하는 각 문자와 줄을 추적하며 이름, 파일모드, 빔볼릭 파일여부와 같은 메타데이터를 해당 파일에 추가합니다. 이러한 방식의 이점은 저장소의 전체 이력을 저장하는데 필요한 공간이 줄어듭니다. 또한 두 파일 사이에서 함수나 클래스의 이동을 알아내거나 어디에서 복사된 코드인지 결정하는 것과 같은 작업이 가능하며 빠릅니다.
모든 수정은 작업트리에서 일어납니다. 작업트리는 저장소에 대한 현재 시점을 표현하며 일련의 평범한 디렉토리와 파일로 이루어져 있습니다. git에서 저장소의 구조는 사용자가 원하는 대로 구성할 수 있습니다. 저장소에 파일과 디렉토리를 구성하는 방법은 프로젝트 따라 다릅니다. 프로젝트마다 새로운 디렉토리를 만들어 프로젝트 간에 이력을 공유 하도록 만들 수도 있고, 아니면 프로젝트마다 새로운 저장소를 만들어도 됩니다.

 

태그를 이용하여 마일스톤 추적하기

프로젝트를 진행함에 따라 마일스톤(milestone)에 도달하게 됩니다. 특정 마일스톤을 달성했을때의 저장소 상태를 추적할 수 있어야 합니다. 이때 사용하면 좋은 것이 tag입니다. 태그에 저장소 이력의 특정 위치를 기록해두면 나중에 편리하게 참조 가능합니다. 태그는 저장소 이력의 특정 시점을 기록하는 용도로 사용하는 이름일 뿐이며 공개 릴리즈 같은 주요 마일스톤이나 버그수정 같이 사소한 것들도 표현 할 수 있습니다.

 

브랜치로 분기이력 만들기

브랜치를 생성하면 파일이 분기하는 위치가 저장소에 기록됩니다. 브랜치는 다른 브랜치와 분리하여 내용에 대한 변경사항을 지속적으로 추적합니다. 그래서 분기이력을 생성할 수 있습니다. Master branch는 개발의 기본줄기입니다. 다른 버전관리 시스템에서 trunk라 불리웁니다.

브랜치로 생성하면 기본 줄기에서 분기됩니다. 브랜치는 계속 남겨두어도 되고 단 몇시간만 사용하도 되며 다른 브랜치와 합칠수도 있습니다. 프로젝트 이전의 주요버전을 추적하기 위한 브랜치일 수도 있고 나중에 지워버릴 생각인 실험용 브랜치 일 수도 있습니다. git 에서 브랜치도 다른 모든것과 마찬가지로 다른 사람과 공유하지 않고 지역적으로 생성할 수 있습니다.

병합(Merge)

두개나 심지어는 열 개 이상의 브랜치를 가져도 됩니다. 하지만 이런 경로 들을 하나로 합쳐서 함께 가야 할때가 있습니다. 이때 merge를 사용합니다. merge는 여러 브랜치의 이력을 하나로 합친다고 보면 되겠습니다..

 

읽으면 좋은 자료들..

• 공식사이트 : http://git-scm.com/

  명령어 모음 : http://blog.outsider.ne.kr/572

출처: https://redgolems.tistory.com/5?category=481635 [레드골렘즈 콤비의 개발이야기]