Git

Git 역사

Bum_2 2024. 4. 30. 19:17

실제 활용할 기능들이 왜 만들어졌는지에 대한 이해를 돕기위해 살펴보자.

 

Git의 역사와 특징

 

Linux 커널 프로젝트를 지원하기 위해 만들어진 버전 관리 도구로 시작

파일 관리(1991 ~ 2002) -> BitKeeper(2002 ~ 2005) -> Git 탄생 (2005) -> GUI 지원( 2008 ~ )

 

BitKeeper : 분산 지원형 프로그램이지만 리눅스 토발즈는 부족한 기능을 만들기 위해 Git을 개발한다고 선언
Git : 커널 형태로만 지원

 

중앙 집중형 VS 분산 관리형

 

중앙집중형 : 중앙에 있는 서버에 단말이 돼서 사용자가 버전을 만들 소스를 올리면 이 서버에서 받은 파일을 가지고 메타 데이터를 구분해서 revision을 만들게 된다. 네트워크가 끊긴 상태에서는 버전관리를 못함
(중앙 통제가 장점이자 단점)

 

분산 관리형 : 버전이 생성되는 시점이 내 로컬에서 내가 버전을 생성, git에서 리비전의 기능을 커밋 아이디 역할을 한다. 

중앙에 있는 서버는 만들어진 버전을 모으는 역할만 하며 직접 만들지는 않는다. 

=> 버전 관리의 주체는 서버가 아닌 사용자가 된다는 것이 가장 큰 차이점

Git의 특/장점 (Git이 내놓은 공식 입장)

 

1. 빠른 속도 

Git은 스냅샷 구조로써 이 소스 파일을 그대로 내 로컬에 저장하는 구조라서 버전 생성 속도가 빠르다.

(네트워크 연결 속도 등 때문에 하지만 다양한 패턴 환경에서 모두 빠르다고 단언하기는 어렵다.)

 

2. 자유로운 버전 생성과 공유

자신의 로컬에 무수한 버전을 만들어 낼 수 있기 때문에, 다른 기능을 같은 파일에서 구현하고자할 때 부차적인 (기본 파일 복사 등) 작업을 하지 않아도 된다.

나에게 의미있는 버전은 내 로컬에만 저장하고 공식적으로 의미있는 버전은 원격 Repo에 전달하는 구조로 작업을 할 수 있도록 한다.

 

3. 원할한 복구

 네트워크로 접속을 하지 않기 때문에 소스 코드에 문제가 발생했을 때 로컬에서 과거 이력, 변경된 이력을 복구 가능하다.

(실상 예. 토이스토리2 중 소스코드가 개봉을 앞두고 다 날아가는 사태, 한 명이 자택근무를 하며 Git Repo에 코드를 저장하면서 최소한의 손실로 당일에 개봉할 수 있었다.)

 

Git의 구조

 

Git의 버전 저장 구조는  SnapShot방식이다.

커밋을 할 때 마다 변경된 파일만 저장되면서 생성되는 구조. 

리버스 델타는 중간의 버전 하나가 사라져도 마지막 버전이 모든 델타 정보를 갖고 있기 때문에 괜찮지만 Snapshot의 중간 버전을 지우는 것이 굉장히 어려워진다.

 

마스터에 브랜치에대해 쭉 진행되는 이력



우측 상단에서 Type 중 Blob은 파일을, Tree는 폴더를 의미한다. 각각은 SHA-1의 고유 주소를 갖고 있는다. 실제 파일명이 포함된다.

배열에 대한 포인터 주소값이 오브젝트로 표현되면서 오브젝트의 주소로 저장이된다. 하나의 배열 구조는 트리로 구성된다.

좌측에는 Object의 Parent는 내 앞 버전의 해시 코드, Tree는 하나의 배열을 가지고 주소값을 갖고 있던 변경분에 대한 정보. 이 트리에 대한 주소값을 갖고 있는다.

 

중간 커밋 내용을 바로 지울 수 없다. 두번째의 Obj가 Parent를 갖고 있어서. 앞에 커밋 정보가 있어야지만 뒤에 커밋을 만들수 있다.

 

하나의 브랜치에서는 하나의 길밖에 갈 수 없다.

Parent는 하나가 존재할 수도 있고 Child도 하나만 존재할 수 있다는게 기본 전제라는 것

예외는 아래 그림처럼 브랜치를 생성할 때 발생.

 

 

브랜치를 생각해 볼 때 가장 큰 차이점 실제 브랜치의 물리적인 내용을 복사해야 한다. 

하지만 Git은 브랜치 생성시, 포인터만 늘어날 뿐 파일에 대한 증감이 없다. 

 

git status에서는 head를 볼 수 있다.

head = 내가 작업하고 있는 공간

 

git은 브랜치를 활용(다양한 기능을 동시 작업)을 전제로 구현되어있다.

 

 

두 번째 공용 Repo는 Blessed Repo가 되었다.

중간에 인티그레이터가 정제해서 올렸기 때문에 그냥 받아서만 쓰면 되는 축복받은 Repo다. 

 

Dictator and Lieutenants Workflow

Lieutenants Workflow : 중간에 있는 integration 매니저 워크플로에 해당하는 구조

Dictator : 이것들이 모여서 한번더 정제되서 올라갈 때 Dictator이라는 구조

(ex. 한명이 10개의 커밋 * 10 => 100개의 커밋 * 협업 하는 회사 (2) = 200개의 커밋 중에서 의미있는 버전을 통제해서 가져가는 것)