2. 브랜치 전략(Branching Strategy) 세우기

브랜치 전략을 사용하는 이유와 다양한 전략들(Git Flow, GitHub Flow, GitLab Flow, Trunk-based development)을 알아봅시다

Table Of Contents

0. 제 Git Graph 한번씩 보고 가세요~

1. git graph

지금까지 했던 프로젝트 중에 Git Branch 관리가 제일 잘 됐다고 생각하는 프로젝트의 Git Graph에요😘

파란색 라인이 main, 핑크색이 develop이고 나머지 브랜치들은 feature/... 브랜치로, 각각의 브랜치에서 작업을 하다가 dev로 머지되는 모습이에요!

물론 이게 항상 정답은 아니고, 저 프로젝트는 코드 리뷰를 받는 1인 프로젝트였기 때문에 이런 식으로 관리가 됐었답니다...!

1. Git Branch 대충 쓰면 안되나요?

안될 건 없죠!

Git 브랜치 전략 없이도 프로젝트는 잘 굴러갈 수 있습니다🤗

 

하지만, 프로젝트가 커지고 여러 개발자들과 협업해야 하는 경우에는 Git Branch를 사용하면 충분한 이점을 얻을 수 있어요.

오히려 브랜치 전략이 없다면 이런 혼란을 겪을 수 있답니다!

  • 여러 개발자가 한 브랜치에서 작업하면 충돌(conflict)이 자주 발생해요. 충돌을 해결하는 데에 많은 비용이 들고, 실수로 코드가 손상될 수 있어요.
  • main 브랜치에 바로 커밋하는 경우, 충분한 테스트를 거치지 않아 잘못되거나 좋지 못한 코드가 배포될 수 있어요.
  • 브랜치를 구분하지 않으면 작업 내역을 추적하기 어려워요.

따라서 팀 프로젝트에서는 브랜치 전략을 꼭 세우고 가는 걸 추천해요!

2. 브랜치 전략이 뭐에요?

브랜치 전략이란, Git에서 브랜치를 관리하고 사용하는 방법에 대한 규칙이에요.

위에서 언급한 문제점들을 해결해 협업을 원활히 할 수 있도록 도와줍니다!

 

다행히도 사람들이 많이 이용하는 브랜치 전략들이 있어요!. 대표적인 브랜치 전략들을 공부해보고, 원하는 방법을 고르거나, 아래 방법들을 개량해서 사용하면 좋을거에요🥰

2. 1. Git Flow

Vincent Driessen이 제안한 Git 브랜치 전략이에요. 처음 보면 언뜻 어려워 보일 수 있지만, main과 develop을 두고, 상황에 따라 release, feature, hotfix 브랜치를 만들어 운영한다는 걸 기억하면 좋아요.

2. 1. 1. 브랜치 소개

Git Flow에서는 main 브랜치만 두지 않고, main(혹은 master)과 develop 브랜치를 모두 사용해요. 또한, 때에 따라 feature, release, hotfix 브랜치들이 생기고 사라지는 구조에요.

  • main 브랜치는 제품의 배포 버전을 관리해요. 따라서 항상 안정적인 상태여야 하고, 직접 커밋을 올리는 것은 비허용해야 해요! release 또는 hotfix 브랜치에서 merge하는 방식으로 변경 사항이 반영된답니다!
  • develop 브랜치는 다음 배포를 준비하는 브랜치에요. feature 브랜치에서 개발한 작업들은 develop 브랜치로 merge됩니다!
  • feature 브랜치는 새 기능이나 특정 작업을 수행하기 위한 브랜치에요. feature 브랜치는 develop에서 따와서 생성해야 하고, 작업을 마치면 다시 develop 브랜치로 merge합니다!
  • release 브랜치는 배포 준비를 위한 브랜치에요. develop에서 따와서 생성해야 하고, 테스트나 버그 수정 등의 작업을 할 수 있어요. 테스트나 버그 수정이 끝나서 안정되었다고 생각하면, main과 develop으로 merge해요!
  • hotfix 브랜치는 배포를 이미 마쳤는데 발견된 긴급한 수정 사항 을 반영하기 위한 브랜치에요. 따라서 main에서 따와서 생성하게 되고, 수정을 완료하면 main과 develop으로 merge해요!

2. 1. 2. 사용 예시

2. git flow

이건 Git Flow를 나타내는 그림 중 굉장히 유명한 그림이에요!

어떤 브랜치들이 사용되는지 간략하게 알아봤으니, 위 그림으로 사용 예시를 한번 살펴보도록 해요!

  1. 프로젝트 시작
    • 처음에는 main(파랑)과 develop(노랑) 브랜치가 존재해요. 현재 버전은 0.1을 가리키고 있네요.
  2. feature 브랜치 생성
    • 새 기능이 필요하면 feature/기능-이름처럼 새로운 브랜치를 만들어줘요. 분홍색 브랜치가 새로 생겼죠?
    • 만약 기능 개발이 끝난다면 다시 develop으로 merge해줘요.
  3. release 준비
    • develop 브랜치의 작업이 완료되면, release/버전-이름 브랜치를 생성해요. develop에서 새로운 초록 브랜치가 생겼습니다.
    • release 브랜치에서 qa 등의 테스트를 하고, 버그가 있다면 수정해요.
    • 지금은 버전 1.0 release를 위한 준비를 하고 있어요.
  4. main으로 배포
    • 문제가 없는 걸 확인하면 release 브랜치를 main으로 merge해요. 이제 1.0 버전이 main으로 올라왔어요!
    • 이 과정을 반복해요.
  5. hotfix
    • 만약 main 브랜치에서 문제를 발견하면, hotfix/버전-이름 브랜치를 생성해요.
    • 위 그림에서는 0.1 버전에서 문제를 발견했기 때문에 hotfix/0.2라는 브랜치를 만들었네요!
    • cf) 이렇게 숫자로 버전을 관리하는 방법을 Semantic Versioning, 의미적 버전 관리라고 해요. 자세한 내용은 포스트를 참고하면 좋아요!
    • 문제점을 모두 수정했다면, main과 develop으로 merge해서 수정 사항을 반영해줘요.

2. 1. 3. 장단점

Git Flow의 장단점 또한 알아볼까요?

  • 장점 👍
    • 각 브랜치의 역할이 명확해서 작업 흐름을 보기 편리해요.
    • 배포 준비를 단계적으로 수행할 수 있어요.
  • 단점 👎
    • 브랜치가 많아 관리가 어려울 수 있어요.
    • 배포 주기가 빠른 경우, 단계가 많아 비효율적일 수 있어요.

2. 1. 4. CLI 도구 git-flow 사용하기

Git Flow를 쉽게 사용할 수 있도록 해 주는 git-flow라는 CLI 도구가 있어요. 또한, 이를 패치한 git-flow (AVH Edition)이 존재한답니다!

git-flow-avh를 이용하여 프로젝트를 세팅하는 방법은 cheatsheet나 git-flow wiki에 더 자세히 나와 있어요! (Git Flow 부분이 너무 길어지는 것 같아 줄이는거 맞습니다😭)

2. 2. GitHub Flow

GitHub Flow는 GitHub의 워크플로우를 기반으로 한 브랜치 전략이에요.

Git Flow보다는 간단하고, 배포가 빠르다는 점이 특징이랍니다!🤗

2. 2. 1. 브랜치 소개

  • main 브랜치는 항상 배포 가능한, 안정된 상태를 유지해요. Git Flow와 마찬가지로, main에는 직접 커밋을 하지 않고, Pull Request(PR)을 통해서만 변경 사힝이 반영되어야 해요.
  • feature 브랜치에서는 다른 모든 작업들을 수행해요. main에서 따와서 feature/기능-이름처럼 생성하고, 작업이 완료되면 다시 main으로 PR을 보내 변경 사항을 적용해줍니다!

2. 2. 2. Pull Request

이렇게 2종류의 브랜치만 가지고 운영되기 때문에, GitHub Flow에서는 Pull Request의 역할이 매우 중요해요! 잘못하면 오류가 있는 코드가 main으로 바로 들어가버리니까요🥲

merge 준비가 완료된 경우, PR을 생성해 코드를 공유하고, 다른 사람의 리뷰를 받아야 해요.

논의가 끝나 코드가 안정되었다고 생각하는 경우, main으로 merge가 일어난답니다!

2. 2. 3. 장단점

GitHub Flow의 장단점도 알아보기로해요!

  • 장점 👍
    • 브랜치 구조가 간단해 관리와 이해가 쉬워요.
    • 배포를 위한 단계가 적어 빠른 배포가 가능해요. 배포 주기가 짧고나 피드백이 바로바로 반영되어야 하는 경우에 적합해요!
  • 단점 👎
    • main 브랜치가 항상 배포 가능한 상태여야 하기 때문에, 코드에 오류가 없는지 테스트가 확실하게 이루어져야 해요.
    • 모든 변경 사항이 main 브랜치에 merge되기 때문에 작은 실수가 main에 들어가기 쉬워요.

따라서 비교적 소규모 프로젝트나 단순한 프로젝트에서 사용하기 좋고, 대규모 프로젝트나 큰 작업이 많은 경우, 그리고 QA 작업이 필요한 경우에는 적용하기 어려워요!

2. 3. GitLab Flow

GitLab Flow 역시 GitHub Flow처럼 GitLab의 워크플로우를 기반으로 한 브랜치 전략이에요.

GitHub Flow는 main에 변경 사항이 있을 때마다 배포한다고 가정해요. GitLab Flow는 main에서 바로 배포가 이루어지는 대신에, 환경 브랜치들을 만들어 단계적으로 배포를 조절할 수 있어요.

2. 3. 1. 브랜치 소개

GitLab Flow는 브랜치를 main, 기능 브랜치들(feature), 환경 브랜치들(environment), 릴리즈 브랜치들(release)로 구분하는 점이 특징이에요.

  • main은 모든 기능이 merge되고, 배포가 준비된 브랜치에요!
  • feature 브랜치들에서는 새로운 기능을 구현하거나 버그를 수정해요. main에서 따와 feature/기능-이름처럼 생성하고, 작업을 완료하면 다시 main으로 merge하면 돼요.
  • 환경 브랜치들은 실제 배포되는 환경에 대응하는 브랜치들이에요. 여러 배포 환경을 관리하기 위해 staging, pre-prod, production같은 환경 브랜치를 만들 수 있어요.
    • staging 브랜치는 스테이징 환경 베포에 대응하는 브랜치에요. 스테이징 환경은 실제 사용 환경과 비슷하게 설정한 테스트 환경이에요. 새로 개발한 기능이나 수정 사항을 반영하고, 최종적으로 배포하기 전에 테스트해봐야 해요. 주로 이 단게에서 QA를 수행하게 돼요. 보통 실제 데이터가 아니라 샘플 데이터를 사용한답니다! 스테이징 단계에서 문제가 없다면 pre-prod 브랜치로 merge해요.
    • pre-prod 브랜치는 프리프로덕션 환경 배포에 대응하는 브랜치에요. 프리프로덕션 환경은 실제 사용 환경과 거의 동일한 환경이에요. 배포 전 마지막으로 문제를 점검할 수 있어요. 프로덕션에 배포하기 전에 실제와 비슷한 데이터로 실험해 보기도 해요. 문제가 없는 걸 확인하면 production 브랜치로 merge애요.
    • production 브랜치는 실제로 사용자가 사용하는 배포 환경에 대응해요.
  • release 브랜치들은 외부로 소프트웨어를 배포해야 할 때 사용해요. 각 브랜치들은 2.3-stable, 2.4-stable처럼 minor 버전을 나타내요.

또한, hotfix가 생기면 production에 먼저 반영하고, downstream 방식으로 production → pre-prod → staging → main 순서로 반영시키게 돼요.

2. 3. 2. 장단점

  • 장점 👍
    • 다양한 환경 브랜치를 이용하기 때문에, 배포 타이밍을 더 자세하게 조절할 수 있어요.
    • 다양한 환경 브랜치를 이용해서 기능을 안정적으로 테스트할 수 있어요.
    • Git Flow에 비해 브랜치 구조가 덜 복잡해요.
  • 단점 👎
    • GitHub Flow에 비해서는 복잡하기 때문에 설정에 시간이 더 걸릴 수 있어요.
    • 배포되는 브랜치가 더 많기 때문에, CI/CD 설정까지 같이 해야 더 효율적으로 사용할 수 있어요.

2. 4. Trunk-based development

Trunk-based development(TBD, 트렁크 기반 개발)는 모든 개발자들이 하나의 메인 브랜치(main 또는 trunk)를 베이스로 작업해요. 기능 개발은 가능한 작은 단위로 나누고, 작은 양의 빈번한 업데이트를 merge하게 돼요.

2. 4. 2. 장단점

  • 장점 👍
    • 변경 사항이 빠르게 배포되기 때문에, 피드백을 빠르게 받을 수 있어요.
    • 브랜치 구조가 간단하기 때문에 코드베이스 관리가 쉬워요.
    • 모든 개발자가 같은 브랜치에서 작업하기 때문에 소통이 편해요.
  • 단점 👎
    • 새로운 코드가 바로 main에 merge되기 때문에, 잘못된 코드가 배포되기 쉬워요.

마무리

브랜치 전략은 프로젝트의 규모와 작업 방식에 따라 다양하게 적용할 수 있어요.

여러분도 브랜치 전략을 설정해서 배포 과정이나 테스트 과정을 체계화할 수 있었으면 좋겠어요🍀

참고