🤝 Github Convention

Git Convention

📢 Branch Workflow

[main - develop - develop-{파트} - feature]

• main : 항상 최신 상태로 관리한다. 이때, 최신 상태는 배포되어 있는 버전을 의미한다.
  • tag 기능으로 배포 버전을 관리한다.
• hotfix : 긴급하게 처리해야할 이슈가 있을 때 main에서 브랜치를 만들어서 작업한다.
• develop : 작업 시작 전 origin develop 에서 fetch, pull 받아서 local develop 최신화
  • WHY?
    • 개발 코드(develop)와 배포 가능 코드(main)을 구분한다.
  • feature 브랜치들이 모두 develop 브랜치에 merge 되었다면 QA를 진행한다.
  • develop-{파트}의 통합 테스트를 develop에서 수행할 수 있다. 이를 통해 main을 안전하게 보호할 수 있다.
  • develop 브랜치를 통해 오류가 확인된다면 develop 브랜치 내에서 수정을 진행한다.
  • QA와 테스트를 모두 통과했다면, 배포를 위해 develop 브랜치를 main 브랜치 쪽으로 merge한다. 만일 develop 브랜치 내부에서 오류 수정이 진행되었을 경우 동기화를 위해 develop-{파트} 브랜치 쪽에도 merge를 진행한다.
• develop-{파트} : 작업 시작 전 origin develop에서 fetch, pull 받아서 local develop 최신화
  • WHY?
    • Backend와 Android Commit 기록이 섞여서 생기는 불편함을 제거하기 위해 파트별 브랜치를 관리한다.
• feature : 최신화된 local develop 에서 개인 feature branch를 생성해 작업 시작
  • feature/#{이슈번호}-{작업 내용}
  • WHY?
    • 기능 또는 작업 단위로 브랜치를 관리할 수 있다.
    • 코드 충돌을 더 잘 관리하고 해결한다.
  • 개인 작업 후 feature branch와 local develop-{파트} branch를 merge한다. → origin feature branch로 push 후 작업 내용 확인한다. → 작업 내용이 맞다면 origin develop-{파트} branch로 PR(Pull Request)

---

Issue Template

• 이슈 생성 시 무조건 이슈 템플릿을 활용

Title 작성 규칙

prefix: 작업 제목

• prefix는 영소문자로 시작
• 띄어쓰기 잘 지키기 : prefix 와 : 는 붙이고, 작업 제목 과 : 사이는 한번 띄우기
• 작업 제목
  • 20자 이내로 간결하게 작성
  • 어떤 작업인지 명확하게 표현
  • 명사로 끝내기 : . 문자를 붙이지 않고, 동사로 끝내지 않기

Description 작성 규칙

### ✅ CheckList

- [ ] 
- [ ] 
- [ ] 
- [ ]

---

PR Template

제목

• 타입: 내용 #{이슈번호}
• 아래 Labels에서 확인

작성 규칙

• PR 생성 시 무조건 PR 템플릿을 활용
• 코드 리뷰를 남길 땐 무조건 존댓말 사용!

📌 PR 템플릿

PULL_REQUEST_TEMPLATE.md 라는 이름으로 아래 내용의 Markdown을 생성한다

---

⭐️ Issue Number

• 이슈 링크

🚩 Summary

• 구현한 내용 설명1
• 구현한 내용 설명2

🛠️ Technical Concerns

Concern 1

좌우로 스와이프 하는 레이아웃은 Compose의 HorizontalPager(기존 xml의 ViewPager)를 이용해 구현했습니다.

참고 블로그

위 블로그에 HorizontalPager의 다양한 활용 예시가 있으니 참고해보시면 좋을 것 같아요!

아래는 Pager Scope 안의 동작입니다.

1. getContentByPageNumber메서드에 현재 몇 번째 page인지에 대한 INT 값을 전달한다.
2. 해당하는 페이지의 내용을 OnboardingPageContent 형식으로 반환받아 pageContent 변수에 저장한다.
3. 페이지의 레이아웃을 그려주는 PagerItem에 pageContent 내용을 전달한다.
4. 이 때 마지막 페이지 (page==4)라면 레이아웃에 온보딩 스크린을 종료할 수 있는 Button을 추가한다.

🙂 To Reviwer

• Review Point
• Caution Point

📋 To Do

• 온보딩의 설명 부분 텍스트 Bold 처리하기

---

커밋 메시지

🛠️ Commit Convention & PR Convention

Type	설명
feat:	기능 (새로운 기능)
fix:	버그 (버그 수정)
refactor:	리팩토링 (변수 및 메서드 네이밍 변경)
style:	스타일 (메서드 순서, 코드 형식, 세미콜론 추가: 비즈니스 로직에 변경 없음)
docs:	문서 (문서 추가, 수정, 삭제)
test:	테스트 (테스트 코드 추가, 수정, 삭제: 비즈니스 로직에 변경 없음)
build:	빌드 관련 (빌드 스크립트 수정 등)
post:	블로그 포스트 추가 (신규 포스트 작성 및 수정)
chore:	기타 변경사항 (위 사항 외 자잘한 수정)
ui:	xml 작업

prefix

• 제목은 50자 이내로 요약하고, [커밋타입: 내용] 과 같이 작성한다.

• 제목은 한줄로 작성한다.

• 작성 예시

  feat: ㅇㅇ기능 추가

• 이 외의 규칙은 문서 하단의 [체크리스트]를 따른다.

body

• 본문 작성은 선택
• 커밋에 대한 자세한 설명이 필요한 경우 자율적으로 작성한다.

체크리스트

• 타입과 내용 사이에 띄어쓰기를 잘 구분했나요?
• 제목은 명령문으로 작성했나요?
• 제목 끝에 마침표(.) 금지
• 제목과 본문을 한 줄 띄워 분리하기
• 본문에 여러줄의 메시지를 작성할 땐 "-"로 구분했나요?

---

Labels

Pull Request 요청시, Pull Request 타입에 맞는 라벨을 부착한다

---

PR MERGE

MERGE 기준

• release
  • 파트별 대표자 1명씩
• develop
  • 파트별 2명 이상 approve
  • 강제 push 불가능
  • branch deletion 불가능

MERGE 방법

💡 Squash and merge

• pr merge 할 때 message 끝에 이슈 번호 붙이기

  ex) build: develop-be 브랜치의 CI 설정 #6 (#7)