티스토리 뷰

Tool/Git

완벽한 커밋 작성하기

Tomining 2016. 11. 8. 16:17

"팀을 위한 Git"(http://www.yes24.com/24/goods/30741673)이라는 책의 "7.3.1 완벽한 커밋 작성하기"라는 챕터에 아래와 같은 내용이 나옵니다.


훌륭한 커밋 객체는 다음과 같은 특성이 있다.

    • 오직 관련된 코드만 포함한다. 스코프 크림(Scope creep)도 없고, "여백 수정"도 없다.
    • 코드 내 문서화를 포함해 프로젝트 코딩 표준을 따른다.
    • 적당한 크기다. 보통 100줄 정도의 코드를 말한다. 또는 함수 이름이 바뀌고 영향을 받는 코드가 1,000줄 정도인 대규모 리팩토링도 여기에 포함된다.
    • 작업을 설명하는 최적의 커밋 메시지를 포함한다(다음절 참조).

커밋 메시지에는 다음과 같은 사항을 포함해야 한다.

    • 쉬운 로그 검색을 위해 표준 형식을 갖춘 간략한 설명(60자이내)
    • 현재 코드의 문제점을 좀 더 자세히 설명하고 해당 수정사항이 중요한 이유를 적는다.
    • 고급 수준 언어로 문제를 어떻게 해결했는지 설명한다.
    • 수정사항이 일으킬 수 있는 잠재적 부작용을 개략적으로 설명한다.
    • 수정사항에 대한 요약을 적어 코드 변경점만 확인하면 커밋 메시지를 확인할 수 있도록 한다. 단, 변경사항/변경 이유를 어림짐작으로 코드 변경사항을 확인해서는 안 된다.
    • 제안된 수정사항에 대한 논의사항을 볼 수 있는 티켓 번호 또는 소스에 대한 다른 참조를 적는다.
    • 수정사항에 영향을 받는 이들이 누군지 적는다.(예: 개발자를 위한 최적화, 유저를 위한 속도 개선)
    • 추가 문서 업데이트할 곳 목록을 적는다.


책 내용 중 공감이 가는 부분도 있고 현실적으로 너무 많은 내용을 작성해야 하는 것은 아닌가 하는 생각도 있습니다. 그래서 개인적으로는 "[티켓번호] 간략한 개발 내용" 정도를 작성합니다.


커밋 메시지에 대한 정답은 없지만 다른 개발자분들은 어떻게 커밋 메시지를 관리하는지 궁금합니다.


'Tool > Git' 카테고리의 다른 글

git log 이쁘게 보기  (0) 2015.10.07
공지사항
최근에 올라온 글
최근에 달린 댓글
Total
Today
Yesterday
«   2024/03   »
1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
31
글 보관함