Git란
분산형 버전 관리 시스템이다. 기존 중앙 관리형 버전 관리 시스템에서는 서버에서 Snapshot을 Checkout 해 로컬에서 사용하는 방식과 달리, 저장소(repository)를 전부 복제해서 전체 시스템을 하나의 Client처럼 사용한다. 그래서 서버에 문제가 생겼을때, 소스 변경 작업이나 복구가 용이하다는 장점을 가지고 있다.
여담으로 Git가 생긴 이유는 Linux 커널 소스 버전 툴인 BitKeeper가 무료로 사용할 수 없다고 함에 따라 리누스 토발즈가 만든 툴이다.
Git의 지향점
- 빠른 속도
- 단순한 구조
- 비선형적 개발(수 천개의 동시 다발적 브랜치)
- 완벽한 분산
- 리눅스 커널과 같은 대형 프로젝트에서도 유용한 구조(속도, 데이터 안전성)
Git의 기초 이론
1. Commit 단위
기존 중앙 관리형 버전 관리 도구에서는 시간의 흐름에 따른 각각 파일들의 변화를 버전으로 만들어 관리했다.
이에 반해 Git에서는 저장(Commit)시점에 변경된 파일의 집합을 하나의 버전으로 관리한다.
-> 파일의 집합을 하나의 버전으로 관리하는 모습은 Perforce의 Changelist나 또는 ClearCase의 UCM에서 Activity를 사용하는 모습과 흡사하다.
2. 속도
Git는 저장소 전체를 복사해 사용하기 때문에 서버 성능이나 장애 상황에 따라 영향을 받는 중앙 관리형 버전 관리 도구에 비해 속도가 현저히 빠르다. 로컬에 모든 정보를 가지고 직접 실행하다 보니 네트워크를 통해 정보를 교환하는 방식에 비해 빠를 수 밖에 없다.
물론 Offline시에서도 소스와 관련된 작업 수행이 가능하다.
3. 무결성
모든 데이터를 다루기 전에 해당 파일에 대한 체크섬1을 구하고, 그 값을 이용해 데이터를 관리한다. Git에서는 SHA-1 Hash를 이용히 체크섬을 만든다.
4. Repository에 대해 삭제 수정이 없는 데이터 추가
데이터가 Commit 된 이후에는 기존 Repository에 대한 데이터를 삭제/수정이 불가능하다.
-> 아직 이 특징을 어떻게 활용해야 할지 의구심이 든다. 정말 정말 없나? 그건 뒤에 공부하면서 알아가야 겠다.
5. 파일의 세가지 상태
Git 상에서 파일은 Committed, Modified, Staged 상태로 관리된다.
- Committed : 로컬 GIT 데이터 베이스에 안전하게 저장된 상태
- Modified : 현재 수정되어 지고 있는 파일
- Staged : 수정 된 파일을 곧 Commit할 것이라는 표시
- Working Directory : 프로젝트의 특정 버전을 Checkout 한 곳 -> 실제 개발 작업이 이루어지는 공간
- Staging Area : Git Directory에 존재 하며 곧 Commit 할 파일으 대한 정보를 저장하는 곳
- Git Directory(Repository) : Git 프로젝트의 메타데이터와 객체 데이터베이스를 저장하는 곳
1) Working Directory에서 파일을 수정한다. (Modified 상태)
2) Staging Area에서 파일을 Stage해서 Commit할 Snapshot을 만든다. (Staged 상태)
3) Staging Area에 있는 파일을 Commit해서 Git Directory에 영구적인 Snapshot으로 저장한다. (Committed 상태)
- (각주) 체크섬 : 중복 검사의 한 형태로, 오류 정정을 통해 송신된 자료의 무결성을 보호하는 단순한 방법이다. 단순한 체크섬 동작의 예를 들면 다음 단계를 따른다. 0. 4바이트의 데이터가 있다. 0x25, 0x62, 0x3F, 0x52 1. 모든 바이트를 더해 값을 구한다. 0x118 2. 캐리 니블을 버린다. 0x18 3. 0x18의 2의 보수를 구해 체크섬 바이트를 얻는다. 0xE8 4. 원래 데이터에 체크섬 바이트를 추가한다. 모든 합이 0x200이 된다. 5. 캐리니블을 버린다. 0x00 -> 오류가 없다는 의미 [본문으로]
'소프트웨어 공학 > 형상관리' 카테고리의 다른 글
| 형상관리에 들어 보셨나요? (0) | 2013.10.19 |
|---|