Git 워크플로우: 혼자 vs 팀의 차이

입사 첫 주에 main에 직접 push했다

사이드 프로젝트를 할 때는 main 브랜치에 직접 push했다. 커밋 메시지도 "fix", "update", "asdf". 혼자니까 아무도 모르고, 아무도 뭐라 안 한다.

첫 회사에 입사하고 첫 주에 main에 직접 push했다가 시니어에게 30분간 설명을 들었다. 왜 브랜치를 따야 하는지, 왜 PR을 올려야 하는지. 그날부터 Git에 대한 인식이 완전히 바뀌었다.

솔직히 혼자 개발할 때도 브랜치를 쓰는 게 좋다. 나는 사이드 프로젝트에서도 feature/, fix/ 접두사로 브랜치를 만든다. 작업 중간에 급한 버그가 발견되면 브랜치를 전환해서 빠르게 고칠 수 있으니까.

근데 PR은 안 올린다. 리뷰할 사람이 없으니까. 커밋 메시지도 좀 자유롭다. "장바구니 기능 절반" 같은 식으로.

브랜치 네이밍 컨벤션, 커밋 메시지 형식, PR 템플릿, 머지 전략. 이런 걸 정하지 않으면 한 달 뒤에 Git 히스토리가 정글이 된다.

우리 팀은 이런 규칙을 쓴다. 브랜치는 feature/JIRA-123-add-cart, 커밋은 conventional commits 형식, PR은 최소 1명 승인 필수, 머지는 squash merge. 처음에는 번거롭다고 느꼈는데, 익숙해지면 자동으로 손이 간다.

혼자일 때: "로그인 구현", "버그 수정", "수정".

팀에서: "feat: 소셜 로그인 기능 추가 (Google, Kakao)", "fix: 장바구니 수량 변경 시 총액이 갱신되지 않는 버그 수정".

(솔직히 혼자일 때도 "수정"이라고만 쓰면 나중에 뭘 수정했는지 모른다.)

좋은 커밋 메시지는 코드 변경의 "왜"를 설명한다. "로그인 로직 변경"이 아니라 "세션 만료 시 자동 로그아웃되지 않는 이슈 해결을 위해 토큰 갱신 로직 추가"처럼.

혼자일 때는 fast-forward든 뭐든 상관없다. 팀에서는 머지 전략이 히스토리의 가독성을 결정한다.

우리 팀은 squash merge를 쓴다. 기능 하나를 만들면서 10개의 커밋을 했더라도, main에는 하나의 깔끔한 커밋으로 들어간다. 중간에 "typo fix", "lint 수정" 같은 커밋이 히스토리를 더럽히지 않는다.

나는 개인적으로 rebase를 선호한다. 히스토리가 깔끔해지니까. 근데 팀에 Git이 익숙하지 않은 사람이 있다면 merge가 안전하다. rebase 중에 충돌을 잘못 해결하면 커밋이 사라질 수 있어서다.

현재 팀에서는 PR 올리기 전에 git pull --rebase origin main으로 최신 main을 반영하고, 머지는 squash merge로 한다. 이 조합이 깔끔하면서도 안전한 편이다.

혼자일 때는 PR이 필요 없지만, 팀에서 PR 없이 코드를 머지하는 건 위험하다. PR은 코드 품질의 최소 방어선이다.

나도 PR을 올리기 전에 diff를 한 번 보면 "아, 이건 빼야 하는 코드다" 하는 걸 자주 발견한다. 리뷰어가 바로 승인하더라도, PR을 올리는 행위 자체가 내 코드를 한 번 더 점검하게 만든다.

혼자 개발할 때는 Git을 백업 도구처럼 쓰고, 팀에서는 소통 도구처럼 쓴다. 중요한 건 규칙 자체가 아니라 팀원 모두가 같은 규칙을 따르는 거다.