VCS 프로젝트 브랜치 전략

서론

   한 프로그램을 만드는 데 많은 사람들이 투입된다. 그중 코딩은 서로 얽히고 얽혀 개발 과정이 매우 복잡한 형태가 된다. 아무 전략을 세우지 않고 하다 보면 아무리 서로에게 보고를 잘하다 한들 그 프로젝트는 개발 기간이 길어지거나 매우 높은 확률로 망하게 된다. 그러기 위해 우리는 브랜치 전략을 세운다. 많은 브랜치 전략 중 GitFlow와 trunk-based를 살펴보자.

---

GitFlow

    Gitflow는 Git을 사용하는 소프트웨어 개발에서 브랜치를 관리하기 위한 워크플로우이다. 프로젝트를 체계적으로 관리하고 팀 간 협업을 쉽게 하기 위해 고안되었다. Gitflow의 기본적인 브랜치 모델과 작업 흐름은 다음과 같다.

브랜치 모델

• Main 브랜치(Master)
  • 항상 배포 가능한 상태를 유지
  • 안정적인 버전만 포함
•  Develop 브랜치
  • 다음 릴리스를 위해 개발 중인 통합 브랜치
  • 모든 기능 브랜치가 여기서 통합
• Feature 브랜치
  • 새로운 기능을 개발하기 위해 사용
  • develop 브랜치에서 생성되고, 작업이 완료되면 다시 develop 브랜치로 병합
  • 브랜치 이름 예시: `feature/awesome`, 'feature-awesome'
• Release 브랜치
  • 릴리스를 준비하기 위해 사용됨
  • develop 브랜치에서 생성되고, 최종적인 버그 수정과 문서 작업을 진행
  • 작업이 완료되면 main과 develop 브랜치에 병합
  • 브랜치 이름 예시: `release/1.0.0`
• Hotfix 브랜치
  • 이미 배포된 버전에서 발생한 긴급 버그를 수정하기 위해 사용
  • master 브랜치에서 생성되고, 수정이 완료되면 main와 develop 브랜치에 병합
  • 브랜치 이름 예시: `hotfix/urgent-fix`

Gitflow 사용 방법

   프로젝트를 진행하면 언제 큰 사고가 날지 모른다 그럴 때에는 슬프게도 뒤로 되돌려야한다. 그럼 가장 안전할 때에 되돌려야 하는 데 그게 도대체 어디일까? 그게 바로 main 브랜치이다. 그리고 개발을 위한 큰 브랜치는 develop이다. 해당 develop 브랜치에서 추가적으로 기능을 만들 때마다 feature 브랜치를 만들어 개발을 진행한다. 즉, 개발자들은 main과 develop 브랜치 보다 feature 브랜치에서 더 작업을 하는 것이다. 이제 develop 브랜치에서 만족스러우면 바로 main브랜치에 머지해도 되지만 보통은 release 브랜치에서 테스트 및 QA를 진행하여 완성도를 높인다. 이제 신뢰성을 가지고 main 브랜치에 합쳐 출시하게 된다. 마찬가지로 수정된 부분이 있다면 release 브랜치를 develop에 풀 받아 main, release, develop이 모두 같은 버전이게 만든다. 그러나 언제나 완벽한 테스팅은 없듯이 버그가 생겨나기 마련이다. 해당 버그를 빠르게 수정하기 위해서는 hotfix라는 브랜치를 만들어 수정하게 된다. 마찬가지로 hotfix로 고쳐진 브랜치는 main과 develop이 일치하게 만든다. 물론, 유저들이 자주 업데이트되는 것을 싫어하기에 언제나 주의 깊게 확인해야 한다.

장단점

장점

• 체계적인 브랜치 모델을 통해 작업이 명확하게 구분된다.
• 팀 간의 협업이 용이해진다. 각 브랜치가 명확한 목적을 가지므로 충돌이 줄어든다.
• 릴리스 준비 과정이 명확하게 분리되어 있어 안정적인 배포가 가능하다.

단점

• 소규모 프로젝트나 작은 팀에서는 다소 복잡할 수 있다.
• 브랜치가 많이 생성되어 관리가 어려울 수 있다.

    Gitflow는 대규모 프로젝트나 여러 팀이 협업하는 프로젝트에 특히 유용하다. 프로젝트의 복잡성과 팀의 요구사항에 따라 Gitflow를 사용해 브랜치를 체계적으로 관리할 수 있다.

---

 

Trunk-Based

   Trunk-Based Development(TBD)는 Gitflow와 같은 브랜치 기반 워크플로우와는 다르게, 소프트웨어 개발에서 브랜치 관리를 최소화하고 주로 trunk (또는 main/master) 브랜치에서 직접 작업하는 방식을 강조하는 워크플로우이다. TBD는 높은 배포 빈도와 지속적인 통합(Continuous Integration, CI)을 지원하며, 주로 애자일 및 데브옵스(DevOps) 환경에서 많이 사용된다.

브랜치 모델

• Trunk (Main/Master) 브랜치
  • 개발자들은 대부분의 변경 사항을 trunk 브랜치에 직접 커밋한다.
  • 브랜치는 짧은 수명 동안만 존재하며, 빠르게 병합된다.
  • 항상 배포 가능한 상태를 유지한다.
• 단기 브랜치
  • 기능, 버그 수정, 또는 실험적 작업을 위해 단기 브랜치를 사용할 수 있다.
  • 이러한 브랜치는 매우 짧은 시간 동안만 존재하며, 보통 하루 이내에 trunk에 병합된다.

Trunk-Based 사용 방법

    Trunk-Based Development(TBD)는 메인 브랜치 하나만 운영하는 코드 관리 전략이다. 이 방식에서는 개발자들이 소스 코드를 여러 브랜치로 나누지 않고, 메인 브랜치에 직접 커밋하거나 짧은 수명의 브랜치를 생성해 작업을 완료한 후 다시 메인 브랜치에 병합한다. 새로운 기능이나 섹션이 필요할 때마다 메인 브랜치에서 작은 브랜치를 만들어 작업을 수행한 후 빠르게 메인 브랜치에 병합한다. Trunk-Based Development는 코드가 안정화된 프로젝트에 적합하며, 자동화된 테스트와 배포 시스템을 갖춘 환경에서 더욱 효과적으로 사용할 수 있다.

모범사례

• 작은 단위로 커밋
  • 변경 사항을 작은 단위로 자주 커밋하여 통합한다.
  • 이는 충돌을 줄이고 문제를 빠르게 해결하는 데 도움이 된다.
• 자동화된 테스트 및 빌드
  • CI 시스템을 사용하여 모든 커밋에 대해 자동화된 빌드와 테스트를 실행한다.
  • 문제를 즉시 발견하고 수정할 수 있도록 한다.
• 코드 리뷰
  • 모든 커밋에 대해 코드 리뷰를 수행하여 코드 품질을 유지한다.
  • 코드 리뷰는 가능한 한 빠르게 진행하여 병합 지연을 최소화한다.
• 피처 토글
  • 미완성 기능을 trunk 브랜치에 통합할 때는 피처 토글을 사용하여 프로덕션 환경에서 비활성화할 수 있도록 한다.
  • 이는 trunk 브랜치의 안정성을 유지하는 데 도움이 된다.

장단점

장점

• 개발자들은 지속적으로 trunk 브랜치에 변경 사항을 통합하므로, 충돌을 최소화하고 문제를 빠르게 해결할 수 있다.
• 변경 사항이 빠르게 trunk 브랜치에 병합되므로, 새로운 기능이나 수정 사항을 빠르게 배포할 수 있다.
• 복잡한 브랜치 구조를 피하고, 단순한 브랜치 전략을 유지할 수 있다.

단점

• 모든 개발자가 trunk 브랜치에 자주 커밋하므로, 코드 품질 유지하기가 힘들다. 코드 품질을 유지하기 위해 철저한 코드 리뷰와 자동화된 테스트가 필요하다.
• 단기 브랜치가 너무 길어지면 trunk 브랜치와의 충돌이 발생할 수 있다.

    Trunk-Based Development는 빠른 배포와 지속적인 통합을 중시하는 환경에서 특히 유용하며, 높은 협업과 자동화된 테스트 환경을 갖춘 팀에 적합하다.

---

주섬주섬

• 툴들을 이용하고 나서 이미지를 직접 제작하기 쉬워졌다. 위 그림들은 직접 제작한 것이다.
• 웬만한 경우에는 gitflow 방법이 대중화되고 좋은 방법이다. 그러나 소수 및 인디 개발일 경우에는 Trunk-based 방식도 고려해 볼 만하다.

참고

Git 간단 사용 방법