Skip to content

Git 전략

Jump to bottom
Gakko edited this page Dec 13, 2022 · 16 revisions

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란?

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

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

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

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

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

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

  • front와 back

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

  • branch 구조

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

image

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 작성 항목

    image

    • 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
    • 🛠 리팩토링
    • 🚨 우선순위-긴급
    • 🐢 우선순위-일반
    ## Branch 전략

    git flow([참고링크](https://techblog.woowahan.com/2553/)), github flow([참고링크](https://ujuc.github.io/2015/12/16/git-flow-github-flow-gitlab-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란?](https://wookkl.tistory.com/57)

      💡 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/* - 리팩토링 브랜치

      Untitled

    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 버그 수정

    Commit Convention

    <Emoji> <Type>: <Message>

    PR

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

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

    PR 템플릿

    # 템플릿

## 체크 리스트

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

## 작업 내역

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

## 문제 상황과 해결

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

## 비고

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

    PR 작성 항목

    Untitled

    • 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
    • 🛠 리팩토링
    • 🚨 우선순위-긴급
    • 🐢 우선순위-일반

    Home

    🔭 개발 기록

    백로그

    👨🏻‍⚖️ Ground Rules

    🤡 스크럼 기록

    스크럼기록

    🏃🏻‍♂️ 스프린트 회의

    매주의 스프린트 회의!

    📔 회고록

    팀회고
    개인회고

    📚 주요 개발일지

    🧚 더 쓰기 좋은 서비스를 만들기 위한 UX 개선기

    📄 페이지네이션과 쿼리 최적화

    🚫 프론트엔드 선언적 에러처리

    📕 스토리북 이거 왜 쓰나요?

    🚰 CI/CD 파이프라인 구축

    🤺 N+1 Problem

    🧹 모달 로직 리팩토링

    🧼 SSE 기반의 알림으로 개편하는 이유

    👉 ...더 보기

    📱 데모

    데모 준비

    Clone this wiki locally