main에 바로 푸시하지 마세요. 팀 프로젝트에서 자주 듣는 말입니다. 왜 그래야 하는지, 또 어떻게 쓰면 협업에 더 도움이 되는지 정리해 봤습니다.
왜 브랜치를 나눠야 할까?
main은 언제나 실행 가능하게: 배포용main브랜치는 항상 깨끗하게 유지돼야 문제가 생겨도 빠르게 복구할 수 있습니다.- 기능별로 작업해서 충돌 줄이기: 각자 브랜치를 따로 만들어 작업하면, 충돌이 나더라도 내가 건드린 부분만 집중해서 고치면 됩니다.
- 코드 리뷰에 유리: 브랜치마다 Pull Request(PR)를 만들면 변경 사항을 묶음 단위로 확인할 수 있어 리뷰 및 토론이 훨씬 수월해집니다.
추천 브랜치 종류
아래는 소규모 팀/대학 팀플에서 쓰기 좋은 브랜치 예시입니다.
| 브랜치 | 용도 | 특징 |
|---|---|---|
main |
배포용 최종 코드 | 직접 커밋 금지, PR로만 병합 |
dev |
개발용 통합 코드 | feature/ 브랜치들을 합치는 기준 브랜치 |
feature/* |
기능 개발 | dev에서 브랜치를 만들어 작업 |
hotfix/* |
긴급 버그 수정 | main에서 바로 브랜치를 따서 수정 |
간단한 작업 흐름
실제로는 dev를 기준으로 작업하는 경우가 많지만, 여기서는 예시를 위해 main 기준으로 보여줍니다.
# 1. 최신 코드로 업데이트
git checkout main
git pull origin main
# 2. 기능 브랜치 만들기
git checkout -b feature/12-login-ui
# 3. 코드 짜고 커밋
git add .
git commit -m "feat: 로그인 폼 UI 구현"
# 4. 내 브랜치에 푸시
git push -u origin feature/12-login-ui팀이 dev 브랜치를 운영한다면, 위 예시에서 main을 dev로 바꿔서 사용하면 됩니다.
좋은 커밋 메시지 작성하기
커밋 메시지는 “나중에 이력이 이해되느냐”를 좌우하는 중요한 기록입니다.
팀원들이 변경 내용을 빠르게 파악할 수 있도록, 아래처럼 최소한의 규칙을 맞춰 두는 걸 추천합니다.
1. 커밋 유형(Type) 명시
| 유형 | 설명 |
|---|---|
feat |
새로운 기능 추가 |
fix |
버그 수정 |
docs |
문서만 수정 |
style |
코드 포맷팅, 세미콜론 누락 등 (동작 변화 없음) |
refactor |
기능 변화 없이 코드 구조 개선 |
test |
테스트 코드 추가/수정 |
chore |
빌드/배포 설정, 패키지 관리 등 (프로덕션 코드 변화 없음) |
2. 제목과 본문 분리
- 제목: 50자 이내, 가능한 한 “무엇을 했는지” 한 줄로 요약합니다. (예:
feat: 로그인 기능 추가) - 본문: 필요시 작성하고, 구현의 세부 사항보다는 “무엇을, 왜 바꿨는지”에 초점을 맞춰 적어야 합니다.
예시:
feat: 로그인 폼 UI 구현
- 이메일/비밀번호 입력 필드 추가
- 폼 유효성 검사 로직 적용
- 잘못된 입력 시 에러 메시지 표시이 정도 규칙만 팀에서 맞춰도, 나중에 git log를 보면서 “이 커밋이 뭘 바꾼 건지”를 훨씬 덜 고생하면서 파악할 수 있습니다.