Skip to content

Clody_iOS_git Convention

Jump to bottom
Seon Woo Kim edited this page Jun 29, 2024 · 2 revisions

1️⃣ Branch

default 브랜치 : develop

스크린샷 2024-06-28 오후 2 24 18

Branch 전략

  1. 각자 작업할 브랜치를 develop에서 생성합니다. (최신화 필수)
  • 작업이 길어질 경우, 1) develop checkout 2) Merge develop into 내 브랜치
  • 내 브랜치에 develop에 머지된 사항들이 업데이트 된다고 생각하면 됩니다!
  1. 커밋은 최대한 쪼개서 작성합니다.
  2. 작업이 끝난 후 Pull Request를 통해 2개의 Approve를 받은 브랜치를 develop에 merge합니다.
  3. 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

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

3️⃣ Pull Request

PR 규칙

  • Feat [#이슈번호] 작업 설명
    1. Assignee에는 자기 자신 태그
    2. Reviewers에 iOS 팀원 모두 태그
    3. PR 폼 양식 맞춰서 설명 올리기
    4. 스크린샷 필수!
    5. 코드리뷰 반영했으면 반영한 사항 적어주기
  • 2개의 Approve를 받을 경우 merge (본인이 직접 merge)

PR Template

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

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

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

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

4️⃣ Commit

[prefix/#이슈넘버] 뷰 이름 - 작업 설명
ex. [Feat/#12] Home - 서치바 레이아웃
  • prefix와 함께 이슈 넘버를 기재해주세요.
  • 프리픽 뒤에 정확히 내가 무엇을 했는지 작성해주세요.
    • Home(어디서) - 서치바 레이아웃(무엇을)
    • UI 작업할 때 뷰컨 이름 ViewController 빼고 쓰기
  • Merge develop into 내 브랜치 시에는
[Merge] #issueNumber - pull develop
  • PR develop merge : 기본 머지 메시지

Prefix

  • Set
  • Feat
  • Chore
  • Add
  • Delete
  • Fix
  • Refactor

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에 대해 아무런 의견을 달지 않고 무시해도 괜찮습니다.

Clone this wiki locally