(3) git commit 실습해보기

📌 파일들을 수정하다 마음에 들면 staging area에 옮겨 놓고 드디어 commit 혹은 version을 만들 준비가 되었습니다.

1. commit 실습

• commit 사용해보기

version을 만들때는 commit이라는 명령어를 사용할 수 있는데, staging area에 있는
변경 사항을 git repository에 옮겨주는 역할을 한다. 아무런 옵션 없이 이용하게 되면
기본적인 template이 나오는데 보통은 Title을 작성하고 좀더 자세한 Description을 작성한 다음에 파일을 닫으면 위와 같이 나온다.

---

첫째 줄을 보면 main branch에 hash code의 제일 앞부분만 나온다.
hash code 아이디와 Title이 표기된다. 3가지의 파일이 변경되었고 3가지 다 처음으로
만들어진 파일이란 것을 확인할 수 있다.

• git history를 확인해보자

git log

commit 과 전체적인 hashcode가 나오고 누가 언제 했는지 확인할 수 있다.
그리고 Title 과 Description 이 나오는 것을 확인할 수 있다.

• 위와 같은 방식으로 git commit을 바로하는 경우는 거의 없고 다른 방식을 한다

echo add >> c.txt#c.txt를 수정한다
git status -s #c.txt의 상태 확인
git add. #전부다 추가
git commit -m "second commit"
git log

git commit -m 뒤에 메시지를 추가해서 간단하게 commit할 수 있다
동일하게 log 를 확인해보면 두번째 commit이 이뤄진것을 확인할 수 있다.

• working directory에서 add를 사용하지 않고 전부 다 바로 commit을 해보자.

echo add >> c.txt #c.txt에 수정사항을 만들어서 working directory에 존재
git commit -am "third commit"
git status -s #git status가 깔끔해졌다

staging area와 working directory의 모든 파일들이 commit된 것을
확인해 볼 수 있다.

2. commit 팁

git directory에 있는 파일들은 사실 history에 창고다. 작업들을 버전별로 나눠서
관리할 수 있는 유용한 창고이다. 따라서 전체 어플리케이션을 만들어서 저장하면
의미가 없다. 어플리케이션을 세분화해서 기능별로 작은 단위로 만들어 나가는게
중요하다. 작은 단위로 나눠서 history에 저장하는게 중요하다.

---

의미있는 이름을 지정해서 저장하는게 중요하다.
예를 들어, 프로젝트를 초기화하는 commit 하나, login 서비스 모듈을 만들어서 commit하는 식으로 작은 단위로 의미있게 history를 보면 작업한 내용을 알아볼 수 있게 저장하는게 중요하다.

---

보통 commit의 메시지는 현재형으로 동사로 만들어진다. init, add, fix 등
commit을 할때 내가 crushing 을 고쳤다고 하면 정말 고친 내용만 포함한 commit을 만들어야지 다른 버그들 고친 것도 commit을 하면 코드를 리뷰할때도 혼동이 오지만
history를 볼때도 혼동이 온다. 따라서 commit 메시지에 맞게 해당 내용만 commit하는 것이 중요하다.