커밋, 언제 하고 어떻게 해야 할까?요즘 프로젝트를 진행하다 보면 자연스럽게 커밋을 하게 되는데, 문득 "도대체 어떤 시점에, 어느 정도 단위로 커밋을 해야 하는 걸까?"라는 고민이 들었다. 그래서 이 기회에 한 번 정리도 해보고, 다른 개발자들의 의견도 참고해서 나만의 기준을 잡아보고자 한다.내가 했던 커밋 방식나는 프로젝트마다 커밋 방식이 제각각이었다. 어느 프로젝트에서는 하루 작업이 끝난 후 기능별로 쪼개서 커밋했고, 또 다른 프로젝트에서는 그냥 큰 덩어리 단위로 묶어서 올린 적도 있다.예를 들어 User 도메인 작업을 할 땐 이런 식이었다:chore: User 엔티티 및 기본 설정feat: 회원가입 요청/응답 객체 추가feat: 회원가입 서비스 로직 작성그 당시에는 ‘기능 단위로 잘 나눴다’고 생..

프로젝트에 앞서 초기 환경 세팅부터 제대로 진행해보고자 한다! Issue template과 Pr template를 만들어보자. 그렇다면 왜 템플릿을 만들어서 진행해야 할까?  Issue와 PR(풀 리퀘스트)은 프로젝트 과정에서 여러 팀원들이 매우 빈번하게 작성하는 문서이니 만큼, 공통된 양식이 있다면 같은 양식을 일일이 작성할 필요가 없어 편리하고 커뮤니케이션이 용이해진다. Issue와 PR은 프로젝트에서 정말 자주 쓰는 문서이니만큼 Template을 사용하는 다음과 같다.시간 절약: 공통된 양식에 내용만 채우기만 하면 된다.실수 방지: 중요한 내용 빼먹을 일이 없어진다.소통 개선: 팀원들이랑 소통할 때 훨씬 편해진다.즉, 공통 양식의 문서관리를 통해 팀 내 의사소통을 명확히 하고, 일관된 문서 관리로 ..

PR 관리 및 코드 리뷰 프로세스의 비효율성 협업 과정 진행 중 , PR을 올리고 승인하고 하는 연습을 모두가 하기 위해, 모두에게 관리자 권한을 부여했었다.그 이후 ,,, 팀원 중 한 명이 실수로 main에 merge 하는 issue가 생겼다..(현우형이라고 말 진짜 안할 거임 진짜로).또, 각자 모두 관리자 권한으로서 pr을 승인하고 그런 과정 중에 크게는 3가지의 단점이 존재했다.PR 승인의 비일관성 및 커뮤니케이션 부족PR 승인을 모두가 하다 보니, PR을 언제 받았는지 무엇이 바뀌었는지 전파가 잘 안 되었다.물론, 완료된 PR 목록을 가면 확인할 수 있었지만, 쉽게 실수하고, 무엇이 바뀌었는지도 모르는 상황이 일어났다.이로 인해 코드 변경사항 추적이 어려워지고, 중요한 업데이트나 변경사항을 놓치..