1) git log
해당 레포지토리에서 이때까지 한 커밋들의 과정, 즉 커밋 히스토리를 불러올 수 있다.
최신것 부터 오래된 것 순으로 나열된다
각 커밋들의 내용은 아래와 같이 표시된다.
커밋 아이디 // 수정한 사람 // 수정날짜 // 커밋이 입력한 -m의 메모

이 로그 창에서 나오려면 q + 엔터
이 로그를 한줄씩 간결하게 보고싶으면
git log --pretty=oneline

2) git show [커밋아이디 또는 커밋아이디의 첫 네자리]
해당 커밋에서 구체적으로 무엇이 바뀌었는지 자세하게 볼 수 있다.
빨간색 - 뒤에 적힌 내용은 커밋 전 내용
초록색 + 뒤의 내용은 커밋 후 바뀐 내용

3) git commit -m 옵션 없이, 더 자세한 설명으로 커밋하기
-m없이 커밋을 하면 vim(리눅스의 기본 문서파일)이 실행되며 해당 커밋에 대한 보다 상세한 설명을 넣을 수 있게 해준다.
아래의 사진은 아직 vim에 아무것도 넣지 않은 상태의 첫 화면

<vim 사용법>

텍스트 입력: 입력 모드(i) → 텍스트 입력 → 다른 상태로 가고 싶으면 ESC
텍스트 한 줄 복사: 일반 모드 → 복사하고 싶은 줄에 커서 위치 → yy
텍스트 한 줄 잘라내기: 일반 모드 → 잘라내고 싶은 줄에 커서 위치 → dd
특정 영역 복사: 비주얼 모드(V는 줄 단위, v는 글자 단위) → 복사하고 싶은 영역 커서로 설정 → y
특정 영역 잘라내기: 비주얼 모드(V는 줄 단위, v는 글자 단위) → 잘라내고 싶은 영역 커서로 설정 → d
텍스트 붙여넣기: 일반 모드 → 붙여넣고 싶은 위치에 커서 위치 → p
파일 저장: 명령 모드(:) → w + enter
파일 저장 + vim 종료: 명령 모드(:) → wq + enter
vim 종료 (내용 저장되지 않음): 명령 모드(:) → q! + enter
vim을 종료하고 끝내면 아래의 화면이 나오며 잘 commit이 된다. 궁금하면 git log로 확인하기

4) git commit --amend
최신 커밋 수정하기!
당근 그 전에 git add . 해줘야함
git commit --amend하면 vim이뜨고 그때 적은 코멘트가 뜨는데 이것도 같이 바꿀 수 있다.
이렇게 바꾸면, 커밋아이디가 바뀐다!!
5) git diff [예전 커밋 아이디 앞 4글자][최근 커밋 아이디 앞 4글자]
두 커밋 사이의 변화를 알아보는 커멘드다.

개인 프로젝트의 경우에는 커밋 메시지를 어떻게 작성하든 큰 상관이 없을 수 있지만, 회사에서 여러 명이 참여하는 프로젝트의 경우에는 이 커밋 메시지가 아주 중요합니다. 그래서 커밋 메시지를 어떻게 작성해야하는지에 대한 규칙이 정해져있는 경우가 많은데요.
그 규칙들은 회사마다 전부 다르겠죠? 그래도 커밋 메시지를 어떻게 작성하면 좋은지에 대한 일반론적인 가이드라인은 있습니다
(1) 커밋 메시지의 제목과 상세 설명 사이에는 한 줄을 비워두세요.
(2) 커밋 메시지의 제목 뒤에 온점(.)을 붙이지 마세요.
(3) 커밋 메시지의 제목의 첫 번째 알파벳은 대문자로 작성하세요.
(4) 커밋 메시지의 제목은 명령조로 작성하세요.
Fix it (O), Fixed it, Fixes it(X)
(5) 커밋의 상세 내용에는 이런 걸 적으면 좋습니다.
왜 커밋을 했는지
어떤 문제가 있었고
적용한 해결책이 어떤 효과를 가지는지
(6) 다른 사람들이 자신의 코드를 바로 이해할 수 있다고 가정하지 말고 최대한 친절하게 작성하세요.
(1) 하나의 커밋에는 하나의 수정사항, 하나의 이슈(issue)를 해결한 내용만 남기도록 하세요. 다양하게 수정을 하고나서 하나의 커밋으로 남기는 것은 좋지 않습니다. 하나의 커밋이 하나의 사실만을 갖고 있어야 나중에 이해하기 쉽습니다.
어느 정도의 수정사항을 하나의 단위로 볼 것인지는 상황에 따라 조금씩 다를 수 있습니다. 회사의 규칙에 따라 다를 수도 있구요. 어찌 됐든 너무 많은 작업의 결과를 하나의 커밋으로 담지 않아야겠다는 생각을 하면서 커밋을 해야합니다.
(2) 현재 프로젝트 디렉토리의 상태가 그 내부의 전체 코드를 실행했을 때 에러가 발생하지 않는 상태인 경우에만 커밋을 하도록 하세요. 나중에 동료 개발자가 특정 커밋의 코드로 실행했을 때 에러가 발생한다면 혼란을 줄 수 있습니다.
즉 커밋으로 보관된 특정 시점의 전체 코드는 항상 문제없이 실행되는 상태여야 합니다.
Git에는 길이가 긴 경우의 커맨드 전체에 별명을 붙여서 그 별명을 사용할 수 있도록 해주는 기능이 있습니다.
이 때 붙이는 별명을 alias라고 하고, 별명을 붙이는 행위를 aliasing이라고 합니다.
git config alias.[줄여서 쓰고싶은 말] '[원래 긴 커멘드]'

1) HEAD
위의 git history를 하면 나오는 HEAD
HEAD는 어떤 커밋을 가리키는 존재로, 주로 보통 가장 최근에 한 커밋을 가리키지만 안그럴 때도 있다. **지금 working directory에 보이는 구성은 주로 HEAD가 가리키는 커밋에 따라 구성되게 된다. (꼭 그렇지는 않다) 그레서 HEAD에 해당하는 커밋을 다른 시점의 커밋으로 바꾸면, working directory의 구성도 달라진다.

2) get reset
그럼 과거의 커밋으로 HEAD를 옮기는 방법은?
get reset --hard [돌아가고 싶은 커밋 아이디 4자리]
: 이걸 사용하면 head의 위치가 바뀌며 working directory도 같이 바뀐다. 하지만 --hard는 과거의 모든 기록을 없애버리는 거라서 권장하지 않는다.이 외에도 2가지 reset 옵션.



참고) staging area 확인하는 방법 : **git status**
참고) staging area에 있던 것들은 커밋을 하더라도 계속 남아있다.
get reset --soft [커밋아이디]
- git history하면 head의 위치는 변해있지만
- cat이나 ls로 확인하면 working directory는 reset 전과 같다.
- 그리고 git status로 보면 내가 reset하기 전에 수정한 파일/디렉토리말고 다른 파일/디렉토리들도 commit된 파일/디렉토리로서 초록색으로 뜬다. 이건 오래된 커밋 기록(커밋때 마다 어떤 것이 staging에 있었나)이 남아있기 때문인데, reset 전 커밋과 현재 head가 되어있는 커밋 간의 모든 차이가 commit 된 파일리스트에 보이게 된 것이다.
get reset --mixed [커밋아이디]
- git history하면 head의 위치는 변해있고
- cat이나 ls로 확인하면 working directory는 reset 전과 같다.
- 하지만 git status로 보면 내가 reset하기 전에 수정한 파일/디렉토리와 head와 다른 최신의 파일/디렉토리들도 모두 commit이 되지 않아 붉은색 글자로 뜬다. 이는 mixed를 하면 staging area도 같이 바뀌면서 옛~날에 지금 head를 commit했던 그 시점의 staging area의 상태로 돌아간 것이라 아무것도 staging이 안된 상태로 대체된 것이다.
3) get reset한 거 되돌리기 = 즉 가장 최신 파일로 돌아가기
만약 git hub에 최신 파일을 push해두었다면
git pull로 그 내용을 가져오면
working - staging - repository 모두 다 최신 파일로 가져오게 됨!
**4) HEAD를 기준으로 git reset하기
git reset [옵션][커밋 아이디]
위의 방법은 커밋 아이디를 일일이 알아야한다는 번거로움이 있음

위와 같이 현재 HEAD가 6커밋에 있는 경우에서
커밋 메세지 말고도 좀 더 중요한 의미가 있는 커밋들에게 태그를 달 수 있다.
예를들어 commit 1-3은 버전 1, 4부터는 버전 2일때
각 버전의 시작 커밋인 commit 1과 4에게 version 1, 2라고 태그를 달아주는 식이다.
이를 위한 방법

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는 여기까지 수행)
그리고 이때 커밋 아이디 대신 HEAD의 위치를 기준으로 한 표기법(예 : HEAD^, HEAD~3)을 사용해도 됨
git tag [태그 이름][커밋 아이디] : 특정 커밋에 태그를 붙임
이번 레슨은 어땠나요?