사족
그간 소중히(?) 작성하며(자주는 아니지만) 차곡차곡 써왔던 개인 블로그 글을 어느순간 날리게 되었다. 왜 날아가게 되었는지는 아직도 모른다. 사실 찐 원인은 간단하다.
“넌 평소에 보안과 백업을 소중히 하지 않았지”
1 | 1. 사실 블로그는 홈 서버에 wordpress 로 대충 글만 올려놓고 있었는데, |
사실 상용 서비스를 운용 할때는 보안과 백업은 기본중의 기본인 것을 쯧쯧.
그렇게 5개월치의 글을 날려먹고 한동안 글 쓸 의욕을 잃고 헤매다, 다시 마음을 다잡고 하나씩 글을 써 보고자 한다.
그리고 보안과 백업은 상대적으로 홈서버 운용보다 자유로는 github pages와 hexo로 옮겨왔다. 익힐게 많지만 이것도 또 하나의 즐거움 이리라.
올바른 Commit 메세지를 작성하는 방법
요즘은 progit이라는 책을 읽으며 git에 대해 공부하고 있다. “현업에서 git을 사용하고 있으므로, 이미 git은 어느정도 사용하는거 아냐?” 라고 할 수 있겠지만, 반은 맞고 반은 틀리다. 그냥 commit을 하고 pull request를 날리고, 코드 리뷰를 하고, merge를 하고 하는 수준은 할 수 있으나 “잘~” 쓰지는 못하고 있다. 그래서 git을 공부를 한다.
오늘은 그 중 가장 기초중의 상기초 커밋 메세지를 작성하는 방법에 대해서 쓰려고 한다. 깃에서 커밋 메세지를 남기는 방법은 간단하다.
1 | git commit -m "커밋메세지" |
잘 못 작성한 커밋 메세지의 예
“이 커밋 메세지를 잘 남기라구? 어떻게 더 잘 남기지??”
이런 의문이 생긴다면, 잘못 작성한 커밋 메세지의 예 부터 살펴보자
멀리 갈 것도 없다. 작년 초의 내가 남긴 커밋이다. 황량하고 알 수 없는 커밋 메세지의 처참한 모습 이루 말할 수가 없다.
물론, 이 총체적 난국의 git 흔적들은 비단 커밋 메세지만이 문제가 아니지만, 오늘의 주제는 커밋 메세지 이므로 커밋 메세지에 집중해서 살펴보자
의미없는 커밋 메세지에, 심지어는 그마저도 귀찮았는지 . 도 있다. 미쳤구나 물론 이 커밋 메세지를 남기던 나는 프로젝트 마감 일정에 쫒기어 정말 제정신이 아니었는데다가, 같이 개발하는 동료는 한명밖에 없었고, 서로 바로 옆자리에 앉아 빈번히 커뮤니케이션 하고 있었기 때문에 서로의 커밋 메세지가 외계어로 쓰이던 암호로 넣던 별 탈이 없었다. 그당시에는..
그러나, 소프트웨어는 한번 만들어 놓으면 끝이 아니다. 그리고 3개월 정도가 지나 열어 본 코드는 “내가 왜 이렇게 짰지? 이거 정말 내가 짠거 맞나?” 할정도로 낮설은 경우가 있다. (3개월 전의 나는 내가 아니라 타인이다.) 이럴 때 찾아보게 되는게 커밋 히스토린데 커밋 히스토리가 무의미한 커밋 메세지로 채워져 있따면.. 심지어 . 이라면?! 노답. 핵노답
생각만 해도 아찔한데 난 이미 겪었다. 이런 아찔한 순간을.. 캡쳐의 히스토리가 이야기 해주고 있지 않은가? 이건 경험담이다..
어떻게 좋은 커밋 메세지를 작성할 것인가?
좋은 커밋 메세지를 작성하는 방법에 대해서는 이미 여러 잘 쓰여진 글들이 있다.
그 중 하나를 소개해 본다.
아래는 위 글에서 발췌한 훌륭한 git 커밋 메세지의 일곱가지 규칙이다.
- 제목과 본문을 빈 행으로 분리한다
- 제목 행을 50자로 제한한다
- 제목 행 첫 글자는 대문자로 쓴다
- 제목 행 끝에 마침표를 넣지 않는다
- 제목 행에 명령문을 사용한다
- 본문을 72자 단위로 개행한다
- 어떻게 보다는 무엇과 왜를 설명한다
위 글에 예시도 훌륭하게 나와있다. 핵심은 최대한 함축적으로 간결하게 제목을 작성하고,
본문에 상세한 내용을 기술 하라는 것이다. 나도 위 일곱가지 규칙에 동의 한다. 그러나 몇몇가지 우리 실정에 맞지 않는 규칙들도 있다. 이 일곱가지 규칙은 영어로 커밋 메세지를 작성할 때의 규칙인데, 우리는 한글로 커밋 메세지를 작성할 때도 많기 때문이다.
2. 제목 행을 50자로 제한한다
이건 영어 기준이다. 한글 기준으로는 30자 정도가 적당한 것으로 보인다.
터미널에서 열었을때, 영어 2글자-> 한글 한글자 정도의 너비를 갖고 있기 때문이다.
3. 제목 행 첫 글자는 대문자로 쓴다
음.. 어… 음.. 영어로 쓸때만 지키면 된다
5. 제목 행에 명령문을 사용한다
사실 오늘 커밋 메세지에 대한 글을 쓰는 이유는 이 항목에 대한 이유가 크다. 일단, 블로그 글들이 그렇듯이, 이 이하 기술하는 글들은 내 개인적인 의견임을 감안하길 바란다.
이 항목 때문에 한글 커밋 메세지에 대해서도 명령문을 사용하는것을 strict하게 지켜서
“스프링 프레임워크의 버전을 업그레이드 하라”
“NullPointerException 방지 코드를 넣어라”
하는 식으로 커밋 메세지를 작성하는 경우를 꽤나 보았고, 이렇게 쓰기를 권고하는 블로그 글들도 많이 보았다. 개인적으로는 이런 형태의 커밋 메세지가 굉장히 이질적이기 때문에 별로 좋아하지 않는데, 왜 이렇게 작성 해야 하는지에 대해서도 열심히 찾아 보았는다.
개인적으로 판단한 이 컨벤션의 시초는 “영어로 커밋 메세지를 작성” 할 때의 규칙을 그대로 한글로 들고 왔기 때문에 이런 일이 발생했다고 본다.
I refactored subsystem X for readability => (X)
Refactor subsystem X for readability => (O)
쓸때없는 I는 없애버리고(글자 제한이 있으므로), git 시스템의 관점에서 수행한 일을 현재시제로 작성하게 되면, 이게 바로 영문법에서의 명령형이다.
위 링크에 소개한 글에서는 이런 식으로 작성할 것을 권고 한다.
만약 이 커밋이 적용되면 이 커밋은 가독성을 위해 서브시스템 X를 리팩토링한다
=> 가독성을 위해 서브시스템 X를 리팩토링한다
만약 이 커밋이 적용되면 이 커밋은 Getting Started 문서를 갱신한다
=> Getting Started 문서를 갱신한다
그러나 좀 부족한 것이 있다. 영문 명령형으로 커밋 메세지를 작성하게 되면 극명히 보이는 장점이 있다.
refactor subsystem X for readability
update getting started documentation
remove deprecated methods
release version 1.0.0
merge pull request #123 from user/branch
동사 + 목적어 로 표현되는 영문법 어순 특성 상, 어떤 행위를 했는지가 문장 제일 앞에 정렬 된다는 점이다. 이런 장점 때문에 더더욱 명령형으로 커밋 메세지를 작성 하라고 하는 것인데, 한글에서 그대로 이런 컨벤션을 사용하게 될 경우, 우측정렬을 하여 커밋 메세지를 보지 않는 이상 이런 장점은 누릴 수가 없게 된다.
방법 1.
따라서 한글로 작성하게 될 경우, 커밋이 담고있는 가장 큰 함축적인 행위의 동사를 제일 앞에 말머리로 붙여주고, 뒤에 커밋 메세지를 작성하는 것이 좋을 것 같다. 자연스런 문장을 위해 단어가 두번 들어가는것도 나쁘지 않다.
리팩토링 - 서브 시스템 X. 가독성 향상 목적
갱신 - Getting Started 문서
방법 2.
아니면 팀만이 사용하는 기호를 사용해 핵심 행위를 가리키는 단어를 강조하는 것도 좋은 방법 중의 하나일 것이다.
가독성을 위해 서브 시스템 X를 [리팩토링]
Getting Started 문서 [갱신]
방법 3.
세번째 방법은, 어차피 프로그램 개발에서 하는 행위들은 몇가지로 정해져 있고, 이는 카테고리화가 가능할 것 같다. Add, Refactor, Remove, Release 등등.. 이런 카테고리들을 팀별로 미리 정의 해 두고 앞부분에 prefix를 붙이는 것도 한 방법이다.
refactor - 가독성을 위해 서브 시스템 X를
update - Getting Started 문서
마무으리
뭐, 이 외에도 여러 아이디어가 있을 수 있겠다. 핵심은, 함축적인 커밋 메세지를 한눈에 파악할 수 있도록 가독성을 확보하는 자신만의, 팀만의 방법을 찾는 것이다.
(본인도 아직 팀원들과 이야기 하며 더 연구하고 찾는 중이다.) 그러나 이런 방법들이 고민스러워 컨벤션을 못 정하겠다면 일단 . 만은 피하자.
순간 바쁘고 귀찮다고 .만을 남겼을때 지금의 나에게 화내고 있을 3개월 후의 나를 위해서, 1분만 더 고민하고 커밋 메세지를 남기는 습관을 들이는게 제일 중요하다.
그럼 난 이만, 1년 전의 나에게 벌을 주러 가보려 한다..