[DND 동아리][LMS 서비스] Git Commit Convention 및 개발 패턴 설정

 

Git Convention (개발 협약)

 

개발을 진행함에 있어서, 코드 및 작업을 통일화하여, 충돌을 최소화하기 위해 안드로이드 개발자 간에 협악을 정하는 것을 Convention이라고 합니다.

특히, 그 중에서도 Git을 어떤식으로 관리할 지에 대해 정한 약속을 Git Convention이라고 합니다.

 

6-4조는 과외 학습관리시스템(LMS)을 개발하기에 앞서, 안드로이드 개발자끼리 어느정도 개발 협약을 정해놓았습니다.

우선 커밋 컨벤션입니다.

 

✏️ Commit Convention

Head

1. 기능을 태그로 작성한다.
2. 어떤 부분을 수정했는지 표시하기 위해서 태그 뒤에 괄호로 커밋한 기능명을 작성한다.
3. 설명은 대문자, 동사원형으로 작성 시작한다. Tag : Feat, Fix, Design, Rename, Remove, Comment, !HOTFIX

ex) Feat(Review): Add no review screen

Body

1. '어떻게' 변경했는지 보다 '무엇을', '왜' 변경했는지 작성 (방법보다 사유 기술)

Tail(Optional)

Format : '유형(Type): #이슈 번호'

1. 여러 개의 이슈 작성 상황에는 쉼표로 구분
2. 유형 (Type)

형식	의미
Close	이슈 닫음
Fixes	이슈 수정중 (아직 해결되지 않은 이슈)
Ref	참고할 이슈가 있을 때
Resolves	이슈를 해결했을 때 (이슈 닫음)
Related to	해당 커밋에 관련된 이슈번호

 

💡 Github

🌿 Branch 전략

브랜치 카테고리

• master : 제품으로 출시될 수 있는 브랜치
• develop : 다음 출시 버전을 개발하는 브랜치
• feature : 기능을 개발하는 브랜치 (네이밍 : feature/{issue num}-{feature name} ex. feature/17-login), 해당 기능 구현시 상의 후 브랜치 제거

 

'Push/Pull/PR 단계 도식화'

1. 새로운 기능 개발 이전에는 코드 충돌 가능성을 줄이기 위해, 항상 Upstream Repository로부터 Local Repository로 Pull하여 작업을 시작한다.
2. Local Repository에서 작업 완료 시, Origin Repository에 Push 한다.
3. Github에서 Origin Repository에 push한 브랜치를 Upstream Repository로 merge하는 PR(Pull Request)을 생성하고 코드 리뷰를 거친 후 merge 한다.
4. 단, 코드 작성자는 이미 내용을 알고 있기 때문에, 번거로운 작업을 줄이기 위해 committer가 아닌, 상대방이 리뷰한다.

 

Git-flow 채택

'Git flow 도식화'

 

1. 새로운 기능 추가 작업이 있는 경우 develop 브랜치에서 feature 브랜치를 생성한다.
2. feature 브랜치는 언제나 develop 브랜치에서부터 시작한다.
3. 기능 추가 작업이 완료되었다면, feature 브랜치는 develop 브랜치로 merge한다.
4. 버전을 출시할 때에는 master 브랜치에 버전 태그를 추가한다.

Issues 생성 및 관리

1. Naming : 구현 및 수정 기능을 한글로 작성
2. Issues Content(message) : 이슈에 대한 구체적인 내용에 대해 작성한다.
3. 기능 구현 또는 에러 수정시, 이슈를 생성해서 관리한다.

Fork & Pull Request

1. 기능 구현시 Upstream Repository의 Develop branch를 Origin Repository로 Fork하여 코드를 관리한다.
2. 커밋 후 Merge가 필요한 경우, Upstream Repository로 PR을 한 후, 상대방이 코드 검토 후 merge한다.
3. 만약, 수정이 필요한 경우, Committer에게 contact한다.
4. 더 이상 develop 브랜치 필요가 없는 경우, 개발자끼리 상의 후 제거 작업을 진행한다.

위 내용은 서칭을 통해 개발자들이 통상적으로 사용하는 Convention을 저희 팀에 적합하도록 수정한 부분이 있습니다.

또한, 간단하게 개발시 리소스 네이밍에 대한 협약까지 정해보았습니다.

 

📙 File Naming

• Resource

Resource Type	Typing Format
Icon	ic_
Background	bg_
Button	btn_
Image	img_

 

• Layout

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를 만들어 관리한다.)