지금 바로 떠나자 먹으러....

 

Git 이란?

Git은 속도와 효율성을 갖춘 소규모에서 매우 큰 프로젝트에 이르기까지 모든 것을 처리할 수 있도록 설계된 무료이자 오픈 소스 분산 버전 관리 시스템입니다. 2005년 리누스 토발즈에 의해 리눅스 커널의 개발을 지원하기 위해 만들어졌습니다. Git은 소프트웨어 개발 중 소스 코드의 변경 사항을 추적하면서 개발자들이 프로젝트의 다른 부분에서 동시에 작업할 수 있도록 함으로써 개발자 간의 협업을 용이하게 합니다. 분기(Branching)는 Git의 핵심 기능 중 하나입니다. 개발자는 분기를 생성하여 메인 프로젝트(보통 "master" 브랜치)로부터 독립적으로 새로운 기능이나 수정 사항을 작업할 수 있습니다. 분기에서의 작업이 완료되면, 그것을 메인 브랜치나 다른 브랜치로 병합할 수 있습니다.

 

Git 브랜치 전략

 

분기 관리에 대한 명확한 기준이 없다면, "이 분기는 왜 만들어졌는가?", "이 분기는 어느 커밋에서 분기되었는가?", "어느 브랜치에서 분기해야 하는가?", "내 브랜치는 어디로 병합해야 하는가?", "어느 브랜치가 최신인가?", "어느 브랜치가 배포된 버전인가?"와 같은 질문에 휩싸일 수 있습니다. 이런 불확실성은 프로젝트 내 혼란을 초래할 수 있습니다. Git 분기 전략은 프로젝트의 Git 브랜치를 효과적으로 관리하기 위해 설계된 워크플로우입니다. 자신만의 분기 전략을 만들 수도 있지만, 효과적인 분기 관리를 위한 업계의 모범 사례가 있습니다. 이 글에서는 두 가지 인기 있는 모범 사례인 Git Flow와 GitHub Flow를 소개합니다.

 

Git Flow

Git Flow는 2010년 Vincent Driessen이 "성공적인 Git 분기 모델"이라는 블로그 게시물을 발표한 후 인기를 얻은 분기 전략입니다. Git Flow는 Main, Develop, 그리고 Supporting 브랜치의 세 가지 주요 유형으로 브랜치를 분류하며, 후자는 Feature, Release, 그리고 Hotfix 브랜치로 더 세분화됩니다. Main과 Develop 브랜치는 개발 과정 내내 유지되며, Supporting 브랜치는 필요에 따라 생성되었다가 그 역할이 완료되면 삭제됩니다. 이를 통해 팀 내 병렬 작업 흐름이 가능합니다. 각 유형을 자세히 살펴보겠습니다:

 

• Main Branch Main 브랜치는 공식 릴리스 이력을 저장합니다. 프로젝트 시작 시 생성되어 개발 과정 내내 유지됩니다. 각 배포된 버전은 태그를 사용하여 표시됩니다. • Develop Branch 이 브랜치는 기능의 통합 브랜치로서 역할을 합니다. 개발이 완료되면 Main 브랜치로 병합됩니다.

 

• Feature Branch Feature 브랜치는 단일 기능을 개발하기 위해 사용됩니다. 완료되면 Develop 브랜치로부터 분기되어 완료 시 다시 Develop 브랜치로 병합됩니다. 병합 시 Fast-Forward 대신 Merge Commit을 생성하여 기능별로 이력이 그룹화되도록 해야 합니다. 이 브랜치는 feature/branch-name 형식으로 명명됩니다.

 

• Release Branch Release 브랜치는 소프트웨어 배포를 준비하기 위해 사용됩니다. Develop 브랜치로부터 분기되어 소규모 편집이나 배포 전 버그 수정을 위해 사용됩니다. 준비가 완료되면 Main과 Develop 브랜치 모두에 병합되며, Main 브랜치 버전은 태그를 사용하여 표시됩니다. 이 분리는 다른 팀 멤버가 배포 과정에 관여하지 않고도 병렬로 기능 개발을 계속할 수 있도록 합니다. 이 브랜치는 release/v1.1과 같은 형식으로 명명됩니다.

 

• Hotfix Branch 배포된 버전에서 문제가 발생한 경우 Hotfix 브랜치가 수정을 위해 사용됩니다. Main 브랜치로부터 분기되어 문제가 해결되면 Main과 Develop 브랜치 모두에 병합됩니다. 이를 통해 팀은 핫픽스에 방해받지 않고 기능 개발을 병렬로 계속할 수 있습니다. Hotfix 브랜치는 hotfix/v1.0.1과 같은 형식으로 명명됩니다.

 

Git Flow의 한계: 웹 애플리케이션에 적합하지 않음 Vincent Driessen은 2010년 "성공적인 Git 분기 모델"을 발표한 지 십년 후인 2020년, 원래 게시물 위에 반성적인 노트를 추가했습니다. 그 내용의 요약은 다음과 같습니다.

 

This model was conceived in 2010, now more than 10 years ago, and not very long after Git itself came into being. In those 10 years, git-flow (the branching model laid out in this article) has become hugely popular in many a software team to the point where people have started treating it like a standard of sorts — but unfortunately also as a dogma or panacea.  

During those 10 years, Git itself has taken the world by a storm, and the most popular type of software that is being developed with Git is shifting more towards web apps — at least in my filter bubble. Web apps are typically continuously delivered, not rolled back, and you don't have to support multiple versions of the software running in the wild.  

This is not the class of software that I had in mind when I wrote the blog post 10 years ago. If your team is doing continuous delivery of software, I would suggest to adopt a much simpler workflow (like GitHub flow) instead of trying to shoehorn git-flow into your team.


이 모델은 2010년에 고안되었으며, 그로부터 10년이 조금 넘는 시간이 지났고, Git 자체가 생겨난 직후가 아니었습니다. 그 10년 동안, git-flow(이 글에서 설명된 분기 모델)는 많은 소프트웨어 팀에서 엄청난 인기를 얻어 어느 정도 표준처럼 취급되기 시작했지만, 불행하게도 일종의 교리나 만병통치약으로도 여겨지게 되었습니다.

그 10년 동안, Git은 전 세계를 휩쓸었고, Git으로 개발되는 가장 인기 있는 소프트웨어 유형은 웹 앱으로 옮겨가고 있습니다 — 적어도 제 필터 버블에서는 그렇습니다. 웹 앱은 일반적으로 지속적으로 제공되며, 롤백되지 않으며, 야생에서 실행되는 소프트웨어의 여러 버전을 지원할 필요가 없습니다.

이것은 제가 10년 전에 블로그 포스트를 썼을 때 염두에 두었던 소프트웨어 유형이 아닙니다. 여러분의 팀이 소프트웨어를 지속적으로 제공하고 있다면, git-flow를 여러분의 팀에 억지로 맞추려 하기보다는 훨씬 간단한 워크플로우(예: GitHub flow)를 채택하는 것이 좋습니다.

 

Git Flow는 명시적인 버전 관리가 필요한 프로젝트에 특히 적합합니다. 예를 들어 스마트폰 애플리케이션, 오픈 소스 라이브러리/프레임워크 등이 있습니다. 웹 애플리케이션의 경우, 그 특성상 사용자에게 일반적으로 최신 버전만 제공되므로 여러 병렬 버전을 지원할 필요가 없습니다. 또한, 웹 애플리케이션은 하루에 여러 번 릴리스될 수 있습니다. 이러한 특성을 감안할 때, Git Flow는 웹 애플리케이션 개발에 가장 적합하지 않을 수 있습니다.

 

Github Flow

GitHub Flow는 소프트웨어 개발에서 사용되는 간단하면서도 효과적인 분기 관리 전략입니다. GitHub에 의해 개발되었으며, 지속적인 배포 환경에 맞게 설계되어 개발 과정을 간소화하고 빠르고 지속적인 소프트웨어 릴리스를 용이하게 합니다.

 

• Main branch: GitFlow의 main 브랜치와 유사합니다. 이 브랜치에는 코드의 릴리스 버전이 포함됩니다.

 

• Feature branch: 개발자들은 새로운 기능 작업을 위해 메인 브랜치로부터 직접 분기합니다. GitHub Flow의 주요 단계는 다음과 같습니다:

1. 분기 생성 새 기능을 추가할 때, 메인 브랜치로부터 feature 브랜치를 생성합니다. 브랜치의 이름을 짧고 명확하게 지어 해당 기능을 한눈에 이해할 수 있도록 합니다.
2. 변경 사항 만들기 새로 생성된 브랜치에서 변경 사항을 만들거나 새 기능을 추가합니다. 이 브랜치는 다른 저장소에 영향을 주지 않으므로, 실수가 발생하면 변경 사항을 되돌리거나 추가 조정을 할 수 있는 유연성을 가집니다. 변경 사항을 커밋하고 푸시합니다. 이는 작업을 원격 저장소에 백업하고 다른 협업자가 변경 사항을 검토하고 기여할 수 있도록 합니다.
3. 풀 리퀘스트 생성 변경 사항에 대한 피드백을 받기 위해 PR(풀 리퀘스트)를 생성할 수 있습니다. 이 과정을 통해 다른 협업자로부터 변경 사항에 대한 리뷰를 받을 수 있습니다. 또한, 메인 브랜치로 병합하기 전에 리뷰 승인을 의무화할 수 있습니다.
4. 풀 리퀘스트 병합 PR이 승인되면, 메인 브랜치로 병합할 수 있습니다. 병합 후에도 커밋 이력이 보존되어 미래의 기여자들이 변경 사항을 이해하는 데 도움이 됩니다. GitHub Flow의 장점은 그 단순함에 있습니다. 복잡한 분기 전략과 달리, GitHub Flow는 배포 준비가 된 코드만 메인 브랜치로 병합되도록 보장하여 메인 브랜치의 코드를 항상 배포 가능한 상태로 유지합니다. 이 접근 방식은 빠르게 진화하는 프로젝트와 소규모 팀에 이상적입니다.