닉네임을 사용해서 화목하게(?) 진행했습니다! 팀원 소개는 아래로~
 Eunhye Jeon(헬리) 📖 🥂 |
 Dongwook Goh(앤디) 📖 🥂 |
 Jaehong Seo(피터) 📖 🥂 |
 Myeongkyu Lee(백준) 📖 🥂 |
 SeungHo Han(승새) 📖 🥂 |
 Jungwoo Heo(부기) 📖 🥂 |
| 날짜 | 시간 |
|---|---|
| 22.10.15 | 21:00 ~ 03:00 |
| 22.10.16 | 19:00 ~ 02:00 |
| 22.10.17 | 23:00 ~ 03:00 |
| 22.10.18 | 21:30 ~ 07:00 |
| 22.10.19 | 19:00 ~ 00:30 |
🍹 나와 어울리는 칵테일 찾으러 가기
🥂 Figjam
🍸 Figma
©Copyright Team DLink
이미지 소스 제공 - 헬리
- 🍸 feat : 새로운 기능 추가, 기존의 기능을 요구 사항에 맞추어 수정
- 🥃 fix : 기능에 대한 버그 수정
- 🧊 build : 빌드 관련 수정
- 🍺 chore : 패키지 매니저 수정, 그 외 기타 수정 ex) .gitignore
- 🍷 docs : 문서(주석) 수정
- 🍹 style : 코드 스타일, 포맷팅에 대한 수정
- 🍻 refactor : 기능의 변화가 아닌 코드 리팩터링 ex) 변수 이름 변경
- 🥂 release : 버전 릴리즈
- 🍶 merge : 병합
- github flow는 git flow의 브랜치 전략이 너무 복잡하고 적용하기 어렵다고 해서 생겨난 브랜치 전략이다.
- github flow는 master 브랜치 하나만을 가지고 진행하는 방식이다.
- master 브랜치는 어떤 기능이 구현되든, 오류가 수정되든 모두 master에 머지되어 항상 update된 상태를 유지한다.
자세한 github flow의 과정을 알아보자.
- master 브랜치에서 개발이 시작된다.
- 기능 구현이나 버그가 발생하면 issue를 작성한다.
- 팀원들이 issue 해결을 위해 master 브랜치에서 생성한 feature/{구현기능} 브랜치에서 개발을 하고 commit log를 작성한다.
- push를 하면 pull request를 날릴 수 있다.
- pull request를 통해 팀원들 간의 피드백, 버그 찾는 과정이 진행된다. release 브랜치가 없으므로 이 과정이 탄탄하게 진행되어야 한다.
- 모든 리뷰가 이루어지면, merge하기 전에 배포를 통해 최종 테스트를 진행한다.
- 테스트까지 진행되면 master 브랜치에 머지한다.
github flow는 시시각각 master에 머지될 때마다 배포가 이루어지는 것이 좋다.
따라서 CI/CD를 통한 배포 자동화를 적용하는 것이 좋다.
브랜치 전략이 단순해 master 브랜치에서 pull 하고, 기능 구현하고, 머지하는 일의 반복이다.
하지만 pull request에서 팀원간의 충분한 리뷰와 피드백이 진행되지 않으면 배포된 자체에서 버그가 발생할 수 있으므로 주의해야 한다.