AngularJS Git Commit Message Conventions을 활용한 커밋 메시지 작성법( + react)

배경

vsCode를 통해 작업을 진행하면서 평소와같이 커밋을 하려는데 메세지 입력이 50자로 제한되어있는것을 확인하게되었다.

단순히 커밋을 작은단위로 유지시키기위해 vsCode에서 강제한 것인가? 라는 생각과함께 메세지 구조에대해 궁금증을 갖게되어 찾아보니 the AngularJS commit conventions 라는 문서를 기반으로 많이 작성하는것을 알게되었다. 다음과같은 말을 많이들어봤을텐데

좋은 커밋 메세지를 작성하자
작은단위로 커밋 메세지를 구성하자

1. 커밋 메세지를 잘 작성하자

여기서 ‘좋은’이 의미하는 바가 무엇일까?

협업과 관련이 있을것같은데 우리는 혼자가 아닌 다른동료들(혹은 미래의나)과 함께 작업을 하기때문에 결국 다른사람이 내가 작성한 커밋 메세지를 보고 어떤 작업을 진행했는지 이해하기쉽게 작성하는것이 잘 작성된 커밋 메세지라 생각한다

the AngularJS commit conventions 에서 제안하는 커밋 메세지 작성 방식은 다음과같다

<type>(<scope>): <subject>
<BLANK LINE>  // 공백
<body>
<BLANK LINE>  // 공백
<footer>

1) 헤더: <type>(<scope>): <subject>

50자이내
종류, 영향범위(optional), 제목을 포함하여 변경사항에 대한 간결한 설명
- type
  - build: config, 의존성에 영향을 미치는 변경사항
  - ci: ci환경설정이나, 스크립트에 미치는 변경사항 (examples: Github Actions)
  - docs: 문서에대한 변경사항(ex. README.md)
  - feat: 기능에대한 변경사항(ex. 함수)
  - fix: 버그 수정
  - perf: 성능 최적화를 위한 변경사항
  - refactor: 기능적으로나, 버그수정과 관련이 없는 오로지 코드자체만의 변경사항
  - test: 테스트파일 작성이나, 기존 테스트에 미치는 변경사항
- scope - optional
  - 변경된 범위를 의미 (ex. router, api, form)
- subject
  - 변경된 내용을 작성한다
  - 명령형,현재형으로 작성: change(o), changed(x), changes(x)
    - git 명령어를 생각해보자( ex. git merge)
  - 마침표(.)는 작성하지 않음

1) 바디: <body>

72자이내
헤더의 subject와 동일하게 명령형,현재형으로 작성
수정한 이유, 이전코드와 비교했을때 동작이 어떻게 달라졌는지 작성

1) 꼬리말

기타 참조 (ex. github issues, jira tickets, slack message link..)

2. 작은단위로 커밋 메세지를 구성하자.

여기서 ‘작은단위’란 무엇을 의미할까?

의미를 부여할 수 있는 최소단위라 생각하는데, 현재 팀에선 리액트를 통해 개발을 진행하고있기때문에 리액트를 기준으로 작업단위를 나눠보자면 다음과같다.

ui를 컴포넌트 계층으로 나누기 - (코드 작성 x)
1. 프로그래밍 관점에서 단일책임 원칙을 반영한다면 하나의 컴포넌트는 하나의 일을 해야한다. 함수를 작성한다는 생각으로 만들어보자.
2. 디자인을 기준으로한다면 시안을 보면서 모든 컴포넌트와 그 하위 컴포넌트에 박스를 그리면서 나눠보고, 해당영역에 이름을 붙이면서 나눠보자.(이과정에서 디자이너가 있다면 어떤식으로 이름을 지었는지 참고해도 괜찮을것같다)
static 버전으로 구현하기
1. mock 데이터로 ui를 렌더링하는 작업을 의미한다(jsx만 리턴)
2. 이때 state를 선언하지 말자. 이유는 아직 컴포넌트간의 관계가 만들어지기 전이기때문에 state의 선언위치나 선언 방식을 이단계에서 생각하게되면 복잡해 질 수 있다고 생각하기 때문이다.
3. 따라서 이때는 컴포넌트를 어떻게 구성하고, 각 컴포넌트의 props가 어떻게 구성될지를 생각하며 ui렌더링에만 초점을 맞추자.
4. mock데이터가 단방향(최상위 컴포넌트 → 최하위 컴포넌트)으로 흐를 수 있게 구성하자(추후 디버깅이나 코드파악이 훨씬 쉬워지기때문.
state선언 및 선언위치 결정하기
1. state란 컴포넌트의 메모리를 의미하는데 이는 유저의 상호작용에따라 화면의 변화를 값으로 표현해주는 것을 의미한다.
2. 따라서 state가 단순한 구조일수록 코드파악이 쉬워져 유지보수 or 기능추가에 유연하게 대처할 수 있다고 생각한다.
3. state 선언 기준
  1. 시간이 지남에따라 값이 변화하는지 → state 선언 o
  2. 부모컴포넌트로부터 props로 전달받는지 → state 선언 x
  3. 컴포넌트안에 다른 state나 props로 렌더링간에 계산이 가능한지 → → state 선언 x
4. 선언 위치 찾기
  1. 해당 state를 기반으로 렌더링하는 모든 컴포넌트를 찾는다
  2. 해당 컴포넌트들의 가장 가까운 공통 부모 컴포넌트를 찾은후 그곳에 state 선언
    1. 없다면 공통부모컴포넌트를 하나 만든후 그곳에 state 선언

마무리

물론 회사에서 프로젝트를 진행하게되면 보통 마감기한이라는게 존재하기때문에 모든것을 완벽하게 지켜내기란 힘든게 사실이다. 하지만 새로운 요구사항을 수용하고, 빠른 디버깅환경을 만들어가기위해선 팀원들 개개인간에 보이지 않는 노력들이 필요하다고 생각한다. 커밋 메세지를 작성하는데 에매하다거나 시간이 오래걸린다면, 작업단위를 모호하게 구분지었거나, 너무 광범위하게 구분지었지 않았나 생각해보면 좋을것같다.

추후에는 AngularJS Git Commit Message Conventions에서 소개된 git bisect 명령어를 활용한 디버깅 방식도 작성해볼 예정이다.

worth a try.