깃(Git)&깃허브(Github) 배우기 -3(커밋 확인 및 버전 관리)

깃& 깃헙 배우기 시리즈
내용이 잘 이해되지 않는다면 이전 포스팅을 차례로 확인하실 것을 추천드립니다.

2021/02/14 - [Computer Science/Git,Github] - 깃(Git)&깃허브(Github) 배우기 -1

2021/02/15 - [Computer Science/Git,Github] - 깃(Git)&깃허브(Github) 배우기 -2(깃 저장소 만들기)

---

포스팅 개요.

 

지난 포스팅에서 작업트리에서 스테이징을 하고, 커밋하는 과정까지 다뤄보았습니다.

이번 포스팅에서는 커밋 내용을 확인하는 방법과 스테이징과 커밋과정에서의 파일 상태 확인 방법,

일부 파일을 버전 관리에서 제외하는 방법에 대해 다뤄보도록 하겠습니다.

 

먼저 지난 번 포스팅에서 작성했던 내용을 기반으로 앞서 실습을 진행할 예정이기 때문에 기존의 커밋 기록을 살펴보기 위해

다음 명령어를 입력해줍시다.

git log

다음과 같은 메시지를 확인할 수 있습니다.

먼저 첫번째 줄은 commit hash 또는 git hash라고 하는데, 커밋을 구별하는 아이디라고 표현할 수 있습니다.
Author은 커밋한 버전을 만든 사람이 나오고, Date는 버전이 만들어진 시간이 나타납니다.

마지막으로 second commit과 같은 메시지는

git commit -m "second commit"

과 같이 초기 저희가 커밋할 때 설정한 메시지에 들어가는 곳입니다.

커밋 메시지는 버전 생성자가 버전에 대한 정보를 알리지만, 사실 정확하게 어떤 부분이 코드에서 수정되었느냐에 대해서는 완벽히 언급한다고 말할 수 없습니다.

따라서 프로그램의 규모가 클수록 구체적으로 어떤 부분이 수정되었는지에 대한 정보를 찾아야 합니다.
이를 위해

git diff

명령어를 사용해 작업 트리의 파일과 스테이지의 파일을 비교하거나, 스테이지의 파일과 저장소의 최신 버전과 비교해 수정한 파일을 커밋하기 전에 점검이 가능합니다.

이 명령어를 사용하기 위해 기존에 생성한 change.txt 파일을 열어 내용의 일부를 수정해주었습니다.

필자는 vim change.txt 명령어를 사용해 vim 편집기에서 작업을 하였습니다.

수정 후 깃 상태 확인 명령어를 사용해 조회를 해보겠습니다.

git status

modified: change.txt라고 표기되는 것을 확인할 수 있습니다.

편집기를 통해 수정이 되었기 때문에 작업 트리에 방금 수정한 change.txt 파일은 최신 버전의 커밋 결과와 다른 값을 가지고 있습니다.

이를 확인하기 위해 앞서 언급한 명령어인 git diff

git diff

를 사용해보도록 하겠습니다.

빨간 글씨로 표기된

-hi i will do second commit.
-hello world!y
의 내용이 삭제되었고,

+hi i will do thrid commit.
+hello world!

의 내용이 추가되었다는 상황을 뜻합니다.

 

위와 같은 방식으로 작업 트리의 수정 파일과 저장소의 최신 커밋을 비교해 수정한 내용으로 다시 버전을 만들려면 스테이지에 올린 후 커밋을 하면 됩니다.
반면, 저장소의 최신 커밋을 그대로 사용하고 수정한 내용을 최신 커밋에 반영하지 않으려면 git checkout 명령어를 사용해 수정 내용을 취소하면 됩니다.(추후 소개해드릴 예정입니다.)

 

위에서 변경한 내용을 아직 반영한 상태가 아니고, 스테이징과 커밋은 지난 포스팅에서 다뤘기 때문에 수정한 change.txt 파일을 다시 원래 상태로 돌려놓도록 하겠습니다.

vim change.txt

명령어를 사용해

> hi i will do second commit.
> hello world!y

에 해당하는 내용으로 수정한 후 다시 반영을 해놓도록 하겠습니다.

수정 후 git diff 명령어를 입력해 봤더니 수정된 부분이 없다고 나오는 것을 확인할 수 있었습니다.

다음으로 버전을 만드는 과정에서 파일 상태를 읽는 방법에 대해서 말씀드리겠습니다.

먼저 vim으로 change.txt 파일을 열고, "add line"이라는 문자열을 한 줄 추가해주었습니다.

vim change.txt

이번에는 새롭게 change2.txt라는 파일을 추가해주고, 안에 아무 내용이나 작성해보았습니다.

vim change2.txt

이제 깃 상태 확인 명령어인

git status

를 사용해 확인해보도록 하겠습니다.

다음과 같은 문구를 볼 수 있는데,

앞서 커밋을 한번 진행했던 change.txt의 경우, Changes not staged for commit: 내부 영역에 소속되어 있고,
이번에 새롭게 작성한 change2.txt의 경우, Untracked files: 내부 영역에 속해 있는 것을 확인할 수 있습니다.

 

쉽게 말해 change.txt는 깃에서 추적하고 있고, change2.txt는 깃에서 추적하고 있지 않다.라고 말할 수 있는데

이처럼 추적하는 파일들은 Tracked 파일, 추적되지 않는 파일들은 Untracked 파일로 구분합니다.

 

지난 포스팅에서 다뤘던 스테이징 명령어를 사용해 작업 트리로부터 스테이지 영역에 두 파일을 모두 올려보도록 하겠습니다.

git add change.txt
git add change2.txt

이제 스테이지에 올라온 두 파일을 모두 새로운 버전으로 만들기 위해 커밋 과정을 진행해보도록 하겠습니다.

커밋이 진행되고 나면, git log 명령어를 입력해 커밋 로그를 확인하면 다음과 같이 출력됩니다.

하지만 제가 작성한 커밋 메시지는 보이지만, 커밋에 어떤 파일들이 관련되어 있는지는 전혀 알 수 없습니다.

커밋을 한 파일을 함께 보기 위해서는 git log 명령에 --stat을 붙입니다.

다음으로 버전 관리에서 파일을 제외하는 방법에 대해서 알아보도록 하겠습니다.

버전 관리에서 제외하기 위해서는 .gitignore을 이용합니다.

먼저 vim 편집기를 활용해 ignore.txt라는 파일을 하나 만들어주었습니다. 이 파일은 버전 관리를 하지 않을 파일입니다.

이후 vim 명령어를 사용해

vim .gitignore

.gitignore 파일을 생성하고,

편집기에서 버전 관리하지 않을 파일을 작성합니다.
필자는 ignore.txt를 버전 관리하지 않을 것이기 때문에 해당 파일을 편집기 내부에 작성했습니다.

git status 명령어를 입력해 깃의 상태를 보더라도

.gitignore 파일만 Untracked에 나올 뿐 먼저 생성한 ignore.txt는 깃 상태에 출력되지 않습니다.

마찬가지로 필자는 맥북을 사용하고 있기 때문에 Track 할 필요가 없는 .DS_Store 파일도 .gitignore 파일에 올려주도록 하겠습니다.

결국 Untracked 상태의 파일을 .gitignore에 올려 더 이상 추적하지 않도록 설정해준다고 보시면 됩니다.

계속 반복하다 보면, git status, git add, git commit 명령어가 익숙해지실 거라 생각합니다.

이제 다음과 같이 nothing to commit, working tree clean이라는 출력 결과를 확인할 수 있게 됩니다.

 

위의 과정을 통해 Untracked 파일을 모두 깃에서 추적하지 않도록 설정했다면, 이제 Tracked 파일들에 대해서 알아보겠습니다.
커밋을 통해 한번이라도 버전이 등록이 된 파일이라면, Track 되는 파일이라고 칭할 수 있는데 깃 명령어를 사용해 파일의 상태를 확인해보면, 작업 트리 내부에 있는지, 스테이지 영역에 있는지, 저장소(리포지터리)에 속하는지 구체적인 상태 정보를 알 수 있습니다.

ls -la

명령어를 사용해 example-git 디렉터리를 살펴보면 다음과 같이 이뤄져 있습니다.

이중 .DS_Store, ignore.txt는 Untracked 상태이니 나머지 change.txt, change2.txt 파일에 대해 알아보도록 하겠습니다.

git status 

명령어를 입력해 상태를 확인해보면

다음과 같이 working tree clean이라는 메시지를 출력 결과로 얻을 수 있습니다.

현재 작업 트리에 있는 Track 상태의 모든 파일이 최신 커밋 버전과 동일하고, 수정되지 않은 상태(Unmodified)를 뜻합니다.

작업 트리에 변화를 주기 위해 vim 편집기를 사용해 change2.txt의 일부 내용을 제거하였습니다.

이후 다시

git status 

명령어를 입력해 상태를 확인해 보도록 하겠습니다.

이제 change2.txt 파일이 수정되었으니, change2.txt 파일은 수정된 상태(modified)입니다. 하지만 아직 스테이징 영역에 올라가지 않았기 때문에, Changes not staged for commit:  메시지를 확인할 수 있는 상태입니다.

git add 명령어를 사용해 change2.txt 파일을 스테이징 영역으로 올리고,

다시명령어를 입력해 상태를 확인해보겠습니다.

git status 

이제 Changes to be committed: 메시지를 확인했다면 스테이징된 상태(staged)라고 말할 수 있습니다.

이제 다시 git commit 명령어를 사용해 스테이징 영역에 올라간 수정 내용을 커밋해 새 버전을 만들도록 하겠습니다.

그럼 다음과 같이 nothing to commit, working tree clean 메시지를 출력 결과로 얻게 되고, 수정되지 않은 상태(Unmodified)로 되돌아가게 됩니다.

이를 시각화하면 다음과 같이 표현할 수 있을 것 같습니다.

이번 포스팅에서는 깃에서 버전을 만드는 과정에서 파일의 상태에 대해서 확인해보았습니다. 다들 정리가 잘 되셨길 바랍니다.

 

 

다음 포스팅에서는 스테이징과 커밋을 되돌리는 방법에 대해서 소개해드리도록 하겠습니다.

---

참고

Do it! 지옥에서 온 문서 관리자 깃&깃허브 입문 / 이지스퍼블리싱

깃헙 : github.com/

---

깃& 깃헙 배우기 시리즈
내용이 잘 이해되지 않는다면 이전 포스팅을 차례로 확인하실 것을 추천드립니다.

2021/02/14 - [Computer Science/Git,Github] - 깃(Git)&깃허브(Github) 배우기 -1

2021/02/15 - [Computer Science/Git,Github] - 깃(Git)&깃허브(Github) 배우기 -2(깃 저장소 만들기)