우리 팀은 기술의 탐구와 공부를 통해 창의적인 서비스를 제작하고자 합니다. 이 과정에서 서비스 배포 및 운영을 넘어, 실제 상용화에 도전하여 반려견 산업에 혁신을 가져오고자 합니다.

• 현재 상황: 전세계적으로 반려견 산업의 매출이 지속적으로 증가하고 있습니다. 다양한 반려견 관련 사업이 등장하고 있지만, 디지털 분야에서의 활용은 상대적으로 미약합니다.

• 우리의 비전: 저희는 반려견 산업에 특화된 디지털 플랫폼을 통해 고객에게 편리성, 안정성, 효율성을 제공하고자 합니다. 이를 통해 고객들이 더욱 풍부한 경험을 할 수 있게 하며, 반려견과의 삶을 더욱 행복하게 만들고자 합니다.

• 편리성(쉬운): 사용자 친화적 인터페이스를 통해 누구나 쉽게 접근하고 이용할 수 있는 서비스를 제공합니다.
• 안정성(신뢰있는): 데이터 보안 및 개인 정보 보호를 최우선으로 하여 사용자의 신뢰를 얻습니다.
• 효율성(가치있는): 사용자의 시간과 비용을 절약할 수 있는 실용적이고 가치 있는 서비스를 개발합니다.

우리 모두의 노력으로 반려견과 사람들의 삶을 더욱 풍부하게 만들어 갑시다!

커밋 메시지는 한국어와 영어를 편하게 섞어 사용할 수 있습니다. 커밋 컨벤션 규칙은 아래 태그를 참고해주세요.

• Feat: 새로운 기능을 추가하는 경우
• Fix: 버그를 고친 경우
• Docs: 문서를 수정한 경우
• Style: 코드 포맷 변경, 세미콜론 누락 등 코드 수정이 없는 경우
• Refactor: 코드 리팩토링
• Test: 테스트 코드 추가 또는 리팩토링 테스트 코드 추가
• Chore: 빌드 업무 수정, 패키지 매니저 수정
• Design: CSS 등 사용자가 UI 디자인을 변경한 경우
• Rename: 파일명 또는 폴더명을 수정한 경우
• Remove: 코드(파일)를 삭제한 경우. "Clean", "Eliminate"를 사용하기도 함

• Add: 코드나 테스트, 예제, 문서 등의 추가 생성
• Improve: 향상된 기능 추가. 호환성, 검증 기능, 접근성 등이 포함됨
• Implement: 코드가 추가된 정도보다 더 주목할만한 구현체를 완성했을 때
• Move: 코드 이동이 있는 경우
• Updated: 계정이나 버전 업데이트 시 사용. 주로 코드보다는 문서나 리소스, 라이브러리 등에 사용
• Comment: 필요한 주석 추가 및 변경

• Feature, Develop, Release, Hotfix, Master 등의 명확한 브랜치 구조를 제공

• Release 브랜치에서의 테스트와 QA 과정을 통해 안정성이 검증된 기능들이 Master 브랜치로 병합되어 배포되므로 안정성이 높음

• 대부분 개발자들이 이미 사용하고 있는 전략

• Master(Main) 브랜치에서는 직접 푸시를 막아서 안정성을 고려

• Master(Main): 최상위 브랜치로, 최종 배포 버전 소스가 저장
• Release: QA를 위해 Develop 브랜치에서 생성. 완료되면 Master 브랜치로 병합
• Develop: 릴리즈 준비가 된 브랜치. 모든 Feature 브랜치는 Develop에 병합
• Feature: 개별 기능 구현과 버그 해결 시 사용하는 브랜치. Master 브랜치에는 직접 접근 불가

• Feat → Develop → Release → Main 순서

• github 커밋 컨벤션에 맞춰 자유롭게 만들되 커밋메세지를 통해서 Jira card 번호와 매칭한다.

달력을 만드는 기능인 경우: DMVM-[카드번호](feat):make calendar
배포 준비 브랜치인 경우: DMVM-[카드번호](release):version(0.0.1)

• Jira를 통해 PR 기록 확인 가능
• 모든 프로젝트 진행 상황을 Jira를 통해 파악 가능
• 이슈 발생 시 커밋 ID 대신 Jira 스프린트 카드 ID로 찾기 가능
• 프로젝트 히스토리 관리 용이

• GitHub 조직 리드미는 리더가 작성
• 각각(서버, 웹, 앱) 개발자들은 레포지토리 리드미 작성
• 기본 리드미를 제공하니 상세 정보 입력
• 리드미를 잘 꾸밀 수 있는 분들은 도와주세요!

• 리뷰어가 서로의 코드를 확인
• 명관님은 PR을 통해서만 병합 기록을 남기세요

• Feature → Develop: Squash and Merge
• 여러 개의 커밋을 하나의 커밋으로 합쳐서 기록
• Feature 브랜치는 Develop 브랜치에 병합 후 제거
• Develop → Main: Rebase And Merge

• Require a pull request before merging: Merge 전 코드 리뷰 필요
• 최소 인원 1명 설정
• Require status checks to pass before merging: 테스트 실패 시 Merge 불가 (현재는 체크하지 않음)

• 오픈소스이기 때문에 민감한 정보는 코드에 삽입 금지
• 리뷰어들은 환경 변수를 꼭 확인해주세요

모든 사항을 준수하여 효율적이고 안정적인 개발 환경을 유지합시다! 🚀