Github Flow 브랜치 전략

Github Flow 브랜치

현재 사내에 정해진 Git 브랜치 전략이 없다.

아마 웹 서비스가 아니라 윈도우 프로그램에 배포 자동화도 이루어져 있지 않은 상태와 인원 문제로 굳이 만들지 않았다고 생각한다.

하지만 다형성을 고려하지 않은 코드로 인해서 커밋때 마다 충돌이 발생하고 에러 추적이 힘들어 브랜치 전략을 도입하려고 한다.

GitFlow , Github Flow 등 여러 브랜치 전략이 있지만 Github Flow 브랜치 전략을 선택하였다.

 

이유는 크게 3가지가 있다.

1. QA 엔지니어가 없고 정식화된 QA 과정이 없다.
2. 인원 2명에서 진행하는 소규모 프로젝트이다.
3. Hotfix 문제가 잦게 발생하는 문제가 있어 빠른 수정 및 배포가 필요

앞으로 진행한 개인 프로젝트에서도 인원이 3명 이하일때는 보통 QA 과정이 없을 확률이 높아 Github Flow를 사용하는 방법을 먼저 알아보자

추후 GitFlow 브랜치 전략도 추가해볼 예정이다.

 

 

1. Github Flow 이란

Github Flow는 Github에서 제안하는 프로젝트 관리 방법이다.

브랜치와 PR 을 활용하여 프로젝트를 관리하는 방법이다.

 

Github Flow는 위 그림과 같이 하나의 마스터 브랜치에서 feature 브랜치를 생성하여 다시 master 브랜치로 merge 하는 형태이다.

위 과정을 요약해보자

• 브랜치를 만든다 (feature 이름)
• 브랜치를 변경
• 커밋 & 푸쉬
• PR 생성
• 코드 리뷰 후 merge
• 사용 브랜치 삭제

기존에 사용을 고려한 GitFlow 브랜치 전략의 경우에는 main - release - develop - feature- hotfix 등 5가지의 브랜치가 존재하고 현재 빠르게 도입하여 팀에 브랜치 전략을 전파해야하는 상황에 적합하지 않다고 판단하였다.

추후 서비스 고도화 및 팀 규모 증가가 되면 브랜치 전략을 변경해야 할 수 도 있다. 하지만 지금은 아니다.

 

2. 사용 방법

시작은 프로젝트 리포지토리를 생성한 상태에서 시작한다.

깃 허브 공식 문서에서는 대부분 Github의 리포지토리에서 웹을 통해서 브랜치를 생성하고 PR을 생성하게끔 되어 있다.

우리팀의 개발자는 대부분 IDE 에서 개발을 하고 바로 커밋을 하거나 터미널을 통해서 커밋 및 푸쉬를 진행하기 때문에 공식 문서는 참고만 하겠다.

 

◼ 브랜치 생성 및 사용

git branch <브랜치 이름>
git checkout <브랜치 이름>

 브랜치를 생성하고 생성한 브랜치로 이동하는 것이다.

✅ 핵심 사항

GithubFlow는 다른 브랜치 전략과 다르고 오직 하나의 feature 브랜치를 다용도로 사용한다.

그렇기 때문에 브랜치의 이름을 굉장히 명확하게 써줄 필요가 있다.

예를 들어보자

리팩토링 : refactory/<소스이름>
기능 개발 : feature/기능이름
수정 : fix/<소스/기능>
긴급 수정 : hotfix/<소스/기능>
개발 문서 : docs/<문서이름

예시처럼 명확하게 이름을 작성하고 브랜치 이름만 보고도 다른 팀원들은 어떤 작업을 수행했는지 예측 가능해야한다.

JIRA를 쓰는 팀에서는 JRAKEY-브랜치명 이런식으로 지라에서 발급한 티켓 번호화 맵핑하는 경우도 있다고 한다.

 

◼ 개발 커밋 및 푸시

커밋 메세지를 적은 커밋 적용

git commit -m "커밋메세지"
git push --set-upstream origin <브랜치이름>

 

아무것도 존재하지 않던 브랜치 목록에서 --set-upstream 옵션을 통해서 push를 진행하면 브랜치가 생성된다.

이제 이렇게 push를 하고 나면 깃 리포지토리에서 PR을 생성하라는 메시지가 생길 것이다.

 

◼ PR 생성

우리는 feature 브랜치와 main 브랜치만 있기 때문에 main으로 PR을 생성한다.

PR 컨벤션은 사내 규칙에 맞춰서 적어주면 된다.

 

◼ 코드 리뷰 후 머지

변경한 소스에 대한 팀원들의 코드 리뷰 이후 모두 Assign이 되면 메인 브랜치에 merge 를 수행한다.

 

✅ Merge 방식 차이

◾ Create merge commit
브랜치를 머지하는 과정에서 새로운 merge 커밋을 생성하는 방법이다.
원본 브랜치와 대상 브랜치의 변경사항을 포함한 새로운 커밋을 만드는 것이다.
두 브랜치를 합친 과정이 명확하게 명시되어야 하는 상황에서 유용하다.

◾ Rebase and merge
대상 브랜치의 변경 사항을 원본 브랜치에 적용하는 방법이다.
대상 브랜치의 커밋들을 원본 브랜치의 최신 커밋 위에 순차배치(rebase) 하여 단일 커밋으로 통합
히스토리가 깔끔하게 유지되어 사용

 

◼ 사용 브랜치 삭제

머지 이후 위 그림처럼 사용한 브랜치를 삭제해주면 된다.

가끔 브랜치가 삭제되지 않는 경우도 있는데 아래 방법으로 해결

 

개인적으로는 로컬에서 삭제하고 푸쉬해서 원격에서도 삭제하는 방법이 편하다.

# 로컬에서 삭제
git branch -d <브랜치 이름>

# 원격지에서 삭제
git push origin -d <브랜치 이름>

이렇게 PR을 생성하고 코드 리뷰를 하고 브랜치를 통해서 프로젝트를 관리하는 방법을 알아보았다.

다음에는 Git flow를 통한 프로젝트 브랜치 관리를 알아보자