1. Git 개념
Git은 개발자를 지망하거나 공부하신 분들이라면 많이 들었을 것이다. 주로 자신의 코드를 저장 및 관리하는데 사용하고 프로젝트를 진행할 때, 다른 사람들과 나의 코드 관리 및 프로그램 버전 관리에 사용한다. Git을 많이 쓰지만 정작 Git이 어떻게 동작하는지 아는가?
아마 모르는 분들이 많을 것이다. 그래서 오늘은 Git에 대해 정리하고 Git이 어떻게 동작하는지 알아볼 것이다.
1.1 Git이란 무엇인가?
Git은 DVSC(Distributed Version Control System) 분산 버전 관리 시스템 중 하나이다.
2005년 리누스 토발즈가 리눅스 커널 프로젝트를 위해 개발한 시스템이다. Git은 속도, 데이터 무결성, 그리고 대규모 프로젝트를 지원하는 능력에 초점을 맞추어 개발되었다. 더 자세한 이야기는 짧게 보는 Git 역사 참조.
Github란 버전 관리와 협업을 위한 코드 웹 호스팅 플랫폼으로, 장소에 국한되지 않고 프로젝트를 쉽게 진행할 수 있도록 도와주는 플랫폼이다.
분산 버전 관리 시스템이란?
- 소프트웨어 버전 관리를 위한 시스템으로 각 개발자가 중앙 서버에 접속하지 않은 상태에서도 코드 작업을 할 수 있는 것
서버가 가지고 있는 버전 변경 이력들을 로컬로 전부 가지고 오는 것
1.2 Git을 사용하는 이유
로컬 코드 관리 : Git
원격 코드 관리 : Github
- 다양한 버전 관리
- 하나의 코드에서 다양한 케이스의 구현하고 테스트해볼 때
- 히스토리 추적
- 작업 시 문제 발생했을때 직전 버전으로 롤백이 가능
- 안전하게 원격 저장
- 로컬 작업 내용들 모두 원격으로 백업
- 협업관리
- 동료 개발자가 적용해놓은 최신 코드를 이어 받아 개발
Github은 협업 관리
- 동료 개발자가 적용해놓은 최신 코드를 이어 받아 개발
2. Git의 원리
그럼 코드는 어떻게 관리가 되고 있는가?, 버전은 어떻게 관리되고 있는가를 아는가?
- 우리가 흔히들 파일을 생성하고 백업할 때는 파일 생성과 내용을 채우고 저장한다. 그리고 백업으로 다른 이름으로 저장하고 파일을 수정하여 저장한다.
- 그럼 버전이 두개의 파일이 있는 것이다. 하나는 최신버전 하나는 백업 버전, 이는 파일 기반으로 관리를 하는 것이다.
그럼 Git은 어떻게 관리하는가?
- 바로 두 파일간 변경된 사이 분량을 기준으로 관리한다.
즉 Diff를 기준으로 버전을 관리한다. - 그 이유는 파일들을 다 저장하는 것 보다 사이 분량을 저장하는 것이 더 적게 저장하기 사용한다.
Diff란 두개의 파일 간의 차이에 대한 정보
2.1 Git과 Github의 구조
- Github : Remote Repository로 원격 저장 공간
- Git : Local Repository로 개인 컴퓨터 저장 공간
- Push : Local Repository의 내용을 Github에 올리는 것
- pull : Remote Repository의 내용을 가져오는 것
- Conflict : git은 Diff 기반(사이 분량)으로 저장하는데 두 가지 버전이 같은 버전을 기준으로 만들어져서 충돌난 것
- snapshot(스냅샷)
- 변화된 부분만 찾아 사진을 찎는 것과 같다고 하여 이름이 스냅샷이다.
- 특정 시점에서 파일, 폴더 또는 워크스페이스의 상태를 의미
- 커밋을 실행하면 스냅샷(각각의 버전)이 저장된다.
pull의 동작 방법
- pull = Fetch + Merge
- Fetch를 먼저 실행 후 Merge를 실행하여 local Repository에 변경 사항을 병합한다.
- Fetch : 로컬 git이 원격 저장소의 변경된 내용을 가져와 변경점을 확인하는 것
- Merge : 원격 저장소에서 최신 메타데이터 정보가 있다면 다운로드하고 병합
2.2 Git의 상태 및 용어
- Working Directory
- 작업 공간, 로드된 브랜치
- Tracked : Git이 추적하는 파일들, 추적하는 상태
- Staging Area
- Commit 되기 위해서 대기 중인 파일들
git add <File>으로 Staging Area로 파일을 올린다- Commit이 되면 하나의 버전으로 올라가는 파일들
- Unstaged Area
- 수정된 파일들의 집합
- 추적하고 있는 파일들의 변경이 있는 경우에는 Unstaged Area로 들어간다. 실질적으로 실질적으로 저장된 것은 아닌다.
- Stagins Area에 있던 파일들이 수정, 삭제 등 변경이 일어나면 Unstaged Area로 파일이 내려온다.
- Staging Area
- Untracked
- Git이 추적하지 않은 파일들의 집합, 새로 만들어진 파일들이다.
- .gitignore에 적혀있는 파일들
3. Git의 각각의 상황
3.1 충돌(conflict) 상황
- Rebase와 Merge 두가지 방식이 있다.
- Rebase
- 현재 내 작업물의 Base를 다시 설정한 뒤 다시 커밋을 쌓는다.
- 장성한 commit 히스토리가 증발하고 새로 작성된다.
- Merge
- 현재 내 작업물과 Remote에 업로드되어있는 상대 작업물 모두 존중하여 두 작업물을 합하여 머지 커밋을 쌓는다.
- 머지 커밋이 덕지덕지 생성되어 머지 수가 많아짐에 따라 커밋 히스토리가 더러워진다.
- Rebase
3.2 삭제 (deleted <-> untracked) :
Git이 추적하는 있는 파일 중 삭제
1. git rm <File> : Staging Area로 바로 올려서 Commit 시 바로 삭제될 수 있다.
=> Git Repository 에서 삭제 예정(Staging), Local에서 삭제
2. 파일을 그냥 삭제하는 경우 : Unstaged에 올려 한번 검토 요청
=> Git Repository에서 삭제 검토(Unstaged), Local에서 삭제
3. git rm --cached <File> : Staging Area로 바로 올림과 동시에 Untracked에 올려 나만 보기
=> Git Repository에서 삭제 예정(Staging), Local에서 사용
3.3. 추가 (new file <-> untracked)
새로운 파일을 추가하면 UnTracked 상태이다.
git add <File> 하면 Straging area 상태로 올라가고 git에 Tracked 된다.
git commit <File> 하면 Repository 들어간다.
3.4 수정
Git을 통해 추적되고 있는 Tracked 파일에서 수정이 일어났을때
- 파일 수정이 디렉토리 혹은 VSCode이라면 Staing Area
- 파일 수정이 내용은 Unstaged 상태
나만 사용하는 상황에서
- Untracked상태로 두어 나만 로컬에서 사용
.gitignore를 통해 Git 한테 이 파일은 git에 tracked하지 않도록 지정한다.
Git에 등록할 것이면git add <File>로 Staging Area로 전달한다
3.5 되돌리기
git restore <File> 이전 상태로 되돌리기
--staged옵션이있다면- deleted(삭제할 파일) : Staging Area에서 -> Unstaged로 이동
- modified(수정된 파일) : Staging Area에서 -> Unstaged로 이동
- new file(추가된 파일) : Staging Area에서 -> Untracked로 이동
- 없다면 Unstaged에서 아무일도 없었던 것처럼 깨끗히 롤백
- deleted(삭제할 파일) : Unstaged에서 -> 기존 Git 내 삭제되기 전 파일 존재 상태로 롤백
- modified(수정된 파일) : Unstaged에서 -> 기존 Git 내 수정되기 전 파일 상태로 롤백
