• feature ⇒ dev ⇒ main

main 최종본을 올리는 브랜치

develop (from main) main 브랜치에 작업 내역을 merge하기 전 최종 검토하는 브랜치

feature/ (from Develop) 기능을 구현하고 코드 작업을 하는 브랜치

Gitflow-cheatsheet ⇒ 명령어 훑어보기

git-flow cheatsheet

Type

[create] 새로운 파일 및 코드 생성

[update] 기존 코드 수정

[delete] 기존에 구현해놨던 기능 삭제 시

PR

Title PR 제목 #PR 번호

Content PR 내용 서술 (~파일의 ~한 부분을 ~하게 ~했음)

Issue

Title Issue 제목 #Issue 번호

Content Issue 내용 서술 (~파일의 ~한 부분에서 ~한 Issue가 발생)

멘토님 피드백

• Github Branch 컨벤션

  • 신규 Feature 개발 -> 브런치 네이밍, 브런치 구조 ex) feature/ feature branch -> develop branch
  • Ex) Git Flow
  • Feature Branch Baseline : develop -> merge -> develop
  • develop -> release : 검증
  • 검증 완료 -> release -> merge (develop, main)
    • https://danielkummer.github.io/git-flow-cheatsheet/index.ko_KR.html

• Github Commit 컨벤션

  • prefix -> 생성, 수정, 삭제
    • [create], [update], [delete] 이걸 예시로
    • [생성] [수정] [코드 수정] 이렇게 commit message로 적는다.

• Document 관리 컨벤션

  • Github Wiki
  • Jira -> Jira Wiki
  • 설계 문서 , 테스트 코드 문서, 인프라 구성 문서

  branch 네이밍 규칙 (feature/NIC-000-name)

  어떤 방식으로 브랜치의 이름을 정하는지 브랜치 종류에 따라 살펴보자.

  1) master branch, develop branch

  master와 develop 브랜치는 본래 이름 그대로 사용하는 경우가 일반적이다.

  2) feature branch

  • 어떤 이름도 가능하다. 단, master, develop, release-..., hotfix-... 같은 이름은 사용할 수 없다.
  • feature/기능요약 형식을 추천한다. ex) feature/login
  • feature/{issue-number}-{feature-name} 이슈추적을 사용한다면 이와 같은 형식을 따른다.ex) feature/1-init-project, feature/2-build-gradle-script-write

  3) release branch

  • release-RB_... 또는 release-... 또는 release/...같은 이름이 일반적이다.
  • release-... 형식을 추천한다. ex) release-1.2

  4) hotfix branch

  • hotfix-... 형식을 추천한다. ex) hotfix-1.2.1