- ✅ main: 운영 서버에 출시되는 브랜치
- ✅ develop: 다음 출시 버전을 대비하여 개발하는 브랜치
- ✅ feature: 추가 기능을 개발하는 브랜치. develop에 PR한다.
- ✅ release: 다음 버전 출시를 준비하는 브랜치. develop 브랜치를 release 브랜치로 옮긴 후 QA, 테스트를 진행하고 main 브랜치로 합친다.
- ✅ hotfix: main 브랜치에서 발생한 버그를 수정하는 브랜치.
- 지라 이슈에 따라 생성
- 핫픽스의 경우에도 지라 이슈를 우선시 하는 것을 목표로 하며 모든 브랜치는 지라 이슈 코드를 가져가도록 함
- ex) feat/API-1-curator
- ex) feat/ADM-23-master-table
- ex) hotfix/API-3-curator
- ex) releases/0.0.1
- ex) hotfix/ADM-24-login-error
의미있는 커밋을 남기도록 함
Commit 순서가 아닌 merge 순서대로 기록된다.
그래서 하나의 PR에 담긴 commit message가 다른 PR의 commit message와 섞이지 않는다.
그리고 rebase 덕분에 merge된 이후의 로그를 보았을 때 하나의 브랜치에서 연속적으로 작업한 것과 같은 로그를 확인할 수 있다.
이 때문에 얼마든지 항상 원하는 수준으로 rollback 이 가능하다.
잘 적용하기 위해서는 commit을 생성할 때부터 올바른 commit 단위로 분리해야 하며,
commit message 또한 설명력을 가지고 있어야 한다.
그리고 다른 PR이 먼저 merge되는 경우, rebase 작업이 필요할 수 있고
이 때 발생할 수 있는 conflict를 잘 해결할 수 있어야 한다.type(옵션): Subject // -> **제목**
(한 줄을 띄워 분리합니다.)
body(옵션) // -> **본문**
(한 줄을 띄워 분리합니다.)
footer(옵션): jiraNumber // -> **꼬리말**
----(example)
feat(login): 로그인 기능 개발
- 로그인 API 개발
WEB-49- 목적
- 수정한 내용
- 추가적으로 알리고 싶은 내용
- TODO / 고민 중인 내용
- 배포 체크리스트
- [ ] PR 이름 확인
- 지라 이슈명과 유사/일치
- ex) [Feature] 결제 취소 시 주문 상태 변경 로직 자동화
- [ ] 본인 Assign 지정
- [ ] 다른 개발자 reviewer 지정- 리뷰어로 등록됐으면 무조건 확인할 수 있도록 함
- 웬만하면 바로 리뷰를 진행하는 편이 좋음
- 시간이 오래 걸릴 경우 👀 이모티콘을 사용해서 확인 중임을 알림
- 슬랙, 깃허브 둘 다
- 리뷰를 완료했으면 어떤 코멘트든 달아주도록 함
- 개선 및 수정이 필요한 내용은 여지없이 코멘트
- 시간이 추가되더라도 퀄리티를 높이는 방법
-
feat(subject): 결제 취소 시 주문 상태 변경 로직 자동화
→ 타임라인, 티켓 등을 통해 작업하는 대부분의 내용은 여기에 해당
-
fix(subject): 주문 상태 변경 시 null exception 오류 해결
→ 배포 후 발생한 오류 수정 시 해당
-
refactor: 주문 상태 변경 로직 리팩토링
→ 리팩토링 티켓 처리 시 해당
-
chore: php-fpm access log disable 처리
→ 지라 티켓과는 상관없이 진행된 기타 변경사항 해당
-
release: 1.1.0
→ release -> 운영배포시 해당
- 코드 퀄리티를 위해 대부분의 상황에서는 코드리뷰를 진행하여 피드백을 줄 수 있도록 합니다.
- 코드 리뷰를 진행 중인지 확인하기 위해서는 👀 이모지로 리액션을 달아놓을 수 있도록 합니다.
- 작업 시간이 조금은 길어지더라도 코드리뷰 문화를 만들어서 정립하면 좋을 것 같습니다.
커뮤니케이션 비용을 줄이기 위한 Pn 룰 우리는 상대방과 대화를 할 때, ‘말’이라는 언어적 표현 외에도 ‘표정’, ‘손짓’ 등의 비언어적 표현도 적극적으로 활용합니다. 온라인으로 코드 리뷰를 진행하는 경우 ‘글’ 로만 생각, 감정을 포함한 의견을 전달하기 때문에 전달력이 상대적으로 부족하고, 이로 인해 가벼운 농담이 상대방에게 진지한 이야기로 전달되는 상황이 연출되어 Blocker 가 될 수도 있습니다.
코드 리뷰의 코멘트에 Pn 룰을 사용하여 리뷰어가 코멘트를 강조하고 싶은 정도를 표현합니다.
-
P1: 꼭 반영해주세요 (Request changes).
리뷰어는 PR의 내용이 서비스에 중대한 오류를 발생할 수 있는 가능성을 잠재하고 있는 등 중대한 코드 수정이 반드시 필요하다고 판단되는 경우, P1 태그를 통해 리뷰 요청자에게 수정을 요청합니다. 리뷰 요청자는 p1 태그에 대해 리뷰어의 요청을 반영하거나, 반영할 수 없는 합리적인 의견을 통해 리뷰어를 설득할 수 있어야 합니다. -
P2: 적극적으로 고려해주세요 (Request changes).
작성자는 P2에 대해 수용하거나 만약 수용할 수 없는 상황이라면 적합한 의견을 들어 토론할 것을 권장합니다. -
P3: 웬만하면 반영해 주세요 (Comment).
작성자는 P3에 대해 수용하거나 만약 수용할 수 없는 상황이라면 반영할 수 없는 이유를 들어 설명하거나 다음에 반영할 계획을 명시적으로(JIRA 티켓 등으로) 표현할 것을 권장합니다. Request changes 가 아닌 Comment 와 함께 사용됩니다. -
P4: 반영해도 좋고 넘어가도 좋습니다 (Approve).
작성자는 P4에 대해서는 아무런 의견을 달지 않고 무시해도 괜찮습니다. 해당 의견을 반영하는 게 좋을지 고민해 보는 정도면 충분합니다. -
P5: 그냥 사소한 의견입니다 (Approve).
작성자는 P5에 대해 아무런 의견을 달지 않고 무시해도 괜찮습니다.
ex)
p1; 사용하지 않는 주석은 제거해주세요.
우선적용이기 때문에 바뀔 가능성 多
- 코드리뷰 요청 시 진행