2. Commit 을 활용하는 법
git reset & git revert
지난 글(Git&Github은 왜 사용하는걸까2-Commit 기초편)에서 Commit은 무엇이고 어떻게 하는지에 대해서 적어봤다.
커밋로그를 열심히 작성을 해뒀는데 정작 쓰지를 않는다면 마치 내 고등학교 시절 오답노트처럼 잘 정리된 쓰레기에 불과하다...
커밋로그로 무엇을 할 수 있고 커밋 이후에 발생하는 이슈에 대응하는 방법을 알아보자.(초간단)
Commit을 조작하는 명령어가 궁금하다면 Git 공식문서를 참고하자. 링크:히스토리 단장하기
0. 커밋로그는 무엇이/어떻게 변경됐는지 안다.
누가/무엇을/어떻게 변경했는지 기록하고 내용물을 공유하기 어렵다.
Git과 Github은 무엇일까 중에서
커밋 로그를 통해서 무엇이 언제 어떻게 변경 됐는지 추적이 가능하다. 1차적으로 커밋메시지를 보고 변경 내용을 유추하기 때문에 커밋메시지를 간단/정확/명확하게 작성해야 한다.
1. 커밋로그는 변경된 부분을 어떻게 되돌릴지도 안다.
수정한 내용 이전 상태로 복구하기 힘들다.
Git과 Github은 무엇일까 중에서
상식적으로 어디를 어떻게 변경했는지 알면 반대로도 되돌릴 수도 있다. 커밋로그를 가지고 변경 내용을 복구할 수 있다.
$git revert and $git reset로 복구하기
복구하는 방법에는 두가지 옵션이 있다. 1)커밋로그를 삭제한다. 2)커밋로그를 반대로 되돌린다.
1) 삭제한다와 2)반대로 되돌린다번의 차이는 뭘까?
1)번의 경우는 커밋로그 자체를 없애린다. 커밋로그가 삭제되면 변경됐던 히스토리는 지구상에 존재하지 않게 되어 그 누구도 알수 없게 된다. 2)번의 경우 커밋을 변경을 반대로 실행하는 커밋을 추가하는 방법이다.
실습 전 준비
1. index2.html 파일을 새로 만들어보자.
2. index2.html 파일 내용을 작성하자.
3. 커밋하자.
($reset 실습)
4. reset-br 브랜치를 만들어서 Head 커밋로그(index2.html)를 삭제해보자.
--soft /--hard 옵션의 차이점을 비교해보자.
명령어: $git reset --soft HEAD^
명령어: $git reset --hard HEAD^
5. index.html 파일을 다시 만들어서 커밋 해보자(1, 2, 3 반복).
($revert 실습)
6. 이번엔 revert 명령을 사용해서 변경 내역을 복구하는 커밋을 추가해보자.
명령어: $git revert HEAD <------'^' 붙이지 말자.
revert vs reset
상황에 따라 다르겠지만 모든 이력을 남겨서 공유해야 한다면 revert를 사용하는 옵션이 더 바람직하다. 되돌리는 과정도 하나의 히스토리가 되기 때문이다.
특정 이슈와 연관됐다면 반드시 커밋로그로 남겨두는게 좋다. 누군가는 왜 이거 다시 되돌려진거지? 라고 의문을 가지기 때문이다. 우리는 모든 변경 내역을 동료들과 공유해야 한다.
마무리
커밋로그를 조작하는 방법은 많다. 그걸 일일히 설명하는건 크게 의미가 없다고 생각한다. 상황에 따라 필요한 명령어를 찾어서 커밋로그를 조작하면 된다. Git에서 제공하는 기능이나 옵션들이 워낙 방대하다. 기본적인 조작법과 자신이 자주 사용하는 명령어부터 숙지하기 바란다.
Revert 와 Reset을 남발하지 말자.
Git은 최대한 단순하고 간단하게 사용해야 한다 (기본적인 명령어를 가지고). 만약 커밋 이후에 로그를 조작하는 명령어를 자주 실행한다면 기존에 해오던 커밋 방식이 효율적이지 않을 가능성이 크다. 자신이 어떤 방식으로 git을 사용하는지 돌아보고 개선해보길 바란다.
또한 커밋로그를 잘 작성하자.
커밋 단위는 어떻게할 것인지, 커밋메시지는 어떻게 작성할지에 대해서도 고민해봤으면 한다.
커밋이 어떻게 작성됐냐에 따라 추적하는 방법이 달라진다.
최고의 방법은 사용하면서 다른 사람들의 커밋을 보고 느꼈던 좋았던 점과 나빴던 점들을 보면서 개선시켜가는게 아닐까?
