CS 스터디 10주차 - Git

Lilac-_-P·2023년 6월 26일

버전 관리 시스템

개발자에게 소스 코드를 작성함에 있어서 버전을 관리하는 것은 필수불가결한 요소이다. 소스 코드를 작성하다보면 요구사항에 따라 수시로 코드가 바뀌게 되는 것은 부지기수이며 변경된 후에도 이전의 코드로 다시 되돌려야하는 경우도 생긴다. 이 때, 이전의 코드를 백업하지 않고 있거나 수동으로 변경된 사항을 하나하나 합쳐야한다면 엄청난 오버로드가 생긴다. 버전 관리 시스템, VCS는 이러한 소스 코드의 변경점을 관리해주는 소프트웨어이다.

VSC는 아래와 같은 편리함을 제공한다.

변경점 관리: 어떤 내용을 누가 작성해서 어느 시점에 들어갔는지 확인할 수 있다.
버전 관리: 특정 시점에 태그를 달아 버전을 표시해주고, 브랜치(Branch) 등으로 동시에 여러 버전을 개발할 수 있다.
백업과 복구: 무언가가 잘못되었을 때 특정 시점으로 돌아가게 해주고, 사고로 내용이 날아간 경우에도 복구할 수 있다.
협업: 같이 일하는 사람들에게 수정사항을 쉽게 공유할 수 있다.

만약 버전관리 시스템이 없다면, 아래와 같은 참사가 벌어진다.

버전 관리 시스템의 종류

로컬 VCS

서버 없이 로컬 컴퓨터 내에서 버전을 관리한다.
간단한 데이터베이스만으로도 구현이 가능하므로 단순하고 개인적인 프로젝트에 적합하다. 단, 협업에서 쓰기에는 힘들고, 컴퓨터가 고장나는 등 내부 정보가 통째로 날아가버리면 복구할 방법이 없다.

CVCS (Centralized VCS)

서버에 최종본 한 벌이 있으며, 사용자들은 이 중 수정을 원하는 파일만 로컬에 받아 수정한 후 서버에 올리게 된다. 간단한 방법으로 협업이 가능하고 관리자가 누가 어떤 일을 하고 있는지 알기 쉬운 장점이 있다. 단, 중앙 서버가 다운될 경우 그동안은 업무가 마비되는 단점이 있다. 그리고 서버의 정보가 날아갈 경우 모든 히스토리가 날아가게 된다. 협업의 규모가 커지면 수정 충돌 문제 등이 발생할 수 있다.

대표적으로 Subversion(SVN)이 있다.
또, 예시로 나무위키와 같은 문서 편집 시스템이 간단한 중앙집중식 버전 관리에 속한다.

DVCS (Distributed VCS)

파일을 저장하는 서버가 있는 것은 동일하지만 수정을 위해 프로젝트 전체를 로컬에 다운 받은 뒤 수정한다. 로컬에 다운 받을 때, 소스코드의 버전 히스토리 또한 같이 다운로드 받기 때문에 중앙 서버가 다운되더라도 개별 사용자들은 작업이 가능하고 서버가 날아가도 다운 받은 내용은 남아있기 때문에 가장 안정적이다. 수정시에도 현재 코드는 로컬에서 사용자 혼자 수정하고 있기 때문에 충돌의 염려 없이 수정할 수 있으며, 최종적으로 서버에 올릴 때만 신경써서 병합(Merge)해주면 된다.

대표적으로 Git이 있다.

Git

Git의 3가지 영역

Working Directory (작업 영역)

사용자가 현재 작업하고 있는 프로젝트의 디렉토리에 해당한다. 해당 디렉토리 내에서 파일 추가, 수정, 삭제 등의 작업 후에 git add 명령어를 실행하면, git은 변경을 감지하여 작업 영역에 변경된 사항들을 Staging Area로 올린다.

Staging Area (인덱스 영역)

작업한 내용들을 영구적으로 반영하기 전에 파일들이 위치하는 영역으로 중간 임시저장소의 역할을 한다.

참고. 왜 Staging Area가 필요한가?

Git의 3가지 상태

Git이라는 소프트웨어는 파일의 변경사항 들을 버전별로 관리하기 위해서 파일들을 Committed, Modified, Staged 3가지 상태로 관리를 한다.

Modified : Working Directory 영역에 있는 파일들 중 수정을 한 파일들의 상태를 의미한다.
Staged : 수정한 파일들 중 commit 할 것이라고 표시한 상태를 의미한다. Staging Area 영역에 있는 파일들의 상태이다.
Commited : Staged 상태의 파일들이 로컬 저장소에 안전하게 저장됐다는 것을 의미한다.

Git 파일의 LifeCycle 관점에서 본 4가지 상태

Repository (헤더 영역)

최종적으로 파일들이 커밋된 후에 git에 의해 버전 관리되는 파일들이 위치하는 영역으로 프로젝트의 버전 정보를 관리하기 위해 필요한 모든 파일이 저장되어 있다.

Git 기본 CLI 커맨드

git init : 현 위치의 디렉터리를 git 저장소(작업 영역 or Working Directory)로 사용하겠다는 명령어

git add : 작업이 완료된 파일을 스테이징 영역으로 올리는 명령어

git commit : 스테이징 영역에 올라온 파일들을 영구적으로 저장 및 반영하는 명령어

git log : Repository(헤더 영역)에 commit된 히스토리를 조회하는 명령어

git reset [--옵션] [돌아가고자하는 커밋의 해시값]: 이미 수행된 커밋을 되돌리는 명령어 (soft, mixed, hard로 옵션을 지정)

git reflog : 한번이라도 수행한 모든 커밋을 로그로 보여주는 명령어

git commit --amend : 가장 최근의 커밋을 수정하여 덮어쓰는 명령어

git status : 현재 작업영역에 있는 파일에 대한 git에서 관리하는 상태를 보여주는 명령어

ETC...

Git Merge & Rebase

Merge 와 Rebase는 모두 협업과정에서 프로젝트 파일을 하나로 합칠 때 사용하는 기능이다.

Merge

Merge를 사용하는 경우, 두개의 브랜치를 병합하는 커밋로그가 master 브랜치에 새롭게 추가된다. 그러므로, 브랜치를 병합할 때마다 커밋로그가 추가되기 때문에, 협업하는 인원이 많아질수록 병합로그가 많아지게 되고 결과적으로 커밋 히스토리를 관리하기 어려워지는 단점이 있다.