Git Flow

💡Git Flow

📌Git Flow 개념 설명

• 소스코드를 관리하고 출시하기 위한 브랜치 관리 전략 중 하나이다.
• Git Flow에서 사용하는 Branch의 종류는 5가지로 항상 유지되는
  메인 Branch(Master, Develop) 와 일정 기간 유지되는 보조 Branch(feature, release, hostfix) 로 나뉜다.
  • 메인 Branch
    • Master(Main) : 제품으로 출시될 수 있는 브랜치
    • Develop : 다음 출시 버전을 개발하는 브랜치
  • 보조 Branch
    • Feature : 기능을 개발하는 브랜치
    • Release : 이전 출시 버전을 준비하는 브랜치
    • Hostfix : 출시 버전에서 발생한 버그를 수정하는 브랜치

📌Branch 구성

├─ main
├─ develop
├─ develop-FE
	 ├─ feature/1-feat-시작화면-개발
   └─ feature/2-feat-스테이지1-개발
├─ develop-BE
	 ├─ feature/1-feat-사용자ID-개발
   └─ feature/2-feat-스테이지_연결-개발

→ 위의 구성대로 main, develop, develop-FE, develop-BE 총 4개의 브랜치로 작업을 진행할 예정입니다.

*Master branchm, Develop branch, Feature branch만 사용할 예정입니다.
*Release branch, Hotfix branch는 현재 사용하지 않으므로 생성하지 않았습니다.

📌Git Flow 사용 방법 및 규칙

1. 각 개발자는 Issue를 생성한다.
 → FE개발자는 ‘시작화면 개발’ 이름의 Issue를 생성한다.
 → BE개발자는 ‘사용자ID 개발’ 이름의 Issue를 생성한다.
2. 개발자는 각 분야의 develop-FE/BE Branch를 바탕으로 Issue이름 앞에 ‘feature/’를 추가하여 ‘feature/Issue 이름’ 이름의 Branch를 생성한다.
 → FE개발자는 develop-FE Branch를 바탕으로 ‘feature/시작화면-개발’ 이름의 Branch를 생성한다.**
 → BE개발자는 develop-BE Branch를 바탕으로 ‘feature/사용자ID-개발’ 이름의 Branch를 생성한다.**
*Branch명은 Issue 이름과 같으며, 공백 부분이 - 로 바뀐다. 이때 Issue명 앞에 ‘feature/’, ‘bug/’, ‘design/’ 등을 붙여 구분한다.
3. Add - Commit - Push - Pull Request 의 과정을 거친다.
4. Pull Request가 작성되면 작성자 이외의 같은 분야의 팀원이 Code Review를 한다.
 → FE 개발자가 Pull Request를 작성해 올리면 다른 FE 개발자가 Code Review를 한다.
 → BE 개발자가 Pull Request를 작성해 올리면 다른 FE 개발자가 Code Review를 한다.
5. Code Review가 완료되면 Pull Request 작성자가 develop Branch로 merge 한다.
 → FE 개발자라면, develop-FE Branch로 merge한다.
 → BE 개발자라면, develop-BE Branch로 merge한다.
+ merge후 Branch는 삭제하고, Issue는 닫는다.
6. merge된 작업이 있을 경우, 다른 브랜치에서 작업을 진행 중이던 개발자는 본인의 브랜치로 merge된 작업을 Pull 받아온다.
7. 이후 FE, BE 개발자끼리 확인이 완료되었다면 develop-FE Branch와 develop-BE Branch를 develop Branch에 merge한다.
8. 개발이 완료된 후, 모든 팀원은 develop Branch에서 프로젝트 실행 결과를 확인한다.
9. 오류가 없을 경우 최종적으로 main Branch에 merge한다.