Portfolio

협업 방식(Tip. 과제를 참고해 보기)

PR 양식 정하기

인간의 실수를 막기 위해 미리 들어갈 수 있도록 설정해두면 좋겠음

코드 리뷰를 며칠 안에 할 것인지

기본 3일
급하면 슬랙으로 요청해주세요

커밋 컨벤션

참고

Commit Message를 작성하는 법

유형들이 복합적으로 포함되어 있을 경우, 되도록 커밋을 분리한다. 분리가 어려운 경우 위 순서상 상위 항목의 유형으로 작성한다. (eg. 기능과 테스트가 모두 포함된 경우 기능으로 작성)

feat: 기능 추가, 삭제, 변경(or ✨ emoji) - 제품 코드 수정 발생
fix: 버그 수정(or 🚑 emoji) - 제품 코드 수정 발생
docs: 문서 추가, 삭제, 변경(or 📚 emoji) - 코드 수정 없음
style:
test: 테스트 코드 추가, 삭제, 변경 등(or 🔬 emoji) - 제품 코드 수정 없음. 테스트 코드에 관련된 모든 변경에 해당
etc: 위에 해당하지 않는 모든 변경, eg. 빌드 스크립트 수정, 패키지 배포 설정 변경 - 코드 수정 없음

커밋 메시지 작성시 사용할만한 Emoji

Emoji

Raw Emoji Code

Description

🎨

:art:

코드의 형식 / 구조를 개선 할 때

📰

:newspaper:

새 파일을 만들 때

📝

:pencil:

사소한 코드 또는 언어를 변경할 때

🐎

:racehorse:

성능을 향상시킬 때

📚

:books:

문서를 쓸 때

🐛

:bug:

버그 reporting할 때, @FIXME 주석 태그 삽입

🚑

:ambulance:

버그를 고칠 때

🐧

:penguin:

리눅스에서 무언가를 고칠 때

🍎

:apple:

Mac OS에서 무언가를 고칠 때

🏁

:checkered_flag:

Windows에서 무언가를 고칠 때

🔥

:fire:

코드 또는 파일 제거할 때 , @CHANGED주석 태그와 함께

🚜

:tractor:

파일 구조를 변경할 때 . 🎨과 함께 사용

🔨

:hammer:

코드를 리팩토링 할 때

☔️

:umbrella:

테스트를 추가 할 때

🔬

:microscope:

코드 범위를 추가 할 때

💚

:green_heart:

CI 빌드를 고칠 때

🔒

:lock:

보안을 다룰 때

⬆️

:arrow_up:

종속성을 업그레이드 할 때

⬇️

:arrow_down:

종속성을 다운 그레이드 할 때

⏩

:fast_forward:

이전 버전 / 지점에서 기능을 전달할 때

⏪

:rewind:

최신 버전 / 지점에서 기능을 백 포트 할 때

👕

:shirt:

linter / strict / deprecation 경고를 제거 할 때

💄

:lipstick:

UI / style 개선시

♿️

:wheelchair:

접근성을 향상시킬 때

🚧

:construction:

WIP (진행중인 작업)에 커밋, @REVIEW주석 태그와 함께 사용

💎

:gem:

New Release

🔖

:bookmark:

버전 태그

🎉

:tada:

Initial Commit

🔈

:speaker:

로깅을 추가 할 때

🔇

:mute:

로깅을 줄일 때

✨

:sparkles:

새로운 기능을 소개 할 때

⚡️

:zap:

도입 할 때 이전 버전과 호환되지 않는 특징, @CHANGED주석 태그 사용

💡

:bulb:

새로운 아이디어, @IDEA주석 태그

🚀

:rocket:

배포 / 개발 작업 과 관련된 모든 것

🐘

:elephant:

PostgreSQL 데이터베이스 별 (마이그레이션, 스크립트, 확장 등)

🐬

:dolphin:

MySQL 데이터베이스 특정 (마이그레이션, 스크립트, 확장 등)

🍃

:leaves:

MongoDB 데이터베이스 특정 (마이그레이션, 스크립트, 확장 등)

🏦

:bank:

일반 데이터베이스 별 (마이그레이션, 스크립트, 확장명 등)

🐳

:whale:

도커 구성

🤝

:handshake:

파일을 병합 할 때

마크다운으로 보기

코드 컨벤션(eslint, prettier, stylelint 등)

브랜치 워크 플로우

문서화

협업 도구

무엇을 사용할 것인가
어떻게 사용할 것인가

사용 기술

React
상태 관리 라이브러리 무엇을 쓸 것인지
스타일링 어떻게 할 것인지 등등

이 모든 규칙은 완벽히 지켜지 않더라도 괜찮고, 문제가 생기면 해결 못할 문제는 절대! 없습니다 마음 편하게 작업하셔요!!

PR 규칙!

PR 시, eslint 처럼 공통적으로 사용되는 부분에서 변경사항이 발생한다면, 슬랙에 그때그때 올리고 각자 로컬에 옮겨서 작업한 후, 해당 변경사항만 따로 커밋하기!

base 브랜치가 develop 인지 잘 확인하기!

develop 에서 작업할 브렌치 생성 (ex. feat/#1-text-component)

remote에서 생성시 그냥 생성하고 fetch 받기
나의 로컬에서 생성 시 develop 브랜치 한번 pull 받고 생성 (내가 작업하는 동안 머지된 변경사항 받아와서 시작하기 위함)

git fetch origin ... 작업할 브랜치 받아오기

git fetch origin : origin에 없는 remote 브랜치를 가져와야 할 때

Github issue 에서 이슈 생성 (ex. Header 컴포넌트 구현) 후,

기능 체크리스트 작성 (ex. h 태그 지정하여 생성, 예외처리 등 ...)

Github projects 에서 칸반보드 관리
해당 이슈 작업
npx cz 를 통한 commitizen 커밋한 후, 같은 이름의 feat 브랜치에 push

ex > feat/#2 → origin/feat/#2 로 브랜치 이름과 맞춰서 push 하기

(ex. feat: header 컴포넌트 구현, feat: header 컴포넌트 예외처리 추가, style: ... )

커밋이 길 때는 개행으로 여러줄 커밋하기

PR 보내고 리뷰 받기 (리뷰어, 링크드 이슈 지정)
리뷰 받았으면 앞에 유형 붙이고(feat, fix...) 스쿼시 앤 머지 (ex. feat: 제목 #부여된 번호)

처음부터 완벽하게 잡고 갈 수 없으니 해보면서 같이 개선해 나가요🏃‍♀️🏃‍♂️

정해야 할 것들

Commit Message를 작성하는 법