Git-flow 및 Git 규칙

김진회·2022년 11월 22일
git
0

git

목록 보기
1/3

들어가기에 앞서

2022년 SSAFY 1년 동안 주로 사용했던 git 규칙을 정리한 글입니다.
협업, 깃 규칙을 정할 때 참고하면 좋습니다.

Git 규칙

1. Commit

📌 commit 은 최대한 촘촘히 & 가능한 많이 하기!

작성 규칙

[타입] 제목 (지라이슈번호)

본문

타입

  • feat : 새로운 기능 추가
  • fix : 버그 수정
  • docs : 문서 수정
  • test : 테스트 코드 추가
  • refactor : 코드 리팩토링
  • style : 코드 의미에 영향을 주지 않는 변경 사항
  • chore : 그 외 기타 작업, 수정 사항 등
  • build : 빌드 관련 파일 수정
  • ci : CI관련 설정 수정
  • 타입과 제목은 필수. 제목은 한글로 작성
  • 본문은 선택. 한글로 작성
  • JIRA 이슈번호 소괄호 안에 제일 뒤에 작성
    • ex) [feat] 댓글 작성 기능 구현 (S07P22A602-85)

참고

https://meetup.toast.com/posts/106
https://blog.ull.im/engineering/2019/03/10/logs-on-git.html

2. Branch

Git-flow

  • Git-flow 전략을 기본으로 develop와 feature 브랜치를 프론트, 백 구분하여 사용
    • fe/dev, fe/feat/<화면>
    • be/dev, be/feat/<기능>
  • master : 제품으로 출시될 수 있는 브랜치
  • hotfix : 출시 버전에서 발생한 버그를 수정하는 브랜치
  • dev : 다음 출시 버전을 개발하는 브랜치
  • be/feat/<기능> : 기능을 개발하는 브랜치 ( 만들고 완료하면 삭제 )

예시 : 최대한 단어 하나로 적기. 불가능하면 Kebab case로

  • fe/feat/login
  • be/feat/login
  • be/feat/user-signup

작업 흐름

📌 master, dev 브랜치로는 바로 merge, push 금지!!!

  1. 프로젝트 clone
$ git clone 프로젝트링크
  1. develop branch로 이동
# front
$ git checkout fe/dev
# back
$ git checkout be/dev
  1. 작업을 위한 feature branch 생성 및 이동 
# front
$ git branch fe/feat/<화면>
# back
$ git branch be/feat/<기능>
  1. 작업 branch에서 개발 및 commit
  2. 작업 완료 후 develop branch 최신화
# front
$ git checkout fe/dev
$ git pull origin fe/dev
# back
$ git checkout be/dev
$ git pull origin be/dev
  1. 작업 완료한 feature branch로 이동 후 develop branch merge
# front
$ git switch fe/feat/<화면>
$ git merge fe/dev
# back
$ git switch be/feat/<기능>
$ git merge be/dev
  1. conflict 여부 확인 후 이상 없으면 MR 생성

3. Git Merge 규칙

  1. 프로젝트의 Merge requests 탭에서 [New merge request] 클릭
  2. merge할 branch 선택
  3. New merge request 내용 작성 후 생성

  • Title

    • [분야] 작업 내용
    • 분야는 항상 대문자로 작업 내용은 한글로 작성
      • ex) [COMMENT] 댓글 생성 기능 구현

  • Description

      ## 어떤 이유로 MR를 하셨나요?
  - [ ] feature 병합(feature issue #를 남겨주세요)
  - [ ] 버그 수정(아래에 issue #를 남겨주세요)
  - [ ] 코드 개선
  - [ ] 코드 수정
  - [ ] 배포
  - [ ] 기타(아래에 자세한 내용 기입해주세요)
  
  ## 세부 내용 - 왜 해당 MR이 필요한지 자세하게 설명해주세요
  - 세부사항을 항목으로 설명해주세요
      
  ## MR하기 전에 확인해주세요
  - [ ] 로컬테스트를 진행하셨나요?
  - [ ] 머지할 브랜치를 확인하셨나요?
      
  ## 관련 이슈 번호
  - 관련된 이슈 넘버가 있으면 이곳에 기입해주세요(없으면 X)
    • 체크는 x표시
      • Merge는 MergeRequest 보낸 사람이 아닌 사람이 하기
        • 설정된 양식에 맞추어 내용 작성

  • Assignee

    • 담당자는 MR 작성자 본인으로 지정

  • Reviewer

    • 작업한 내용과 관련 있는 사람을 리뷰어로 지정
      • 해당 내용을 이전에 작업한 사람
      • 작업한 내용에 영향이 있는 사람
    • Label
      • Asking For Review - 대기
      • Refused (comment에 이유 남기기) - 거절
      • Complete - 승인
      • BackEnd
      • FrontEnd
  1. 리뷰어가 코드 리뷰 진행
  2. 리뷰어가 comment 작성(최소 ‘확인했습니다.’ 정도는 작성하기)
  3. 리뷰어가 라벨 변경(Asking For Review → Complete)
  4. 리뷰어 승인 완료(approve) 후 리뷰어가 merge 진행
  5. merge 완료된 branch 삭제
    • (master, dev 브랜치는 삭제 X)

4. 전체 작업 흐름

  1. Jira 이슈 등록
  2. 브랜치 생성
  3. 작업 및 커밋
  4. MR 등록
  5. 코드 리뷰
  6. MR 완료 및 사용 브랜치 삭제
  7. Jira 이슈 완료 처리

5. 참고

Commit 관련

Branch 관련

기타

profile
김진회
SSAFY 7기. HMG. 협업, 소통, 사용자중심
다음 포스트

[Git] Git Branch 전략

0개의 댓글