팀 프로젝트 첫 회의에서는 보통 무엇을 만들지와 어떤 기술을 쓸지만 정해요. 어떻게 같이 일할지는 "일단 하면서 맞춰 가자"로 넘어가요. 그리고 2주쯤 지나면 커밋 기록은 뒤죽박죽이 되고, 누가 어떤 브랜치에서 무엇을 하는지 아무도 모르게 돼요.
규칙은 거창할 필요가 없어요. 첫날 30분만 써서 아래 다섯 가지를 정해 두면 프로젝트 내내 편해요.
1. 커밋 메시지
가장 먼저 정할 것은 커밋 메시지 형식이에요. 가장 흔한 방식은 앞에 작업 종류를 붙이는 것이에요.
feat: 회원가입 기능 구현
fix: 로그인 후 화면이 멈추는 문제 수정
docs: 실행 방법 문서 보완
자주 쓰는 말머리는 이 정도예요.
| 말머리 | 언제 쓰나요 |
|---|---|
feat |
새 기능을 추가했을 때 |
fix |
버그를 고쳤을 때 |
docs |
문서를 고쳤을 때 |
refactor |
동작은 그대로 두고 코드를 정리했을 때 |
chore |
그 밖의 자잘한 수정을 했을 때 |
같이 정해 두면 좋은 것이 두 가지 더 있어요.
- 어떤 언어로 쓸지: 한국어든 영어든 하나로 맞춰요. 섞이면 나중에 검색하기 어려워요.
- 무엇을 적을지: 고친 파일 이름이 아니라 무슨 작업을 했는지를 적어요. "Header 수정"보다 "공유하기 버튼 추가"가 훨씬 읽기 좋아요.
2. 브랜치
두 번째는 브랜치 이름이에요. 이름만 봐도 무슨 작업인지 알 수 있으면 돼요.
feat/login
fix/cart-total
12-order-history
종류를 앞에 붙이는 방식과 이슈 번호를 넣는 방식이 가장 흔해요. 어느 쪽이든 괜찮고, 팀 안에서 하나로 통일하는 것이 중요해요.
그리고 한 가지 약속을 꼭 같이 정하세요. main에는 바로 올리지 않기예요. 두세 명짜리 팀이라도 이 약속 하나만 지키면 서로의 작업이 날아가는 사고가 크게 줄어요.
3. PR
브랜치에서 작업을 끝내면 PR을 올려서 합쳐요. PR 템플릿을 만들어 두면 매번 무엇을 적을지 고민하지 않아도 돼요. 처음에는 세 칸이면 충분해요.
## 무엇을 바꿨나요
## 왜 바꿨나요
## 어떻게 확인했나요
함께 정할 것들이에요.
- 몇 명이 확인해야 합칠 수 있는지: 작은 팀이라면 한 명이면 충분해요.
- 어떤 방식으로 합칠지: 커밋을 하나로 뭉쳐서 합치면 기록이 깔끔해지고, 그대로 합치면 작업 과정이 남아요.
- PR 하나의 크기: 읽는 데 10분이 넘는 PR은 아무도 제대로 읽지 않아요. 작게 나눠서 올려요.
4. 이슈
할 일은 메신저가 아니라 이슈에 적어요. 메신저의 할 일은 위로 밀려 올라가서 사라지지만, 이슈는 닫을 때까지 남아 있어요.
- 이슈 하나에는 할 일 하나만 적어요.
- 담당자를 꼭 지정해요. 담당자가 없는 이슈는 아무도 하지 않아요.
- 종류를 구분하는 라벨은 서너 개면 충분해요.
- 브랜치 이름이나 커밋 메시지에 이슈 번호를 적으면 할 일과 작업이 이어져요.
5. 자동 검사
마지막은 사람이 매번 확인하던 것을 자동으로 돌리는 일이에요. PR을 올리면 빌드가 되는지, 코드 형식이 맞는지 자동으로 확인하게 해 두면 "내 컴퓨터에서는 됐는데"라는 말이 사라져요.
처음부터 꼭 필요한 것은 아니에요. 앞의 네 가지가 자리를 잡은 다음에 붙여도 늦지 않아요.
잘하는 팀의 규칙을 가져오세요
빈 문서에서 규칙을 만들려면 막막해요. 가장 빠른 방법은 이미 잘 굴러가는 팀의 규칙을 가져와서 고쳐 쓰는 것이에요.
- 닮고 싶은 프로젝트의 공개 레포를 하나 골라요.
- WhoIsLoafing에 링크를 넣고 "이 팀의 협업 방식을 훔치고 싶어요" 를 골라요.
- 그 팀이 실제로 쓴 브랜치 이름, 커밋 메시지, PR 템플릿, 이슈 관리 방식을 읽어 봐요.
- 팀 규칙 문서 복사하기를 눌러서 문서를 가져와요.
- 우리 팀 크기와 기간에 맞게 덜어내고 고쳐요.
레포에 PR 템플릿이나 이슈 템플릿 파일이 있으면 내용을 그대로 보여드리고, 파일마다 복사하기 버튼이 있어서 바로 가져다 쓸 수 있어요.
규칙을 지키게 하는 방법
규칙은 정하는 것보다 지키는 것이 어려워요. 몇 가지 요령이 있어요.
- 적게 정해요. 지킬 수 있는 다섯 개가 지키지 못하는 스무 개보다 나아요.
- 레포에 적어 둬요. 메신저 공지는 금방 묻혀요. README나 기여 안내 문서에 적어 두면 언제든 찾아볼 수 있어요.
- 이유를 같이 적어요. 왜 필요한지 아는 규칙은 지키게 되고, 이유를 모르는 규칙은 귀찮은 일이 돼요.
- 중간에 한 번 확인해요. 프로젝트 중간에 우리 팀 레포를 분석해서 커밋 메시지 규칙을 실제로 얼마나 지키고 있는지 봐요.
- 맞지 않으면 바꿔요. 규칙 때문에 일이 느려진다면 규칙이 잘못된 것이에요.
첫날의 30분이 마지막 주의 며칠을 아껴 줘요. 다음 프로젝트를 시작한다면 기능 목록을 적기 전에 팀 규칙부터 한 장 적어 보세요.