나의 기존 커밋 단위는 업무 중 흐름에 따른 커밋이었다. (feat. 의식의 흐름에 내 커밋을 맡긴다)
커밋 내역에는 A.파일추가와 B.구조변경, C.새로 추가 한 비즈니스 로직이 뒤엉켜있었다
C.새로 추가 한 비즈니스 로직이 완성된 후, 변경사항에는 A,B,C 파일의 변경 사항이 존재하였고
A와 B는 고려하지 않고, 현재 커밋을 하는 주 목적은 C라고 생각하였다
그래서 대략 '기능 추가'라는 메시지가 담긴 커밋을 하였다. 이때까지만 해도 이것이 문제상황이라는 것을
인식하지 못했다고 한다..
팀원과 협업 중, 내가 완전히 잘못된 커밋을 하고 있다는 것을 알게 된 계기가 있었다
공통 프로젝트에서 하나의 라이브러리를 설치했는데 팀원에게도 이 라이브러리가 필요했던 것.
나에게 커밋을 부탁하였고, 나는 별생각 없이 이전 작업 내역과 함께 커밋을 하였다.
라이브러리 변경사항만 받으려던 팀원은 git pull을 하자마자 여러 작업 내역이 섞인 로직을
받게 되었다 ... 거기다 에러는 덤이었다 (다시 떠올려보니 미안함에 눈물이 앞을 가린다..)
만약 뭉텅이로 작업 내역이 섞인 커밋을 한 뒤에, 무엇인가 잘못되어 다시 되돌려야 하는 상황이 온다면?
그땐 정말 골치 아파질 것이다.
하나의 액션, 하나의 커밋 원칙에 따라 커밋을 한다.
만약 커밋 메시지가 꼬리에 꼬리를 물고 길어진다면? 이는 커밋을 더 작게 나눠야 한다는 증거이기도 하다
'A페이지의 B라는 버그 픽스'와 'A페이지의 C한 부분을 리팩토링' 은 두 개의 커밋으로 나눠져야 한다.
커밋은 파일 단위로 이루어지는 것이 좋으며, 한 파일에 1개 이상의 액션이 들어가지 않도록 한다.
가끔 너무 작은 커밋이라는 생각이 들더라도, 거대한 커밋보다는 훨 씬 낫다
참고로 git log를 통해 커밋 메시지를 보기에 76자 이하로 작성하는 것이 보기 편하다
전역으로 커밋 하는 걸 피하자
여러 페이지에 같은 기능을 추가한다 하여도, (ex. 예약 취소) 프로젝트 전역에서 한 것을
한 번에 커밋으로 처리하는 것은 좋지 않다. 커밋 revert 시, 전역적인 범위의 코드들이
영향을 받기 때문이다.
따라서 적당한 바운더리를 나누어 전역이 아닌 '유저 설정 페이지의 예약 취소 기능 추가'로
하는 것이 좋다.
전역에서 변경을 한다면(ex. '전역 예약 취소 기능 추가') 해당 커밋 메시지를 봤을 때
어디서 어떤 파일을 변경했는지 한 번에 알기 어렵기 때문이다.
커밋 단위를 작게 가져가야 하는 이유?
1. 작게 나누면 나중에 합칠 수 있지만, 처음부터 크게 나누면 나중에 작게 나누기 불가능에 가깝다
2. 세이브포인트를 많이 남겨놓자. 커밋 내역을 많이 남겨 놓을수록, 특정 시점으로 롤백이 수월하다
3. 커밋 로그가 너무 많다면, rebase 또는 merge를 이용하여 정리하면 그만이다
4. 코드 리뷰가 용이하다
5. 양심적으로 팀원을 생각한다면 작게 나눠라
물론 예외 상황을 완전하게 배제시킬 순 없겠지만
본인만의 기준을 갖고, 그 기준에서 너무 엇나가지 않도록
커밋하는 습관을 만들어가보자 🙂 즐커밋!
Ref.
https://okky.kr/articles/337818?note=1089865
https://jaeheon.kr/257
https://tech.10000lab.xyz/git/git-commit-discipline.html
'IT 개발' 카테고리의 다른 글
[github] 삭제된 브랜치에 branch PR 날리기 (0) | 2023.04.13 |
---|---|
expo dev client와 eas build 사용하기 (0) | 2023.02.12 |
ReactNative expo-cli 시작하기. 시작이 반이다. 고로 오늘 반을 끝냈다 (2) | 2023.02.05 |
AWS는 왜 계속 내 만원을 가져가나.. (Feat. 탄력적 IP 삭제) (0) | 2023.01.29 |
Nextjs useEffect안의 router query가 빈값으로 나올 때 (0) | 2023.01.19 |