Why do we need commit rules & branch Strategy?

---

Commit Rule 이란?

• Git 커밋 메시지 작성시 Title과 Discription을 조직에서 정한 규칙에 따라 작성하는 것
• 프로젝트 참여자들이 일관된 형식으로 커밋 메시지를 작성하기 위한 규칙
• 일반적으로 개발자들 사이에서 관습적인 가이드라인이 존재
• 하지만 각 프로젝트에 따라 별도의 규칙을 적용하기도 함

Commit Rule 지켜야 하는 이유

• 가독성을 증대시키고 커뮤니케이션의 효율을 증대시킬 수 있음
  • 일관된 커밋 메시지 형태를 통해 전체 내용을 한눈에 파악 가능
  • 작업 내역이나 변경 사항을 쉽게 확인하고 이해할 수 있음
• 코드 변경 이력 추적이 용의하고 버그 해결시 생산성이 증대함
  • 일관된 커밋 메시지 형태를 통해 각 커밋의 종류와 내용을 쉽게 확인 가능
  • 오류가 발생한 코드의 수정 내역을 쉽게 찾고 수정하여 버그 해결이 빨라짐

Branch Strategy 이란?

• 작업을 여러 유형의 브랜치로 분리하여 각각의 독립된 환경에서 독립된 작업을 수행하는 것
• 각 업무 담당자가 자신의 작업에 해당하는 브랜치에서 작업을 하여 환경을 분리함
• 작업 완료 후 원본 브랜치에 Pull Request을 통해 코드리뷰 및 병합 진행
• main과 develop 브랜치가 대표적인 브랜치 전략의 유형임

Branch Strategy을 사용하는 이유

• 다양한 유형의 작업을 브랜치를 통해 쉽고 직관적으로 분리 및 구성 가능
• 체계적인 개발 프로세스를 구축하여 효율적인 코드리뷰 및 테스트가 가능함
• release 및 hotfix 브랜치를 통해 여러 버전의 출시 작업을 지속적으로 지원 가능

Commit Rule

---

Summary

• 커밋 종류: 제목(영어)
• 변수명, 함수명, 클래스 명 등 `(option + ~)로 감싸줄것
• 감싼 경우 variable
• 감싸지 않은 경우 variable

Description

본문(한글) → 어떻게(How) 보다는 무엇을(What), 왜(Why)에 맞춰 작성

Tag Type

• Init : 프로젝트 생성
• Feat : 새로운 기능 추가
• Fix : 버그 수정
• Docs : 문서 수정
• Style : 코드 formatting, 세미콜론(;) 누락, 코드 변경이 없는 경우
• Design : 디자인 적용 및 디자인 관련 코드 수정
• Refactor : 코드 리팩토링
• Test : 테스트 코드, 리팽토링 테스트 코드 추가
• Chore : 빌드 업무 수정, 패키지 매니저 수정
• Minor : 사소한 변화

Example

Init: Create Ajou-swift project
# 엔터 꼭 넣어주세요.
이렇게 이렇게 개발해서 이러이러한 결과물이 나옴
- 어떠한 문제가 발생하여 무엇을 해결
- 왜 이러한 방법을 사용하여 개발

Branch strategy

---

Summary

• Repository의 종류
  • upstream : 소유자 혹은 조직의 repository
  • origin : upstream 에서 fork 하여 사용, 각자의 개인 깃허브에서 확인 가능한 repository
• Branch의 종류
  • develop : 현재 개발이 진행 중인 브랜치, 해당 브랜치에서 각 작업에 해당하는 브랜치를 생성하고 개발 완료 후 해당 브랜치에 병합
  • main : 현재 출시가 완료된 최종 버전의 브랜치, 개발 완료 후 release / hotfix 브랜치에서 출시 작업 진행 후 해당 브랜치에 병합
  • release : 출시 작업을 위한 브랜치, QA 및 출시 작업 진행 후 develop 이랑 main 에 merge
  • hotfix : 긴급한 버그 수정 및 출시 작업을 위한 브랜치, 버그 수정 및 출시 작업 진행 후 develop 이랑 main 에 merge

Branch Name

태그-브랜치_설명의 규칙으로 작성, 기본적으로 커밋 룰과 동일

단 : 콜론은 - 대시로 변경, 공백은 _ 언더바로 변경

Example

init-create_ajou_swift_project

Tag Type

• main : 안정 버전 브랜치
• develop : 개발 버전 브랜치
• release : 출시 작업 진행
• hotfix : 긴급 출시 작업 진행
• init : 프로젝트 생성
• feat : 새로운 기능 추가
• fix : 버그 수정
• docs : 문서 수정
• style : 코드 formatting, 세미콜론(;) 누락, 코드 변경이 없는 경우
• design : 디자인 적용 및 디자인 관련 코드 수정
• refactor : 코드 리팩토링
• test : 테스트 코드, 리팽토링 테스트 코드 추가
• chore : 빌드 업무 수정, 패키지 매니저 수정
• minor : 사소한 변화

PR message

• Branch Name을 Title로 작성
• Discription은 커밋 메시지를 기반으로 요약하여 작성
  • 이 브랜치에서 이루어진 전반적인 작업을 요약
  • 병합 전 리뷰어가 전체적인 작업 내용을 확인하기 위함

Merge Order('←' 는 Merge를 의미)

1. upstream/feature-[function] ← origin/feature-[function]

   origin/feature-[function]에서 작은 단위의 기능 개발이 끝난 후 upstream/feature-[function]에 병합, 이때 PR을 통한 코드 리뷰 필수

2. upstream/develop ← upstream/feature-[function]

   기능 개발과 코드 리뷰가 완료된 후 develop에 병합, 이때 자체적인 코드 리뷰 필수

3. upstream/main ← upstream/release-[version]

   버전 단위의 개발이 끝난 후 release 브랜치를 생성하여 테스트 후 다시 main 브랜치에 병합

• 1번 과정과 2번 과정이 여러번 반복되며 각 브랜치 병합 후 origin에서 Fetch upstream을 통해 upstream과 origin을 동기화 필요
• 3번 과정의 경우 각 버전의 최종 출시에만 시행하며, 출시가 완료된 후 develop 브랜치에서 main 브랜치를 다시 생성하여 Tagging

hotfix vs. release

• hotfix는 main 에서 땀
• release는 develop 에서 땀
• 결국에 둘다 develop 이랑 main에 병합되어야 함

참고

---

• Git 커밋 메시지 컨벤션은 왜 중요할까?
• What is the best Git branch strategy?
• How to Write a Git Commit Message
• [Git] Github, Git Commit Rule (깃허브 커밋 룰)
• 우린 Git-flow를 사용하고 있어요 | 우아한형제들 기술블로그