[Git] Git에 대한 고찰 (2) - git add, git commit

Git LifeCycle - Untracked 와 Git LifeCycle - (2) 이 두가지의 게시글을 작성하면서 git add와 git commit의 옵션들을 사용하는 법과 개념이 명확히 잡혀있지 않다는것을 느껴 따로 정리하는 글을 작성하였습니다.

git add

git add는 작업 디렉토리(working directory)상의 변경 내용을 스테이징 영역(staging area)에 추가하기 위해 사용하는 Git 명령어 입니다. 파일과 폴더를 모두 arguments로 받습니다. 또한 git add는 Untracked상태의 파일을 Tracked상태롤 바꿀때와 not staged상태의 파일을 staged상태로 바꾸어줄때 사용하며 Merge한 파일중 충돌난 상태의 파일을 Resolve상태로 만들때 또한 사용합니다.

git commit vs git add

git add 명령어는 사용자가 커밋을 하기 전까지 변경된 내용들을 모아놓기 위해 사용합니다. 따라서 git commit이라는 명령어를 사용하기 이전에는 아무리 git add 명령어를 실행해도 Git 저장소의 변경 이력에는 어떤 영향도 주지 않습니다. git add는 스테이징 영역에만 올릴뿐 Git 저장소에 실질적인 영향을 못미치기 때문입니다. 실질적인 영향을 미치는 명령어는 git commit이 되겠습니다.

git status

git status는 git add와 빼놓고 볼수없는 명령어 입니다. git status명령어를 통해 작업 디렉토리와 스테이징 영역의 상태를 확인할수 있습니다. 이 말은 작업 디렉토리에 있는 파일들이 현재 Staged상태인지 Unstaged상태인지 Untracked상태인지를 git status명령어를 통해 확인할수 있다는 말입니다.

위의 사진은 git status명령어의 결과이며 크게 3개의 영역으로 구분되어 있는것을 볼수 있습니다.

• Changes to be committed: 이 영역은 스테이징 영역에 넘어가 있는 변경 내용을 보여주며 저는Changes를 변경사항으로 해석하여 **커밋이 되기위한(커밋을 할수있는) 변경사항이라고 해석해 이해하고 있습니다. Git을 거의 모를때 이 Changes의 뜻을 이해하기 쉽게(?) 해석하지 못해서 3가지의 영역이 잘 이해가 되지 않은 경험이 있었습니다.
• Changes not staged for commit: 커밋을 위해 아직 staged되지 않은 변경사항을 말합니다. 커밋을 하기위해서는 staged영역에 올라가 있어야 하는데 이 파일들은 내용의 변경은 있었지만 아직 git add하지 않았기 때문에 commit을 하지 못하는 상태입니다.
• Untracked files: 말 그대로 추적하지 않는 파일, 즉 Git이 이 파일을 관리하지 않습니다. Untracked에 관련해 여기에 제가 정리해 두었습니다.

Staging Area

git add와 git commit을 적절한 상황에 사용하기위해 알아야하는 아주 중요한 개념입니다. 스테이징 영역은 작업 디렉토리와 Git 저장소의 변경 이력 사이에 징검다리 역할을 합니다.

Staging Area가 존재하는 이유

옛날 Version Control 도구들은 일어난 모든 변경사항들을 한번에 Commit을 했어야 했는데 Git은 한번에 커밋을 하지않고 자기가 커밋을 원하는 파일들만 선택적으로 Commit을 하게 해줄수 있는데 이러한 기능을 하기위해 Staging Area가 존재한다.

커밋 하나는 하나의 변경사항을 담고있는게 가장 이상적인데 커밋의 시기를 놓치면 하나의 변경사항이 아닌 10개,20개 심하면 그 이상까지의 개수의 변경사항을 한번에 커밋해야할수도 있다. 이렇게 되면 나중에 버그를 추적하거나 변경 이력을 롤백(roll back)할 때 힘들어집니다.

위의 말을 조금 더 예를들어 설명하자면, 변경사항 A,B가 있다고 가정했을때, A변경사항을 먼저 커밋하고, B변경사항을 그 다음으로 커밋을 했는데 A변경사항에서 문제가 생겼다고 가정합시다.

그렇다면 문제가 발생한 A변경사항에서만 문제해결을 해주면 됩니다.

그럼 이와 달리 커밋 시점을 놓쳐 부득이 하게 A,B변경사항을 한번에 커밋을 하게됬고 똑같이 A변경사항에서 문제가 발생했다고 상황을 가정하겠습니다. 이렇게 되면 A와 B의 변경사항이 동시에 Commit되었기 때문에 A의 오류를 해결하기위해서는 B의 변경사항까지도 같이 되돌려서 오류해결을 진행해야합니다. 따라서 이러한 상황 자체를 아예 막기위해 커밋하길 원하는 파일만 커밋해줄수 있게 해주는 Staging Area가 생겼습니다.

git commit

git commit명령어를 통해 변경사항을 남길 시점에는 Staged되지 않은 작업 디렉토리의 변경사항은 고려하지않고 Staged가 된 변경사항만 Commit할수 있습니다.

git add

아래의 git add명령어는 작업 디렉토리의 변경 사항의 일부만 스테이징 영역에 넘기고 싶을때 사용합니다.

git add <파일/디렉토리 경로>

위 사진에 보이듯이 변경사항이 생긴 3개의 파일이 있는데 첫 git status명령어의 결과로 3개의 파일 모두 Staged되지 않은 상태임을 확인할수 있습니다 이후에 git add one이라는 명령어를 통해서 one이라는 파일만 Staged영역에 올라간것을 확인할수 있습니다.

git add .

git add .은 상위폴더와 상위파일을 제외한 현재의 디렉토리와 그 하위에 있는 폴더 혹은 파일의 모든 변경 사항을 스테이징 영역으로 넘기고 싶을때 사용합니다.

git add -A

git add -A는 작업 디렉토리 내의 모든 변경 내용을 몽땅 스테이징 영역으로 넘기고 싶을때 사용합니다. (상위, 하위 모두 포함)

만약 git add .명령어를 최상위 폴더에서 하게된다면 git add -A명령어와 동일한 결과를 냅니다.

git add *

git add .와 동일하게 상위폴더, 상위파일을 제외한 현재디렉토리부터 하위디렉토리까지의 모든 변경사항을 Stage영역에 추가합니다. 제가 많이 쓰던 옵션인데 git add .과 같다는것을 이 게시글을 쓰면서 알게되었습니다.

git add -p

git add -p는 현재 변경된 코드들의 파일들을 하나씩 보여주면서 해당 파일을 스테이지에 올릴 것인지, 혹은 올리지 않을 것인지를 바로바로 선택할수 있습니다. 한마디로 git status/ git diff / git add를 동시에 진행하는 아주 유용한 명령어 입니다.

저는 블로그에 올라와있는 많은 게시물 말고도 게시글 작성을 중단한 글도 많은데 이렇게 되면 각각의 파일이 중간에 중단된 파일인지 아니면 모두 작성을 한 파일인지를 일일이 확인해야할일이 발생합니다. 이럴때 귀찮아서 보통 git add .명령어를 사용했지만 이렇게되면 아직 작성이 완료되지 않은 게시글도 stage영역에 추가가 됩니다. 그러면 미완성제품이 commit및 push될 가능성이 있으므로 이렇게 하나하나 눈으로 직접 편리하게 스테이지 영역에 올릴것을 구분할때 씁니다.

명령어를 치면 맨 아래에 Stage this hunk [y,n,q,a,d,e,?]?라는 문구에서 기본적으로 y,n,q만 알아도 지장이 없습니다. 이때 hunk는 스테이지에 올라 갈수 있는 하나의 단위를 말합니다.

`Stage this hunk [y,n,q,a,d,e,?]?` 옵션들
y - stage this hunk
n - do not stage this hunk
q - quit; do not stage this hunk or any of the remaining ones
a - stage this hunk and all later hunks in the file
d - do not stage this hunk or any of the later hunks in the file
g - select a hunk to go to
/ - search for a hunk matching the given regex
j - leave this hunk undecided, see next undecided hunk
J - leave this hunk undecided, see next hunk
k - leave this hunk undecided, see previous undecided hunk
K - leave this hunk undecided, see previous hunk
s - split the current hunk into smaller hunks
e - manually edit the current hunk
? - print help

git add -p명령어를 치면 하단부에 나오는 옵션들의 자세한 설명입니다. 링크

출처

• https://www.daleseo.com/git-add/
• https://siyoon210.tistory.com/103