아직 작성한 git이 없으므로 깃헙에서 다운받아서 진행한다.
보고자 하는 코드가 들어있는 폴더로 이동
git log를 쳐보면,
다음과 같은 메세지들이 나타남
commit ID와 author,date,commit message로 구성
두 커밋간의 차이점을 보고 싶다면
git diff <commit ID> <commit ID>
결과로 이러한 화면이 출력.
녹색은 추가, 빨간색은 삭제된 것임을 알 수 있다.
커밋(commit)이란?
git에게 프로젝트의 버젼관리를 맡기고 개발해 나가다가 필요 시점에 그 프로젝트에 해당하는 모든 코드,이미지, 텍스트 등의 snapshot을 찍어 시간별로 보관한다. 이때 스냅샷을 찍는 행위가 바로 commit
얼마나 자주 commit 할 것인가?
원칙은 없다. 하지만 너무 자주 하는 것도 너무 띄엄띄엄 하는 것도 효율적이지 못하다.
logical change가 일어날 때마다 한번씩의 커밋을 하는게 원칙적.
그렇게 할때마다 한개의 커밋이 하나의 목적을 가질 것이기 때문.
다음의 경우를 생각해보자
1. 일주일 동안 작업해 온 모든 것을 한번에 커밋. 그 동안 커밋은 안 해왔다. -너무 큼
2. .readme 에서 3개의 오타를 발견. 첫 번째 오타를 고치고 커밋한다. -너무 작음
3. 한 시간 동안 작업한 새 기능의 모든 변화를 커밋 -적절
4. 두개의 function에서 버그를 발견하고 고친 후 한번에 커밋 - 너무 큼
프로젝트 내부 모든 파일의 변화를 보고 싶으면
git log --stat
다음과 같은 결과를 볼수 있다.
프로젝트 내부의 각 파일마다 녹색 +는 추가, 붉은색 -는 삭제된 것으로 도식화해준다.
google docs와 같은 버젼 컨트롤은 이런 multiple commit이 불가하므로 한번에 각 파일의 변화를 알아내기가 힘들다.
댓글 없음:
댓글 쓰기