[Git] Git flow와 merge with rebase 전략

원래 회사에서 main - develop - feature라는 단순한 브랜치 모델을 사용 했었는데, 몇달 전에 git flow를 도입했다. 그에 대한 내용을 정리해보려고 한다. 

0. 왜 Git flow를 도입하게 되었는가?

단순 브랜치 모델을 사용했던 이유는 팀이 작아서 간단한 브랜치 구조로도 관리가 쉬웠기 때문이다. 하지만 팀원이 늘어나면서 기능을 병행해서 개발할 때 복잡한 충돌이 날 가능성이 있고, 장기적으로 봤을 때 git flow를 사용하는게 더 좋지 않겠냐는 제안을 받아 git flow를 사용하게 되었다.

1. Git Flow와 브랜치 전략

Git flow는 기능 개발, 버그 수정, 릴리즈 준비 등을 체계적으로 관리하기 위한 브랜치 모델이다. 주요 브랜치는 다음과 같다.

• main (master): 배포 가능한 상태를 유지하는 브랜치.
• develop: 다음 릴리즈를 개발하는 브랜치로, 기능 브랜치들이 합쳐지는 곳.
• feature: 새로운 기능을 개발하기 위한 브랜치로, 작업이 끝나면 develop 브랜치로 병합된다.
• release: 릴리즈 준비가 완료되면 release 브랜치에서 최종적인 버그 수정 등을 거쳐 main 브랜치로 병합된다.
• hotfix: 긴급 버그 수정을 위해 main에서 바로 따로 분기하여 문제를 수정하고, develop과 main에 병합된다.

출처: https://techblog.woowahan.com/2553/

2. Merge 전략

merge는 두 브랜치를 통합하는 방법으로, 보통 새로운 커밋을 생성하여 두 브랜치의 작업을 합치는 방식이다. Git flow에서는 feature 브랜치를 develop 브랜치로 병합할 때 주로 merge를 사용한다. 주로 협업 중에 여러 사람이 동시에 여러 feature 브랜치에서 작업을 하게될 때 사용하면 좋다.

• 장점:
  • 두 브랜치를 합칠 때 기록이 명확하게 남는다.
  • 충돌이 발생했을 때, 쉽게 해결할 수 있는 커밋 히스토리를 유지할 수 있다.
• 단점:
  • merge를 했다는 기록으로 인해 커밋 히스토리가 복잡해질 수 있다.
• 사용법:

# 현재 feature/test에 있다고 할 때

git checkout develop
git merge feature/test

3. Rebase 전략

rebase는 하나의 브랜치에 있는 커밋을 다른 브랜치 위로 재정렬하는 방법이다. 커밋을 병합하면서 중간에 새로 커밋을 추가하지 않고, 커밋 히스토리를 깔끔하게 유지할 수 있다.

• 장점:
  • 히스토리가 깔끔하게 유지된다.
  • 불필요한 merge 커밋이 생기지 않는다.
• 단점:
  • 협업 중에는 충돌을 해결하기 까다로울 수 있으며, 브랜치 히스토리가 뒤섞일 수 있다.
• 사용법: 

git checkout feature/test2
git rebase develop

4. Merge와 Rebase를 동시에 사용해 관리하기

여기서 Merge와 Rebase를 동시에 관리하는 방법이 있다. develop의 최신 커밋을 지속적으로 rebase함으로써 팀원들과 충돌이 나는 부분을 수정해 나가면서 git의 그래프를 깔끔하게 만들고 merge를 하는 방법이다.

• 장점:
  • git flow전략의 핵심인 히스토리가 깔끔하게 유지된다.
• 단점:
  
  • 브랜치가 꼬일 경우 그래프를 다시 깔끔하게 만들기 까다롭다.
• 사용법:

feature/test 브랜치에서 작업을 완료하고 push

# 현재 feature/test 브랜치에서 작업을 완료한 상태

git add .
git commit -m "feat: feature/test"

git push origin feature/test  # (원격 저장소에 올리는 경우 - 꼭 올릴 필요는 없음)

원격 저장소 업데이트 확인 (선택)

git fetch

 

develop 브랜치로 이동 후 git pull로 최신 커밋 병합

git checkout develop
git pull origin develop

feature/test 브랜치로 돌아가서 rebase develop 실행 (여기서 feature/test의 커밋들을 develop의 최신 커밋 위로 재정렬 함)

git checkout feature/test
git rebase develop

develop 브랜치로 이동 후 --no-ff 옵션을 사용해 merge

(--no-ff옵션을 사용하면 git이 강제로 병합 커밋을 만들어준다. 이로인해 어떤 브랜치가 언제 병합되었는지 명확하게 히스토리 상에 기록된다. - 어떤 흐름으로 develop 또는 main 브랜치에 병합되었는지 쉽게 파악이 가능해진다는 뜻)

git checkout develop
git merge feature/test --no-ff

feature/test 브랜치 삭제

 

git branch -d feature/test 
git push origin --delete feature/test  # (원격에서 feature/test 브랜치 삭제, 필요시)

이 과정을 거치면 feature/test 브랜치의 작업이 깔끔하게 develop 브랜치로 병합이 되며, 릴리즈나 main에도 이 방법을 적용해 히스토리를 각 flow마다 깔끔하게 관리 할 수 있다.