작업 방식 - Amubookclub/amubookclub-wiki GitHub Wiki

Git branch strategy

master-develop-feature

master branch

• 배포 버전의 브랜치입니다.
• develop에서 배포할 커밋을 release 브랜치에 체리픽해서 master로 스쿼시 머지합니다.
• release 브랜치는 배포할 버전에 맞게 명명합니다. (ex: release/v1.1.0)
• master 브랜치에 머지되는 커밋들은 바로 서비스되어도 문제가 없는 커밋들로 한정합니다.
• release 이외의 방식이나 브랜치를 이용해 머지하지 않습니다.

develop branch

• 개발 완료된 태스크들을 머지하는 브랜치입니다.
• develop에 머지할 땐, PR을 스쿼시 머지하는 방식으로 합니다.
• 새로운 기능을 개발할 때 develop에서 feature 브랜치를 만들어서 진행합니다.

feature branch

• 하나의 이슈-PR에 대응하는 feature 브랜치를 만들어 작업합니다.
• 브랜치 이름은 '태그/작업 내용'으로 합니다. (ex: fix/main-page)

Commit convention

feat: 유저 로그인 기능 추가

• 커밋 메시지는 '태그: 작업 내용'으로 합니다.
• 커밋 바디는 작성하지 않습니다.
• 바디를 작성하지 않아도 될 정도의 작은 단위로 작업을 진행해주세요.

태그 목록

• feat: 기능 개발
• fix: 버그 수정
• refactor: 리팩토링 혹은 버그 수정이 아닌 코드 수정
• docs: 문서 작업
• chore: 설정, config 파일 변경

Issue

• 작업을 하기 전 issue를 먼저 작성해 어떤 부분을 작업하는지 공유하도록 합니다.
• issue 내용은 템플릿을 참고하여 작성하시면 됩니다.
• 작업을 시작하게 되면 assignee에 등록해주세요.

Pull request

feat: 유저 로그인 API 추가

• PR은 기본적으로 이슈와 1대1로 대응되도록 합니다.
• PR(이슈) 하나당 하나의 feature 브랜치를 만들어서 작업합니다.
• PR의 제목은 커밋 메시지와 같은 형태가 되도록 작성해주세요.
• develop 브랜치에 스쿼시 머지를 하기 때문에 PR 제목이 커밋 제목, 세부 커밋 내역이 커밋 바디가 된다고 생각하시면 됩니다.
• PR 내용은 템플릿을 참고하여 작성하되, 어떤 생각과 고민을 가지고 작업을 했는지, 문제를 어떻게 해결했는지, 궁금한 부분은 어떤 부분이지 등, 작업하면서 생각했던 것들을 작성해 주시는 것을 권장합니다.

Review

• develop 브랜치에 머지는 최소 한 명의 approve 이후에 하도록 합니다.
• 얘기해보고 싶거나 리뷰 받고 싶은 부분을 먼저 언급해주셔도 좋습니다.
• 서로 배워가는 입장이니 리뷰는 비난보다 질문과 답변, 고민 공유 등을 통해 서로가 학습할 수 있도록 합니다.

⭐ Ground rule

• 스트레스 받지 않고 즐겁게 작업하는 걸 최우선으로 합니다.
• 형식이 개발보다 우선시 되지 않도록 합니다. 규칙은 협업 과정에서 충돌을 최소화하고 정보 공유를 효율적으로 하기 위해 정해진 겁니다. 현재 규칙이 너무 무거워 오히려 작업에 방해가 된다면 언제든 수정될 수 있습니다.