Git branch 전략

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

Issue 작성 후 생성되는 번호와 Issue의 간략한 설명 등을 조합하여 Branch의 이름을 결정한다. 

<Prefix>/#<Issue_Number> 의 양식을 따른다.

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

git forking workflow 적용

1. 팀 프로젝트 레포 포크한다.(이하 팀 레포)
2. 포크한 개인 레포(이하 개인 레포)를 클론한다.
3. 개인 레포에서 작업하고 개인 레포의 원격저장소로 푸시한다.
4. 풀리퀘스트를 통해서 팀 레포로 머지한다.
5. 풀받아야 할때는 팀 레포에서 풀 받는다.

[GitHub] GitHub로 협업하는 방법[2] - Forking Workflow - Heee's Development Blog

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를 관리한다. → 자동으로 되도록 처리.

[GitHub] GitHub로 협업하는 방법[3] - Gitflow Workflow - Heee's Development Blog