4. 커밋 다루기 - [ commit history / 커밋 메세지 / HEAD / git reset ]

1. 커밋 히스토리 살펴보기

 

이때까지 한 커밋들을 커밋 히스토리라고 한다.

git bash에서 git log 커맨드를 입력하면 커밋 히스토리를 확인할 수 있다. 가장 오래된 커밋이 아래에, 최신 커밋이 위에 출력된다.

노란색으로 표시된 commit 옆에 긴 문자열들은 커밋 아이디(=커밋 해시)이다.

커밋 히스토리에는 차례로 커밋 아이디, 커밋을 한 사람, 날짜와 시간, 커밋 메세지가 출력된다.

 

 

앞서 커밋 히스토리를 확인해 봤을 땐 커밋 히스토리 하나가 공간을 많이 차지해 한눈에 알아보기 어려운 느낌이다.

q를 입력해 빠져나간 후, git log 커맨드에 --pretty=oneline 이라는 옵션을 붙여주면 더 깔끔하게 볼 수 있다.

훨씬 알아보기 쉽다!

사진처럼 커밋 아이디와 커밋 메세지만 한 줄에 표시된다. 나는 총 네 번의 커밋을 했단걸 쉽게 알 수 있다.

 

 

만약 어떤 파일이 어떻게 변했는지 알고 싶다면 git show [커밋 아이디] 커맨드를 사용하면 된다.

커밋 아이디는 네 자리 정도만 입력해도 알아서 잘 판단해서 출력해준다. wow!!

git show 커맨드를 사용해 아무거나 출력해 보았다.

하이라이팅 해놓은 부분을 보면 ---가 붙은 줄은 해당 커밋 이전의 모습, +++이 붙은 줄은 해당 커밋에서의 모습이다.

아래쪽에 보면 빨간색 줄은 해당 커밋 이전의 모습, 초록색 줄은 해당 커밋에서의 모습이다.

 

 

---

2. m 옵션 없이도 커밋 메세지를 남길 수 있다

 

앞서 커밋 메세지를 남길 땐 -m 옵션을 붙였지만, 사실 없어도 커밋 메세지를 남길 수 있다.

먼저 calculator.py 파일에 곱하기 기능을 하는 multiply 함수를 추가하겠다.

 

git bash로 돌아와 git add . 를 해준 후 git commit 만 입력해주면 아래와 같이 출력된다.

이 창은 커밋 메세지를 입력할 수 있는 창이다! 위에 출력된 내용은 커밋 메세지를 작성할 수 있는 간단한 안내문구이다.

 

여기에 커밋 메세지를 남긴 후 저장하면 알아서 커밋된다.

커밋 메세지 입력 후 저장

 

git bash로 돌아와 커밋 히스토리를 살펴보면, 제일 위에 방금 남긴 메세지가 잘 저장되었음을 알 수 있다.

 

 

나는 git commit을 하면 기본 에디터로 비주얼 코드가 실행되어서 찾아보니, git bash에서 

git config --global core.editor "vim" 을 입력하면  vim이 기본으로 실행된다고 한다.

 

---

3. 최신 커밋 수정하기

 

git에는 최신 커밋을 수정하는 기능이 있다. calculator 파일에서 띄어쓰기를 수정 후 다시 커밋을 해 보겠다.

함수 띄어쓰기 수정!

여기서 커밋할 때, 새로 커밋하는것이 아니라 최신 커밋을 수정해야 하므로 --amend 옵션을 주면 된다.

 

그러면 커밋 메세지를 입력할 수 있는 창이 뜨는데, 화면을 보니 원래 입력했던 커밋 메세지가 출력되고 있다. 여기서 커밋 메세지를 그대로 둬도 되고, 수정해도 된다.

 

난 아래와 같이 수정해주었다.

 

커밋 히스토리를 보면 최근 커밋이 잘 수정되었음을 확인할 수 있다.

 

마지막으로 git push 커맨드를 사용해 리모트 레포지토리에도 반영해주는 것 잊지 말기! ! !

 

 

---

4. 커밋 생성, 커밋 메시지 작성 가이드라인

 

개인 프로젝트의 경우에는 커밋 메시지를 어떻게 작성하든 큰 상관이 없을 수 있지만, 회사에서 여러 명이 참여하는 프로젝트의 경우에는 이 커밋 메시지가 아주 중요하다. 

회사마다 규칙들은 전부 다르겠지만, 커밋 메시지를 어떻게 작성하면 좋은지에 대한 일반론적인 가이드라인은 있다.

1. 커밋 메시지의 제목과 상세 설명 사이에는 한 줄을 비워두기
2. 커밋 메시지의 제목 뒤에 온점(.)을 붙이지 않기
3. 커밋 메시지의 제목의 첫 번째 알파벳은 대문자로 작성
4. 커밋 메시지의 제목은 명령조로 작성(Fix it / Fixed it / Fixes it)
5. 커밋의 상세 내용에는 왜 커밋을 했는지 / 어떤 문제가 있었고 / 적용한 해결책이 어떤 효과를 가지는지 등 작성
6. 다른 사람들이 자신의 코드를 바로 이해할 수 있다고 가정하지 말고 최대한 친절하게 작성
1. 하나의 커밋에는 하나의 수정사항, 하나의 이슈(issue)를 해결한 내용만 남기도록 하기
2. 현재 프로젝트 디렉토리의 상태가 그 내부의 전체 코드를 실행했을 때 에러가 발생하지 않는 상태인 경우에만 커밋하기

 

---

5. 긴 커맨드에 alias 설정하기

 

이때까지 커밋 히스토리를 보기위해 git log 커맨드를, 그리고 커밋 하나당 한 줄씩 보기 위해 --pretty=oneline 옵션을 붙여서 사용해왔다.

Git에는 이렇게 길이가 긴 경우의 커맨드 전체에 별명을 붙여서 그 별명을 사용할 수 있도록 해주는 기능이 있다. 이 때 붙이는 별명을 alias 라고 하고, 별명을 붙이는 행위를 aliasing 이라고 한다.

 

전에 누가 커밋을 남기는지 사용자 정보를 저장하기 위해 git config 커맨드를 사용했었다. aliasing을 할 때도 git config

커맨드를 사용하면 된다.

예를 들어 git log --pretty=oneline 을 git history 라는 별명으로 aliasing 하려면 git config alias.history 'log --pretty=oneline' 라고 입력해주면 된다.

물론 history는 원래 git에 있는 커맨드가 아니라 단지 내가 만든 alias 이다.

aliasing 했으므로 git log --pretty=oneline 대신 git history만 입력해주면 됨

 

---

6. 두 커밋 간의 차이 보기

 

두 커밋 간의 차이를 볼 떈 git diff [이전 커밋아이디] [이후 커밋아이디] 커맨드를 사용하면 된다.

난 최신 2개의 커밋을 비교해보았다.

 

출력 결과는 git show 커맨드의 결과와 비슷하다.

- 가 붙은 빨간줄이 이전 커밋의 모습, + 가 붙은 초록줄의 모습이 이후 커밋의 모습이다.

이후 커밋에는 multiply 함수가 추가되어 있넹

 

---

7. HEAD의 의미

 

커밋 히스토리를 확인해 보면 제일 위에 HEAD 라는 글자가 보인다.

git에서 HEAD는 어떤 커밋 하나를 가리키고 있는 존재인데, 보통 가장 최근에 한 커밋을 가리킨다.

내 커밋 히스토리를 봐도 가장 최신 커밋에 HEAD가 붙어있다.

지금 내가 작업하고 있는 MathTool은 working directory이다. working directory는 HEAD가 가리키는 커밋에 따라 구성된다.

 

현재 파일의 내용들을 출력해보면, 내가 마지막으로 작업한 내용이 출력된다. 이는 HEAD가 가장 최신의 커밋을 가리키고 있기 때문이다. 만약 HEAD가 이전 커밋을 가리키면, working directory의 내용도 과거 커밋의 내용으로 바뀌게 된다.

 

---

8. 이전 커밋으로 git reset 하기

 

HEAD가 이전 커밋을 가리키도록 하고 싶다면, git reset --hard [커밋 아이디] 커맨드를 입력해주면 된다.

나는 HEAD가 최신 이전 커밋을 가리키도록 해주었다.

확인해보면??

최신의 Add multiply function 커밋은 사라졌고, 아래의 Add the info of ~~ 커밋으로 HEAD가 옮겨졌다.

그러면 working directory의 내용도 그에 맞게 바뀌었을까?

짜잔 multiply 함수가 사라졌다~~ 그 전 커밋의 상태로 달라졌음을 알 수 있다.

 

 

즉 과거 커밋으로 아예 돌아가고 싶을 때 git reset 커맨드를 사용해주면 된다.

 

---

9. git reset의 옵션을 배우기 전에 확실히 알아야 할 부분

 

1. git reset과 함께 쓸 수 있는 옵션에는 --hard 말고도 --soft, --mixed라는 옵션들도 있다. HEAD가 과거의 커밋을 가리키게 되는 결과는 git reset에서 어느 옵션을 쓰든 항상 똑같지만, working directory의 내부도 그 과거 커밋의 모습처럼 바뀌는 건 --hard 옵션을 썼기 때문이다.
2. 커밋을 하고 나면 staging area에 있던 파일들은 어떻게 될까? 계속 git add를 할 때마다 staging area에서는 새로운 파일이 추가되거나 원래 있던 파일이 더 새로운 버전의 것으로 교체되거나 할 뿐이고, 원래 있던 게 사라지지는 않는다. 즉 커밋을 했다고 staging area가 초기화되거나 하지는 않는다.

 

---

10. git reset의 3가지 옵션

 

git reset에는 --hard 외에 --soft, --mixed 옵션이 있다. 옵션들은 git의 3가지 작업 영역 중 몇 가지 영역까지 reset하느냐로 구분할 수 있다.

 

git reset을 취소하고 싶을때는 git pull을 이용해 깃허브에 있는 내용을 가져오면 됨!

 

 

---

11. HEAD를 기준으로 git reset 하기

 

reset을 할 때는 git reset [옵션] [커밋 아이디] 이렇게 사용했다. 그런데 이렇게 커밋 아이디를 쓰려면 매번 커밋 아이디를 찾아야한다는 불편함이 조금 있다. 사실 [커밋 아이디] 자리에 다른 걸 써줘도 된다.

 

• git reset --hard HEAD^

HEAD^는 현재 HEAD가 가리키고 있는 커밋의 바로 이전 커밋을 나타낸다. 

 

• git reset --hard HEAD~2

여기서 HEAD~2는 현재 HEAD가 가리키는 커밋보다 2단계 전에 있는 커밋을 나타낸다.

 

즉 HEAD~x는 현재 HEAD가 가리키는 커밋보다 x단계 전에 있는 커밋을 말합니다. 이렇게 커밋 아이디 대신 상대적인 표현법을 이용하는 방법도 있다.

 

---

12. 커밋에 Tag 달기

 

커밋 중에서는 다른 것들보다 좀더 중요한 의미가 있는 커밋들도 있습니다. 이런 중요한 커밋에는 커밋 메시지뿐만 아니라 태그(tag)라는 것을 추가적으로 달기도 한다.

보통 프로젝트에서 주요 버전의 시작점이 되는 커밋에 태그를 단다. git tag [태그 이름] [커밋 아이디]커맨드를 이용하면 된다.

1번에 Version_1 5번에 Version_2 태그 작성

 

프로젝트에 있는 모든 태그를 조회할 때는 git tag 를 사용하면 된다.

그 다음 각 태그와 연결된 커밋이 보고 싶으면 git show [태그 이름] 을 사용하면 된다.

혹시 태그를 삭제하고 싶을 땐 git tag -d [지울 태그명] 을 사용하면 된다!

 

 

---

정리하기

 

• git log : 커밋 히스토리를 출력

• git log --pretty=oneline : --pretty 옵션을 사용하면 커밋 히스토리를 다양한 방식으로 출력할 수 있음. --pretty 옵션에 oneline이라는 값을 주면 커밋 하나당 한 줄씩 출력. --pretty 옵션에 대해 더 자세히 알고싶으면 링크 참조

• git show [커밋 아이디] : 특정 커밋에서 어떤 변경사항이 있었는지 확인

• git commit --amend : 최신 커밋을 다시 수정해서 새로운 커밋으로 만듦

• git config alias.[별명] [커맨드] : 길이가 긴 커맨드에 별명을 붙여서 이후 별명으로 해당 커맨드를 실행할 수 있도록 설정

• git diff [커밋 A의 아이디] [커밋 B의 아이디] : 두 커밋 간의 차이 비교

• git reset [옵션] [커밋 아이디] : 옵션에 따라 하는 작업이 달라짐(옵션을 생략하면 --mixed 옵션이 적용됨) 

1. HEAD가 특정 커밋을 가리키도록 이동시킴(--soft는 여기까지 수행)
2. staging area도 특정 커밋처럼 리셋(--mixed는 여기까지 수행)
3. working directory도 특정 커밋처럼 리셋(--hard는 여기까지 수행)

• git tag [태그 이름] [커밋 아이디] : 특정 커밋에 태그를 붙임