간단하고 실용적인 Git 컨벤션 (브랜치 네이밍, 커밋 메시지)

EKODec 20, 2024

Git 컨벤션, 왜 중요할까요?

Git 컨벤션을 잘 정하고 지키는 것도 코드를 깔끔하게 작성하는 것만큼이나 중요합니다. Git 브랜치 이름이나 커밋 메시지를 일관성 있게 작성하면, 프로젝트의 히스토리를 쉽게 파악할 수 있어 협업이 원활해집니다. Git 히스토리는 곧 작업 내역이자 협업 기록이기도 합니다. 그래서 Git 레포지토리를 포트폴리오로 제출하면, 담당자는 코드를 열어보기 전에 Git 로그를 보면서 프로젝트 관리가 잘 이루어졌는지 평가하기도 합니다.

Git 컨벤션은 유명한 것을 그대로 따르기보다는, 팀의 상황이나 프로젝트 특성에 맞게 유연하게 커스터마이징하는 것이 좋습니다. 브랜치명이나 커밋 메시지 앞에 어떤 접두어를 붙일지 매번 고민해야 한다면 컨벤션을 지키기가 귀찮아질 것입니다. 경우에 따라서는 복잡하고 체계적인 컨벤션보다, 모든 팀원이 확실하게 지킬 수 있는 간단 명료한 컨벤션이 더 효과적일 수도 있습니다. 이번 글에서는 기존에 알려진 컨벤션들을 간소화한 간단하고 실용적인 Git 컨벤션을 소개하겠습니다.

Git 브랜치 전략

브랜치 네이밍 컨벤션을 정하기 전에, 먼저 어떤 브랜치 전략을 사용할지 결정해야 합니다. Git 브랜치 전략은 프로젝트를 효율적으로 관리하고 팀원 간의 협업을 원활하게 하기 위해 필요합니다.

Git Flow

우선 가장 유명하고 널리 사용되는 브랜치 전략인 Git Flow에 대해 알아보겠습니다. Git Flow는 릴리즈에에 초점을 맞춰 설계된 엄격한 브랜치 전략으로, 5가지 종류의 브랜치가 존재합니다. 항상 유지되는 메인 브랜치들(main, develop)과 일정 기간 동안만 유지되는 보조 브랜치들(feature, release, hotfix)이 있습니다.

main(master): 배포를 위한 브랜치
develop: 다음 출시 버전을 개발하는 브랜치
feature: 새 기능을 개발하는 브랜치
release: 이번 출시 버전을 준비하는 브랜치(배포 준비, QA)
hotfix: 배포된 버전의 긴급한 버그 수정을 위한 브랜치

장단점

장점
- 용도에 맞게 브랜치를 분리하기 때문에 프로덕션 코드가 안정적으로 유지됩니다.
- 주기적으로 릴리즈해야 하는 프로덕트를 개발하기에 적합합니다.
- 여러 버전을 동시에 관리하기 수월합니다.
단점
- 브랜치가 많아서 복잡하고 관리가 어렵습니다.
- 프로세스가 복잡하여 개발 및 릴리즈 주기가 느려질 수 있습니다.

실무에서 Git Flow를 어떻게 사용하는지 구체적인 사례가 궁금하시다면, 우린 Git-flow를 사용하고 있어요 | 우아한형제들 기술블로그 포스팅을 참고해보세요.

Git Flow를 비롯한 여러 가지 브랜치 전략의 장단점을 비교해보고 싶다면 이 글도 참고해보세요.

간소화된 브랜치 전략

주기적으로 버전 업데이트를 진행하지 않는 단기 프로젝트나 소규모 프로젝트라면 release 브랜치가 필요하지 않습니다. 따라서 Git Flow 전략을 그대로 적용하기엔 무리가 있습니다. 기본적으로 main, develop, feature 브랜치를 사용하고, 필요에 따라 hotfix 브랜치를 사용하는 정도로 간소화하는 것이 좋을 것 같습니다.

Git Flow에서 release 브랜치를 제외한 간소화된 워크플로우를 정리해보면 다음과 같습니다.

main 브랜치에서 develop 브랜치를 생성합니다.
develop 브랜치에서 각자 feature 브랜치를 생성하여 작업합니다.
기능 개발을 완료하면 Pull Request를 통해 feature 브랜치를 develop 브랜치에 병합합니다.
로컬에서 최신 develop 브랜치를 pull 받고, 2~3을 반복합니다.
develop 브랜치에 코드가 어느 정도 합쳐졌다면 main 브랜치에 병합하여 배포합니다.
2~5 과정을 반복합니다.
만약 배포된 버전에 급하게 해결해야 할 문제가 있다면, main 브랜치에서 hotfix 브랜치를 생성하여 버그를 수정하고 main, develop 브랜치에 병합합니다.

브랜치 네이밍 컨벤션

브랜치 전략을 정했다면, 이제 브랜치 네이밍 컨벤션을 정할 차례입니다. 브랜치 네이밍 컨벤션은 브랜치의 용도와 작업 내용을 한눈에 파악할 수 있도록 도와줍니다. 일반적으로 많이 사용되는 컨벤션은 다음과 같이 작업 유형과 설명을 kebab-case로 적는 것입니다.

type/description-in-kebab-case

팀 상황에 따라 작업 유형을 여러 종류로 나누어 사용할 수 있겠지만, 필수적인 것만 추려보면 다음과 같습니다.

feature/ 또는 feat/: 기능 추가 및 제거, 리팩터링 (develop 브랜치에서 분기)
bugfix/ 또는 fix/: 버그 수정 (develop 브랜치에서 분기)
hotfix/: 프로덕션의 긴급한 버그 수정 (main 브랜치에서 분기)

예시

feature/login-form
bugfix/user-auth-error
hotfix/crash-fix

커밋 메시지 컨벤션

커밋 메시지는 작업 내용과 변경 사항을 나타내는 중요한 메시지입니다. 커밋 메시지를 잘 작성하면 프로젝트의 변경 기록을 체계적으로 관리하고 협업의 효율성을 높일 수 있습니다. 일반적으로 다음과 같이 작업 유형과 구체적인 변경 내용을 함께 적는 방식이 많이 사용됩니다.

type: do someting

대표적으로 Conventional Commits, gitmoji 등을 살펴보면 커밋 메시지 앞에 붙이는 작업 유형이 10개 내외(feat, fix, docs, style, refactor, test, chore 등)로 세분화되어 있습니다. 하지만 유형이 너무 많으면 헷갈리기도 하고 적절한 것을 선택하기 어려울 수 있습니다. 그래서 정말 필수적인 유형 4가지만 추려보았습니다. 웬만한 작업은 이 4가지 유형으로 커버할 수 있으므로 고민하는 시간을 줄일 수 있을 것입니다.

feat: 새로운 기능 추가
fix: 버그 수정
refactor: 코드 가독성이나 효율성 향상을 위한 리팩터링(기능에는 영향 없음)
chore: 그 외의 잡다한 작업(문서 작성, 코드 포맷팅, 불필요한 코드 정리 등)

예시

안 좋은 커밋 메시지
- feat: 로그인
- feat: 업데이트
- fix: 버그 수정
- fix: 최종 수정 완료
좋은 커밋 메시지
- feat: 로그인 기능 추가
- fix: 유저 데이터 페칭 오류 수정
- feat: add login functionality
- fix: correct user data fetching error

마무리

Git 히스토리는 프로젝트의 작업 기록이기 때문에 팀의 컨벤션을 잘 준수하며 깔끔하게 관리해야 합니다. 소규모 팀이나 단기 프로젝트라면 이번 글에서 소개한 간단하고 실용적인 Git 컨벤션을 참고하여 팀의 컨벤션을 정리해보세요. 컨벤션을 지키는 것이 귀찮은 일처럼 느껴질 수 있지만, 프로젝트를 진행하면서 더 큰 혼란을 막아줄 수 있는 중요한 작업이라는 것을 잊지 마세요.

참고자료

목차