Skip to content

Git Rules

Jump to bottom
MinseungSeon edited this page Mar 7, 2021 · 1 revision

Rule : Git Message

  1. 먼저 커밋 메시지는 크게 제목, 본문, 꼬리말 세 가지 파트로 나누고, 각 파트는 빈줄을 두어서 구분합니다.
  2. 커밋 메세지는 모두 한글로 통일합니다.
  3. 제목의 경우, type은 대괄호 안에 소문자로 작성합니다.
  4. 이슈를 해결했다면, footer에 적습니다.(footer는 생략 가능합니다.)
[type] Subject  // -> 제목 

(한 줄을 띄워 분리합니다.)

body //  -> 본문 

(한 줄을 띄워 분리합니다.)

footer(옵션) // -> 꼬리말

type

  • 어떤 의도로 커밋했는지를 type에 명시합니다.
  • 제목은 최대 50글자가 넘지 않도록 하고 마침표는 찍지 않습니다.
  • 로그인 뷰 - 꾸미는거 [style] [refactor] + 서버통신 [feat] [network]

  1. feat : 새로운 기능 추가하기

    [feat] 버튼 클릭 시 날짜 선택 하는 기능 추가

body: 버튼 클릭 시 picker를 통해 날짜를 선택하게 구현
picker뷰는 toolbar를 이용했음

  2. fix : 버그 수정하는 경우

    [fix] 라벨 길이가 짤리는 버그 수정

body: 라벨 길이를 view leading에서 간격 추가

  3. refactor : 코드 리팩토링 하는 경우

    [refactor] MainVC 코드 정리

body: convension 내용 중 변수명을 지키지 못한 점 수정
lowerCamelCase를 지켜서 변수명을 수정했음

  4. style : 색상 변경, 폰트 변경 등이 있는 경우

    [style] back 버튼 색상 red로 변경

body: 제플린 수정으로 인해 black -> red로 변경

  5. upload : 파일 생성하는 경우

    [upload] HomeVC 파일 생성

  6. docs : 문서 수정하는 경우

    [docs] README.md 파일 수정

body: Git Message Convention 방법 정리

body

  • "body: " 를 앞에 포함하여 작성합니다.
  • 긴 설명이 필요한 경우에 작성합니다.
  • 어떻게 했는지가 아니라, 무엇을 왜 했는지를 작성합니다.
  • 최대 75자를 넘기지 않도록 합니다.

footer (생략 가능)

  • 꼬리말은 optional이고 이슈 트래커 ID를 작성합니다.

  • 꼬리말은 "유형: #이슈 번호" 형식으로 사용합니다.

  • 여러 개의 이슈 번호를 적을 때는 쉼표로 구분합니다.

  • 이슈 트래커 유형은 다음 중 하나를 사용합니다.

    • Fixes: 이슈 수정중 (아직 해결되지 않은 경우)
    • Resolves: 이슈를 해결했을 때 사용
    • Ref: 참고할 이슈가 있을 때 사용
    • Related to: 해당 커밋에 관련된 이슈번호 (아직 해결되지 않은 경우)

    ex)

    • Fixes: #45
    • Related to: #34, #23
    • close #45
    • Related to: #112
[feat] "추가 로그인 함수" 로그인 서버 연결

body: 로그인 구조체 생성(Login Model)
로그인 URL 연결

Resolves: #5

💪🏻 How to use Git as a team

  • WeekFlex iOS 팀은 기능별 브랜치를 만들어서 작업합니다.
  • master(main) - develop - feature branch 의 형태를 따릅니다.

1. master(main)

- 배포 가능한 상태로 관리

2. develop

- 다른 브랜치를 합치는 통합 브랜치로서 사용  
- 우리의 feature branch를 여기로 merge 하여 오류가 나지않은 안정적인 상태일 때 main(master)에 올려서 main(master)는 항상 안정적인 상태로 유지하기

3. feature

- feature 브랜치들은 기능별로 생성하여 사용합니다.  
- 기능이름/주요사항이름 으로 이름을 구성하도록 합니다.  

예.  

mainHome 뷰 레이아웃을 구성했을 때 : mainHome/style  
mainHome 뷰 서버 API 를 짰을 때 : mainHome/network  
mainHome 뷰에서 일부분 코드 수정을 했을 때 : mainHome/refac  
mainHome 뷰에서 주석, MARK 등을 수정했을 때 : mainHome/docs  

- 기능 구현이 완료된다면 PR 을 생성한 후, 반드시 iOS 팀원을 Reviewer 로 등록합니다.  
- 팀원들의 피드백을 받은 후, 피드백에 따라 코드 수정이 필요하다면 수정을 하여 추가 commit 을 합니다.    
- 수정까지 모두 끝난다면 최근 develop 브랜치의 버전과 충돌이 없는지 반드시 확인 후, develop으로 merge합니다. 그리고 해당 브랜치는 삭제합니다.
Clone this wiki locally