일단 테스트 코드 만들고
테스트코드 체크 될 때까지 기능 만들고 리팩터링하고 하다가
테스트코드 체크되면 수정사항들 한번에 커밋하는데
그러지 말고 기능 하나 만들고 리팩터링 하나 할 때마다 커밋하는게 나아?
물론 내 개인프로젝트로 상관없긴한데 한번에 커밋하니까 내가 뭐 고쳤는지도 까먹고
커밋 메세지도 엄청 길어져서 가독성 개떨어짐..
일단 테스트 코드 만들고
테스트코드 체크 될 때까지 기능 만들고 리팩터링하고 하다가
테스트코드 체크되면 수정사항들 한번에 커밋하는데
그러지 말고 기능 하나 만들고 리팩터링 하나 할 때마다 커밋하는게 나아?
물론 내 개인프로젝트로 상관없긴한데 한번에 커밋하니까 내가 뭐 고쳤는지도 까먹고
커밋 메세지도 엄청 길어져서 가독성 개떨어짐..
어떻게 하는지는 하기 나름임. 너가 느끼는것처럼 누군가가 '커밋메세지' 내용을 신경쓰는 상황에서는 하나로 뭉쳐서 커밋하는게 나을 수 있음. 하지만 작업 자체의 기록을 남겨야하는 상황에서는 잘개 쪼개는것도 나쁘지않음.
근데 일반적인 통념으로는 커밋할 목표와 작업이 명확한게 좋지. 그래야 나중에 커밋기록 읽었을 때도 추적이 쉽고.
보통 그런것들을 잘 관리하려고 git으로는 부족하니 PR이라는 도구가 있는거임.
PR = 내가 작업하고 싶은것에 대한 정보 그 안에있는 커밋은 꼭 한개로 뭉칠필요는 없지만 대부분 3개 이내로 만든다 <- 이유는? : 리뷰어가 보기 편하고 핵심만 보게 하기 위해서.
ㄳㄳ 어떻게 해야되는지 방향이 잡힌 것 같음