Git 소개

Lee Yong Seok·2022년 7월 13일

Git 소개

1. Git History

1) Linux Kernel project를 위한 version 관리 system으로 개발
2) Birth year : 2005년
3) Linus Benedict Torvalds를 포함한 Linux 개발 community에서 상용 도구인 Bitkeeper의 대용으로 만듦.

2. Version관리 System이 필요한 이유

1) file의 version관리를 어떻게 하는가?
2) 가장 간단한 방법은 파일을 미리 복사해두는 것이다.
3) 예를 들면, file과 folder명 뒤에 편집한 날짜를 붙여주는 방식같은 것이다.
4) 하지만 file을 편집할 때마다 매번 복사하는 일은 번거롭기도 하고 실수할 가능성도 많다.
5) 또한 특별한 규칙 없이 마음대로 이름을 붙여놓는 경우 어느 file이 최신인지, 또 file의 어떤 부분이 변경된 것인지 파악하기 어렵다.
6) 바로 이런 문제를 해결하기 위해 만들어진 것이 version 관리 system이다.
7) version관리 system을 사용하면 개별 file이나, project를 이전 상태로 되돌릴 수 있다.
8) 시간에 따른 수정 내용을 비교할 수도 있고, 공동 작업을 하는 경우에는 누가 문제를 일으켰는지도 알 수 있다.

3. Version 관리 System의 유형

1) Local Version Control System

User의 local 환경에서 version 관리를 한다.
일반적으로 날짜별로 file을 구분한다.

2) Centralized Version Control System, CVCS

별도의 version 관리 server를 두고 모든 사용자가 접근하는 방식
공동작업을 하는 경우 local version 관리 system으로는 협업이 원활한 대응이 힘들기 때문에 개발
중앙 server에 문제가 발생했을 때 version 관리를 계속할 수 없다는 단점이 있다.
CVS, SVN, Perforce

3) Distributed VCS, DVCS

위의 CVCS의 단점을 극복하는 방식
Client는 file의 마지막 snapshot를 check하는 것으로 끝나지 않고, 저장소 전부를 복제하여 local 저장소에 관리한다.
그럼 중앙의 version 관릿 system에 문제가 발생하더라도 local 저장소에서 복구할 수 있다.
Git, Mercurial, Bazaar, Darcs

4. Git?

1) Source code를 보다 효과적으로 효율적으로 관리하기 위해 개발된 분산형 version 관리 system이다.
2) Git에서는 source code가 변경된 이력을 쉽게 확인할 수 있다.
3) 특정 시점에 저장된 version과 비교하거나 특정 시점으로 되돌아갈 수도 있다.
4) 또 내가 올리려는 file이 누군가 편집한 내용과 충돌한다면, server에 upload할 때 경고 메시지가 발생한다.
5) 협업관리
6) 효율적으로 백업하기

5. Version이 만들어지는 단계 - Version이 되기까지 거쳐가는 세 개의 공간

1) Working Directory( 작업공간)

내가 코드 작업을 하는 공간
File들이 생성/수정/삭제되는 공간
즉, 변경사항이 생기는 공간
과연, Working Directory의 모든 변경사항들을 Version으로 만들어야 하는가? ⇒ 변경사항들 중 다음 버전이 될 File들을 선별해서 선별된 File들을 Version으로 만든다.
그래서 Staging Area가 필요한 것이다.

2) Staging Area

Version이 될 후보들이 올라오는 공간
Working Directory에서 선별

3) Repository

Version들이 저장되어 있는 공간

6. 초기 목표

1) 속도(Network 및 File 처리)
2) 단순한 구조
3) 동시 다발적인 개발
4) 비선형적인 개발(branch model)
5) 완벽한 분산
6) 책임성
7) 대형 project를 효율적으로 지원

7. 저장소

1) 저장소(Git repository)란 file이나 folder를 저장해 두는 곳.
2) Git 저장소는 file이 변경 이력별로 구분되어 저장된다.
3) 비슷한 file이라도 실제 내용 일부 문구가 서로 다르면 다른 file로 인식하기 때문에 file을 변경사항별로 구분해 저장할 수 있다.

4) Git은 원격 저장소와 local 저장소 두 종류의 저장소를 제공한다.
5) 원격 저장소(Remote Repository)는 file이 원격 저장소 전용 server에서 관리되며 여러 사람이 함께 공유하기 위한 저장소를 말한다.
6) 반면 로컬 저장소(Local Repository)는 내 PC에 file이 저장되는 개인 전용 저장소이다.
7) 평소에는 내 PC의 local 저장소에서 작업하다가 작업한 내용을 공개하고 싶을 때에 원격 저 장소에 upload를 하면 된다.
8) 반대로 원격 저장소에서 다른 사람이 작업한 file을 local 저장소로 가져올 수도 있다.
9) 저장소를 만드는 방법은

저장소를 새로 생성한다.
이미 만들어져 있는 원격 저장소를 local 저장소로 복사해서 사용한다.

8. Git의 file 관리 방법

1) Git 이전의 system에서는 각 file의 변화를 시간순으로 관리하면서 version 관리를 했다.
2) 예를 들면 Subversion은 변경 내용만 저장한다.
3) Git에서는 data를 file system snapshot으로 취급한다.
4) file에 변경이 없을 때는 file을 새롭게 저장하지 않고 기존 file에 대한 link만 저장한다.
5) 아래의 그림을 보면, 4번째 version을 생성하는 경우, Subversion은 각 file의 변경 내용을 다 적용한 후에 최신 file을 만든다(일종의 differential backup 같은 개념).
6) 반면, Git은 file B1와 file C1에 이미 변경 내용이 적용되어 있다.
7) 변경이 없는 file A1의 link를 따라 file을 취득해서 ‘version 4’를 생성하게 된다.
8) 즉 Subversion은 version을 확정(Subversion에서는 commit,혹은 tag)할 경우에 앞의 변경(revision) 내용을 순차적으로 적용해야 하므로 Git에 비해서 시간이 많이 걸리는 단점이 있다.
9) Git은 상대적으로 용량을 많이 필요로 하지만, 빠르게 최신 version을 가져올 수 있다.
10) 참고로, 아래의 그림에서 Subversion에서 화살표는 merge의 의미이고, Git의 선은 서로 연결되어 있다는 의미이다.

9. 동작원리

1) Snapshot

Data를 가져오거나 project를 저장할 때마다 그 시점의 file에 대해 snapshot을 저장한다.
변경되지 않은 file은 다시 file에 저장하지 않고 지정한 동일한 file을 link한다.

2) Checksum
Data를 저장하기 전에 checksum을 구하고 이 checksum을 통해 data를 관리한다.
SHA-1 hash 사용
৹ 16진수 문자 40개로 구성된 문자열
৹ File의 내용 또는 directory 구조를 기반으로 계산
File 이름이 아닌 contents의 hash 값을 저장한다.
৹ File의 이름이 변경되더라도 내용이 동일하면 같은 hash를 갖는다.

3) Sections(Work Tree)
Working Directory
৹ Repository의 project를 checkout하거나 수동으로 생성
Staging Area(Index)
৹ Repository에 commit하기 위한 중간 저장소
Repository
Commit은 working directory에 있는 변경 내용을 저장소에 upload하는 과정이다.
그런데, 바로 upload하는 것이 아니라 중간 단계인 Staging area(Index)에 file 상태를 기록해야 한다.
따라서 저장소에 변경 사항을 기록하기 위해서는, 기록하고자 하는 모든 변경 사항들이 Staging area(Index)에 존재해야 한다.