Git 전략

• 노션링크: https://brawny-zydeco-6b6.notion.site/Git-d6cccacd7eea4f09aec92cb1fa5bee28

Branch 전략

git flow(참고링크), github flow(참고링크), gitlab flow

github flow + develop

• 정의

  1. 마스터 브랜치는 배포 가능한 브랜치이다.
  2. 새로운 작업을 하기 위해 해당 작업을 master로부터 브랜치를 생성한다. (i.e new-oauth2)
  3. 로컬 브랜치에서 커밋 후 정기적으로 origin 에 push한다.
  4. 코드 리뷰를 받거나 머지할 준비가 되면 p-r을 연다.
  5. 리뷰를 받고 master 로 푸쉬되면, 즉시 배포한다.

  GIt-flow, GitLab-flow, Github-flow란?

  💡 Git flow를 선택하지 않은 이유

  • git flow는 개발과 테스트, 릴리즈 등을 동시에 진행하면서 서비스를 관리하기 위한 브랜치 전략이다.
  • 현재 서비스가 배포되어 있지 않고 별도의 팀(예를 들어 QA팀)에서 테스트를 진행하거나 하지 않는데, git flow를 써야할까?

  💡 그렇다면 Github Flow를 사용하는 이유는?

  • 브랜치 전략이 단순하기 때문에 효율성이 높을 거라고 판단했다.
  • Main 브랜치를 깔끔하게 유지해야하는 전략이기 때문에 PR을 날릴 때마다 코드 리뷰가 강제할 수 있다.
  • 해당 프로젝트가 서비스로 정착되고나서 git flow를 적용해도 괜찮을 거라고 생각한다.

• Main브랜치를 정말 깔끔하게 유지해야한다.

  • PR, 코드리뷰 신경쓰기
  • ESLint로 console.log() 적으면 경고뜨게 만들기

• front와 back

  • 이슈를 백엔드 프론트엔드 나눠서 상세하게 작성한다.
  • 이슈 넘버를 브랜치명 앞에 붙임으로써 구분할 수 있다.

• branch 구조

  • main - 배포용. 최상단 브랜치
  • develop - 개발 통합용
  • feature/* - 개발 피쳐별 브랜치
  • fix/* - 버그 수정 피쳐별 브랜치
  • refactor/* - 리팩토링 브랜치

1. develop → [feature | fix | refactor]/${issueNumber}-${기능이름} → pr → develop
2. main -> develop -> main

ex) feature/50-login, fix/51-login-error

Branch 네이밍 컨벤션

• (feature|fix|refactor)/<Issue#>-<Name>
• 이슈나눌 때 백엔드, 프론트 나눠서 이슈를 작성해야 한다.
• 이슈와 관련지어 영어로 네이밍한다.

커밋 타입	설명
feature	새 기능
refactor	리팩토링
fix	버그 수정

[GIT] ⚡️ Gitmoji 사용법 정리 (+ 깃모지 툴 소개)

Commit Type

• feature: 이슈에 대한 기능 구현을 위하여 코드가 수정된 경우
• fix: 버그 수정
• chore: 코드 상의 수정이 없는 수정
  • 패키지 수정사항
  • 주석
• merge : merge 할 때(ex - master에서 다른 브랜치에 내용을 들고올때)
• refactor: 리팩토링
• docs: 문서화

Commit Message

• 적당히 한글/영어 섞어쓰자 (되도록 한글로)

PR

PR을 master로 머지시 squash 머지 사용

• 하나의 feature를 작게 가져가 1명이 처리
  • 세부적인 기록이 master 브랜치에 남아있을 필요가 없음
  • 너무 상세한 커밋들이 있으면 오히려 커밋내역 이해하는게 힘듦
  • 대신 PR 메시지를 자세하게 적는다.

PR 템플릿

# 템플릿
체크 리스트

 적절한 제목으로 수정했나요?
 관련된 이슈와 연결 시켰나요?
 Target Branch를 올바르게 설정했나요?
 Label을 알맞게 설정했나요?

작업 내역

작업한 내용을 간략하게 작성해주세요.

문제 상황과 해결

작업 중 마주한 문제상황 및 해결방법을 남겨주세요.

비고

참고했던 링크 등 참고 사항을 적어주세요. 코드 리뷰하는 사람이 참고해야 하는 내용을 자유로운 형식으로 적을 수 있습니다.

PR 작성 항목

• PR 제목

  • pr 제목은 이슈 제목으로 하기
  • ex) [42-4] 사용자의 아바타 업로드 요청을 처리한다.

• PR 커밋 제목(ㅅㄷㄱㅅㄷ (#1))

  • pr 제목 (# pr-number)

• PR 메시지(ㅅㄷㄱㅅㄷ)

  • pr의 commit 내역들

Issue

• 매주 월요일 스프린트 회의 후에 이슈 발행
• 데일리 스크럼에서 안건으로 상정되면 이슈 추가 발행

이슈 제목

• [Feature|Bugfix|Refactor] 이슈 이름

  ex) [Feature] 모바일 이미지 업로드가 되도록 heic 변환하기

이슈 템플릿

Feature 템플릿

.github/ISSUE_TEMPLATE/feature_request.md
name: Feature request
about: 기능 구현 예정을 작성해주세요.
title: '[backlog-number] '
label: '✨ feature'
assignees: ''
요구 사항

요구 사항을 상세하게 적어주세요.

이렇게 하위 리스트를 적극 활용하는 것도 좋은 방법입니다.



체크 리스트

 작업 목록을 작성합니다.
 작업자가 완료하면 체크를 할 수 있기 때문에 PM이 확인하고 싶은 단위로 나누어 작성하면 개발 진척도를 확인하기 용이합니다.

비고

참고 사항을 적어주세요. 해당 작업을 하는 사람이 참고해야 하는 내용을 자유로운 형식으로 적을 수 있습니다.

Bugfix 템플릿

name: Bug request
about: 수정 작성해주세요.
title: 'fix: '
label: '🐛 수정'
assignees: ''
버그 상세 설명

버그에 대한 상세한 설명과 정상적인 동작 방식에 대해 작성해주세요. 버그를 타인이 해결할 경우에도 현상과 작업 목표를 정확히 파악할 수 있어야 합니다.
가능하면 버그를 재현하는 방법도 작성해주세요.

예상되는 원인과 해결 방법 제시

예상되는 원인을 자유롭게 작성해주세요. 처리하는 사람에게 도움이 될 수도 있습니다.
구체적인 해결 방법을 제시할 수 있다면 작성해주세요.

비고 및 추가 정보

기타 참고할만한 링크나 도움이 될만한 정보를 추가해주세요.

Label

• 🌿 백엔드
• 💎 프론트엔드
• 🐛 수정
• ✨ feature
• 🛠 리팩토링
• 🚨 우선순위-긴급
• 🐢 우선순위-일반