Convention
개발을 진행함에 있어, 코드 및 작업을 통일화하여, 충돌을 최소화하기 위해 안드로이드 개발자간에 Convention(협약)을 설정하였습니다.
차후 기존 Convention은 추가되거나 수정 또는 제거될 수도 있으며, 원활하고 매끄러운 작업을 위해 언제든 새로운 의견을 제시할 수 있습니다.
| Resource Type | Typing Format |
|---|---|
| Icon | ic_ |
| Background | bg_ |
| Button | btn_ |
| Image | img_ |
| Selector | selector_ |
| Layout Type | Typing Format |
|---|---|
| Activity | activity_ |
| Fragment | fragment_ |
| Dialog | dialog_ |
| List Item | item_ |
| Normal View | view_ |
| Package | Under case |
| Color, String | Under bar(_) 표기법 |
| Class, Variable, Method | Camel 표기법 |
(단, 빈도가 높은 로직들은 Method를 만들어 관리한다.)
- 기능을 태그로 작성한다.
- 어떤 부분을 수정했는지 표시하기 위해서 태그 뒤에 괄호로 커밋한 기능명을 작성한다.
- 설명은 대문자, 동사원형으로 작성 시작한다. Tag : Feat, Fix, Design, Rename, Remove, Comment, !HOTFIX, Docs
ex) Feat(Review): Add no review screen
- '어떻게' 변경했는지 보다 '무엇을', '왜' 변경했는지 작성 (방법보다 사유 기술)
Format : '유형(Type): #이슈 번호'
- 여러 개의 이슈 작성 상황에는 쉼표로 구분
- 유형 (Type)
ex) close : #12
| 유형 | 의미 |
|---|---|
| Close | 이슈 닫음 |
| Fixes | 이슈 수정중 (아직 해결되지 않은 이슈) |
| Ref | 참고할 이슈가 있을 때 |
| Resolves | 이슈를 해결했을 때 (이슈 닫음) |
| Related to | 해당 커밋에 관련된 이슈번호 |
- master : 제품으로 출시될 수 있는 브랜치
- develop : 다음 출시 버전을 개발하는 브랜치
- feature : 기능을 개발하는 브랜치 (네이밍 : feature/{issue num}-{feature name} ex. feature/17-login), 해당 기능 구현시 상의 후 브랜치 제거
- 새로운 기능 개발 이전에는 코드 충돌 가능성을 줄이기 위해, 항상 Upstream Repository로부터 Local Repository로 Pull하여 작업을 시작한다.
- Local Repository에서 작업 완료 시, Origin Repository에 Push 한다.
- Github에서 Origin Repository에 push한 브랜치를 Upstream Repository로 merge하는 PR(Pull Request)을 생성하고 코드 리뷰를 거친 후 merge 한다.
- 단, 코드 작성자는 이미 내용을 알고 있기 때문에, 번거로운 작업을 줄이기 위해 committer가 아닌, 상대방이 리뷰한다.
- 새로운 기능 추가 작업이 있는 경우 develop 브랜치에서 feature 브랜치를 생성한다.
- feature 브랜치는 언제나 develop 브랜치에서부터 시작한다.
- 기능 추가 작업이 완료되었다면, feature 브랜치는 develop 브랜치로 merge한다.
- 버전을 출시할 때에는 master 브랜치에 버전 태그를 추가한다.
- Naming : 구현 및 수정 기능을 한글로 작성
- Issues Content(message) : 이슈에 대한 구체적인 내용에 대해 작성한다.
- 기능 구현 또는 에러 수정시, 이슈를 생성해서 관리한다.
- 기능 구현시 Upstream Repository의 Develop branch를 Origin Repository로 Fork하여 코드를 관리한다.
- 커밋 후 Merge가 필요한 경우, Upstream Repository로 PR을 한 후, 상대방이 코드 검토 후 merge한다.
- 만약, 수정이 필요한 경우, Committer에게 contact한다.
- 더 이상 develop 브랜치 필요가 없는 경우, 개발자끼리 상의 후 제거 작업을 진행한다.