---

본 포스팅에서는 이전에 간단하게 설명한 Git Flow 전략에 대해 조금 더 자세히 설명하고자 한다.

Git Flow

git 에서 제공하는 강력한 브랜칭 기능을 활용한 변경이력 관리 전략

Git Flow 는 Git 을 사용하여 형상관리 작업을 수행할 때 효율적으로 브랜치를 관리하기 위해 사용되는 브랜치 관리 전략(Branch management strategy) 이다.

여기서 브랜치 모델 (Branch Model) 이란 각각의 브랜치 이름, 임무를 규정한 것으로 브랜치 모델 중 가장 유명한 것이 Vincent Driessen 가 고안해낸 Git Flow 이다.

Git Flow의 Branch

Git Flow 는 프로젝트를 효율적으로 관리하기 위해 Master , Develop , Feature , Release , Hotfix 와 같은 5개의 브랜치로 구분한다.

대부분의 작업은 Feature -> Develop -> Release -> Master 순으로 Merge되며, 각각의 역활은 다음과 같다.

• Feature
  프로젝트의 기능을 정의힌 뒤, 각각의 기능을 Feature 브랜치에 구현한다.
• Develop
  기능 구현을 마친 Feature 브랜치를 Develop 브랜치에 Merge한다.
• Release
  프로젝트의 기능을 구현한 뒤 Release Cycle을 진행하기 위해 Develop 브랜치를 Release 브랜치로 Merge한다.
• Master
  최종 Product를 Release할 때 Release 브랜치를 Master 브랜치로 Merge한 뒤 해당 버전 Tag를 추가한다.
• Hotfix
  Product Release 후 버그가 발생되면 Hotfix 브랜치에서 해결한 뒤, Develop 및 Master 브랜치로 Merge한다.

Git Flow 장점, 단점

Git Flow 의 대표적인 장점과 단점은 다음과 같다.

장점

• 브랜치별로 책임을 명확히 하는 규칙성

• 디테일한 버전 정보 제공

• Master 브랜치는 테스트를 거쳐 최종 수정된 코드로서, 정상적인 상태를 유지할 수 있다.

• 브랜치별 역활이 확고하여, 문제 발생시 각 브랜치를 대기 시킬 필요가 없다.

단점

• 많은 브랜치로 인한 복잡한 규칙

• Release로 인한 많은 동기화 작업

• 애자일의 반복적인 접근법과 Git-Flow의 엄격하고 구체적인 규칙은 충돌 위험이 있다.

---

Git Flow Example

Git Flow전략을 사용 하여 로그인 기능을 구현하는 순서는 다음과 같다.

1. Project Setting

프로젝트 팀장은 아래 명령어를 통해 Develop 브랜치 생성하여 Team Repository 에 Push한다.

git branch develop
git push -u origin develop

이 후 Github Settings 탭에서 default branch 설정한다.

2. Feature Implementation

각각의 팀원은 Team Repository를 Clone한 뒤, 브랜치를 생성하여 기능을 구현한다.

git switch -c Feature/Login

~~~ 기능 구현
git add .
git commit -m 'Feat: Login page'

3. Push to Remote Branch

기능을 정상적으로 구현한 뒤 작업이 끝난 로컬 브랜치를 원격 브랜치로 Push 한다.

git push -u origin Feature/Login

이 때 원격으로 푸쉬된 브랜치는 Compare & Pull Request 되며, 추가로 해당 브랜치의 기능 및 연관된 이슈를 작성한다.

4. Code Review

Pull Request 가 정상적으로 완료되면 프로젝트의 팀원들은 Code Review 과정을 거쳐 Comment , Approve , Request changes 중 응답을 선택한다.

5. Delete Branch

Code Review 를 통과한 Feature 는 Develop 브랜치로 Merge 하여 병합한 뒤 삭제한다.

이 후 로컬 Feature 브랜치를 삭제한 뒤 Develop 브랜치를 원격의 Develop 브랜치와 동일하게 위치시키기 위해 Pull 한다.

git switch develop
git branch -d Feature/Login
git pull

---

Conflict Resolution

Git Flow Example 의 3. Push to Remote Branch 과정에서 팀원과의 코드 충돌이 발생한다면 다음과 같이 해결할 수 있다.

1. Pull Branch

로컬의 Develop 브랜치에서 변경된 원격의 코드를 Pull한다.

git pull

2. Merge with Develop Branch

Feature 브랜치로 이동하여 Develop 를 Merge 하면 다음과 같이 충돌된 문제를 확인할 수 있다.

상황에 맞게 옵션을 선택한 뒤 문제를 해결한다.

3. Push Feature Branch

문제를 해결한 뒤 다시 Commit 하여 로컬의 Feature Branch 를 원격으로 Push 한다.

git add .
git commit -m 'Fix: Conflict resolution'
git push -u origin Feature/Login

---

Commit Message Convention

Commit Message Convention 은 협업 과정에서 발생할 수 있는 커뮤니케이션 문제를 방지하기 위해 사용된다.

기본적인 커밋 메시지 구조는 다음과 같다.

제목 (Type: Subject)

본문 (Body)

꼬리말 (Footer)

Commit Type

Commit Message Convention 제목에 사용되는 Commit Type 의 종류는 다음과 같다.

Tag Name	Description
Feat	새로운 기능 추가
Fix	버그 수정
Design	사용자 UI 디자인 변경
!BREAKING CHANGE	커다란 API 변경
!HOTFIX	치명적인 버그 수정
Style	코드 포맷 변경, 세미 콜론 누락...등등
Refactor	프로덕션 코드 리팩토링
Comment	주석 추가 및 변경
Docs	문서 수정
Test	기능, 리팩토링 테스트...등등
Chore	빌드 수정, 패키지 매니저 수정, 패키지 관리자 구성...등의 업데이트
Rename	파일 구조 변경, 폴더명 수정
Remove	파일 삭제

Subject

Commit Message Convention 제목에 사용되는 Subject 는 50글자 이내로 작성하며, 첫글자는 대문자를 사용한다.

또한 마침표, 특수기호는 사용하지 않고 영문으로 작성하는 경우에는 동사(원형)를 가장 앞에 명령어로 작성한다.

최대한 간결하고 요점적인 개조식 구문으로 작성하는 것이 좋다.

Feat: Add login form
Rename: Modify login page name

Body

Commit Message Convention 본문 에 사용되는 Body 는 72이내로 최대한 상세히 작성한다.

코드 변경의 이유는 명확할수록 좋으며, 어떻게 변경했는지보다 무엇을, 왜 변경했는지에 초점을 맞춰 작성한다.

Footer

Commit Message Convention 꼬리말에 사용되는 Footer 는 선택사항으로 issue tracker ID 명시하는 경우에 작성한다.

'#이슈 번호' 형식으로 작성하며 여러 개의 이슈번호는 쉼표(,)로 구분한다.

이슈 트래커 유형은 다음과 같다.

• Fixes: 이슈 수정
• Resolves: 이슈를 해결
• Ref: 참고 이슈
• Related to: 커밋과 관련된 이슈

Fixes: #7
Related to: #8, #9, #10

Example

Commit Message Convention 을 참고한 예제는 다음과 같다.

Feat: 게시글 작성 기능 구현

다음 항목을 구현
* 포스팅 max-length 제한
* 이미지 업로드

Resolves: #32
Ref: #41
Related to: #35, #36

---

참고 자료

Udacity Git Commit Message Style Guide
깃&깃헙 브랜치 3개로 협업하기(주니어개발자 팀프로젝트)