Github 사용법과 전략

git branch rule

Branch를 생성하기 전 Issue를 먼저 작성한다.

Issue 작성 후 생성되는 번호와 Issue의 간략한 설명 등을 조합하여 Branch의 이름을 결정한다. <Prefix>/<Issue_Number> 의 양식을 따른다.

• main : 개발이 완료된 산출물이 저장될 공간
• develop : feature 브랜치에서 구현된 기능들이 merge될 브랜치
• feature : 기능을 개발하는 브랜치, 이슈별/작업별로 브랜치를 생성하여 기능을 개발한다
• release : 릴리즈를 준비하는 브랜치, 릴리즈 직전 QA 기간에 사용한다
• bug : 버그를 수정하는 브랜치
• hotfix : 정말 급하게, 데모데이 직전에 에러가 난 경우 사용하는 브렌치

git commit message

📍Commit Message

• 🚑️[HOTFIX] : issue나, QA에서 급한 버그 수정에 사용
• 🔨[FIX] : 버그, 오류 해결
• ➕[ADD] : Feat 이외의 부수적인 코드 추가, 라이브러리 추가, 새로운 파일 생성 시
• ✨[FEAT] : 새로운 기능 구현
• ⚰️[DEL] : 쓸모없는 코드 삭제
• 📝[DOCS] : README나 WIKI 등의 문서 개정
• 💄[MOD] : storyboard 파일,UI 수정한 경우
• ✅[CHORE] : 코드 수정, 내부 파일 수정
• ✏️[CORRECT] : 주로 문법의 오류나 타입의 변경, 이름 변경 등에 사용합니다.
• 🚚[MOVE] : 프로젝트 내 파일이나 코드의 이동
• ⏪️[RENAME] : 파일 이름 변경이 있을 때 사용합니다.
• ⚡️[IMPROVE] : 향상이 있을 때 사용합니다.
• ♻️[REFACTOR] : 전면 수정이 있을 때 사용합니다
• 🔀[MERGE]: 다른브렌치를 merge 할 때 사용합니다.

여기에 오늘 말한 한개 추가해서 진행해봐요!

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. 종료된 Issue와 Pull Request의 Label과 Project를 관리한다.