[깃(Git)] 11. 깃플로우(Gitflow)란?

깃(Git)의 전략적 활용

• 보통 하나의 프로젝트에 여러 명의 개발자가 참여한다.
• 같은 직군들이 모인 팀일 수도 있고 프론트엔드, 백엔드, QA 개발자 등 다양한 직군의 개발자들이 함께할 수도 있다.

• 이때 여러 사람이 개발과 테스트를 할 때 어떻게 진행하면 좋을까?

• 가장 간단하게는 하나의 Git 브랜치 위에서 모두가 작업하는 방법이 있다.
• 그러나 리모트 레포지토리(remote repository) 내용은 자주 바뀌게 될 것이며 최신 버전으로 동기화하기 위해 풀(pull)을 하게 되면 수시로 컨플릭트(conflict)가 날 가능성이 높다.

• 또한 브랜치에 내 작업만 있는 것이 아니라, 쉽게 리셋(reset)하기도 어렵다.

• 더 나은 방법은 메인(main) 브랜치를 하나 두고 개개인이 작업할 브랜치를 지속적으로 만들어서 작업하는 것이다.
• 이러면 개인의 작업만 브랜치에 남길 수 있고, 코드의 충돌과 변경에 대한 부담도 덜하다.
• 그리고 해당 브랜치에서 생긴 변경사항들에 대해 리뷰도 받을 수 있다.
• 하지만 사람들이 각자 만드는 브랜치를 관리하기 어려워진다.

• 브랜치 개수는 언제든 늘어날 수 있으며, 브랜치 이름 규칙도 정해지지 않아 관리가 어려워질 수 있다.

• 위와 같은 고민들 끝에, 협업의 관점에서 Git을 효율적으로 운영할 수 있는 전략들이 나오게 되었다.
• 그 중 가장 대표적인 것이 바로 깃플로우(Gitflow)이다.

깃플로우(Gitflow)란?

프로젝트 개발 사이클

• 일반적인 개발 프로젝트 과정을 생각해보면 다음과 같이 대략적인 정형화된 사이클이 있음을 알 수 있다.

1. 필요한 기능을 분석, 정의하고 개발한다.
2. 개발이 완료되면 테스트 환경에 배포한다.
3. 통합 테스트를 진행하며 버그 등 문제가 없는지 확인한다.
4. 문제가 있으면 이를 수정하고 2~3의 과정을 거친다.
5. 테스트 완료 후에 최종적으로 운영 환경에 배포한다.
6. 최종 배포 후 며칠 뒤 심각한 버그를 발견하면 빠르게 수정하여 업데이트된 프로젝트를 배포한다.

• 깃플로우는 이런 사이클을 고려한 하나의 패턴이다.

깃플로우 브랜치 전략

• 깃플로우는 다음과 같이 5개의 브랜치를 두도록 약속한다.

master

• 운영 환경에 최종 배포가 되는 프로젝트를 담는 브랜치이다.

develop

• 아직 배포하지는 않았지만, 기능 개발을 완료한 프로젝트를 담는 브랜치이다.
• master 브랜치로부터 파생된다.

feature

• 필요한 각 기능을 작업하는 브랜치이다.
• 보통 feature/기능으로 브랜치 이름을 짓는다.
  • ex. feature/create_user
• 실제 개발자들은 이 브랜치를 만들어 이 위에서 작업한다.
• develop 브랜치로부터 파생된다.
• 해당 브랜치에서 작업을 완료하면 develop 브랜치로 머지된다.

release

• 최종 배포 전 통합 테스트를 할 프로젝트를 담는 브랜치이다.
• develop 브랜치로부터 파생된다.
• 테스트 중 발견한 버그 수정 역시 release 브랜치에서 이뤄진다.
• 테스트가 완료되면 master 브랜치와 develop 브랜치에 머지된다.

hotfix

• 운영 환경 중 발견된 심각한 버그를 수정할 때 사용하는 브랜치이다.
• master 브랜치로부터 파생된다.
• 버그 수정 후 master 브랜치와 develop 브랜치에 머지된다.

브랜치 흐름

• 전체적인 프로젝트와 브랜치 흐름은 다음처럼 이뤄진다.

1. master 브랜치에서 develop 브랜치를 만든다.
2. 필요한 기능 사항들을 정의하고 개발자들 별로 어떤 기능 개발을 담당할지 정한다.
3. 기능 사항 별로 각 개발자는 develop 브랜치에서 feature 브랜치를 만들어 작업한다.
   • 실제로는 feature/create_user, feature/payment 등 한 번에 개발할 단위로 브랜치를 만든다.
   • 한 사람이 여러 브랜치를 담당할 수 있다.
   • 반대로 한 브랜치에 해당 기능 개발에 참여한 여러 사람이 작업할 수도 있다.
4. feature 브랜치에서 작업 완료 후 리모트 레포지토리에서 푸시하여 팀원들에게 리뷰를 받는다.
5. 리뷰가 완료된 feature 브랜치는 develop 브랜치로 머지한다.
6. 정의했던 기능 사항들을 모두 개발하면 이제 develop 브랜치에서 release 브랜치를 만든다.
7. 이 release 브랜치 위에서 통합 테스트를 진행한다.
8. 보통 회사 내 QA팀이 있으면 QA팀에서 이런 테스트를 진행해준다.
9. 통합 테스트 중 발견된 버그는 release 브랜치 위에서 수정하고 커밋한다.
10. 통합 테스트를 마치면 master 브랜치와 develop 브랜치를 머지한다.
11. 마지막으로 master 브랜치의 최종 커밋에 태그를 달아 프로젝트 버전을 명시한 후 배포한다.
12. 이후에 최종 배포된 프로젝트에 심각한 버그가 발견됐을 때 master 브랜치에서 hotfix 브랜치를 만들어 버그 수정 작업을 한다.
13. 버그 수정 작업 완료 후에는 master 브랜치와 develop 브랜치에 머지한다.
14. 버그 수정이 완료된 master 브랜치의 프로젝트의 최종 커밋에 다시 태그를 달아 프로젝트 버전을 명시한다.

릴리즈 버전

• 팀에서 운영하는 프로젝트는 보통 주기적으로 배포(릴리즈)를 진행할 때마다 최종 커밋에 git tag를 활용해 버전을 붙인다.
• 버전을 기록하는 방식도 Semantic Versioning 같이 몇 가지 대표적인 패턴들이 존재한다.

장단점

장점

1. 브랜치의 이름과 개수를 통일성 있게 가져갈 수 있다.
   • master, develop 브랜치는 항상 존재한다.
2. 브랜치 간 작업 흐름이 명확하다.
   • feature -> develop -> release -> master 로 흐른다.
3. 브랜치를 명확하게 나눴기 때문에 브랜치별로 담당 팀을 명확하게 나눌 수 있다.
   • 예를 들어 feature/user는 유저 관련 팀이, feature/payment는 결제 관련 팀이 담당할 수 있다.
4. QA팀에게 release 브랜치에 있는 프로젝트만 제공할 수 있다.

단점

1. 개발 팀의 규모나 개발 방식에 따라 5개의 브랜치를 관리하는 것이 부담스러울 수 있다.
   • 별도의 QA팀이 없고, 개발 팀이 직접 통합 테스트해야 하는 경우, 굳이 release 브랜치가 필요 없을 수도 있다.
     • develop 브랜치에 있는 내용으로 테스트하고 수정하는 게 더 빠를 수 있다.
2. 프로젝트가 항상 위와 같이 명확한 라이프사이클을 가지는 것은 아니다.
   • 해당 버전에 구체적인 스펙들을 정하고 개발을 하기보단, 필요에 따라 매번 기능을 즉각적으로 테스트하고 배포할 수도 있다.
   • 이 때문에 Gitflow는 주로 소프트웨어 공학론에서 말하는 애자일(agile)한 모델보다는, 폭포수(waterfall) 모델에 어울린다는 평도 있다.

• 실제로는 각 팀에 맞게 깃플로우 전략을 수정하여 사용한다.
• 예를 들어, 각 브랜치 이름을 다르게 둔다거나, release 브랜치를 사용하지 않기도 한다.
• 보통 master, develop, feature 브랜치 개념에 해당하는 식으로 브랜치를 활용하고 있으면 폭넓게 깃플로우라고 부르기도 한다.

참조

• git flow model
• 배달의 민족 블로그 - 우린 Git-flow를 사용하고 있어요
• ujuc님 블로그 - Git flow, GitHub flow, GitLab flow
• kentrick님 블로그 - 다양한 소프트웨어 버전 명명 (Software versioning)