git - working directory, staging area, git repo 영역에 대해서

Git이란?

Git은 소규모 프로젝트부터 대규모 프로젝트까지 모든 것을 빠르고 효율적으로 처리하도록 설계된 무료 오픈 소스 분산 버전 제어 시스템

분산 버전제어시스템이란?

분산형 버전제어시스템(DVCS, Distributed Version Control System)이란, 중앙에서 관리하고 있는 전체 프로젝트의 히스토리와 변경 내용을 복제하여, 로컬 환경에 저장소를 만들어 관리하는 방식

그래서 왜 써야하는데?

개발자라면 당연히 알고있어야되고, 써야하는 것으로 잘 알려져있는 git은 도대체 왜 필요한 것 일까?

이직하기 전의 회사가, 버전관리시스템없는 환경이었기 때문에 얼마나 git(버전관리시스템)이 편리하고 중요한지에 대해 깨달을 수 있었습니다.

 

파일은 서버 파일 시스템으로부터 FTP를 이용해 다운로드하거나, 업로드하는 형식이었습니다.

어느날, 시스템에 문제가 있어서 해당 파일을 확인해보니 수정날짜가 변경되어있어 누군가 수정은 했지만, 누가? 무엇을? 수정했는지 추적하는 것이 불가능 했습니다. (그리고, 아무도 자기가 수정했다고 말하는 사람이 없음...)

결국, 옛날에 백업한 파일을 가지고 있던 사람이, 해당 파일을 그대로 옛날 버전으로 덮어씌우는 식으로 해결한 적이 있었습니다.

 

이것을 제외하더라도, 서버 내에는 여러 백업 파일(index.html_20231111, index_test.html, 등등...)이 그대로 남아있어, 프로젝트 관리도 점점 힘들어지고, 서버 용량에도 영향을 끼치기 때문에 버전관리시스템의 도입이 필요했던 환경이었습니다.

 

하지만, git(버전관리시스템)을 이용하게 되면, 위와같은 문제를 해결 할 수 있습니다.

git은 변경사항을 저장하고, 언제든 해당 변경사항 지점으로 되돌아갈 수 있습니다.

사진과 앨범같은 느낌으로 이해하면 좋을 것 입니다.
우리는 지금의 순간, 추억을 남기기 위해, 사진을 찍어 대상의 모습이 사진으로써 저장을 합니다.

 

또한, 여러 사진들을 모아서 하나의 앨범으로 만드는 것도 가능합니다. 또한, 앨범에는 이름이나 앨범의 설명을 적어두는 것도 가능합니다.
초등학생의 모습이 그리운 경우에는, 초등학교 졸업 앨범을 찾아서 안에있는 사진을 보고 추억을 떠올리곤 합니다.

 

git도 마찬가지입니다.
변경사항이 있는 파일(사진)들을 모아서, 커밋(앨범)을 통해서 설명을 적고 repo에 저장합니다.
그리고, 언제나 원하는 커밋으로 이동해, 그 때 당시의 파일의 변경사항을 확인할 수 있습니다.
(물론, git은 그외에도 다양한 기능을 제공합니다 )

 

그래서 개발자뿐만 아니라, 작가, 음악인, 학생등등 모든 사람이 활용할 수 있는 좋은 도구입니다.
git을 왜 사용해야하는지에 알았기 때문에, 이젠 깃을 잘 활용하기 위해서, 기초개념에 대해서 알아보도록 합시다.

repository(=repo)

하나의 프로젝트나, 서비스등의 단위를 repo 단위로 관리하게 됩니다.

채팅 서비스를 개발하고 싶으면, chatting-project라는 이름의 repo를 생성하고, 그 안에서 파일들을 변경하고 추적합니다.

각각의 repo는 서로에게 아무런 영향을 주지않는 독립적인 영역입니다.

 

git 추적하고 싶은 프로젝트가 있는 경우, 맨처음으로 해줘야하는 것이 git repository를 생성하여, 프로젝트를 git이 추적할 수 있도록 하는 것 입니다.

 

repository를 생성하는 방법은, git init 명령어를 통해 생성할 수 있습니다.

(또는, git clone 명령어를 통해 github으로 부터 이미 존재하는 repository를 복제하는 것도 가능하다.)

3개의 영역 (working directory, staging area, repository)

git은 3가지의 영역으로 나뉘어져 있습니다.

working directory

우리의 로컬 작업공간을 의미합니다.

실제 파일을 변경하고 있는 우리의 컴퓨터 공간

staging area

repository에 저장에 하기전, 저장할 파일들을 저장하는 공간

repository

변경 사항의 파일들을 영구적으로 git내에 저장하는 공간

변경사항을 git 에 저장하는 순서도

 

맨 처음, 로컬 환경에서 a.txt과 b.txt파일을 추가했다고 생각을 하겠습니다.

그럼 working direct리에 첫 번째 사진과 같이 파일 두 개가 추가되는 것을 확인할 수 있습니다.

 

그리고, git add <파일명>을 입력하게 되면, 해당 파일을 staging area로 이동할 수 있습니다.

 

마지막으로, git commit 명령어를 통해서, staging area에 있는 파일을 git의 repository에 저장하게 됩니다.

왜 git은 이렇게 3가지의 영역으로 나뉘어져있을까요???

그 이유는, 만약에 a.txt파일과 b.txt파일을 두 개를 생성했는데, 한 가지의 파일만을 commit하고 싶은 경우가 존재할 것 입니다.

commit은 작업의 최소 단위로 묶어서 하는 것이 좋다고 알려져있습니다.

 

예를들어, 오전중에 여러가지의 기능을 개발한 경우, 변경사항을 한 번에 다 commit하는 것이 아닌, 각 기능에 관련된 변경사항의 파일만을 커밋으로써 저장하는 것을 권장합니다.

 

그렇지 않고, 두 가지의 기능을 하나의 커밋으로 묶어서 저장하게 되면, 나중에 채팅을 작성하는 기능 전의 파일로 되돌아가고 싶은데

채팅을 작성하는 기능뿐만아니라 채팅 내용을 가져오는 가능까지도 삭제된 상태로 되돌아가게 됩니다.

 

따라서, 파일을 a.txt와 b.txt 두 개를 추가했지만 파일을 각각 나누어 커밋하고 싶은 경우에는 우선 git add a.txt로 working directory에 있는 파일을 staging area에 이동시키고, git commit 명령을 통해서 커밋을 하면 됩니다.

 

git commit 명령어는 staging area에 있는 파일을들을 묶어서 커밋으로 저장하는 것이기 때문에, 커밋 단위로 묶고 싶은 파일만 staging area에 옮겨서 처리하기 위해서 위와 같이 3개의 영역으로 나뉘어진 것을 알 수 있습니다.

 

---