Git에 대하여
업데이트:
개발자를 지망한다면 git과 github에 대해 많이 들어봤을 것이다.
이 포스트에서는 그 git과 github이라는 것의 정체를 파헤쳐보고자 한다.
그런데 왠지 git이란 것을 알아야 github에 대해 이해할 수 있을 것 같다.
그 git이란 것을 알아보기 전에 ‘버전 관리’라는 것에 대해 알아보자.
버전 관리
버전 관리란 말 그대로 어떤 대상의 버전을 관리하는 것을 말한다.
그 대상은 프로그램 소스 코드가 될 수도 있고 프로그램 자체가 될 수도 있다.
복사-붙여넣기(Ctrl + C,V)
우리는 git과 github이란 것을 쓰기 전부터 버전 관리를 해왔다.
바로 복사-붙여넣기(Ctrl+C,V)를 통해 팀 프로젝트의 ppt 파일이나 word 파일의 버전을 관리해왔을 것이다.
복사본의 파일명 뒤에 날짜를 붙이면서 말이다.
이런 복사-붙여넣기(이하 복붙)를 통해 버전 관리를 할 순 있다. 그러나 이런 복붙은 다음과 같은 문제를 일으킬 수 있다.
- 실수로 작업하던 폴더를 지워버린 경우
- 파일을 잘못 고치고 저장해버려서 파일을 되돌릴 수 없는 경우
그리고 복붙은 다음과 같은 불편한 점이 있다.
- 파일의 변경 사항을 알기 어렵다.
- 파일을 특정 시점으로 되돌리기 어렵다.
- 복사된 파일이 디스크의 용량을 차지한다.
- 협업(분산작업)이 어렵다.
이러한 복붙을 통한 버전관리의 단점 때문에 버전 관리 시스템이 등장했다.
버전 관리 시스템(VCS, Version Control System)
버전 관리 시스템이란 파일 변화를 시간에 따라 기록했다가 나중에 특정 시점의 버전을 다시 꺼내올 수 있는 시스템을 말한다.
첫번째로 로컬 버전 관리 시스템(LVCS)이란게 생겼다.
로컬 버전 관리 시스템(LVCS, Local Version Control System)
로컬 VCS는 아주 간단한 데이터베이스를 사용해서 파일의 변경 정보를 관리한다.
그림 1. 로컬 버전 관리.
로컬 VCS 중 하나인 RCS(Revision Control System)는 Patch Set(파일에서 변경되는 부분)을 관리한다. 파일에 일련의 Patch Set을 적용하거나 해제함으로써 파일을 특정 시점으로 되돌릴 수 있다.
하지만 이러한 로컬 VCS은 로컬에서만 동작해서 협업할때는 불편한 점이 많아 중앙집중식 버전 관리 시스템이 등장한다.
중앙집중식 버전 관리 시스템(CVCS, Centralized Version Control System)
중앙집중식 버전 관리 시스템은 파일을 관리하는 서버가 있고 클라이언트는 중앙 서버에서 파일을 받아서 사용한다.
그림 2. 중앙집중식 버전 관리(CVCS).
마치 ‘구글 드라이브’를 사용하는 것과 같다.
하지만 이러한 시스템 역시 협업할 때는 불편하고 만약 중앙 서버가 마비되거나 인터넷에 연결이 안되는 환경이라면 작업을 수행할 수가 없게 된다.
이러한 단점때문에 분산 버전 관리 시스템이 등장한다.
분산 버전 관리 시스템(DVCS, Distributed Version Control System)
분산 버전 관리 시스템에서는 클라이언트가 중앙 서버의 저장소와 더불어 히스토리를 전부 복제함으로써 서버의 문제가 발생하더라도 복제물로 작업을 수행하게 할 수 있고 서버의 복원도 할 수 있다.
그림 3. 분산 버전 관리 시스템(DVCS).
중복된 파일을 메모리에 저장하는 것이 비효율적으로 보이지만, 이렇게 함으로써 버전을 내 컴퓨터에서 관리할 수 있게 되고 필요할 때마다 원격 서버를 이용해 파일을 업로드할 수 있게 된다. 그리고 서로 참조하면서 협업도 쉽게 가능해진다. 또한 파일의 저장방식을 특이하게 해서 메모리도 효율적으로 사용가능하다.
우리가 배울 git이란 것도 분산 버전 관리 시스템이다.
Git
Git의 간단한 역사
Git은 Linux를 창시한 리누스 토발즈(Linus Torvalds)가 2005년에 만들었다.
Linux 커널은 당시 상용 DVCS 중 하나인 BitKeeper를 사용했다.
그러다가 BitKeeper의 무료 사용이 중지되자 리누스 토발즈는 Git을 만들게 된다.
그렇게 만들어진 git은 다음과 같은 특징을 가진다.
- 빠른 속도
- 단순한 구조
- 비선형적인 개발(수천 개의 동시 다발적인 브랜치)
- 완벽한 분산
- Linux 커널과 같은 대형 프로젝트에도 유용할 것(속도나 데이터 크기 면에서)
Git 기초
용어정리
Snapshot: 특정 시점에서의 파일 상태(현재 상태의 모든 정보)
Delta: 파일의 이전 상태와 비교한 변경사항
차이가 아니라 스냅샷
그림 4. 각 파일에 대한 변화를 저장하는 시스템들.
Serbversion과 같은 시스템들은 각 파일의 변화를 시간순으로 관리하면서 파일들의 집합을 관리한다.
보통 델타 기반 버전 관리 시스템이라고 한다.
그림 5. 시간순으로 프로젝트의 스냅샷을 저장.
Git은 데이터를 파일 시스템 스냅샷의 연속으로 취급한다.
파일이 달라지지 않았으면 이전 상태의 파일에 대한 링크를 제공한다.
Git은 최종적으로 마지막 버전의 스냅샷만 저장하고 나머지는 델타로 관리한다.
거의 모든 명령을 로컬에서 실행
Git은 거의 모든 명령이 로컬에서 실행되므로 빠르며 네트워크에 연결할 필요가 없다.
로컬에서 작업하고 원격으로 업로드하면 된다.
Git의 무결성
Git은 데이터를 저장하기 전에 항상 체크섬을 구하고 이 체크섬으로 데이터를 관리한다.
체크섬은 SHA-1 해시를 사용하여 40자 길이의 16진수 문자열로 만들어지며 이는 파일의 내용이나 디렉토리 구조를 이용하여 구한다.
Git은 파일을 이름으로 저장하지 않고 해당 파일의 해시로 저장하며 이 해시값을 통해 버전을 이동한다.
Git은 데이터를 추가할 뿐
Git으로 무엇을 하든 데이터베이스에 데이터가 추가된다.
Git은 데이터를 추가만 할 수 있다.
파일 삭제는 파일 삭제 기록을 추가하는 것을 의미한다.
세가지 상태
Git은 파일을 세가지 상태로 관리한다.
- Committed: 데이터가 로컬 데이터베이스에 안전하게 저장됐다는 것을 의미한다.
- Modified: 수정한 파일을 아직 로컬 데이터베이스에 커밋하지 않은 것을 의미한다.
- Staged: 현재 수정한 파일을 곧 커밋할 것이라고 표시한 상태를 의미한다.
이 세가지 상태는 Git 프로젝트의 Git 디렉토리, 워킹 트리, Staging Area라는 세 가지 단계와 연결되어 있다.
그림 6. 워킹 트리, Staging Area, Git 디렉토리.
-
Git 디렉토리는 Git이 프로젝트의 메타데이터와 객체 데이터베이스를 저장하는 곳을 말한다.
-
워킹 트리는 프로젝트의 특정 버전을 Checkout한 것이다.
-
Staging Area는 단순한 파일이고 곧 커밋할 파일에 대한 정보를 저장한다.
Git이 하는 일
- 워킹 트리에서 파일을 수정한다.
- Staging Area에 파일을 Stage해서 커밋할 스냅샷을 만든다. 모든 파일을 추가할 수도 있고 선택하여 추가할 수도 있다.
- Staging Area에 있는 파일들을 커밋해서 Git 디렉토리에 영구적인 스냅샷으로 저장한다.
Git 디렉토리에 있는 파일들은 Committed 상태이다.
파일을 수정하고 Staging Area에 추가했다면 Staged이다.
그리고 Checkout 하고 나서 수정했지만, 아직 Staging Area에 추가하지 않았으면 Modified이다.
Git 설치
윈도우 사용자는 아래 링크로 가서 Git을 다운받아 설치하면 된다.
https://git-scm.com/download/win
Git 최초 설정
사용자 정보
git을 설치하고 나서 가장 먼저 해야하는 것은 사용자 이름과 이메일 주소를 설정하는 것이다.
git은 커밋할 때마다 이 정보를 사용한다.
git bash를 통해 입력하자.
git config --global user.name "username"
git config --global user.email user-eamil@email.com
설정 확인
아래 명령어를 통해 설정 정보를 확인할 수 있다.
git config --list
댓글남기기