연관된 기능이 있을 때 커밋 나누는 기준이 궁금합니다.

안녕하세요! 커밋과 PR은 항상 작게 하는게 좋다고 배웠습니다. 근데 이게 말이 쉽지 실제로 개발을 하다보면 질문자님처럼 그 기준이 애매할때가 많은데요. 개인적으로 커밋 메세지를 적을때 한 문장으로 설명할 수 없는 정도라면 너무 큰 커밋이라고 생각합니다. 그치만 이런 모호한 기준보다 명확한 기준이 있는게 좋아서 팀적으로 "이런 작업을 할때는 커밋/PR을 분리하자" 라고 정하는게 좋은 것 같습니다. 저 같은 경우는 - 리팩토링 - 기능 추가 - 기능 수정 - 기능 삭제 - 오타 수정 - 주석 이런 식으로 작업 형태에 따라 다 나눠서 커밋/PR을 올리는 편입니다. 그리고 기능 작업이라도 더 세분화할 수 있으면 나누는 편이에요. 예를 들면, 새로운 백엔드 endpoint를 추가하는 작업이라면, 각 레이어 (서비스, 컨트롤러, 라우터 등)별로 나누고 로직이 복잡하면 함수 단위로 나누기도 해요. 기능이 연결된 경우라도 최대한 분리해서 커밋을 올려주는게 좋습니다. 작은 단위 커밋과 PR은 코드 리뷰 리소스가 적게 든다는 장점도 있지만 문제가 생겼을때 원인을 빠르게 추적해서 롤백을 더 쉽게 할 수 있다는 장점이 있어요. 참고하면 좋을것 같은 링크 첨부할게요 :) - https://devloun.tistory.com/m/entry/%EC%9B%90%EC%9E%90%EC%A0%81-%EC%BB%A4%EB%B0%8B

커밋을 나누는 기준은 개발자마다 조금씩 다를 수 있지만, 아래의 몇 가지 원칙을 따라 나누는 것이 좋습니다. 1. 작은 단위의 기능별로 커밋을 하세요: 기능이 서로 연결되어 있다고 해도, 작은 단위의 기능을 완성한 후 커밋을 합니다. 이렇게 하면 추후 문제 발생 시 해당 기능을 수정하거나 롤백하기 쉬워집니다. 2. 커밋 메시지는 명확하게 작성하세요: 커밋 메시지는 해당 커밋에서 수행한 작업을 명확하게 설명해야 합니다. 이를 통해 나중에 변경 사항을 찾기 쉽게 할 수 있습니다. 3. 코드 리팩토링과 기능 개발을 분리하세요: 코드 리팩토링과 기능 개발은 별도의 커밋으로 분리하는 것이 좋습니다. 리팩토링 커밋에서는 기존 코드를 개선하거나 가독성을 높이는 작업을 하고, 기능 개발 커밋에서는 새로운 기능을 추가합니다. 4. 커밋 전 테스트하세요: 커밋 전 코드가 정상적으로 작동하는지 테스트를 수행하세요. 테스트를 통과한 코드만 커밋하면 나중에 문제를 찾고 수정하기가 더 쉬워집니다. 5. 불필요한 파일을 커밋하지 않으세요: 프로젝트에 포함되지 않아야 할 파일(예: 로그 파일, 컴파일된 바이너리 파일 등)은 .gitignore 파일에 추가해 커밋하지 않도록 설정하세요. 이러한 원칙을 따라서 커밋을 나누면, 코드 변경 이력을 관리하기가 더 쉬워지고 팀원들과의 협업도 원활해집니다. 기능이 서로 연결되어 있더라도 작은 단위로 커밋을 나누는 연습을 통해 더 나은 버전 관리 습관을 기를 수 있습니다.