팀 협업 룰

브랜치 구조

1. main
2. release
   • 완성된 기능 매주 금요일 Merge
3. dev → feat/refactor/fix…
   • 기능 완성될 때마다 merge
   • 버전 관리 공부해서 해보기

에픽-스토리-태스크

• 스토리 위주로 Issue 생성 후 Task 작성
• Branch 명 = Issue Number

브랜치 생성 방법

  type/#이슈번호
  
  ex) 
  feat/#02
  fix/#05
  add/#08

PR 룰

1. 코드가 잘 작동하는지 로컬에서 병합해서 확인한다.
2. PR을 작성한다.
3. Assignees에 자신을 등록한다.
4. 자신을 제외한 3명에게 리뷰를 요청한다.

리뷰 룰

1. SwiftLint에 맞도록 작성되었는지 확인한다.
2. 코드 개선점이 보인다면 코멘트를 남긴다.
3. 궁금한 점이 있다면 질문을 남긴다.
4. 모든 코멘트가 resolve되었을 때 approve 한다.
5. 마지막에 확인하는 사람이 merge한다.
6. 이슈 요구사항이 모두 완료되었다면 이슈와 브랜치를 만든 사람이 삭제한다.

프로젝트관리

• XcodeGen, Tuist

둘중하나를 도입하자! - xcodproj 파일 충돌 방지를 위함 + 모듈화 용이

• CI/CD
  • Jenkins ?
  • fastlane
  • github action

git kraken 사용하기

새로운걸 써봐야 왜 좋은지 앎

swift format 사용하기

Convention

[[[Xcode Extension] Swift format 설치(format on save 적용하기)

커밋 메시지 작성 방식

👉 로컬에서 수정한 코드를 깃허브에 올리려면 commit을 하게 되는데요, 어떤 부분이 수정되었는지 설명하기 위해 커밋메시지를 작성합니다.

• 해당 작업을 진행하지 않은 사람도 커밋메시지에 요약된 내용만 보고도 무슨 내용인지 추측하게 쉽게끔 작성하는 것이 중요해요!

• 아래와 같은 형식으로 작성하면 됩니다.

  type: title
  
  body
  

• title과 body 사이 한칸 띄워주셔야 합니닷

• type: 어떤 의도로 커밋했는지를 명시합니다

  • type의 종류

    • feat

      → 새로운 기능을 추가했을 경우

      → 이슈에 적힌 작업을 진행했을 때 선택하면 됩니닷

      → 아마 가장 사용할 일이 많을거에요

    • refactor

      → 새로운 기능이나 버그 수정 없이 코드의 모양만 바꿨을 때

      → 변수명 수정이나, 함수 리팩토링 등등 코드 동작의 수정이 없을 때 선택하세요

    • fix

      → 버그 또는 오탈자를 고친 경우!

      → “내가 의도하지 않은 동작이면 모두 다 버그이다”

    • style

      → formatter 수정과 같은 사소한 수정일 때!

      → EX)

      // BEFORE
      Image("Tomato").resizable().scaledToFit()
      
      // AFTER
      Image("Tomato")
      	.resizable()
      	.scaledToFit()

    • chore

      → 코드 수정은 아니고, 프로젝트 관련 환경 설정할 때!

      → 에셋 변경, 폴더 구조 변경이나, 패키지 매니저 설정할 경우

    • docs

      → README 등 문서 관련 수정일 때!

    • remove

      → 사용하지 않는 파일이나 폴더를 삭제할 때!

    • rename

      → 파일이나 폴더명을 수정하는 경우!

• title: 수정한 내용을 모두 포함하는 한 줄로 작성합니다.

• body: 어떻게 했는지가 아닌, 무엇을 왜 했는지를 작성합니다.

  • 꼼꼼하게 쓸수록 좋아용

• EX)

  [Feat] #이슈번호 - 계단 카운트 기능 구현
  
  - 올라갈 때마다 워치에서 측정하는 기능 구현
  - 워치에서 받은 데이터를 아이폰에 연동 성공
  

코드 작성 스타일(린트)

기본적으로 루카스 스위프트 스타일 가이드를 따른다.

함수 매개변수 3개 이상이면 개행

Ctrl + M = 자동 개행 해줌(파라미터 많은 경우)

only_rules:
  - colon
  - fatal_error_message
  - implicitly_unwrapped_optional
  - legacy_cggeometry_functions
  - legacy_constant
  - legacy_constructor
  - legacy_nsgeometry_functions
  - operator_usage_whitespace
  - return_arrow_whitespace
  - trailing_newline
  - unused_optional_binding
  - vertical_whitespace
  - void_return
  - custom_rules
  - line_length
  - identifier_name

excluded:
  - Carthage
  - Pods
  - .build

colon:
  apply_to_dictionaries: false

indentation: 4

line_length: 140

identifier_name:
  min_length:
    warning: 0
    error: 0
  max_length:
    warning: 130
    error: 150
  allowed_symbols:
    - $
    - _
    
custom_rules:
  no_objcMembers:
    name: "@objcMembers"
    regex: "@objcMembers"
    message: "Explicitly use @objc on each member you want to expose to Objective-C"
    severity: error
#  no_direct_standard_out_logs:
#    name: "Writing log messages directly to standard out is disallowed"
#    regex: "(\\bprint|\\bdebugPrint|\\bdump|Swift\\.print|Swift\\.debugPrint|Swift\\.dump)\\s*\\("
#    match_kinds:
#    - identifier
#    message: "Don't commit `print(…)`, `debugPrint(…)`, or `dump(…)` as they write to standard out in release. Either log to a dedicated logging system or silence this warning in debug-only scenarios explicitly using `// swiftlint:disable:next no_direct_standard_out_logs`"
#    severity: warning
  no_file_literal:
    name: "#file is disallowed"
    regex: "(\\b#file\\b)"
    match_kinds:
    - identifier
    message: "Instead of #file, use #fileID"
  no_filepath_literal:
    name: "#filePath is disallowed"
    regex: "(\\b#filePath\\b)"
    match_kinds:
    - identifier
    message: "Instead of #filePath, use #fileID."

문서화 방식

1. 기획자료/학습한 자료는 깃허브 위키에 업로드
2. 회의록도 매일 깃허브 위키로 업로드
3. 트러블슈팅 상황, 원인, 해결방식 정리해서 업로드
4. 백로그(기능적 요소, 비기능적 요소) 업로드
5. 이슈, PR 템플릿 만들기