전 글에 이어서 유노코딩을 통해 공부한 Git 관련 내용을 복습해보겠습니다.
전에 만든 git_practice의 text1.txt 파일을 열어서 아무 말이나 적어봅시다.
파일을 수정하고 저장소에 보내지 않았으니, $ git status를 입력하면 "저장소로 보내야 할 즉, 커밋해야 할 수정한 기록이 있는 파일이 있다"라는 식의 말이 나올겁니다.
먼저 수정 이력이 있는 파일을 저장소에 보내기 전 대기 장소인 'Staging Area'로 보내는 $ git add 명령어를 사용해보겠습니다.
여기서 Working Directory에 있는 파일을 바로 저장소(Repository)에 보내지 왜 Staging Area를 거치는지 의문이 생기지 않나요? 그 이유를 챗GPT에게 물어봤습니다.
Staging Area를 거치는 이유는 "유연하고 안전한 버전 관리를 위함"이라고 하는데요, 생각해보면 파일 입력을 아직 완료하지도 않았는데 수정사항들이 계속 저장소에 저장된다면 불필요한 혹은 불완전한 파일만 늘어나고 그렇게 오류 파일과 실제 파일의 구분도 어려워질 듯 합니다.
또한, 저장할 때도 "정말로 저장하겠습니까?"가 나와야 진짜 필요한 것만 완전한 상태에서 저장할 수 있는 것처럼 잠깐 특정 장소에 대기시켰다가 나중에 대기 중인 파일을 수정 완료 상태에서 저장소로 보내는 것이 훨씬 안전하고 효율적이겠죠.
말이 길어졌는데, 수정 사항이 있는 파일 'text1.txt'를 $ git add를 사용해 Staging Area로 보내겠습니다.
$ git add text1.txt
다시 $ git status로 상태를 확인해봤습니다.
"Untracked files"에서 "Changes to be commited"로 바뀌면서 글자 색깔도 빨간색에서 녹색으로 바뀐 걸 확인할 수 있는데요, 그러면 이제 파일 수정사항이 Staging Area로 들어간 겁니다.
참고로 $ git add에 .을 추가한 $ git add . 을 입력하면 Working Directory에 있는 모든 파일을 Staging Area로 보내게 됩니다.
$ git add .
다음으로 $ git commit 명령어를 사용해 Staing Area에 대기중인 'text1.txt' 파일을 Respository에 추가해보겠습니다.
$ git commit text1.txt
그러면 다음과 같은 화면이 등장할겁니다.
여기서 'Shift'를 누르고 i를 누르면 아래 "-- INSERT"라고 바뀌면서 본 화면에 저장할 commit의 이름을 입력할 수 있게 됩니다. 저는 아래와 같이 "first commit"이라고 입력해보겠습니다.
입력을 다 했으면 ESC 키를 누르고, 아래처럼 ": wq"를 입력하고 Enter를 누르면 커밋 이름 입력이 완료되면서 파일 수정사항이 저장소로 보내집니다.
저장소로 잘 보내졌는지 확인하기 위해서는 커밋한 수정이력을 확인하는 명령어인 "$ git log"를 사용합니다.
$ git log
제가 입력한 이름 'TKM'이 first commit이라는 수정이력을 12월 21일 오후 1시에 만들었다고 나오네요. 추가적으로, $ git status로 staging area에 있는 파일이 있는지 확인해봅시다.
커밋할게 없다고 뜹니다. 그럼 Working Directory에 있는 파일 수정사항을 Staging Area, 그리고 Repository까지 이동시키는 과정을 성공적으로 수행했다고 볼 수 있습니다.
다음으로 또 한번 text1.txt 파일을 수정하고 그 수정이력을 또 한번 Repository로 보내보겠습니다.
"아무 말" 뒤에 "오늘은 날씨가 춥다"라는 내용을 추가하고 저장했습니다. 그리고 상태를 확인해보겠습니다.
그럼 다시 이렇게 빨간글씨와 함께 커밋해야할 수정 사항이 있는 파일이 등장하는데요, 아까 했듯이 git add로 staging 영역으로 보내고, git commit으로 repository로 보내겠습니다.
위에서 말했듯 이렇게 . 만 입력하면 Working Directory에 있는 모든 파일을 Staging Area로 보낼 수 있습니다. 특정 파일만 보낼 경우 파일 이름을 입력해야 하니 유의 바랍니다.
commit의 경우는 굳이 아까처럼 파란색 글씨가 등장하는 화면을 만들어 수정 이력의 이름을 쓰지 않아도 '-m' 옵션을 추가해서 명령어에 바로 수정 이력의 이름을 쓸 수 있습니다.
이번엔 "second commit"이라는 이름으로 지정해보겠습니다.
git commit -m "second commit"
그럼 이제 완료입니다. 제대로 들어갔는지 $ git log로 확인해봅시다.
second commit이 보이네요! 이제 git의 차별화된 기능인 "이전 수정 시점으로 돌아가는 기능"과 "다시 현재 시점으로 돌아오는 기능"을 보여줄 때가 된 것 같습니다. 즉, text1에서 "오늘은 날씨가 춥다"라는 문장이 적혀이기 전 "아무 말"만 있었던 first commit으로 돌아가보고자 합니다.
먼저 어떤 변경사항들이 생겼는지 자세하기 볼 수 있는 $ git log -p를 입력해봅시다.
$ git log -p
저는 두 개 밖에서 커밋한 이력이 없어서 이렇게 간단하게 나왔는데요, 커밋이 여러 개가 있을 때 특정 개수만 보고 싶으면 $ git log -(숫자)를 입력하면 됩니다. 예로, 한개만 보고 싶으면 $ git log -1을 쓰면됩니다.
암튼 출력된 걸 보니까 first commit에는 "아무 말"이 적혔고, second commit에는 "오늘은 날씨가 춥다"가 추가로 적혔다는 걸 확인할 수 있습니다. 그럼 "아무 말"만 적힌 first commit으로 넘어가기 위해 해당 커밋으로 돌아갈 수 있도록 하는 커밋의 '마커'를 확인해보고자 합니다.
커밋의 '마커'는 각 커밋을 한줄 씩 출력하는 옵션인 $ git log -- oneline 명령어를 입력하면 나옵니다. 다음과 같이 말이죠.
git log --oneline
commit의 이름 옆에 영어와 숫자로 구성된 7자리의 고유의 식별자가 나옵니다. 이것을 마커로 활용하면 되는데, first commit의 수정 시점으로 가고 싶으면 '1d12ff9'를 기억하면 됩니다.
그리고 문서 내용을 특정 시점으로 되돌리는 깃 명령어인 $ git checkout (마커 7자리)를 입력하면 됩니다.
git checkout 1d12ff9
그럼 이렇게 나오면서 first commit의 시점으로 돌아가게 됩니다. 이제 text1.txt 파일을 다시 열어봅시다.
"오늘은 날씨가 춥다"를 입력한 두번째 문장이 사라지고 첫번째 "아무 말"만 남게 되었습니다. first commit으로 잘 돌아갔네요.
다시 현재 시점 즉, "오늘은 날씨가 춥다"를 입력한 second commit으로 돌아가보겠습니다. 문제는 다시 $ git log --oneline을 입력하면 second commit이 사라졌다는 겁니다.
이럴 때는 돌아갈 수 있는 마커를 확인하기 위해 HEAD가 이동해온 이력을 알려주는 명령어인 $ git reflog를 입력해줍니다.
$ git reflog
여기서 second commit의 식별자인 83dbdb9와 $ git checkout을 사용해서 "오늘은 날씨가 춥다"가 입력된 시점으로 돌아가보겠습니다.
그리고 다시 text1.txt를 확인해보겠습니다.
"오늘은 날씨가 춥다"가 다시 추가되었음을 확인할 수 있습니다. 다음에는 문서 중 수정 이력에서 제외하고 싶은 문서를 추적 대상에서 제외할 수 있는 .gitignore에 대해 알아보도록 하겠습니다.
본 글은 유노코딩 YOUTUBE "깃과 깃허브가 처음인 당신에게" 영상 내용을 참고했으며, 자세하고 정확한 설명은 아래 유튜브 영상을 참고하시길 추천드립니다. 감사합니다!