Skip to content

Git 컨벤션

Jump to bottom
최영수(suya) edited this page Jul 19, 2024 · 4 revisions

😎 Commit Message Convetion

Udacity Nanodegree Style Guide

😇 Format

$ <type>: <subject> -- 헤더
  <BLANK LINE>                 -- 빈 줄
  <body>                        -- 본문
  • type subject 는 필수이다. body는 선택이다.
  • type은 소문자로 작성한다. (ex. feat, fix)
  • subject는 명사형으로 작성한다. (ex. 모임 추가 기능 구현)

Type

  • feat: A new feature
  • fix: A bug fix
  • docs: Changes to documentation
  • style: Formatting, missing semi colons, etc; no code change
  • refactor: Refactoring production code
  • test: Adding tests, refactoring test; no production code change
  • chore: Updating build tasks, package manager configs, etc; no production code change

Body

  • 어떻게 보다는 무엇과 왜를 설명한다.
  • 본문의 각 행은 72글자 내로 제한한다.

Example

feat: 모임 추가 기능 구현

🥺 Git Flow Convention

(1) 이슈 발행

  • 이슈 작성 시 BE/FE 태그와 이슈의 종류 태그를 선택한다.

    이슈발행

  • 이슈 작성 시 템플릿에 맞추어 작성한다.

    # 문제 정의

이 작업을 통해 해결하려는 문제를 정의하세요.

# 액션 아이템

문제를 해결하기 위해 필요한 액션 아이템을 입력하세요.

- [ ]  

# 내용

결과물, 참고사항 등을 입력하세요. (ex. PR, 문서 링크)

(2) 브랜치 생성

Git 브랜치 작업 과정

  • 브랜치명

    브랜치명 용도 규칙
    main 배포를 위한 브랜치 단일 브랜치. 삭제 금지. 태그가 따져있는 버전으로만 존재해야 함.
    develop 개발을 위한 브랜치. 백엔드와 프론트엔드의 스프린트 완료 시 병합한다. 업데이트 시 다른 팀원에게 항상 공지해야함.
    develop-backend 백엔드 개발을 위한 개발용 브랜치. 백엔드 기능 개발 완료 시 병합한다. merge하기 위해 2명의 approve가 필요로 한다.
    develop-frontend 프론트 개발을 위한 개발용 브랜치. 프론트엔드 기능 개발 완료 시 병합한다. merge하기 위해 2명의 approve가 필요로 한다.
    hotfix main에서 파생된 문제를 해결 main 으로 부터 분기하고 머지되면 삭제한다.
    feature 새로운 기능 구현 각 파트에 맞는 develop 브랜치로 부터 분기한다. develop 에 머지하면 삭제한다.
    fix develop에서 파생된 문제를 해결 각 파트에 맞는 develop 브랜치로 부터 분기한다. develop 에 머지하면 삭제한다.
    docs 문서 작업 각 파트에 맞는 develop 브랜치로 부터 분기한다. develop 에 머지하면 삭제한다.
    style 코드 스타일에 대한 사소한 수정 ex) 세미 콜론 추가 각 파트에 맞는 develop 브랜치로 부터 분기한다. develop 에 머지하면 삭제한다.
    refactor 기능이 변경되지는 않지만 코드를 수정 각 파트에 맞는 develop 브랜치로 부터 분기한다. develop 에 머지하면 삭제한다.
    test 테스트 작성 및 수정 각 파트에 맞는 develop 브랜치로 부터 분기한다. develop 에 머지하면 삭제한다.
    chore 빌드 스크립트나 설정 파일 작성 등 각 파트에 맞는 develop 브랜치로 부터 분기한다. develop 에 머지하면 삭제한다.

  • 기능 개발을 위한 브랜치 생성 시 컨벤션

    {branch-name}/#{issue-id}

ex) feature/#18

(3) 기능 완료 후 PR

  • 백엔드는 두 명 이상 Approved를 받았을 때 스스로 머지한다.

  • 프론트엔드는 두 명에게 Approved를 받았을 때 스스로 머지한다.

  • PR 작성 시 아래 템플릿에 맞추어 작성한다.

    ## PR의 목적이 무엇인가요?

<!-- 변경 사항에 대해서 간단하게 요약해 주세요 (자세한 내용은 아래 **설명** 부분에 적어주시면 됩니다.) -->

## 이슈 ID는 무엇인가요?

- closed #

## 설명

<!-- 수정 사항, 참조 사항 등 자세한 내용을 적어주세요 (스크린샷이 포함되면 기능 이해해 많은 도움이 됩니다.) -->

## 질문 혹은 공유 사항 (Optional)

<!-- 필요 시 작성해 주세요. -->

(4) PR 머지 후 정리

GitHub의 Merge, Squash and Merge, Rebase and Merge 정확히 이해하기 : NHN Cloud Meetup

  • dev 브랜치에 머지하는 경우 → Merge
  • main 브랜치에 머지하는 경우 → Squash Merge
  • merge 된 브랜치를 삭제하기
Clone this wiki locally