🚀 HMH Git flow

1️⃣ Branch

default 브랜치 : develop

Git Flow

1. 각자 작업할 브랜치를 develop에서 생성합니다. (최신화 필수)

• 작업이 길어질 경우, 1) develop checkout 2) Merge develop into 내 브랜치
• 내 브랜치에 develop에 머지된 사항들이 업데이트 된다고 생각하면 됩니다!

2. 커밋은 최대한 쪼개서 작성합니다.
3. 작업이 끝난 후 Pull Request를 통해 2개의 Approve를 받은 브랜치를 develop에 merge합니다.
4. Release Version을 업데이트할 때 main 브랜치를 사용합니다.

Branch Role

• main : release 관리, 버전 관리를 위한 브랜치
• develop(default) : feature 작업을 합치는 브랜치, 다음 출시 버전을 개발하는 브랜치
• feature : 단위 기능을 개발하는 브랜치, 완료되면 develop에 머지됨

Branch naming role

prefix /#issueNumber/ 작업한 view

• 폴더링
  • feat : 기능 구현
  • network : 네트워크
  • fix : 간단한 수정
  • set : 플젝 세팅과 같은 세팅
• 이슈번호
• 작업 요약
• 예시
  • feat/#13-homeSearchbarUI
  • network/#42-homeGetTag

feat/#1-calendarView

2️⃣ Issue

• 필수 : Assignees(본인), Labels, Project, MileStone 설정 필수
• 이슈 생성 후 Project의 status, priority, Size를 설정해주세요!

이미지	설명
	Labels : Prefix와 동일합니다. 주요 역할을 prefix로 작성하고 부가적인 폴더링을 위해 추가 가능합니다. Priority - AppJam🍎 - 1st Sprint - 2nd Sprint Size : 이슈의 크기를 대략적으로 나타냅니다. - XS, S: 작은 오류 수정, 적은양의 코드 변화만 있을 때 - M : 오류 수정, 코드 변화가 있는 경우 - L, XL : 하나의 Feature를 구현할 때 Milestone : 1차 스프린트로 설정

Prefix

• [Feat] → 기능 구현

• [Style] → 커스텀 뷰 짜기

• [Fix] → 오류 고치는 것 / 수정용

• [Set] → 세팅할 시

• [Network] → api 붙일때

• issue Template

---
name: "🩷 issue template"
about: Zoe의 새로운 이슈 추가
title: "[Feat] description"
labels: [🩷 지희]
assignees: Zoe929

---

## 💡 About
<!--무엇에 관한 이슈인지 소개해주세요.-->

3️⃣ Pull Request

PR 규칙

• Feat [#이슈번호] 작업 설명

  1. Assignee에는 자기 자신 태그
  2. Reviewers에 iOS 팀원 모두 태그
  3. PR 폼 양식 맞춰서 설명 올리기
  4. 스크린샷 필수!

• 2개의 Approve를 받을 경우 merge (본인이 직접 merge)

• PR Template

## 작업 내용
작업한 내용 쓰기

## PR Point
설명이 필요한 코드나 논의가 필요한 부분을 작성합니다.
코드 넣을 때는 permaLink 사용해보기 

## 스크린샷
Gif나 스크린샷 필수로 넣어주세요.

## 이슈넘버
issue: #이슈넘버 

4️⃣ Commit

[prefix/#이슈넘버] 뷰 이름 - 작업 설명
ex. [Feat/#12] Home - 서치바 레이아웃

• Merge develop into 내 브랜치 시에는

[Merge] #issueNumber - pull develop 

• PR develop merge : 기본 머지 메시지
• prefix와 함께 이슈 넘버를 기재해주세요!

Prefix

Prefix

Prefix	Role
Set	환경 세팅
Feat	새로운 기능 구현
Add	파일 추가
Delete	파일 삭제
Fix	버그 해결
Chore	기타

규칙

• 마침표, 특수기호는 사용하지 않는다.
• 간결한 설명만 덧붙인다.
• 프리픽 뒤에 정확히 내가 무엇을 했는지 적기
  • Home(어디서) - 서치바 레이아웃(무엇을)
    • UI 작업할 때 뷰컨 이름 ViewController 빼고 쓰기

5️⃣ Code Review

뱅크샐러드의 코드리뷰 문화를 차용했습니다.

커뮤니케이션 비용을 줄이기 위한 Pn 룰

• P1: 꼭 반영해주세요 (Request changes) 리뷰어는 PR의 내용이 서비스에 중대한 오류를 발생할 수 있는 가능성을 잠재하고 있는 등 중대한 코드 수정이 반드시 필요하다고 판단되는 경우, P1 태그를 통해 리> 뷰 요청자에게 수정을 요청합니다. 리뷰 요청자는 p1 태그에 대해 리뷰어의 요청을 반영하거나, 반영할 수 없는 합리적인 의견을 통해 리뷰어를 설득할 수 있어야 합니다.
• P2: 적극적으로 고려해주세요 (Request changes) 작성자는 P2에 대해 수용하거나 만약 수용할 수 없는 상황이라면 적합한 의견을 들어 토론할 것을 권장합니다.
• P3: 웬만하면 반영해 주세요 (Comment) 작성자는 P3에 대해 수용하거나 만약 수용할 수 없는 상황이라면 반영할 수 없는 이유를 들어 설명하거나 다음에 반영할 계획을 명시적으로(JIRA 티켓 등으로) 표현할 것을 권장합니다. Request changes 가 아닌 Comment 와 함께 사용됩니다.
• P4: 반영해도 좋고 넘어가도 좋습니다 (Approve) 작성자는 P4에 대해서는 아무런 의견을 달지 않고 무시해도 괜찮습니다. 해당 의견을 반영하는 게 좋을지 고민해 보는 정도면 충분합니다.
• P5: 그냥 사소한 의견입니다 (Approve) 작성자는 P5에 대해 아무런 의견을 달지 않고 무시해도 괜찮습니다.

코드 리뷰 in 뱅크샐러드 개발 문화 | 뱅크샐러드