Home

Jump to bottom

태관 edited this page Dec 26, 2023 · 3 revisions

branch 전략

github flow 브랜치 전략
- [https://inpa.tistory.com/entry/GIT-⚡️-github-flow-git-flow-📈-브랜치-전략#git-flow_전략](https://inpa.tistory.com/entry/GIT-%E2%9A%A1%EF%B8%8F-github-flow-git-flow-%F0%9F%93%88-%EB%B8%8C%EB%9E%9C%EC%B9%98-%EC%A0%84%EB%9E%B5#git-flow_%EC%A0%84%EB%9E%B5)
- why❓ 해당 b2b 서비스는 주기적으로 버전이 나오지 않을 거라고 판단. 또한 6명 모두 git flow보다 간편하기에 어려움 없이 사용할 것으로 예상
- main 브랜치에 vercel로 미리 배포 → 기능 개발이 될 때마다 vercel이 빌드 및 배포 자동으로 진행 → 자동으로 배포된 기능을 PM팀,UX/UI 팀이 테스트
- 어떻게 분기를 할까?
  - main에서 feature/기능이름 브랜치를 분기한다 ( 반드시 main에서 분기한다 )
  - 이때 main은 항상 최신 상태로 만들어준다
  - main에 병합되면 해당 브랜치는 삭제한다
- feature 브랜치에서 main으로 merge할 때 squash merge
- git graph 확인하면서 작업하기
branch를 통한 작업 flow

main에서 브랜치를 분기한다 ex) feature/cart-layout
1. 이때 브랜치명을 자세히 적는다
분기한 브랜치에서 작업을 한다
이때 merge 한 팀원이 있으면 자신이 작업하던 브랜치에서 pull을 한다 ( git pull origin main)
작업을 끝냈으면 draft pull request를 pull request로 변경한다
approve가 됐으면 squash merge를 진행한다

pull request

draft pull request 사용
- 기능 개발을 시작할 때 미리 pull request를 올려놓는 방식
- https://hbase.tistory.com/50
- why ❓ 팀원들의 진행 상황을 파악하기 쉬움
pull request 너무 많은 양을 한 번에 게시하지 말자 (line이 100~500 줄 이내에 작성한다)
- why ❓ 너무 많은 기능들을 한꺼번에 게시를 하면 리뷰를 해야 하는 내용이 많아짐, 피드백 많아짐, 수정사항 많아짐 → 비효율

pull request template

template

### ⛳️ Task

- [ ] 할 일 1

### ✍️ Note

### ⚡️ Test

### 📸 Screenshot

### 📎 Reference

commit convention

Feat : 기능 개발
Fix : 버그 수정 - 수정 이유와 수정 내역
Refactor : 리팩토링, 개선 코드 작성 - 수정 이유와 수정 내역
Test : 테스트 코드 작성 및 수정
Docs : 문서 작성 및 수정
Build : 빌드 파일 작성 및 수정
Style : 디자인(ui) 관련된 커밋
Setting: 개발 환경 설정
Chore : 단순한 작업 (예: 파일 경로)
Rename: 파일명 변경
Delete: 파일 삭제

코드 리뷰

모든 팀원이 코드 리뷰를 진행한다
- why❓모든 사람이 코드 리뷰를 진행해야할까 궁금했고 멘토진한테 피드백 → “모든 팀원이 코드 리뷰 진행해야한다, 다른 사람 코드에 대해 왜? 라는 의문이 생기면 다 남겨야 한다 결국 나중에도 의문이 생긴다”
과정 시간 내 게시한 PR은(10:00~ 19:00) 2시간 이내 ,
과정 시간 이후에 게시한 pr은 다음날 ( 다음날이 과정 날이라는 가정 하) 오전 11시 까지
- why❓모든 팀원이 코드 리뷰를 진행하게 되면, pr을 merge 하는데 시간이 걸리고 이를 방지하기 위해 코드 리뷰 남기는 시간에 대한 규칙을 정한다
- 코드 리뷰를 시간 내 남기지 못한다면 무조건 슬랙에 태깅하여 메시지 남기기

Clone this wiki locally