Skip to content

GitHub 전략

ddb8036631 edited this page Oct 28, 2021 · 3 revisions

🖥 Pull Request

  • PR은 story 단위로
  • 코드 리뷰하기
    • PR마다 각자 comment 1개 이상
    • assign 팀원들을 모두 넣죠

✔ 커밋 메세지 작성법

커밋 메시지 규칙
# 커밋 메시지의 7가지 규칙
1. 제목과 본문을 빈 행으로 구분합니다.
2. 제목을 50글자 내로 제한합니다.
3. 제목 첫 글자는 대문자로 작성합니다.
4. 제목 끝에 마침표를 넣지 않습니다.
5. 제목은 명령문으로 사용하며 과거형을 사용하지 않습니다.
6. 본문의 각 행은 72글자 내로 제한합니다.
7. 어떻게 보다는 무엇과 왜를 설명합니다.

# 커밋 메시지 구조

헤더는 필수이며, 범위(scope), 본문(body), 바닥글(footer)은 선택사항입니다.

```tsx
<type>: <subject>        // 헤더
<BLANK LINE>
<body>                    // 본문
<BLANK LINE>
<footer>                // 바닥글
```

## type

해당 커밋의 성격을 나타내며 아래 중 하나를 사용합니다.

```tsx
Feat: 새로운 기능에 대한 커밋
Fix: 버그 수정에 대한 커밋
Build: 빌드 관련 파일 수정에 대한 커밋
Design: UI 디자인 및 스타일 추가/ 수정
Config: 프로젝트 설정 작업
Chore: 그 외 자잘한 수정에 대한 커밋(.gitignore 등 ..)
CI: CI관련 설정 수정에 대한 커밋
Docs: 문서 수정에 대한 커밋
Style: 코드 스타일 혹은 포맷 등에 관한 커밋
Refactor:  코드 리팩토링에 대한 커밋
Test: 테스트 코드 수정에 대한 커밋
```

## body

본문으로 헤더를 표현할 수 없는 상세한 내용을 적습니다.

## footer

바닥글로 어떤 이슈에서 왔는지 같은 참조 정보들을 추가하는 용도로 사용합니다.~~예를 들어 특정 이슈를 참조하려면 `close #122`와 같이 추가하면 됩니다.close는 이슈를 참조하면서 main브랜치로 푸시될 때 이슈를 닫게 됩니다.~~
  • 작성 템플릿
<타입>: <제목>

본문

꼬릿말

ex) Feat: 기능

설명(왜 이렇게 수정했는지)

#이슈번호

📜 커밋 템플릿 : https://junwoo45.github.io/2020-02-06-commit_template/

📈 Git Branch 전략

Git flow : https://techblog.woowahan.com/2553/

  • Master : 매주 데모에 사용할 브랜치
  • Develop : 다음 데모를 개발하는 브랜치
  • Feature : 기능을 개발하는 브랜치
  • Release : 이번 데모 버전을 준비하는 브랜치(QA)
  • Hotfix : 사용하고 있는 데모 버전에서 발생한 버그를 수정하는 브랜치

필요시 Hotfix 브랜치를 도입

🔥워크플로우

  • Develop → Feature : 기능 개발시 Origin/Develop에서 Feature branch 생성
  • Feature → Develop : 기능 개발 완료 시 Origin/Feature로 push하고 Upstream/Develop에 PR후 Merge
    • 이후 Origin/Develop을 Upstream/Develop에서 fetch, rebase하고 Feature 작업 진행
    • 현재 Feature에서 작업을 진행 중인데 Upstream/Develop에서 변경사항이 있을 시 PR 날리기 전에 반드시 Upstream/Develop과 동기화 후 날릴 것
  • Develop → Release : 매주 목요일 저녁 데모를 준비할 때 배포 테스트
  • Release → Master, Develop : 한 주 데모 버전 완성
  • CI/CD : Release와 Master에 PR시 수행

작업을 할 때 지켜야할 서로 간의 약속

  1. 작업 시작 전 project 탭에 있는 이슈(story)를 progress로 옮긴다
  2. commit 단위를 지킨다.
  3. 커밋 그래프는 최대한 단순하게 가져갑니다.
  4. merge 시 팀원들에게 알려 pull 받게 하기
  5. 서로 공유하는 브랜치의 커밋 그래프는 함부로 변경하지 않습니다.
  6. assignee에는 자기 자신을 추가합니다.
  7. 자신의 Pull Request는 reviewer의 리뷰를 2개 이상 받으면 스스로 merge 합니다.
    1. 리뷰어는 Comment와 Resolve를 수행한다.

📨 Merge 방식

Feature → Develop : Squash and Merge

Develop → Master : Rebase and Merge

Release → Develop : Squash and Merge

Hotfix → Master(or Develop) : Squash and Merge

📝 이슈 작성 템플릿

# Title

[에픽명] 스토리명
ex) [로그인] 사용자는 네이버 로그인 버튼을 클릭해 로그인

## Progess

- [] 테스크~~
ex) - [] 로그인에 성공하면 메인 페이지로 이동한다.
    - [] 로그인에 실패하면 다시 로그인 페이지로 이동한다.

📝 PR 작성 템플릿

# 제목 (작업내용 한줄요약)
# 작업 내용
# 고민한 부분
# 리뷰 포인트
# 관련된 이슈 넘버

⚒ 브랜치명

feature/분야/epic이름
ex) feature/FE/login

🍇 Home

Home

✨ Info

About Us

🤙 Team Rules

Ground Rule

GitHub 전략

🗓 Planning

프로젝트 설계

API 명세

ERD

백로그

와이어 프레임

📜 Project

기술 스택

자료실

고민거리

🔥 Progress

1️⃣ 1주차 Progress
2️⃣ 2주차 Progress
3️⃣ 3주차 Progress
4️⃣ 4주차 Progress
5️⃣ 5주차 Progress
6️⃣ 6주차 Progress

⏳ Meetings

0️⃣ 0주차 Meetings
1️⃣ 1주차 Meetings
2️⃣ 2주차 Meetings
3️⃣ 3주차 Meetings
4️⃣ 4주차 Meetings
5️⃣ 5주차 Meetings
6️⃣ 6주차 Meetings
Clone this wiki locally