Home

📌 정기 미팅 정책

• 매일 PM 3:00 Zoom 정기 미팅!

  • FE, iOS 기능 구현 단계 시연
  • BE API 요청사항 협의
  • Slack 에서 할 이야기 없을 것 같으면, 스킵신청 가능!

• 매일 AM 10:00 스크럼

  • 잡담으로 잠 깨우기
  • 하루 예상 일과

📌 Branch Rule

rule

• ios backend frontend 브랜치에 각각 개발
• 브랜치 생성 전 관련 이슈 만들기
• PR은 각 브랜치로 보낸다

example

{직군} / {기능} / #{이슈번호} / {브랜치제목} 
ex) frontend : FE/feature/#24/LoginUI

브랜치 예상 시나리오

1. 각 직군별 이슈와 브랜치 자유롭게 생성
2. 코드 리뷰 시 main 브랜치에 PR 전송
3. 코드 리뷰 적용 후 main 브랜치에 merge

📌Commit Convention

Basic Rule

• 커밋 메시지는 알아보기 쉽게 한글로 작성.
• 다만, Commit Header는 영어로 작성.

Convention

{헤더}: {커밋 타이틀}
ghojeong/issue-tracker/#{issue_number}
ex) feat:로그인 UI 구성
ghojeong/issue-tracker/#24

Commit Header

• feat: 신규 기능 구현 : 사용자를 위한 신 기능; 새로운 빌드 관련 기능은 미포함
• fix: 버그나 에러 수정 : 사용자 버그 수정; 빌드 관련 버그 픽스 미포함
• refactor: 리팩토링 : Production Code ( 비즈니스 로직 ?)의 수정사항; 변수의 이름 변경 포함.
• style: 코드 스타일 수정 : 포멧, 잊어버린 세미 콜론 등; Production Code의 코드 변경이 없음.
• docs: 문서 작업 : 문서의 변경점
• test: 테스트 코드 : 빠진 테스트의 추가, 테스트의 리팩터링; Production Code의 변경 없음
• chore: 그외 기타 : updating grunt tasks etc; Production Code의 변경 없음

커밋 메시지 자주 쓰는 동사

• 추가(Add)
• 수정(Update)
• 삭제(Delete)

예시

• refactor: Delete plus function from practice/prac03/index.js (#11)
• style: Add practice/background.js (#13)
• fix: Add meta property to index.html (#22)
• docs: Update README.md (#27)
• feat: Connect weather API (#31)

참고 링크

• gist.github.com
• seesparkbox.com
• conventionalcommits.org
• karma-runner