[Git] 깃 기본편(2): 스테이징 영역, 커밋 (Staged, Commit, Status, Add, Log)

Staging area

깃의 스테이징 영역은 매우 중요한 개념이다.

이전 글에서 우리는 local repository(로컬저장소)에서 했던 작업 내용들을 remote repository(원격저장소)에 반영을 해봤다. 한번 반영된 내용은 돌이키기가 어렵다. 그래서 그 중간에 스테이징 영역이라는 것이 존재한다. 쉽게 생각해서 배달되기 전 박스라고 생각하자. 어떤 내용물이든 집어넣을 수 있고 또 뺄 수 있다. 박스가 완성이 됐다면 원격 저장소로 넘기자.

 

git에 관리되는 파일의 라이프사이클부터 보고 가자.

https://git-scm.com/book/ko/v2

디렉토리의 파일은 Untracked와 Tracked 두 가지로 구분된다. 그리고 Tracked는 또 다시 Unmodified, Modifed, Staged로 구분된다. Untracked 파일은 Git이 팔로우업을 하고 있지 않는 파일들이고, Tracked 파일은 Git이 인지하고 있는 파일들이다. 만약 Untracked 파일을 Tracked 상태로 바꾸고 싶다면 git add 명령어를 통해 추가해주면 된다.

 

Tracked 파일은 Unmodified, Modifed, Staged 단계를 반복한다. 어떤 파일을 수정하면 Modified 상태가 된다. 그리고 git add 명령어를 이용하여 Staged 상태로 파일을 올릴 수 있다. 그 이후 Commit(커밋)을 하게 되면 다시 Staged 상태에서 Unmodified 상태로 돌아간다. 즉, Commit을 하면 Staging 영역에 있는 변경된 작업 내용들을 저장하는 것이고 그 저장된 상태가 최신 상태이기에 다시 Unmodified 상태로 돌아가는 것이다. 그림을 보면 이제 이해가 갈 것이다.

 

그럼, 예시를 통해 한번 더 복습해보자. 

파일 상태를 알 수 있는 두가지 명령어를 알아보자.

git status

git status는 파일들의 상태 및 현재 상태를 보여준다.

좀 전에 우리는 작업 내용들을 모두 원격 저장소에 커밋하였기 때문에 더 이상 변경된 내용이 없다.

그래서 위와 같이 nothing to commit, working tree clean이라고 뜬다. 즉, Tracked 파일은 하나도 변경되지 않았다는 뜻이다. 

 

그럼 portfolio 안에 있는 test.txt의 내용을 바꾼 이후에 git status를 해보면 어떻게 뜰까? 

중간에 빨간 문구를 해석하자면, Tracked 파일 중 test.txt가 modified 상태라는 뜻이다. 만약 처음 만들어진 파일이라면 Untracked files 라는 문구가 붙을 것이다. 

"Changes not staged for commit"은 현재 Staged 상태는 아니라는 뜻이다. 만약 Staged 상태로 올리고 싶다면 git add 명령어를 입력하면 된다. 잠깐, 아까 Untracked 파일을 Tracked 상태로 추가할 때도 git add이지 않았던가? 

그렇다. 둘 다 git add 명령어로 가능한 부분인데, 다음 커밋하기 전에 커밋할 내용들을 Staged에 추가한다고 생각하자. 

 

git add "filename"

그럼 예시를 통해 git add 기능을 자세히 보자.

먼저, Tracked 파일이 아닌 새로운 파일을 추가하여 이를 Untracked에서 Tracked로 바꿔보자. 앞서 예시에서 사용했던 test.txt는 이미 Tracked된 파일이므로 untracked.txt 라는 파일을 추가하고 git status를 입력해봤다.

그러니 Untracked files 란에 untracked.txt가 추가된 것을 볼 수 있다. 이제 git add untracked.txt 명령어를 통해 Tracked 상태로 바꿔보자. 

이번에는 Changes to be committed 밑에 untracked.txt가 추가된 것을 볼 수 있다. 즉, Staged 상태에 있는 것이다.

git add를 하지 않은 test.txt 파일은 여전히 Modified 상태에 머물러 있는 것을 볼 수 있다.

 

git diff "filename"

git diff "filename"을 입력하면 어떤 작업 내용이 바뀌었는지 보다 상세하게 보여준다.

앞서 test.txt를 수정했는데, 어떤 내용이 바뀌었는지, git diff test.txt를 입력해봤다.

뭐가 많이 뜬다. 한줄씩 보자.

// 첫째줄에 a와 b는 이전 버전, 현재 버전을 뜻한다. 

// index line은 깃 내부의 데이터베이스에서의 변화를 보여준 것이다.

// ---, +++ 는 각각 제거된, 추가된 줄을 의미한다.

// @@는 어느 부분이 변경 됐는지 보여준다. -는 이전버전을, +는 현재버전을 의미하고, 위 예시에서는 이전버전 0번째 라인에서 현재버전 1번째 라인까지를 비교했다는 의미이다.

// +asdf는 현재버전에 asdf 라는 문구가 추가되었다를 나타낸다.

 

뒤에 filename을 입력하지 않고 git diff 만 입력할 경우에는 수정된 파일들 전체에 대한 내용을 보여준다.

 

Commit

Staged 상태로 원하는 파일 작업 내용들을 다 올렸다면 이제 Commit을 할 차례이다. Commit은 원격 저장소로 업로드 하기 전에 Staged 상태인 파일들을 하나의 박스 안에 다 넣어둔다고 생각하면 된다. 추후 알게 될 것이지만, 이 박스를 원격 저장소에 업로드 한 이후에는 박스 단위로 그 업로드 자체도 취소가 가능하지, 그 안에 있는 파일 몇개만을 골라서 작업할 순 없다. 

git commit -m "커밋에 대한 설명 메시지"

 만약, 실수로 커밋 메세지를 잘못 입력 했다면 아래와 같이 --amend 플래그를 통해 수정하면 된다.

git commit --amend -m "커밋에 대한 설명 메세지"

커밋 메세지를 규칙적으로 잘 작성하는 것도 협업의 필수 요소이기에 구글링을 해서 찾아보는 것도 추천한다.

 

 

Log

커밋을 했으면 이제 기록이 남을 것이고, 이는 log를 통해 커밋 내용들을 시간 순서대로 확인할 수 있다.

git log

예시를 보면 위에서부터 최신순으로 로그 내용들이 보여지는데, 우리는 커밋을 한번 했기에 하나만 보여진다. 

// 첫째줄의 commit 뒤에 일련의 숫자는 hash라고 부르며 unique ID이다.  

// 두번째, 세번째 줄과 그 아래 내용들은 누가, 언제, 커밋 메세지가 차례로 표기된다.