Git 전략
git flow(참고링크), github flow(참고링크), gitlab flow
-
정의
- 마스터 브랜치는 배포 가능한 브랜치이다.
- 새로운 작업을 하기 위해 해당 작업을 master로부터 브랜치를 생성한다. (i.e new-oauth2)
- 로컬 브랜치에서 커밋 후 정기적으로 origin 에 push한다.
- 코드 리뷰를 받거나 머지할 준비가 되면 p-r을 연다.
- 리뷰를 받고 master 로 푸쉬되면, 즉시 배포한다.
GIt-flow, GitLab-flow, Github-flow란?
💡 Git flow를 선택하지 않은 이유- git flow는 개발과 테스트, 릴리즈 등을 동시에 진행하면서 서비스를 관리하기 위한 브랜치 전략이다.
- 현재 서비스가 배포되어 있지 않고 별도의 팀(예를 들어 QA팀)에서 테스트를 진행하거나 하지 않는데, git flow를 써야할까?
- 브랜치 전략이 단순하기 때문에 효율성이 높을 거라고 판단했다.
- Main 브랜치를 깔끔하게 유지해야하는 전략이기 때문에 PR을 날릴 때마다 코드 리뷰가 강제할 수 있다.
- 해당 프로젝트가 서비스로 정착되고나서 git flow를 적용해도 괜찮을 거라고 생각한다.
-
Main브랜치를 정말 깔끔하게 유지해야한다.
- PR, 코드리뷰 신경쓰기
- ESLint로 console.log() 적으면 경고뜨게 만들기
-
front와 back
- 이슈를 백엔드 프론트엔드 나눠서 상세하게 작성한다.
- 이슈 넘버를 브랜치명 앞에 붙임으로써 구분할 수 있다.
-
branch 구조
master → [feature | fix]/${issueNumber}-${기능이름} → pr → master
ex) feature/50-login, fix/51-signup(feature | bugfix)/<Issue#>-<Name>- 이슈나눌 때 백엔드, 프론트 나눠서 이슈를 작성해야 한다.
- 이슈와 관련지어 영어로 네이밍한다.
<Emoji> <Type>: <Message>-
Commit Emoji
-
Commit Type
-
feature: 이슈에 대한 기능 구현을 위하여 코드가 수정된 경우 -
fix: 버그 수정 -
chore: 코드 상의 수정이 없는 수정- 패키지 수정사항
- 주석
-
merge: merge 할 때(ex -master에서 다른 브랜치에 내용을 들고올때) -
refactor: 리팩토링 -
docs: 문서화
-
-
Commit Message
- 적당히 한글/영어 섞어쓰자 (되도록 한글로)
- 하나의 feature를 작게 가져가 1명이 처리
- 세부적인 기록이 master 브랜치에 남아있을 필요가 없음
- 너무 상세한 커밋들이 있으면 오히려 커밋내역 이해하는게 힘듦
- 대신 PR 메시지를 자세하게 적는다.
# 템플릿
<br/>
## 체크 리스트
- [ ] 적절한 제목으로 수정했나요?
- [ ] 관련된 이슈와 연결 시켰나요?
- [ ] Target Branch를 올바르게 설정했나요?
- [ ] Label을 알맞게 설정했나요?
## 작업 내역
- 작업한 내용을 간략하게 작성해주세요.
## 문제 상황과 해결
- 작업 중 마주한 문제상황 및 해결방법을 남겨주세요.
## 비고
- 참고했던 링크 등 참고 사항을 적어주세요. 코드 리뷰하는 사람이 참고해야 하는 내용을 자유로운 형식으로 적을 수 있습니다.
-
PR 제목
- pr 제목은 이슈 제목으로 하기
- ex) [42-4] 사용자의 아바타 업로드 요청을 처리한다.
-
PR 커밋 제목(ㅅㄷㄱㅅㄷ (#1))
- pr 제목 (# pr-number)
-
PR 메시지(ㅅㄷㄱㅅㄷ)
- pr의 commit 내역들
- 매주 월요일 스프린트 회의 후에 이슈 발행
- 데일리 스크럼에서 안건으로 상정되면 이슈 추가 발행
-
[${backlog-number}] 이슈 이름ex> [27-3] 로그인 API 제작
web15-TadakTadak/.github at main · boostcampwm-2021/web15-TadakTadak
.github/ISSUE_TEMPLATE/feature_request.md
---
name: Feature request
about: 기능 구현 예정을 작성해주세요.
title: '[backlog-number] '
label: '✨ feature'
assignees: ''
---
## 요구 사항
- 요구 사항을 상세하게 적어주세요.
- 이렇게 하위 리스트를 적극 활용하는 것도 좋은 방법입니다.
## 체크 리스트
- [ ] 작업 목록을 작성합니다.
- [ ] 작업자가 완료하면 체크를 할 수 있기 때문에 PM이 확인하고 싶은 단위로 나누어 작성하면 개발 진척도를 확인하기 용이합니다.
## 비고
- 참고 사항을 적어주세요. 해당 작업을 하는 사람이 참고해야 하는 내용을 자유로운 형식으로 적을 수 있습니다.---
name: Bug request
about: 수정 작성해주세요.
title: 'fix: '
label: '🐛 수정'
assignees: ''
---
## 버그 상세 설명
- 버그에 대한 상세한 설명과 정상적인 동작 방식에 대해 작성해주세요. 버그를 타인이 해결할 경우에도 현상과 작업 목표를 정확히 파악할 수 있어야 합니다.
- 가능하면 버그를 재현하는 방법도 작성해주세요.
## 예상되는 원인과 해결 방법 제시
- 예상되는 원인을 자유롭게 작성해주세요. 처리하는 사람에게 도움이 될 수도 있습니다.
- 구체적인 해결 방법을 제시할 수 있다면 작성해주세요.
## 비고 및 추가 정보
- 기타 참고할만한 링크나 도움이 될만한 정보를 추가해주세요.- 🌿 백엔드
- 💎 프론트엔드
- 🐛 수정
- ✨ feature
- 🛠 리팩토링
- 🚨 우선순위-긴급
- 🐢 우선순위-일반