[GitHub] Feature 등 브랜치 활용법, 커밋 메시지 작성법

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를 보면서 “이 커밋이 뭘 바꾼 건지”를 훨씬 덜 고생하면서 파악할 수 있습니다.