-
Notifications
You must be signed in to change notification settings - Fork 10
커밋스타일 가이드 📝
Gihyun Cho edited this page Nov 28, 2020
·
7 revisions
-
Tools
- SwiftLint
- SwiftFormat
-
기본 Raywenderlich 스위프트 스타일 가이드 채택
-
일부 Airbnb Swift Style Guide 채택
- Multi-line conditional statements should break after the leading keyword.
- Never use the default case when switching over an enum.
- Name booleans
- Names should be written with their most general part first and their most specific part last.
- Event-handling functions should be named like past-tense sentences.
- Bind to self when upgrading from a weak reference
- Name members of tuples for extra clarity.
- Attributes on the line above the declaration
- Multi-line arrays should have each bracket on a separate line
- Separate long function declarations with line breaks before each argument label and before the return signature.
- Extract complex property observers into methods.
- Prefer immutable values whenever possible
- Computed properties and properties with property observers should appear at the end of the set of declarations of the same kind.
(#issue number) 커밋타입: 제목
Why
1. 이유가 있다면 기술
2. 이유가 있다면 기술
What
1. 무엇을 했는지 기술
2. 무엇을 했는지 기술
- feat: 기능 구현
- feat: (P'Number') 페어프로그래밍 기능구현
- ex) (#1) feat: (P10) 뷰 모델 작성
- fix: 버그 수정
- docs: 문서 수정
- style: 콤마, 세미콜론 추가 제거 (코드 변경사항이 없을 때)
- refactor: 동작의 변경없이 코드 로직만 수정했을때
- chore: 그 외 모든 것들(허드렛일)
- ex) feat: app.js 초기화 로직 추가
- ex) feat: app.js 불필요한 코드 삭제
- ex) refactor: app.js 초기화 로직 수정
- 세부 내용
- 추가(Add, Update): 최초로 파일을 추가할 때
- 수정(Mod): 기존에 있던 로직을 수정했을 때
- 삭제(Remove): 불필요한 로직이나 기능을 삭제했을때
(#5) feat: Mod app.js 초기화 로직 구현
Why
1. ~~하기 때문에
What
1. ~~ 을 했다
- https://doublesprogramming.tistory.com/256