Skip to content

Github로 협업하기

Jump to bottom
토마스 edited this page Mar 13, 2024 · 2 revisions

1. abloom의 컨벤션 💬

  1. Issue 타이틀 작성법

    [Label] 작업 내용

  2. Branch 컨벤션

    feature/이슈번호-작업-내용

    feature/549-keyboard-layout-refactor

  3. Commit 컨벤션

    [Label/#이슈번호] 작업 내용

    [Feat/#22] 방 생성 기능 구현

    [Feat/#22] 방 입장 기능 구현

  4. PR 타이틀

    [Label/#이슈번호] 작업 내용

2. 이슈 생성부터 머지까지 💬

이슈 생성 → 이슈 작업 → 풀리퀘스트 → 코드리뷰 → 이슈 반영(Merge)

1) 이슈 생성

Issue의 기준

프로젝트 기획, 새로운 추가 기능, 버그와 수정사항 등의 모든 것을 이슈라고 할 수 있습니다.

모든 활동 내역에 대해서 이슈를 등록하고 등록한 이슈를 기반으로 작업을 진행합니다.

Label종류

  • Feat: 새로운 기능을 추가, 수정
  • Design: 디자인 수정
  • Bug: 버그 수정
  • Ref: 리팩토링
  • Doc: 문서 수정
  • Chore: 인프라 세팅, 잡일

이슈 발행 순서 및 템플릿

  1. Issue인 경우

    • Issue 타이틀 작성법

      [Label] 작업 내용

      [Feat] 방 생성 시 입장되는 기능 구현

      작업 내용과 연관있는 Label을 사용하며, 앞글자는 대문자로 통일합니다. 작업 내용은 동사원형 형태로 끝냅니다.

    • Issue 내용 작성법

      ## ✏️ 이슈 설명
이슈에 대한 설명을 작성해주세요.

## 💻 작업 내용
- [ ] 작업할 내용을 작성해주세요.

  2. Bug인 경우

    • Bug 타이틀 작성법

      [Bug] 버그 내용

      [Bug] 방 생성하기 시 데이터가 업데이트 되지 않는 버그

    • Bug 내용 작성법

      ## ⚠️ 버그 설명
어떤 버그인지 알려주세요. 원인을 파악했다면 함께 작성해주세요.

## 📑 재현 방법
재현을 위한 과정을 남겨주세요.
1. 00뷰에서 00를 입력
2. 다음 00뷰에서 값을 00로 입력
3. 에러 발생

## 📱 스크린샷(optional)
이해를 위해 사진을 첨부해주세요.

  3. Assigness

    본인으로 지정합니다. 같이 작업한 인원이 있다면 작업 인원을 모두 지정합니다.

  4. 라벨 설정

    이슈를 시각적, 효율적으로 관리하기 위해 라벨을 설정합니다.

    이슈의 타이틀에 작성한 Label과 동일한 이름의 라벨로 설정합니다.

    Feat Design Bug Ref Doc Chore

2) 이슈 작업(브랜치 추가, 커밋 컨벤션)

이슈를 발행했다면 develop에서 feature 브랜치를 추가하고 작업을 시작합니다.

  1. Branch 컨벤션

    feature/이슈번호-작업-내용

    feature/549-keyboard-layout-refactor

  2. Commit 컨벤션

    [Label/#이슈번호] 작업 내용

    [Feat/#22] 방 생성 기능 구현

    [Feat/#22] 방 입장 기능 구현

브랜치 전략

Git-flow 전략

📌 Git-flow 전략을 따르되, 
초반엔 develop에서 feature브랜치를 생성하여 
feature 브랜치에서 작업하는 부분만 신경씁시다!

- master : 제품으로 출시될 수 있는 브랜치
- develop : 다음 출시 버전을 개발하는 브랜치
- feature : 기능을 개발하는 브랜치
- release : 이번 출시 버전을 준비하는 브랜치
- hotfix : 출시 버전에서 발생한 버그를 수정 하는 브랜치

3) Pull Request

PR Template

  • 제목

    • [Label/#이슈번호] 작업 내용
    • [Feat/#11] 프로필 화면에서 좋아요 상품 컴포넌트 헤더에 상품 개수를 표시
    • [Feat/#24] 좋아요 상품이 미노출 상태인 경우 좋아요 취소
    • 작업내용은 문장 형태로 주로 조건 + 변화의 방식으로 제목을 정합니다. 복잡한 변화라면 긴 제목을 사용하셔도 무방합니다.

  • 내용

    📌 ✔️ PR을 올리기 전 확인해주세요.
- [x] merge할 branch를 확인해주세요(develop O/main X) 

### ✏️ 개요
close #닫을 이슈 번호를 적어주세요.
작업 배경 및 작업 내용을 간단히 적어주세요.

### 💻 작업 사항
작업 내용을 자세히 적어주세요.

### 📄 리뷰 노트
리뷰어가 봐주면 하는 내용을 적어주세요.

### 📱결과 화면(optional)
리뷰어의 이해를 위해 스크린샷을 추가해주세요. 

### 📚 ETC(optional)
변경한 로직에 대해 추가로 공유하고 싶은 내용이 있다면 작성해주세요.
개발을 하시면서 발견하신 새로운 점을 팀원들에게 공유해주세요.
해결되지 않은 문제가 있다면 팀원들이 확인하도록 적어주세요.

  • 설정

    • Reviewers 본인을 제외한 테크 2명을 지정합니다.

    • Assigness 본인으로 지정합니다. 같이 작업한 인원이 있다면 작업 인원을 모두 지정합니다.

    • Labels

      아래의 라벨에 따라 해당되는 태그를 지정합니다.

      • 수정사항
        • 🗝️ Feat: 기능을 개발, 수정했다
        • 🎨 Design: 디자인을 수정했다
        • 🐛 Bug: 버그를 고쳤다
        • 🛠️ Ref: 리팩토링했다
        • 📄 Doc: 문서를 수정했다
        • ⚙️ Chore: 인프라 세팅, 잡일을 수행했다
      • 긴급여부
        • 🚨 Emergency: 빠르게 적용되어야 한다
      • 소요시간
        • 🌱 Simple: 변경이 크지 않아 리뷰가 오래 걸리지 않는다
      • PR상태
        • 👀 Review Needed: 리뷰를 요청하는 상태 - PR작성자가 변경
        • 💬 Answer Needed: 리뷰에 대한 PR 작성자의 답변을 기다리는 상태 - 리뷰어가 변경
        • 👍🏻 Merge Needed: 2명 이상이 승인하여 머지를 기다리는 상태 - 2번째 리뷰어가 변경

  • 주의 사항

    - 15분 내로 리뷰 가능한 PR을 작성합시다
- PR과 커밋은 최대한 작은 단위로 쪼개기
- 리뷰어가 빌드 성공여부/코딩컨벤션 확인하는데 시간을 쓰지 않도록 하기

4) 코드리뷰

  • 리뷰어는 리뷰를 남기고, PR에 대해 3가지 의사표현을 할 수 있습니다.
    • Comment : 그냥 코멘트만 달아줌.
    • Request changes : 코드에서 버그를 발견하면 다시 수정해달라고 요청할 수 있음.
    • Approve : 이 코드가 merge 되는 것에 동의함.
  • 본인 제외 2명에게 Approve를 받아야 PR을 완료할 수 있습니다.
    • 코드에 수정이 필요없다면 Comment 작성 후 Approve 한다.
    • 만약 코드에 수정이 필요하다면 Comment만 달거나, Request change를 요청할 수 있다. 이 경우에는 Merge 승인이 되지 않는다.
  • 코드리뷰 내용 반영한 후 해당 리뷰의 커멘트에 커밋 id 남깁니다.
  • 리뷰 내용을 확인했으면 커멘트에 이모지로 확인했음을 알립니다.

5) 이슈 반영(Merge)

Approve 리뷰를 받은 코드에 대해 PR 작성자가 직접 merge 합니다. merge 후 브랜치를 삭제합니다.

Clone this wiki locally