들어가기에 앞서

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

2. 작업을 위한 feature branch 생성 및 이동

# front
$ git branch fe/feat/<화면>
# back
$ git branch be/feat/<기능>

3. 작업 branch에서 개발 및 commit
4. 작업 완료 후 develop branch 최신화

# front
$ git checkout fe/dev
$ git pull origin fe/dev
# back
$ git checkout be/dev
$ git pull origin be/dev

5. 작업 완료한 feature branch로 이동 후 develop branch merge

# front
$ git switch fe/feat/<화면>
$ git merge fe/dev
# back
$ git switch be/feat/<기능>
$ git merge be/dev

6. 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

4. 리뷰어가 코드 리뷰 진행
5. 리뷰어가 comment 작성(최소 ‘확인했습니다.’ 정도는 작성하기)
6. 리뷰어가 라벨 변경(Asking For Review → Complete)
7. 리뷰어 승인 완료(approve) 후 리뷰어가 merge 진행
8. merge 완료된 branch 삭제
   • (master, dev 브랜치는 삭제 X)

---

4. 전체 작업 흐름

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

---

5. 참고

Commit 관련

• https://udacity.github.io/git-styleguide/
• https://blog.ull.im/engineering/2019/03/10/logs-on-git.html
• https://djkeh.github.io/articles/How-to-write-a-git-commit-message-kor/

Branch 관련

• https://techblog.woowahan.com/2553/
• https://youtu.be/EV3FZ3cWBp8
• https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow

기타

• https://www.notion.so/nyeol/Git-Commit-20cd4800cad04a3885c94ec95aef3989