팀 명 : A4용지

프로젝트 명 : AVOCADO

팀원 : 황시은, 정연수, 오승기, 이원희, 정재현, 권민재

배포 링크 : [아보카도 경매](https://i9a407.p.ssafy.io)

아무거나

보여주고

카메라로 판매하는

도떼기경매

`경매` 거래방식을 메인으로 잡은 서비스로, 이용자의 물건을 등록하고 `라이브경매`와 `상시경매`를 통해 이용자는 다양한 상품을 적절한 가격으로 구매할 수 있습니다.

• 예외를 반환하는 경우 끝에 OrElseThrow 붙임 ex) 사용자 명을 찾는데 없으면 예외를 반환하는 경우 findMemberOrElseThrow 라고 붙임
• cancle같이 예외 반환이 명확한 경우엔 생략해도 괜춘

• final or static 이 붙는 변수명은 대문자로 작성, 공백이 필요하면 _ 사용
• 그 외엔 Camel Case 사용

• 모든 항목은 대문자로 구성
• 각 원소 식별자는 정수가 아닌 **문자열**로 한다.

• domain과 repository는 같은 패키지에 넣자

Git-Flow 브랜치 전략에 따라 기능별로 브랜치를 나누어 작업하고 있고 모든 브랜치에 대해 pull request를 통한 리뷰 완료 후 Merge를 하고 있습니다.

✅ master : 제품으로 출시될 수 있는 브랜치

✅ develop : 다음 출시 버전을 개발하는 브랜치. feature에서 리뷰완료한 브랜치를 Merge

✅ feature : 기능을 개발하는 브랜치

✅ hotfix : 출시 버전에서 발생한 버그를 수정하는 브랜치

참고 문헌

• 우아한 형제들 기술블로그 "우린 Git-flow를 사용하고 있어요"
• README 참고

Karma - Git Commit Msg

• 기능 하나당 하나의 브랜치에 작업
• 즉, 한 사람당 한 브랜치를 사용
• 상황에 따라 중간 브랜치를 두고 그곳에 병합할 수 있음
• 브랜치 네이밍은 케밥 케이스 사용 ex) 방송의 채팅 피쳐를 맡은 경우 feature-live-chatting - develop의 경우 백, 프론트 구분을 위해 backend/develop, frontend/develop 식으로 구현
• 각 FEATURE들은 중간 브랜치 또는 DEVELOP 브랜치에 스쿼시 머지 후 새로운 브랜치 생성

• 머지 conflict 발생시, 병합 지정 충돌 날 때 중간 브랜치 또는 DEVELOP에다 하면 커밋 로그가 지저분해짐
• 스쿼시 머지 후 브랜치 삭제
• 브랜치 네이밍은 케밥 케이스 사용

• 급하게 수정할 일이 있을 때 사용
• 스쿼시 머지 후 브랜치 삭제
• 브랜치 네이밍은 케밥 케이스 사용
  

EX) 채팅 기능 구현시 Feat: 채팅 기능 구현 필요시 1~2줄 정도의 추가 메시지 달 수 있다.

• 새로운 기능이 추가될 때

• readme, swagger, 주석같이 문서화와 관련된 모든 작업

• 포맷팅, 코드 컨벤션같이 로직이 바뀌지 않은 수정 작업

• 코드 로직 재구성과 관련된 모든 작업

• 사소한 커밋 ex) Chore: 점심 먹기 전 커밋

• test 코드 작성과 관련된 모든 작업

• 문서화를 통한 협업
• PR 과정에서 발생하는 conflict 해결 및 협업 능력 향상
• Spring Boot를 활용해 주어진 요구에 맞춰 REST API 설계 및 구현
• 주어진 요구에 맞춰 ERD 설계