이전 포스팅에서는 깃이 무엇인지에 대해 이야기했었다. 이번 포스팅에서는 깃의 기초적인 개념과 사용법에 대해 이야기하겠다.

레포지토리(repository, 저장소)

레포지토리란 쉽게 말해 사용자가 깃이 관리하는 폴더에 대한 버전을 저장할 때마다 저장 당시의 버전들이 저장되어 관리되는 공간(저장소)이다.

개발자가 어떠한 개발 프로젝트를 한다고 가정해보자. 그러면 시작하기에 앞서 본인의 컴퓨터에 해당 프로젝트에 관한 파일들을 저장하고 모아두기 위한 프로젝트 디렉토리(폴더)를 생성할 것이다.

이 때 앞서 말했듯이 코드 버전 관리 프로그램인 깃을 사용하면 해당 디렉토리 안에 어떤 파일들이 존재하는지, 해당 파일들의 내용이 어떻게 되는지 등을 스냅샷 찍듯이 저장하여 저장 순간의 버전들을 이 레포지토리에 보관하는 것이 가능하다.
(※ 몇몇 사람들은 프로젝트 파일들이 담겨 있는 프로젝트 디렉토리 자체를 레포지토리라고 표현하지만 엄연히 말하면 저장 순간의 프로젝트의 모습(버전)들이 담겨있는 저장소가 레포지토리이다.)

git init : 레포지토리(.git ) 생성 및 초기화

특정 디렉토리를 깃으로 관리하고 싶다면 우선 해당 디렉토리의 경로로 이동하여야 한다. 그 후 터미널에서 'git init'을 입력하면 해당 디렉토리에 .git이라는 파일이 하나 생겨나는데 이 파일이 바로 위에서 이야기한 레포지토리이다.
(※ .git이 생겨났는지 확인하고 싶으면 디렉토리 안의 숨겨진 파일을 포함하여 모든 파일을 보여주는 리눅스 명령어인 ls -a를 디렉토리 경로에서 터미널에 입력하면 된다.)

예시로 컴퓨터에 Test라는 디렉토리를 만들고 디렉토리 안에 test1.py, test2.py라는 파일들을 추가한 후 이 디렉토리를 깃으로 관리하자고 한다고 가정해보자.

위와 같이 git init을 입력했을 때 Initialized empty Git repository~'('빈 깃 저장소를 초기화했습니다')로 시작하는 비어 있는 레포지토리가 제대로 생성되었다는 뜻이다. ls -a를 입력하면 레포티지토리인 .git이 제대로 생성된 것도 확인할 수 있다.

git add: 추적 및 변경 사항 저장할 파일 지정

우리가 어떤 파일들을 깃에 의해 관리하고 싶어하는지, 어떤 파일들의 변경 사항을 레포지토리에 저장하고 수정 사항들을 반영하고 싶어하는지 깃으로서는 알 길이 없다. 그렇기 때문에 처음 레포지토리에 저장할 때에는 어떤 파일들을 저장하고 추적할 것인지를 등록해야 하며 매번 레포지토리에 해당 버전을 저장할 때마다 새로 만들거나 수정된 파일들 중 어떤 파일들의 수정 사항을 반영하여 저장하고 싶은지 깃에게 알려주어야 한다.
이처럼 파일을 새로 생성하거나 기존의 파일들을 수정하고 그 파일들 중에서 어떤 파일들의 변경 사항을 반영하여 새로운 버전에 포함될 것인지를 사전에 지정하는 사전 작업을 하기 위해 git add 명령어를 입력해야 한다.

git add 커맨드 입력 후 등록하고 싶은 파일의 이름을 지정하면 해당 파일이 저장 및 변경 사항 추적 대상의 파일로 등록된다. 하지만 만약 여러 개의 파일 특히 대량의 파일을 등록해야 하는 상황이면 일일이 하나 하나 등록하기 난감할 것이다. 이럴 때에는 git add . 명령어를 입력하면 해당 디렉토리에 있는 모든 파일이 등록 대상이 된다.


밑에서 설명할 것이지만 미리 말해두면 git add하면 해당 파일은 Staging Area라는 공간에 올라간다.

git status(디렉토리의 현재 상태 확인)

하지만 작업을 하다 보면 내가 git add를 통해서 추적 및 저장 대상으로 어떤 파일을 등록했는지 헷갈리거나 제대로 등록되었는지 불안할 때가 있다. 이 때는 git status 명령어를 통해 깃으로 관리되는 파일의 상태들을 확인할 수 있다.

예시로 아까 만든 Test 디렉토리에서 test1.py 파일만 git add한 후 git status를 입력하면 이러한 화면을 확인할 수 있다.

git status 입력 시 사용자가 확인할 수 있는 정보에는 다음과 같은 것들이 존재한다.

1. Changes to be commited: 해당 파일이 git add되어 있음 (Staging Area에 존재 중)

2. Untracked files: 생성된 이후 한 번도 git add되지 않아 깃의 추적 및 관리 대상의 파일이 아님

3. Changes not staged for commit: 이전에 커밋되었던 파일이고 변경 사항이 존재하지만 git add되지 않았음(Stagin Area에 존재하지 않음)

4. nothing to commit, working tree clean: working tree(프로젝트 디렉토리)에 마지막 커밋(최신 버전)과 비교하여 변경 사항이 존재하지 않음
   
   
   또한 깃은 4가지 상태로 분류하여 파일들을 관리한다.

git으로 관리되는 파일의 4가지 상태

1. Untrakced : 이 상태는 해당 파일이 아직 한 번도 git add되지 않아 깃에 의해 그 변동 사항이 아예 추적되지 않고 있는 상태를 의미한다.

이후의 나머지 3가지 상태는 모두 Tracked의 상태이다.

2. Staged: 커밋(저장)되었던 파일이 수정되었거나 파일이 새로 생성된 이후 git add되어 있는 상태이다.

3. Unmodified: 현재 파일이 저장되어 있는 직전 버전의 해당 파일이랑 비교해서 수정된 사항이 없는 파일이다.

4. Modified: 아직 git add는 되지 않았지만 저장된 최신 버전의 파일과 비교해서 파일에 수정된 사항이 존재하는 상태이다.

git reset (git add된 파일 취소하기)

하지만 깃을 사용하다 보면 실수로 올리면 안 되는 파일을 git add해버리는 상황이 충분히 발생할 수 있다. 이럴 때 사용할 수 있는 명령어는 git reset이다.
파일 이름을 지정하여 git reset 커맨드를 입력하면 해당 파일은 git add가 취소되어 staging area에서 내려오게 된다. 만약 git add된 모든 파일을 취소하고 싶으면 git reset만 입력하면 된다.

git reset을 한다고 하더라도 파일의 내용 자체가 바뀌지는 않으니 만약 파일의 내용도 이전으로 원상복귀시키기를 원한다면 직접 파일을 수정해야 한다.

git commit

앞서 여러 번 언급했듯이 깃의 본질은 버전 관리 도구이다. 버전 관리 도구의 가장 핵심 기능은 현재의 작업물을 지금 모습 그대로 하나의 버전으로 남겨 저장하는 것인데 깃에서 이러한 기능을 수행하는 명령어가 git commit -m "남기고 싶은 메시지"이다.
깃에서는 프로젝트 디렉토리의 현재 모습을 하나의 버전으로 남기는 행위 또는 버전으로 만들어진 결과물을 커밋이라고 한다. 커밋을 실행하면 현재의 디렉토리 안의 모습이 하나의 버전으로써 스냅샷처럼 레포지토리에 기록된다. 사용자는 이런 식으로 저장된 여러 버전들을 자유롭게 참조하거나 만약 필요하다면 이전의 버전들로 작업물을 회귀시키는 것이 가능하다.

하지만 커밋하기 위해서는 선행되어야 하는 전제 조건들이 존재한다.

1. 만약 본인이 깃을 설치하고 처음 사용한다면 사용자의 이름과 이메일 주소를 설정해야만 한다. 깃은 협업의 도구로도 이용되기 때문에 누가 커밋을 했는지 팀원들이 공유할 필요성이 존재한다. 때문에 누가 커밋을 했는지 식별하기 위해 본인의 이름과 이메일을 깃에 설정하여야 한다.
   git config user.name "임의의 본인 이름"
   , git config user.email "이메일 주소" 명령어를 통해 이름과 이메일 설정이 가능하다.

2. 커밋할 파일들을 git add로 지정해주어야 한다.

3. -m "" 옵션 또는 vim을 통해 사용자가 남기고 싶은 커밋에 대한 정보를 커밋 메시지로 남겨주어야 커밋이 가능하다.

앞서 예시로 들었던 Test 디렉토리에서 git add한 test1.py를 "first commit"이라느 커밋 메시지와 함께 commit했더니 first commit(해당 디렉토리의 첫 커밋), 1 file changed(파일 몇 개가 수정되었는지), 0 insertions(+), 0 deletions(-) 코드 몇 줄이 증감되었는지 등의 정보와 함께 무사히 커밋된 것을 확인할 수 있다.

Git의 작업 영역

깃에는 내부적으로 관리하는 3가지의 영역이 존재한다. 해당 영역들은 다음과 같다.

1. working directory(working tree): 작업을 하고 있는(현재 경로의) 디렉토리, 즉 프로젝트에 필요한 파일들이 모여 있는 프로젝트 디렉토리를 의미한다.

2. staging area(.index): git add를 한 파일들이 존재하는 영역이다. 커밋을 하면 해당 영역에 존재하는 파일들만 커밋에 반영된다.

3. repository(.git): 디렉토리의 변경 이력들 즉, 커밋들이 저장되는 영역이다.

쉽게 말해 사용자가 working directory에서 열심히 작업을 한 후 작업한 파일들을 git add하여 staging area에 올린 후 커밋을 하면 staging area에 존재하는 파일들의 현재 모습을 반영되고 디렉토리의 전체의 모습이 마치 하나의 스냅샷처럼 촬영되어 repository에 저장되는 원리이다.

요약

요약하자면 작업을 위해 처음 working directory를 만들면 git init 명령어를 통해 repository를 생성하고 작업 후 git add로 staging area에 추적할 파일을 등록한 후 git commit -m "커밋 메시지"하여 디렉토리의 현재 모습을 저장하는데 이 버전을 커밋이라고 한다.

이후 파일들을 수정하고 변경된 수정 사항을 반영하고 싶으면 git init은 디렉토리 생성 후 최초 한 번만 하면 되니 생략하고 수정 사항 반영할 파일들 선택하여(혹은 git add .로 전체 선택) add한 후 커밋하면 된다. 만약 add를 취소하고 싶으면 git reset 명령어를 실행하면 취소가 가능하다.

*해당 포스팅은 코드잇의 강의를 참고하였습니다.