0. Introduction

• Pro git : Second editions 자체 스터디 내용이다.
• 이번 장은 Git을 처음 접하는 분들에게 필요한 내용이다.
• 이 챕터를 통해서 Git 탄생 배경, 사용 이유를 알 수 있다.
• 지속적인 복습을 위해 만든다.

1. What is Version Control System ???

Version Control System이란 무엇이고, 왜 필요할까??

버전 관리 시스템(VCS) : 파일의 변화를 시간에 따라 기록했다가, 나중에 특정 시점의 버전을 다시 꺼내올 수 있는 시스템

VCS를 통해서 큰 노력 없이

1. 각 파일을 이전 상태로 되돌릴 수 있다.
2. 프로젝트를 통째로 이전 상태로 되돌릴 수 있다.
3. 시간에 따라 수정 내용을 비교할 수 있다.
4. 누가 문제를 일으켰는지 추적할 수 있다.
5. 누가 언제 만들어낸 이슈인지 알 수 있다.
6. 파일을 잃어버리거나 잘못 고쳤을 때도 쉽게 복구할 수 있다.

VSC의 종류에는 LVCS, CVCS, DVCS가 있다.

각 종류에 대해 알아보자.

1.1 Local Version Control System (LVCS, 로컬 버전 관리)

LVCS 탄생 계기

• 많은 사람은 버전을 관리하기 위해 directory로 파일을 복사하는 방법을 사용한다.
• 하지만 이러한 방식은 잘못되기 쉬어서 Local Version Control System을 만들었다.
• 간단한 DB를 사용해서 파일의 변경 정보를 관리했다.

LVCS의 한 예: RCV

• 많이 사용하는 VCS 중 RCS (Revision Control System)가 오늘날까지도 많은 회사에서 사용하고 있다.
• RCS는 Mac OS에서도 개발 도구를 설치하면 함께 설치되며, 기본적으로 Patch Set(: 파일에서 변경되는 부분)을 관리한다.
• Patch Set을 통해 모든 파일을 특정 시점으로 되돌릴 수 있다.

1.2 Central Version Control System (CVCS, 중앙 집중식 버전 관리)

CVCS 탄생 계기

• 위의 LVCS의 장점에도 불구하고, LVCS는 다른 개발자와 협업 시에 사용할 때에는 적절한 tool이 아니었다.
• 그래서 중앙 집중식 버전 관리 (CVCS, Central Version Control System) 를(을) 개발했다.

CVCS 특징과 장점

• CVCS는 LVCS에 비해 장점이 많다.
• 파일을 관리하는 서버가 별도로 있고, 클라이언트가 이 중앙 서버에 파일을 받아서 사용(checkout)하기 때문에,
  • 누가 무엇을 하고 있는지 알 수 있다.
  • 관리자의 입장에서는 누가 무엇을 할지 꼼꼼히 관리할 수 있다.
  • 모든 client의 local DB를 관리하는 것보다 VCS 하나를 관리하기가 훨씬 쉽다.

CVCS 단점

• 파일을 관리하는 중앙 서버가 별도로 있고, client가 checkout 방식으로 사용하고, 저장소를 전부 복제하는 게 아니기 떄문에,
  • 서버가 다운되는 동안, 다른 사람과 협업할 수 없고, 백업할 방법도 없다.
  • 중앙 DB가 있는 하드디스크에 문제가 생기면 project의 모든 history를 잃는다. (client가 가진 snapshot 제외)

🔅 snapshot: 특정 시점에서 파일, 폴더 또는 워크스페이스의 상태

1.3 Distributed Version Control System (DVCS, 분산 버전 관리 시스템)

DVCS 장점

• 첫 번째, Git과 같은 DVCS는 저장소를 전부 복제한다.
  • 그래서 서버에 문제가 생기면 작업을 할 수 없었던 CVCS와는 달리, 이 복제물로 다시 작업을 시작할 수 있다.
  • Client 중에서 아무거나 골라도 서버를 복원할 수 있다.
  • 모든 checkout이 모든 데이터를 가진 백업이라는 의미다.
• 두 번째, 대부분의 DVCS 환경은 remote repository가 존재한다.
  • 그래서, 사람들은 동시에 다양한 그룹과 방법으로 협업이 가능하다.
  • 계층 모델 같은 CVCS으로는 할 수 없는 workflow를 다양하게 사용할 수 있다.

2. Histroy summaries of Git

• 리눅스(Linux) kernel은 굉장히 규모가 큰 open source project였다.
• 1991~2002년 단순 압축 파일로만 관리하다가 2002년 BitKeeper라 불리는 DVCS를 사용하기 시작했다.
• 그러다 2005년에 BitKeepr가 유료화가 되었다.
• Linux는 커뮤니티이고, BitKeeper는 이익을 추구하는 회사이기 때문에 이해관계가 달랐다.
• 이 계기로 Linux 개발 커뮤니티가 자체 도구를 만들었다. 그 도구가 Git이다.
• Git은 아래와 같은 목표로 세워져서 지금도 유지하고 있다.
  • 빠른 속도
  • 단순한 구조
  • 비선형적인 개발 (동시다발적인 branch)
  • 완벽한 분산
  • 속도나 데이터 크기 면에서 대형 proejct에도 유용할 것

3. Key point of Git : 데이터를 다루는 방식의 차이

3.1 Snapshots, Not Differences

VCS들과 Git의 가장 큰 차이점은 데이터를 다루는 방식에 있다.

• VCS는 각 파일의 변화를 시간 순으로 관리하면서 파일들의 집합을 관리한다.
• Git은 데이터를 파일 시스템 스냅샷으로 취급하여, 각 파일의 변화가 아닌 파일 전체를 스냅샷으로 찍어낸다.
  • 그래서 Git은 데이터를 snapshot stream처럼 취급한다.
  • 그래서 Git은 프로젝트의 상태를 저장할 때마다, 파일이 존재하는 그 순간을 중요하게 여긴다.
  • 그래서 Git은 파일이 달라지지 않으면 성능을 위해 새로 저장하지 않는다.

VCS와 Git 차이점

• [VCS: Storing data as changes to a base version of each file]

  

• [Git: Storing data as snapshots of the project over time]

  

3.2 거의 모든 명령을 로컬에서 실행

Git은 거의 모든 명령이 저장소 전체를 복사해서 로컬 파일과 데이터만 사용하는 방식으로,

• 네트워크의 속도에 영향을 받는 다른 CVCS보다 매우 빠른 속도를 가진다.
• project의 history를 조회할 때, 서버 없이 local DB에서 조회하기 때문에 매우 빠르다.
• 어떤 파일의 현재 버전과 한 달 전의 상태를 비교하고 싶을 때도 이 두 상태를 로컬에서 찾는다.
• 오프라인 상태거나 네트워크와 연결할 수 없어도 막힘 없이 일할 수 있다.

3.3 Git의 무결성: checksum 방식

체크섬(checksum)이란

• 40자 길이의 16진수 문자열인 SHA-1 해시를 사용하여 만든다.
• Git에서 사용하는 가장 기본적인(atomic) 데이터 단위이다.
• Git의 기본 철학이다.

SHA-1: 24b9da6552252987aa493b52f8696cd6d3b00373 같은 40자 길이의 16진수 문자열이다.

그래서 Git은 checksum을 사용하여 (중심으로)

• 데이터를 저장하고 관리한다.
• 그래서 체크섬 없이는 어떠한 파일이나 디렉터리도 변경 할 수 없다.
• 모든 것을 식별한다.
• 파일을 저장하고, 파일 이름으로 저장하지 않는다.

3.4 Git은 데이터를 추가할 뿐

Git은 무엇을 하든 Git database에 데이터를 추가한다.

• 그래서 데이터를 되돌리거나 삭제할 방법이 없다.
• 또한, 다른 VCS처럼 commit하지 않으면 변경사항을 잃어버릴 수 있다.
• 하지만, commit 하면 데이터를 잃기 어렵다.

3.5 Git의 3가지 상태와 3가지 단계

이 부분에 대한 자세한 내용은 Chapter 2를 참고한다.

• Git 파일은 3가지 상태(: Commited, Modified, Staged) 로 관리한다.

  • Commited: 데이터가 local database에 안전하게 저장된 상태
  • Modified: 수정한 파일을 아직 local database에 커밋하지 않은 상태
  • Staged: 현재 수정한 파일을 곧 커밋할 것이라고 표시한 상태

- 이 3가지 상태는 Git project의 3가지 단계(: Working directory, Staging Area, .git Directory(Repository)와 연결된다.

Git directory

• repository 라고도 불린다.
• 커밋된 상태
• Git이 project의 meta data와 객체 datebase를 저장하는 곳이다.
• 다른 컴퓨터에 있는 저장소를 clone할 때 만들어지는 곳이다.

Working directory

• project의 특정 버전을 checkout한 것이다.
• Git directory 안에 압축된 database에서 파일을 가져와서 만든 것이다.
• 파일을 수정하는 공간이므로, checkout하고 나서 수정했지만, 아직 staging area에 추가하지 않은 상태다.

Staging Area

• 커밋을 위한 준비 단계
• 단순한 파일이고 곧 커밋할 파일에 대한 정보를 저장한다.
• 파일들이 Staged 상태

Summary

• working directory에서 파일을 수정한다.
• Staging area로 파일을 스테이지해서 커밋할 snapshot을 만든다.
• Staging area에 있는 파일들을 커밋해서 Git directroy에 영구적인 snapshot으로 저장.

4. CLI

• Git은 CLI (Command Line Interface)와 GUI (Grapic User Interface)로 사용할 수 있다.
• 하지만, Git의 모든 기능을 지원하는 것은 CLI 뿐이다.
• CLI를 사용할 줄 알면 GUI를 사용할 수 있지만, 반대는 성립되지 않는다.

5. Git initail setup

5.1 사용자 정보 등록 명령어

• --global 은 전역 설정하는 명령어로, 딱 한 번만 하면 된다.
  • git config --global user.name "user-name"
  • git config --global user.email <user-email>
• 만약, 프로젝트마다 다른 이름과 이메일 주소를 사용하고 싶으면 --global전역 명령어를 빼고 입력한다.

5.2 설정 확인 명령어

설정 확인 방법은 git config --list 명령을 실행한다.

• Git은 같은 키를 여러 파일에서 읽기 때문에 같은 키가 여러 개 있을 수 있다.
• 그러면 Git은 나중값을 사용한다.
• git config <key> 명령으로 특정 Key에 대해 어떤 값을 사용하는지 확인할 수 있다.
• git config user.name

5.3 명령어 도움말

• 명령어 도움말 이 필요할 때는 방법은 3가지다.
  • git help <verb>
  • git <verb> --help
  • main git-<verb>
  • 예를 들어 git help config를 실행하면 config 명령에 대한 도움말만 볼 수 있다.

Reference

• Pro git : Second editions
• 더북(TheBook:Git 교과서)
• git snapshot