Git commit 다루기(히스토리, 수정, 생성, reset)

 

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

- git log

• 오래된 커밋일수록 아래에 있다
• 노란색 commit 19f1c8a913119fa49ef50d8b45466 은 커밋 아이디와 같다.  Git이 commit을 서로 구분하기 위해 부여한다. (=커밋 해시)

 

커밋 히스토리를 더 깔끔하게 보려면 

• git log --pretty==oneline

 

 

 

 

commit 하나에 대해 어떤 일이 있었는지 알고싶다면

• git show 커밋아이디 (앞에 한 4-5자리정도 쳐주면 알아서 인식한다!)

 

 

 

 

 

-m 옵션 없이 커밋 메시지 남기기

classification.py에 def coding() 을 추가해주고,

git add .  해주고

git commit 을 메시지 없이 쳐준다면

위와 같은 창이 뜬다.

말인 즉슨, 커밋 메시지를 입력해주세요. #으로 시작하는 문장은 무시될것이다!

아래는 커밋 메시지를 작성하는데 필요한 간단한 안내문구들이다.

 

이 상태에서 " i " 를 누르면 입력모드로 바꿀수 있다.

Add one function

 

classification.py supports now  를 추가했고,

1. esc를 누르고,

2. ":wq" 를 입력하면 저장하고 나올 수 있다. 그럼 커밋 메시지가 저장된다.

 

 

 

최신 커밋 수정하기

위와같이 coding() 메소드의 return을

"개발 관련 도서입니다." -> "개발 도서입니다." 로 classification.py를 바꾸고, 

- git add . 

- git commit 을 하려하는데,

여기서 우리는 새로 commit이 아니라 최근 commit을 수정하려고 하는 것이니

- git commit --amend로 한다. 그러면 아래와 같은 commit 창이 뜨고,

다시 " i " 를 눌러 수정할 수 있다.

ㅅ

수정후 다시 esc -> ":wq" 를 눌러 저장하면

바뀐 commit을 확인할 수 있다!

 

 

 

---

긴 커맨드에 alias 설정하기

• git log --pretty=oneline 은 매번 치기에 조금 길다
• 별칭을 "git history"로 하고 싶다.

git config alias.history 'log --pretty=oneline' 이라고 하면 된다.

---

 

 

두 커밋간 차이 보기

 

git diff (이전 커밋 아이디 4글자) (이후 커밋 아이디 4글자)

 

 

 

 

 

 

HEAD의 의미

git history를 보면 HEAD를 볼 수 있는데

보통 가장 최근의 Commit을 가리킨다.

HEAD가 왜 필요할까? working directory 내부는 HEAD가 가리키는 커밋에 따라 구성된다.

 

즉, HEAD가 옛날옛적 첫 commit을 가리키고 있다면,

working directory는 README.md 파일도 없었던 처음 환경이 된단 말이다.

snapshot을 컨트롤 하는 방법중 하나이다.

 

 

만약 git reset으로  예전 commit으로 돌아간다면

아래와 같이 바뀐다.

그럼 working directory의 내용이 과거 내용대로 바뀐다!!!! (내 coding 메소드가 없어졌다)

 

중간에 세이브 포인트로 돌아갈 수 있는 방법이다!

 

 

 

Git reset 막 쓰지 말자!!

1. git reset을 쓸 때 --hard 옵션이란?

• HEAD가 과거의 커밋을 가리키게 되었고
• working directory의 내부도 그 과거 커밋의 모습처럼 바뀌었다. 

사실 git reset과 함께 쓸 수 있는 옵션에는 --hard 말고도 --soft, --mixed라는 옵션들도 있다. 

• HEAD가 과거의 커밋을 가리키게 되는 결과는 git reset에서 어느 옵션을 쓰든 항상 똑같다. 
• 하지만 working directory의 내부도 그 과거 커밋의 모습처럼 바뀌는 건 --hard 옵션을 썼기 때문
  --soft, --mixed 옵션을 쓰면 그렇지 않다

 

2. staging area에 있던 것들은 커밋하고 나면 어떻게 될까?

파일을 수정하고 git add를 해서 staging area에 올린 다음 커밋을 하면

staging area에 있던 파일들은 그냥 그 상태 그대로 남아있다. 그러니까 커밋을 했다고 staging area가 초기화되거나 하지는 않는다.

 

계속 git add를 할 때마다 staging area에서는

• 새로운 파일이 추가되거나
• 원래 있던 파일이 더 새로운 버전의 것으로 교체되거나 할 뿐

이 사실을 확실히 기억하고 넘어가야 다음에 배울 git reset의 옵션에 관한 내용들을 잘 이해할 수 있습니다.

staging area에 있던 것들은 커밋을 하더라도 그것과 상관없이 계속 남아있다

 

 

Git reset 옵션 (--soft, --mixed, --hard)

 

해석하면,

1. --hard

-> 커밋 이후로 한 작업이 전부 사라진다

 

2.--mixed

-> working directory는 냅두고, staging area만 바꾼다

 

3. --soft

-> repository만 바꾼다!!

 

hard 옵션은 그렇게 권장되지 않는다.
작업했던 내용이 전부 사라져서 복구할 수 없다.

 

 

위와 같이 바꾸고 저장한 뒤, 

git add . 하면

working directory -> 내용 수정되어있는 상태

staging area -> 내용 수정되어 있는 상태

repository -> 내용 수정 반영 안되어있는 상태

 

1. soft로 reset 하기

실행 뒤에는 

head가 잘 가리키고 있고, 

working directory는 reset의 영향을 받지 않았다

Staging area 도 영향을 받지 않았다

근데 나 README.md는 수정하지 않았는데? -> staging area에 있던 것들은 커밋을 하더라도 그것과 상관없이 계속 남아있다

아까 커밋을 리셋하기 전에는 "staging area 에 있던 README.md파일과 repository에 있던 README.md파일이 같았다"

근데 커밋을 soft 리셋하니 staging area에 남아있는 README.md 파일과 repository에 있는 README의 내용이 달라진 것!

그래서 staging area 에서 README.md 파일이 보이는 것!!!

 

 

2.  mixed로 reset 하기

HEAD는 바뀌어 있지만

working directory안의 내용은 바뀌지 않았다.

 

staging area를 살펴보면

"staging area 에 있던 파일들이 reset 때문에 staging area에서 내려왔음"을 의미한다

 

 

작업 내용 복구하기

 

 

 

---

커밋에 tag 달기

커밋 중에서는 다른 것들보다 좀 더 중요한 의미가 있는 커밋이 있다

이런 중요한 커밋에는 태그(tag)라는 것을 추가적으로 달기도 한다.

보통 프로젝트에서 주요 버전의 시작점이 되는 커밋에 이렇게 태그를 다는데

 

git tag [태그 이름] [커밋 아이디]

 

 

총 2개의 태그를 달았다

 

git tag

실행해보면

추가했던 Version1, Version2 태그들이 보이는데

그 다음 각 태그와 연결된 커밋이 보고 싶으면,

git show [태그 이름]

의 형식으로 실행해주면 된다.