readme 꾸미는 걸 좋아하는 당신

언제든 수정해주세요.. ㅎ_ㅎ

개발자

벨라, 쏘, 미누스, 데릭

TOOLS

• NextJS
• ContextAPI

Git flow

배포 브랜치

• main
  운영 서버, 실제 유저들에게 보여지는 코드

• release (고민중)
  다음 버전 배포를 위해서 작업하는 브랜치입니다.

• develop
  개발 서버, 개발하면서 로컬 환경에서 검증을 완료한 이후 QA가 필요한 시점에 사용하는 브랜치
  서버 개발자나 기획, 디자이너들에게 QA를 요청할 때 사용할 듯 합니다. (원래는 release에서 하는게 맞긴한데 우린 얊게,, ㅎ_ㅎ)

개발 브랜치

• feature
  기능 개발할 때 사용하는 브랜치
  브랜치 컨벤션 : feature/{xxxxxxx} => 브랜치 이름에 기능에 대한 제목을 작성

• fix
  기능을 수정할 때 사용하는 브랜치
  브랜치 컨벤션 : fix/{xxxxxxx} => 브랜치 이름에 수정할 내용의 제목 작성

• hotfix
  긴급한 수정사항이 있을 때 사용하는 브랜치
  브랜치 컨벤션 : hotfix/{xxxxxxx} => 브랜치 이름에 수정할 내용의 제목 작성

pr 전략
모든 pr은 코드리뷰를 받기 위해 개발자들에게 알립니다.
main브랜치에 merge할 때는 반드시 미누스과 데릭의 코드리뷰(approve)가 진행되고 난 이후 진행합니다.
hotfix 브랜치의 경우 빠르게 모든 개발자들에게 사실을 알리고 미누스, 데릭 중 1인의 코드리뷰(approve)가 진행된 이후 머지합니다.
모든 pr은 작성자가 merge 함을 원칙으로 합니다.

좋은 코드리뷰를 위해
무작정 코드리뷰를 요청하는 것은 좋지 못할 수 있습니다. 내가 만든 것을 남이 잘 봐주기 위해서는 자신의 노력이 많이 필요합니다.
코드를 잘 설명하기 위해 주석을 사용할 수도 있고, 사진같은 첨부자료를 사용할 수도 있고, 미팅을 요청해서 설명하는 시간이 있을 수도 있습니다.

또한 코드리뷰를 요청해도 리뷰어는 모든 코드를 이해할 수 없음을 인정해야 합니다.
그리고 실력에 상관 없이 궁금한 점이 생기거나 필요한 것이 있다면 가감없이 이야기 해야 우리들의 성장에 도움이 될 수 있습니다.

코드리뷰의 목적은 실수 방지, 코드의 팀적인 합의, 히스토리 공유 등등이 있지만 이번 프로젝트에서 가장 중요한 것은 서로의 실력 향상을 위함입니다.

그래서 언제든 코드리뷰 혹은 어려운 점에 대한 해결을 요청하면 가능한한 빠른 시간에 도와주려고 노력할 것이니 편하게 이야기해주면 좋을 것 같습니다 :)

커밋 룰

커밋은 기능이 문제 없이 동작하는 최소한의 단위로 진행하게 됩니다.
물론 이 기준이 모르겠고 명확하지 않을 수 있습니다. 그렇지만 한번 해보고 각자만의, 우리만의 커밋 룰을 만들어가면 좋을 것 같습니다 :)

커밋 컨벤션

'{type}: {xxxx: 주제} /n
{xxxxxxxxxxxxxxxxxxx: 커밋 세부 사항} /n
#{1: 이슈넘버}

커밋 타입

• feature
  기능에 대한 커밋입니다.

• fix
  수정에 대한 커밋입니다.

• design
  스타일(css)에 대한 커밋입니다.

• refactor
  코드를 리팩토링 했을 때 커밋입니다.

• chore
  기타 유저들에게 영향이 가지 않지만 변경되는 것들의(버전 수정, 문서 수정 등등) 커밋입니다.

• wip
  working in progress의 약자로 특정 기능을 완료하지 못했지만 중간 저장을 위해 사용하는 커밋입니다.

issue

이슈를 발급하면 프로젝트에 이슈 사항에 대한 칸반보드를 함꼐 수정합니다.
issue를 발행하는 이유는 다른 개발자가 어떤 일을 어느정도 했는지 체크를 하기 위해서 사용합니다.

fin

모든 코드는 코드리뷰를 진행하고 배포될 예정입니다.
코드리뷰를 하면 서로의 실력 향상에도 도움이 되지만 누군가 실수를 했을 때 그사람만의 잘못이 아닌 리뷰어의 문제도 함께 있다는 의미이기도 합니다!

그러니 코드를 짜면서 생기는 다양한 문제는 우리가 함께 해결할 거니까 걱정하지말고 마음 껏 코딩해보고 마음껏 실수해보고 마음껏 망쳐보는 경험이 되길 바랍니다!