[소스코드 관리] 이쁘게 커밋(commit) 하는 방법 개발 이것저것

IT 프로덕트 제작을 하다보면 개발자들은 코드관리를 하게된다.
코드관리 시, 1회 의 코드 추가/수정 내역 을 커밋 이라고 한다.

커밋 메세지 는 이러한 매 커밋 작업(코드의 추가/수정의 저장작업) 시,
코드관리 프로그램에 동시에 입력하는 간단한 요약글을 말한다.

이 커밋메세지의 역할은 프로젝트의 진행에 있어서 어떤 코드상의 변화가 있었는지
유일하게 코드레벨 이상으로 그 의미를 전달할 수 있는 수단이다.

하나의 프로젝트를 두고, 여러 개발자들이 같이 개발을 진행하게 될 경우, 다른 개발자들은 프로젝트의 진척사항을 커밋메세지로 짐작하게 될 때가 많다.
코드 한줄한줄의 변경사항을 툴에서 표시해주기는 하지만 코드리뷰를 매번 시행 할 만큼 여유가 없는경우가 많기 떄문이다.

자, 그럼 똑똑한 커밋메세지, 어떻게 만들면 좋을까?
여기 그 노하우가 있다.

====================================================

최소한의 커밋 메시지 형식

- (필수) 작업자체를 대표하는 ID
  : 작업에 할당되는 회사 통용 코드 혹은 번호. (JIRA 를 사용하는 경우 이슈번호에 해당)

- (필수) 변경에 대한 짧은 요약 (20자 이내)
  : 작업내용을 간단하게 적는다.

- (선택) 상세 설명
   : 20자 이내의 요약글 이외에 작업내용에 대한 세부 내용이 필요할경우 추가합니다.

- 예제
KS-1567: 태그기반 검색기능 추가

사용자가 검색 버튼을 눌러 모든 컨텐츠에 입력된 태그 기반으로 검색을 가능하도록 하였음.
랭킹 알고리즘은 XXX를 사용하였으며, XXX 의 오픈API를 연동함.


커밋의 규칙

- 1 커밋 - 1 기능
  : 하나의 커밋에 태스크 하나 해결이 가능하면 가장 좋고, 태스크 규모가 큰 경우에는 그것을 더 잘게 쪼개서 작은 기능의 구현단위로 커밋을 쪼갠다.

- 코드 저장용 커밋은 하지말자.
  : 소스 콘트롤 관리는 백업 시스템이 아니다! 특히 퇴근용 커밋

- 너무 빈번한 커밋
  : 기능을 너무 잘개 쪼개어 자주 커밋하는 것은 피하도록 하자. 예를들어 파일 당 커밋 이라던가...

- 귀차니즘이 묻어나오는 커밋 메시지 금지
  : ‘여러가지 고치고 정리했음’  << 이런 메세지 극혐입니다...

- 하나의 패치 안에 두 가지 변경은 되도록 금지
  : 어떤 코드변경이 어떤 기능을 위한 수정이었는지 알수없을 뿐더러, 추후 특정 기능에 대한 변경사항만 롤백하고 싶을경우 변경코드전체를 롤배했다가 다시 하나하나 수정해야하는 불상사가 발생할 수 있다. 
‘버그#1 를 수정했고 모든 foo를 bar로 수정했음’ << 이런 경우가 없는게 좋다.

패치와 관계 없는 코드 포맷팅 변경 커밋 금지
  : 코드 수정 뿐만아닌 공백 변경을 함께 넣는 경우는 괜한 파일 변경의 의심을 살 수 있습니다. 코드 포맷팅은 따로 커밋합시다!

- 너무나도 사랑스러운?? 코드 누락... 
  : 이건 정말 커밋할때 가장 조심해야 할 것입니다. 스테이징 단계에서 자신이 직접 변경파일을 선택하는 경우가 있는데.. 이때 변경해야할 코드를 빠뜨리고 커밋이 이루어지게 되면 정말 큰일이겠죠? gitignore 파일과 같은 설정으로 미리 커밋에서 제외하고자 하는 파일은 스테이징 때 자동으로 예외처리되도록 합시다.




통계 위젯 (블랙)

00
0
0

GoogleAdsenseResponsive

Cluster map