커밋을 잘게 쪼개자 - 커밋은 언제 하는 것이 가장 좋을까?

"깃 커밋은 언제 하는 것이 가장 좋을까?"

들어가면서

커밋의 단위는 개발자들마다 생각이 각기 다를 것이다. 누구는 크게, 누구는 작게 말이다. 이 글에서는 커밋을 어느 단위로 할지에 대해 이야기한다.

다만 웹 프론트엔드 개발에 한정한다. 이는 웹 백엔드나 기타 다른 응용 프로그램 개발에서는 또 다른 원칙이 적용될 수도 있기 때문이다.

 

커밋의 기본 원칙

커밋의 기본 원칙은 '1 Action, 1 Commit'이라고 생각한다. 이는 추후에 혹시나 모를 revert 등을 통한 롤백을 쉽게 하기 위함이기도 하다.

 

하나의 액션, 하나의 커밋

하나의 액션은 커밋 메시지 한 줄이다.

예를 들면 "카드 컴포넌트 내부에 말 줄임표 처리", "font-size를 16px에서 14px로 조정", "Item이란 용어를 Card로 변경"과 같은 일련의 작업들은 하나의 액션이다.

이러한 관점에서 볼 때, 커밋 메시지가 길어지는 경우는 대부분 더 잘게 나눌 수 있다.

 

전역으로 커밋하지 않기

전역적으로 영향을 미치지 않는 작업을 전역으로 수행해서 커밋하는 것은 좋지 않다. 예를 들면, '말 줄임표 처리'를 프로젝트 전역에서 한 것을 한 번에 커밋하는 것은 좋지 않다. 이 커밋을 revert 시킬 때 너무 많은 범위의 코드들이 영향받기 때문이다.

그래서 페이지나 맥락, 어떠한 의미 바운더리를 경계로 나눠서 커밋하는 것이 좋다. "전역에서 말 줄임표 처리" 보단 "유저 정보 페이지에서 말 줄임표 처리"와 같이 맥락이 포함된 커밋 메시지가 더 좋다.

 

커밋 메시지만 봐도 이해하기 쉽게

커밋하는 단위가 중요한 이유는 커밋 단위로 변경 내용을 사람이 읽기 쉽게 하고 싶기 때문이다. 마치 읽기 쉬운 코드를 추구하는 것처럼, 읽기 쉬운 커밋 기록을 추구하는 것이다.

커밋 메시지를 보고 어떤 파일들이 변경되었을지 추측 가능한 것이 좋다. 위에서 언급했던 "전역에서 말 줄임표 처리"가 안 좋은 이유도, 도대체 어떤 파일들을 변경했는지 눈치채기 어렵고, 파일을 봐도 너무 많을 가능성이 높기 때문이다.

 

합칠 순 있지만 나눌 순 없다

커밋은 합칠 수 있다. 하지만 나눌 순 없다. 이러한 상황에서 가장 좋은 선택은, 일단 잘게 나누고 나중에 합치는 것이다.

물론 push를 한 상태에서는 합치기 어렵지만, 커다란 커밋 보단 작은 커밋이 낫다.

커밋이 커서 문제가 되는 경우는 있어도, 작아서 문제가 되는 경우는 없을 것이다.

 

어느 시점에 커밋할까?  ―  일하는 흐름대로 커밋한 경우

2가지 수정 사항이 있는 상황을 가정해본다.

A파일의 A1코드에 버그가 있어서 수정했는데, 이에 영향받는 B, C 파일의 코드를 고쳤다. 수정하다 보니 A파일의 A2코드의 성능을 개선할 여지가 생겨서, A2코드를 리팩토링하고 이에 영향받는 D, E 파일을 수정했다. 

 

이제 작업을 마무리한 것 같아 커밋을 하려고 보면 A, B, C, D, E 파일을 커밋해야 한다. 

그래서 커밋 메시지를 고민하다가, "A컴포넌트의 XX버그를 고치고, A컴포넌트의 YY한 부분을 리팩토링" 이렇게 적었다.

 

이런 경우는 의식의 흐름(?)이라고 부를 수 있는 일하는 흐름에 따라 커밋했다고 할 수 있다.

 

그러나 일반적으로 일하는 의식의 흐름대로 커밋하면, 추후에 이런 문제를 겪을 수도 있다.

A1 버그 처리한 것이 못되어 되돌려야 하는 상황이다. 그러나 되돌리기가 간단하지 않다.

 

분명 버그 수정과 성능 개선은 각기 다른 코드를 수정했다.

하지만 일일이 버그 수정 내용을 수동으로 되돌리거나 커밋을 Revert하고 다시 성능 개선 작업을 진행해야 한다.

설령 코드를 Ctrl + C, Ctrl + V 하더라도 여러모로 귀찮은 일이 아닐 수 없다.

 

의식의 흐름대로 커밋하는 것은 분명 일의 효율이 올라간다.

커밋하는 시간이 짧다면 짧은 시간이지만, 집중을 깨뜨리기에도 충분한 시간이기 때문이다.

 

어느 시점에 커밋할까?  ― 액션대로 커밋한 경우

액션대로 커밋을 한 경우에는 위와 동일한 상황이지만, 버그를 처리한 시점에서 한번 커밋을 한다. 성능 개선은 커밋 후에 한다. 

커밋 메시지는 당연히, "A컴포넌트의 XX 버그 수정"과 "A컴포넌트의 YY한 부분을 리팩토링"으로 2개다.

커밋을 되돌려야 하는 상황에서도, 버그 처리한 커밋만 Revert 하면 되고, 성능 개선한 커밋은 그대로 들고 갈 수 있다.

 

물론 현실에서 항상 예시처럼 딱딱 맞는 상황이 발생할 것이라고는 기대할 수 없다.

일부러 예시에서도 덜어냈지만, 버그 수정한 것을 바탕으로 성능을 개선한 경우도 충분히 존재할 수 있기 때문이다. 이 경우에는 예시와 같이 할 수밖에 없다.

 

어느 시점에 커밋할까?  ―  절충안?

의식의 흐름대로 작업을 다 끝낸 후 커밋해도 괜찮은 경우가 있다. 각각의 액션들이 각기 다른 파일에만 영향을 미치면 된다.

버그 수정은 A파일에서 하고 리팩토링은 B, C파일에서, 성능개선은 D, E파일에서 하는 경우다.

 

만약에 성능 개선이 A파일을 조금 건드렸더라도, A파일 커밋할 때만 잠깐 메모장에 복사해 놨다가 다시 성능 개선 커밋할 때 붙여 넣는 방법도 있다.

 

다만 이 경우에도 커밋 메시지를 "버그 수정 & 리팩토링 & 성능개선"과 같이 작성하여 한번에 커밋하는 것은 좋지 않다. 시간이 조금 더 걸리더라도, 세 번에 걸쳐서 커밋하는 것이 좋다.

 

결국 커밋은 파일 단위로 하게 된다. 한 커밋의 한 파일에서 2가지 액션이 들어가는 순간, 해당 커밋은 복잡한 커밋이 된다.

 

마치면서

잦은 커밋으로 인해 집중이 깨지는 것도 문제가 되며, 너무 거대한 커밋도 문제가 된다.

적절한 타협을 통해 나에게 맞는 커밋 단위를 찾는다면, 분명 추후에 도움이 될 것이다.

 

요약

1. 커밋을 하는 단위는 커밋 메시지 한 줄로 설명할 수 있는 행동이어야 한다.

2. 커밋을 잘게 쪼개자 ― 커다란 커밋보단 너무 상세하더라도 작은 커밋이 더 낫다.

3. 복잡한 커밋보단 간단한 커밋 ― 한 커밋의 한 파일에서 2가지 액션이 들어가는 순간, 해당 커밋은 복잡한 커밋이 된다.