-
Notifications
You must be signed in to change notification settings - Fork 0
1. Git 사용법
기본적으로 Git Flow 전략을 이용한다. 작업 시작 시 선행되어야 할 작업은 다음과 같다.
1. Issue를 생성한다.
2. feature Branch를 생성한다.
3. Add - Commit - Push - Pull Request 의 과정을 거친다.
4. Pull Request가 작성되면 작성자 이외의 다른 팀원이 Code Review를 한다.
5. Code Review가 완료되면 Pull Request 작성자가 develop Branch로 merge 한다.
6. merge된 작업이 있을 경우, 다른 브랜치에서 작업을 진행 중이던 개발자는 본인의 브랜치로 merge된 작업을 Pull 받아온다.
7. 종료된 Issue와 Pull Request의 Label과 Project를 관리한다.
협업 시 준수해야 할 규칙은 다음과 같다.
1. develop에서의 작업은 원칙적으로 금지한다. 단, README 작성은 develop Branch에서 수행한다.
2. 자신이 담당한 부분 이외에 다른 팀원이 담당한 부분을 수정할 때에는 Slack을 통해 변경 사항을 전달한다.
3. 본인의 Pull Request는 본인이 Merge한다.
4. 빠른 협업 속도를 위해 Pull Request가 올라온 이후 24시간 내에 Code Review를 수행한다.
5. Commit, Push, Merge, Pull Request 등 모든 작업은 앱이 정상적으로 실행되는 지 확인 후 수행한다.
6. README 수정을 위한 Commit 도배는 금지한다. 미리보기는 Preview를 통해 확인한다.
Branch의 Naming Rule은 1.2.1을 따른다. Branch는 가능한 한 작업단위, 기능단위로 생성하며 이는 Issue를 기반으로 한다. 단, 같은 범위의 기능이라면 같은 브랜치를 사용한다. 예를 들면, 회원가입 기능 구현 시 아이디 중복 체크, 비밀번호 확인, 아이디 유효성 확인 등은 회원가입 하나로 구분한다.
Branch를 생성하기 전 Issue를 먼저 작성한다. Issue 작성 후 생성되는 번호와 Issue의 간략한 설명 등을 조합하여 Branch의 이름을 결정한다. <Prefix>/<Issue_Number>-<Description> 의 양식을 따른다.
-
main: 개발이 완료된 산출물이 저장될 공간 -
develop: feature 브랜치에서 구현된 기능들이 merge될 브랜치 -
feature: 기능을 개발하는 브랜치, 이슈별/작업별로 브랜치를 생성하여 기능을 개발한다 -
release: 릴리즈를 준비하는 브랜치, 릴리즈 직전 QA 기간에 사용한다 -
hotfix: 버그를 수정하는 브랜치
main
develop/v1.0.0
feature/10-sign-up
release/v1.0.0
hotfix/11-main-activty-bug
작업 시작 전 Issue 생성이 선행되어야 한다. Issue는 작업 단위, 기능 단위로 생성하며 생성 후 표시되는 Issue Number를 참조하여 Branch Name과 Commit Message를 작성한다.
이슈의 제목에는 기능의 대표적인 설명을 적고, 내용에는 세부적인 내용 및 작업 진행 상황을 작성한다.
이슈 생성 시 Github 오른편의 Assignee, Label, Project, Linked Pull Requests 를 적용한다. Assignee는 해당 이슈의 담당자, Label에는 담당자, TODO, 우선순위 등의 Label을 추가한다. 작업 대기중인 Issue에는 TODO, 작업 진행 중이면 In Progress를, 완료된 Issue에는 complete Label을 추가한다.
[<PREFIX>] <Description> 의 양식을 준수하되, Prefix는 협업하며 맞춰가기로 한다. 또한 Prefix는 대문자를 사용한다.
[FEAT] 회원가입 구현
[DEBUG] MainActivity 버그 수정
[STYLE] 폰트 변경
Commit Message는 영어로 작성하는 것을 원칙으로 하되, 의미 전달이 어려운 경우 한글을 사용한다. Commit Message Convention은 다음 [1] 을 따른다.
[1] https://github.com/4z7l/Today-I-Learned/blob/master/Git/GitCommitConvention.md 참고.
[<PREFIX>] <Issue_Number> - <Description> 의 양식을 준수한다.
-
FIX : 버그, 오류 해결
[FIX] #10 - callback error -
ADD : Feat 이외의 부수적인 코드 추가, 라이브러리 추가, 새로운 View나 Activity 생성
[ADD] #11 - LoginActivity[ADD] #12 - CircleImageView Library -
FEAT : 새로운 기능 구현
[FEAT] #11 - google login - UPDATE : 기능 수정
-
DEL : 쓸모없는 코드 삭제
[DEL] #12 - unnecessary import package -
DOCS : README나 WIKI 등의 문서 개정
[DOCS] update readme -
REFACTOR : 내부 로직은 변경 하지 않고 기존의 코드를 개선하는 리팩토링 시
[REFACTOR] #15 - MVP architecture to MVVM -
CHORE : 그 이외의 잡일/ 버전 코드 수정, 패키지 구조 변경, 파일 이동, 가독성이나 변수명, reformat 등
[CHORE] #20 - delete unnecessary import package[CHORE] #21 - reformat MainActivity -
UI : xml 파일 작성, 수정한 경우
[UI] #30 - use constraintlayout in activity_main.xml - TEST : 테스트 코드 추가
## 🌳 내용
> 상세 내용
## 🍀 Progress
- [ ] todo1
- [ ] todo2
- [ ] todo3
develop, main으로 merge할 때에는 Pull Request와 다른 팀원의 Code Review가 필요하다. Pull Request의 내용에는 변경된 사항에 대한 설명이 작성되어야 하며, View에 관한 수정이 있는 경우 스크린샷을 함께 첨부한다.
## 🌳 관련 이슈
close #1
## 🍀 PR Point
- DI
- Base Activity, Base Fragment
- 라이브러리 세팅
- 바텀 네비게이션 세팅
- 기타 뷰 세팅
<img src = "..." width = 400>
Merge를 위해 Pull Request에 대한 팀원들의 Code Review를 수행한다. Code Review는 변경 사항에 대해 궁금한 점, 코드 가독성(변수명, 함수명 등)에 대한 조언 등을 작성한다. Code Review는 존댓말로 하며, 일방적인 시비나 비난은 금지한다. Pull Request 작성자는 Code Review에 대해 성실히 답변한다.
Issue, Pull Request를 한 눈에 파악하기 위해 Label을 추가한다. 필수적으로 추가되어야 할 Label은 Assignee, TODO/In Progress/Complete, 우선순위 이다.
-
Assignee: 담당자의 Github 아이디 -
TODO/In Progress/Complete: Issue 혹은 Pull Request의 진행 상황, 진행 상황이 변경되면 기존의 Label을 삭제하고 새로운 Label을 부여한다. -
우선순위: 기본적으로 0순위~3순위로 구분하며 각 우선순위는P0,P1,P2,P3등으로 표기한다.
각 Repository에 대한 진행 상황을 파악하기 위해 Project를 이용한다.
Project Rule, Coding Convention, 회의록 등에 관한 내용은 WIKI에서 작성한다. 가독성을 위해 목차도 함께 작성한다. 목차는 모든 내용이 작성된 후 Generator를 통해 쉽게 작성할 수 있다.