-
Notifications
You must be signed in to change notification settings - Fork 4
GitHub 전략
ddb8036631 edited this page Oct 28, 2021
·
3 revisions
- 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 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시 수행
작업을 할 때 지켜야할 서로 간의 약속
- 작업 시작 전 project 탭에 있는 이슈(story)를 progress로 옮긴다
- commit 단위를 지킨다.
- 커밋 그래프는 최대한 단순하게 가져갑니다.
- merge 시 팀원들에게 알려 pull 받게 하기
- 서로 공유하는 브랜치의 커밋 그래프는 함부로 변경하지 않습니다.
- assignee에는 자기 자신을 추가합니다.
- 자신의 Pull Request는 reviewer의 리뷰를 2개 이상 받으면 스스로 merge 합니다.
- 리뷰어는 Comment와 Resolve를 수행한다.
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) - [] 로그인에 성공하면 메인 페이지로 이동한다.
- [] 로그인에 실패하면 다시 로그인 페이지로 이동한다.
# 제목 (작업내용 한줄요약)
# 작업 내용
# 고민한 부분
# 리뷰 포인트
# 관련된 이슈 넘버
feature/분야/epic이름
ex) feature/FE/login