dseoki dseoki dream developer

GIT Branch

Feb 8, 2024 » git

GIT

GIT은 형상 관리를 위한 강력한 도구로, 여러 개발자들이 협업하면서 파일이나 문서의 변경 이력을 관리하고 추적할 수 있도록 해준다. 이를 통해 개발 과정에서 발생하는 충돌을 최소화하고 안전한 작업 환경을 제공한다.

분산형 버전 관리 시스템인 Git은 SVN과 달리 중앙 서버에 의존하지 않고 각 개발자가 로컬 저장소를 가지고 작업을 수행할 수 있다. 이는 병렬적인 개발과 빠른 작업 흐름을 가능하게 한다.

Git의 주요 특징 중 하나는 브랜치를 통한 작업 분리와 관리이다. 각 작업은 독립적인 브랜치에서 수행되며, 이후에 필요에 따라 메인 브랜치에 병합될 수 있다. 이를 통해 개발자들은 동시에 여러 작업을 진행하고 서로의 작업에 영향을 주지 않으면서 안정적으로 협업할 수 있다.

그러나 Git에서도 브랜치 관리에 대한 일정한 전략이 필요하다. Git 브랜치 전략은 프로젝트의 규모와 특성에 맞추어 브랜치를 효과적으로 관리하기 위한 방법론을 제시한다. 예를 들어, 주요 기능 개발을 위한 feature 브랜치, 버그 수정을 위한 hotfix 브랜치 등을 사용하여 작업을 분리하고 관리한다.

따라서 Git을 사용하는 팀은 효율적인 브랜치 전략을 수립하고 이를 따르며 작업을 진행하여 협업 과정을 원활하게 할 수 있다.

형상 관리

어떠한 문서나 파일이 변경된 경우, 변경된 내용과 그 원인을 기록하였다가 나중에 필요한 경우 찾아볼 수 있도록 하여 관리하는 것을 말한다.

Git Flow

Git Flow는 Vincent Driessen에 의해 제안된 브랜치 전략으로, 주로 중대형 프로젝트에 적합하며 다음과 같은 주요 브랜치를 사용한다.

git-flow

  • master: 제품 출시 가능한 안정적인 상태의 코드를 유지한다.
  • develop: 개발 중인 기능들이 모이는 브랜치로, 각 기능별로 feature 브랜치를 생성하여 개발을 진행한다.
  • feature: 새로운 기능을 개발하기 위한 브랜치로, Develop 브랜치에서 분기된다.
  • release: 출시를 위한 준비 단계에서 사용되는 브랜치로, develop 브랜치에서 분기되며 테스트와 버그 수정이 이루어진다.
  • hotfix: 출시된 제품에서 발생한 긴급한 버그를 수정하기 위한 브랜치이다.

웹 애플리케이션에는 적합하지않다?

Vincent Driessen은 A successful Git branching model을 작성하고 10년이 지난 2020년에 해당 포스팅 위에 반성의 글(Note of Reflection)을 적는다. 그 내용을 요약하면 아래와 같다.

Git-Flow는 등장하고 10년 넘게 표준처럼 자리잡고, 더 나아가 마치 만병통치약처럼 사용되었다. 현재는 Git으로 관리되는 인기있는 유형의 소프트웨어가 웹 어플리케이션으로 이동하고 있다. 웹 어플리케이션은 일반적으로 롤백되지 않고, 지속적으로 제공(Continuous Delivery)되므로 여러 버전의 소프트웨어를 지원할 필요가 없다.

웹 어플리케이션은 내가(Vincent Driessen) 10년전 블로그 글을 쓸때에는 염두해둔 소프트웨어 유형이 아니다. 팀이 소프트웨어를 지속적으로 제공한다면, Git Flow 대신 Github Flow와 같은 더 단순한 워크플로우를 채택할 것을 제안한다.

그러나 명시적으로 버전을 관리해야하는 소프트웨어를 개발한다면, 여전히 Git Flow가 적합할 수 있다.

즉 Git Flow는 롤백이 수정 작업이 빈번한 웹 애플리케이션 개발에서는 적합하지 않다는 것이다. 그리고 문장의 아래에는 Github Flow를 제안하고 있다.

Github Flow

GitHub Flow는 단순하고 직관적인 개발 워크플로우로, 주로 작은 규모의 프로젝트나 빠른 배포가 필요한 경우에 적합하다.

Github Flow에서는 브랜치가 2개만 존재한다. main브랜치에만 엄격한 규칙을 적용하고, 다른 하나는 규칙이 없다.

  • main: 언제든 배포가 가능한 상태를 유지해야 한다. main으로 merge하기 전에는 엄격한 테스트를 거쳐야 한다. (CI 필수)
  • 나머지 브랜치: main에서 생성하며 이름, 규칙이 자유롭다. 이때, 브랜치 명과 커밋 메세지는 어떠한 일을 하는지 자세하게 작성해야 한다.

git hub flow

github flow는 다음과 같은 순서로 동작한다.

  1. main 브랜치에서 새로운 브랜치를 생성한다. 이때 브랜치명은 어떠한 일을 하는지 자세히 작성한다.
  2. 생성한 브랜치에서 작업이 끝나면 main으로 PR을 작성한다.
  3. PR 리뷰가 끝나고 main으로 merge할 때 CI/CD를 거쳐서 배포한다.

이렇듯 main은 항상 안정적이고 언제든 배포가 가능해야 한다.

그럼 Git Flow와 Github Flow중 무엇을 사용해야 할까?

  • Git Flow
    • 브랜치 수가 많고 여러 규칙이 있는 만큼, 규모가 큰 프로젝트에서 적합하다.
    • 배포 주기가 잦지 않은 프로젝트에서 적합하다.
    • 다양한 버전 관리가 필요한 모바일 애플리케이션에서 적합하다.
  • GitHub Flow
    • 규칙이 있는 브랜치가 main 뿐이고 간단한만큼 비교적 규모가 적은 프로젝트에서 적합하다.
    • 수시로 배포가 일어나서 잦은 배포 주기를 가지는 프로젝트에서 적합하다.
    • git에 익숙하지 않은 사람이 있을 때 경험해보기 좋다.

Trunk Based Development

모든 개발자가 단일 브랜치(주로 master 또는 main)에서 작업하는 소프트웨어 개발 방법론이다.
작은 변경 사항을 빠르게 배포하고 지속적인 통합을 강조한다.