GIT 브랜치 전략

목차

 

최신 소프트웨어 개발에서는 소프트웨어 를 개발하고 출시할 때 속도와 민첩성이 중요합니다 . 그러나 동시에 작업하는 대규모 개발자 팀이 있는 경우 코드 분기 및 병합이 빠르게 지저분해질 수 있습니다.

따라서 팀은 한 번에 여러 변경 사항을 구현하는 프로세스가 필요합니다. 여기에서 효율적인 분기 전략을 갖는 것이 이들 팀의 우선 순위가 됩니다.

 

브랜치 전략이란 무엇입니까?

분기는 주로 팀이 코드를 위한 별도의 작업 공간을 제공하는 기능을 개발하는 수단으로 사용됩니다. 이러한 분기는 일반적으로 작업 완료 시 다시 마스터 분기로 병합됩니다. 이러한 방식으로 기능(및 모든 버그 및 버그 수정)이 서로 분리되어 있어 실수를 더 쉽게 수정할 수 있습니다.

이것은 분기가 코드의 메인라인을 보호하고 주어진 분기에 대한 변경 사항이 다른 개발자에게 영향을 미치지 않는다는 것을 의미합니다.

따라서 분기 전략은 버전 제어 시스템을 사용할 때 소프트웨어 개발 팀이 코드를 작성, 병합 및 배포할 때 채택하는 전략입니다.

이것은 본질적으로 개발자가 공유 코드베이스와 상호 작용하는 방법을 규정하기 위해 따를 수 있는 일련의 규칙입니다.

여러 개발자가 동시에 작업하고 모두 동시에 변경 사항을 추가할 때 응용 프로그램의 오류와 두려운 병합 지옥을 피하기 위해 리포지토리를 구성하는 데 도움이 되므로 이러한 전략이 필요합니다 . 

이러한 병합 충돌은 결국 코드 배송을 빠르게 방해하여 DevOps의 전체 목적이 작은 배치의 코드를 릴리스할 수 있는 빠른 워크플로를 만드는 것이기 때문에 효율적인 DevOps 프로세스를 만들고 유지 관리하는 데 방해가 됩니다 .  

따라서 분기 전략을 고수하면 이 문제를 해결하는 데 도움이 되어 개발자가 서로의 발을 밟지 않고 함께 작업할 수 있습니다. 즉, 소스 제어를 변경할 때 명확한 프로세스를 생성하여 팀이 더 빠른 릴리스와 더 적은 충돌을 달성하기 위해 병렬로 작업할 수 있습니다.

분기에 대해 이야기할 때 마스터 분기에서 분기되는 독립적인 코드 줄을 참조하여 개발자가 변경 사항을 코드 베이스에 다시 병합하기 전에 독립적으로 작업할 수 있습니다.

이 게시물에서는 팀이 워크플로를 구성하기 위해 사용하는 몇 가지 분기 전략에 대해 간략히 설명합니다. 여기서 장단점을 살펴보고 필요, 목표 및 팀의 능력에 따라 선택해야 하는 전략을 살펴보겠습니다.

 

브랜치 전략이 필요한 이유

위에서 언급한 것처럼 병합할 때 충돌을 피하고 변경 사항을 마스터 트렁크에 더 쉽게 통합하려면 분기 전략이 필요합니다.

분기 전략은 다음을 목표로 합니다.

• 개발자 간의 적절한 조정을 통해 생산성 향상
• 병렬 개발 활성화
• 일련의 계획되고 구조화된 릴리스 구성 지원
• 소프트웨어를 변경할 때 프로덕션에 이르는 명확한 경로를 매핑합니다.
• 개발자가 개발 워크플로를 방해하지 않고 문제를 신속하게 수정하고 이러한 변경 사항을 프로덕션으로 다시 가져올 수 있는 버그 없는 코드를 유지합니다.

 

Git Branching

브랜치는 Git에만 있는 것이 아닙니다. 그러나 이 기사에서는 이 분기 모델이 제공하는 많은 이점으로 인해 Git에 중점을 둡니다.

결과적으로 Git 분기 전략을 포함하여 다양한 분기 전략을 살펴보기 전에 Git이 실제로 분기를 처리하는 방법과 다른 VCS 도구 중에서 뛰어난 이유를 살펴보겠습니다.

간단히 말해서 Git 및 기타 버전 제어 도구를 사용하면 개발자가 코드를 추적, 관리 및 구성할 수 있습니다 .

Git 분기를 사용하면 개발자가 코드 변경 사항을 격리하기 위해 별도의 분기를 생성하여 기본 분기에서 분기할 수 있습니다. Git의 기본 브랜치는 마스터 브랜치입니다. 

Git 브랜치의 가장 큰 장점은 '가벼움'입니다. 즉, 데이터가 일련의 스냅샷으로 구성되므로 커밋할 때마다 Git이 그 순간의 파일 모양을 사진으로 찍고 해당 스냅샷에 대한 참조를 저장합니다. . 이것은 이러한 분기가 파일 시스템의 복사본이 아니라 단순히 최신 커밋에 대한 포인터임을 의미합니다. 

한편, 다른 VCS 도구는 정보를 파일 기반 변경 목록으로 저장하여 속도를 늦추고 상당한 공간을 차지할 수 있습니다. 

Git에서 분기는 본질적으로 주어진 컨텍스트의 최신 커밋에 대한 참조 또는 포인터입니다. 커밋을 위한 컨테이너가 아닙니다. 새 브랜치에서 새 커밋을 생성하면 Git은 변경 사항을 추적하기 위해 새 포인터를 생성합니다. 그러면 Git 분기는 변경 사항의 스냅샷에 대한 포인터로 볼 수 있습니다. 

아래 이미지는 이 개념을 보여줍니다. 맨 위 이미지는 마스터 브랜치와 마지막 커밋을 가리키는 포인터를 보여주고 바로 아래 이미지는 'dev'라는 새 브랜치를 만들 때 일어나는 일을 보여줍니다. 새 포인터는 이제 다음을 가리킵니다. 최신 커밋.

참조

요약 하면 Git 분기 모델은 다른 버전 관리 시스템에 비해 가볍습니다. 이것이 다른 VCS 도구와 달리 많은 양의 중복 파일을 생성하는 브랜치에 전체 코드를 복사할 필요가 없기 때문에 Git에서 브랜치를 만드는 것이 쉽고 저렴한 이유 입니다.

 

 

 

 

Git Branch 전략 종류

• GitFlow
• Github Flow
• GitLab Flow
• Trunk-based development

 

GitFlow

오늘날의 많은 프로젝트에서 약간 복잡하고 고급 스러운 것으로 간주되는 GitFlow 는 개발자가 마스터 분기에서 기능 분기가 생성되는 기능에 대해 마스터 분기와 별도로 작업할 수 있는 병렬 개발을 가능하게 합니다.

그런 다음 변경이 완료되면 개발자는 이러한 변경 사항을 릴리스를 위해 마스터 분기에 다시 병합합니다.

이 분기 전략은 다음 분기로 구성됩니다.

• 주인 
• 개발하다
• 기능 - 개발 분기에서 분기하는 새 기능을 개발하기 위해 
• 릴리스 - 새로운 프로덕션 릴리스를 준비하는 데 도움이 됩니다. 일반적으로 개발 분기에서 분기되며 개발 및 마스터 모두에 다시 병합되어야 합니다.
• 핫픽스- 또한 릴리스 준비에 도움이 되지만 릴리스 분기와 달리 핫픽스 분기는 발견되어 해결해야 하는 버그에서 발생합니다. 이를 통해 개발자는 버그가 수정되는 동안 개발 분기에서 자신의 변경 사항을 계속 작업할 수 있습니다.

기본 및 개발 분기는 수명이 무한한 기본 분기로 간주되며 나머지는 일반적으로 수명이 짧은 개발자 간의 병렬 개발을 지원하기 위한 지원 분기입니다.

저자: Vincent Driessen
원본 블로그 게시물
라이선스: Creative Commons BY-SA

GitFlow의 장단점

아마도 이 모델의 가장 분명한 이점은 병렬 개발을 허용하여 프로덕션 코드를 보호할 수 있으므로 개발자가 별도의 분기에서 작업하는 동안 기본 분기가 릴리스를 위해 안정적으로 유지된다는 것입니다.

또한 다양한 유형의 분기를 통해 개발자가 작업을 쉽게 구성할 수 있습니다. 이 전략에는 특정 목적을 위한 별도의 간단한 분기가 포함되어 있지만 그 때문에 많은 사용 사례에서 복잡해질 수 있습니다. 

여러 버전의 프로덕션 코드를 처리할 때도 이상적입니다.

그러나 더 많은 분기가 추가됨에 따라 개발자가 개발 분기에서 메인으로 변경 사항을 병합함에 따라 관리가 어려워질 수 있습니다. 개발자는 먼저 릴리스 분기를 만든 다음 최종 작업도 개발 분기로 다시 병합한 다음 해당 릴리스 분기를 기본 분기로 병합해야 합니다.

변경 사항이 테스트되고 테스트가 실패하는 경우 개발자가 커밋의 바다에서 길을 잃기 때문에 문제가 정확히 어디에 있는지 파악하기가 점점 더 어려워질 것입니다.

실제로 GitFlow의 복잡성으로 인해 개발 프로세스 및 릴리스 주기가 느려질 수 있습니다. 그런 의미에서 GitFlow는 지속적 통합 및 지속적 전달을 구현하려는 팀에게 효율적인 접근 방식이 아닙니다. 

따라서 이 경우 GitHub Flow와 같은 훨씬 간단한 워크플로를 권장합니다.

 

 

GitHub Flow

GitHub Flow 는 여러 버전을 관리할 필요가 없기 때문에 소규모 팀에 이상적인 GitFlow의 간단한 대안입니다.

GitFlow와 달리 이 모델에는 릴리스 분기가 없습니다. 기본 브랜치로 시작한 다음 개발자는 마스터에서 직접 파생된 기능 브랜치를 생성하여 작업을 분리한 다음 다시 기본 브랜치로 병합합니다. 그런 다음 기능 분기가 삭제됩니다.

이 모델의 기본 아이디어는 마스터 코드를 지속적으로 배포 가능한 상태로 유지하여 지속적인 통합 및 지속적인 전달 프로세스를 지원할 수 있다는 것입니다.

GitHub Flow의 장단점

Github Flow는 Agile 원칙에 중점을 두고 있으므로 짧은 생산 주기와 빈번한 릴리스로 빠르고 능률적인 분기 전략입니다. 

이 전략은 또한 팀이 신속하게 문제를 식별하고 해결할 수 있도록 빠른 피드백 루프를 허용합니다.

빠르고 지속적인 배포를 허용하는 하나의 분기에 대한 변경 사항을 테스트 및 자동화할 때 개발 분기가 없기 때문입니다.

이 전략은 특히 소규모 팀과 웹 애플리케이션에 적합하며 단일 프로덕션 버전을 유지해야 할 때 이상적입니다.

따라서 이 전략은 여러 버전의 코드를 처리하는 데 적합하지 않습니다.

또한 개발 분기가 없기 때문에 이 전략은 버그에 더 취약하므로 마스터 릴리스 준비와 병합하기 전에 분기를 제대로 테스트하지 않고 이 분기에서 버그 수정이 발생하면 불안정한 프로덕션 코드가 발생할 수 있습니다. 결과적으로 마스터 브랜치는 프로덕션 브랜치와 개발 브랜치 모두의 역할을 하기 때문에 더 쉽게 어수선해질 수 있습니다.

또 다른 단점은 이 모델이 소규모 팀에 더 적합하기 때문에 팀이 성장함에 따라 모든 사람이 동일한 분기에 병합되고 투명성이 부족하여 개발자가 다른 개발자가 작업 중인 것을 볼 수 없기 때문에 병합 충돌이 발생할 수 있다는 것입니다.

 

 

GitLab Flow

GitLab Flow 는 기능 중심 개발 및 기능 분기를 문제 추적과 결합한 GitFlow의 더 간단한 대안입니다.

GitFlow를 사용하면 개발자가 개발 분기를 만들고 GitLab Flow가 기본 분기와 즉시 작동하는 동안 기본값으로 설정합니다.

GitLab Flow는 여러 환경을 유지 관리 하고 프로덕션 환경과 별도 의 스테이징 환경 을 선호할 때 유용합니다 . 그런 다음 기본 분기를 배포할 준비가 될 때마다 프로덕션 분기로 다시 병합하고 릴리스할 수 있습니다.

따라서 이 전략은 개발자가 서로 다른 환경에서 여러 버전의 소프트웨어를 유지 관리할 수 있도록 환경 간에 적절한 격리를 제공합니다.

GitHub Flow는 기능 분기를 마스터에 병합할 때마다 프로덕션에 배포할 수 있다고 가정하지만 GitLab Flow는 아래 이미지와 같이 코드가 프로덕션에 도달하기 전에 내부 환경을 통과하도록 허용하여 해당 문제를 해결하려고 합니다.

원천

따라서 이 방법은 앱 스토어 유효성 검사를 먼저 거쳐야 하는 iOS 앱 또는 특정 배포 기간이 있는 경우와 같이 출시 시기를 제어할 수 없는 상황에 적합합니다.

 

Trunk-based development

트렁크 기반 개발 은 실제로 분기가 필요하지 않지만 대신 개발자가 변경 사항을 적어도 하루에 한 번 공유 트렁크에 통합하는 분기 전략입니다. 이 공유 트렁크는 언제든지 릴리스할 준비가 되어 있어야 합니다.

이 전략의 기본 아이디어는 개발자가 더 작은 변경을 더 자주 수행하므로 모든 개발자가 동일한 분기에서 작업할 때 오래 지속되는 분기를 제한하고 병합 충돌을 피하는 것이 목표라는 것입니다. 즉, 개발자는 분기를 사용하지 않고 트렁크에 직접 커밋합니다.

결과적으로 트렁크 기반 개발은 CI(지속적 통합) 및 CD(지속적 전달)를 가능 하게 하는 핵심 요소입니다.   변경 사항이 트렁크에 더 자주, 종종 하루에 여러 번(CI) 수행되어 기능을 훨씬 더 빠르게 릴리스할 수 있기 때문입니다(CD). ).

이 전략은 종종 기능 플래그 와 결합됩니다 . 트렁크는 항상 릴리스 준비 상태로 유지되므로 기능 플래그는 배포를 릴리스에서 분리하는 데 도움이 되므로 준비되지 않은 변경 사항은 기능 플래그에 래핑되고 숨겨진 상태로 유지되는 반면 완전한 기능은 최종 사용자에게 지연 없이 릴리스될 수 있습니다. 

원천

 

 

 

트렁크 기반 개발 장단점

우리가 보았듯이, 트렁크 기반 개발은 트렁크가 지속적으로 업데이트되기 때문에 지속적인 통합을 위한 길을 열어줍니다.

또한 개발자는 브랜치 없이 트렁크에 직접 커밋할 때 다른 개발자가 변경하는 사항을 더 잘 볼 수 있으므로 협업이 향상됩니다. 이것은 각 개발자가 자신의 브랜치에서 독립적으로 작업하고 해당 브랜치에서 발생하는 모든 변경 사항은 기본 브랜치에 병합된 후에만 볼 수 있는 다른 브랜치 방법과 다릅니다.

트렁크 기반 개발은 브랜치가 필요하지 않기 때문에 수명이 긴 브랜치의 스트레스를 없애고 개발자들이 작은 변경 사항을 훨씬 더 자주 밀면서 병합 충돌 또는 소위 '병합 지옥'이 발생합니다. 또한 발생할 수 있는 충돌을 쉽게 해결할 수 있습니다.

마지막으로, 이 전략을 사용하면 공유 트렁크가 지속적으로 해제 가능한 상태로 유지되고 지속적인 작업 흐름이 트렁크에 통합되어 보다 안정적인 해제가 가능해지므로 보다 빠르게 해제할 수 있습니다.

그러나 이 전략은 경험이 없는 개발자가 공유 트렁크와 직접 상호 작용할 때 벅차게 느낄 수 있는 많은 양의 자율성을 제공하기 때문에 고위 개발자에게 적합합니다. 따라서 작업을 면밀히 모니터링해야 하는 하위 팀의 경우 Git 분기 전략을 선택할 수 있습니다. 

 

 

 

팀에 가장 적합한 분기 전략을 선택하는 방법

처음 시작할 때는 모든 것을 단순하게 유지하는 것이 가장 좋으므로 초기에는 GitHub Flow 또는 Trunk 기반 개발이 가장 잘 작동할 수 있습니다. 또한 단일 버전의 릴리스만 유지 관리해야 하는 소규모 팀에 이상적입니다. 

GitFlow는 변경 사항에 대한 엄격한 액세스 제어가 필요한 오픈 소스 프로젝트에 적합합니다. 이는 오픈 소스 프로젝트에서 누구나 기여할 수 있고 Git Flow를 사용하여 소스 코드에 도입되는 내용을 확인할 수 있기 때문에 특히 중요합니다.

하지만 앞서 언급한 것처럼 GitFlow는 DevOps 환경을 구현하고자 할 때 적합하지 않습니다. 이 경우 논의된 다른 전략은 Agile DevOps 프로세스에 더 적합하고 CI 및 CD 파이프라인을 지원하는 것 입니다.

다음 표 에는 이 문서에서 논의된 전략과 어떤 전략이 어떤 상황에서 적절한지 요약되어 있습니다.

 

제품 유형 및 출시 방법	팀 규모	협업 성숙도	적용 가능한 메인스트림 분기 모드
모두	소규모 팀	높은	트렁크 기반 개발(TBD)
SaaS 제품과 같이 지속적인 배포 및 릴리스를 지원하는 제품	가운데	보통	GitHub-Flow 및 TBD
iOS 앱과 같이 명확한 출시 기간과 주기적인 버전 출시 주기가 있는 제품	가운데	보통	릴리스 분기가 있는 Git-Flow 및 GitLab-Flow
기본 플랫폼 제품과 같이 제품 품질을 요구하고 지속적인 배포 및 출시를 지원하는 제품	가운데	보통	GitLab-Flow
2B 기본 플랫폼 제품과 같이 출시된 버전의 유지보수 주기가 길고 품질이 요구되는 제품	크기가 큰	보통	Git-Flow

요약하자면 완벽한 전략은 없습니다. 선택하는 전략은 팀과 프로젝트의 특성 및 복잡성에 따라 다르므로 사례별로 평가해야 합니다.

하나의 전략으로 시작하여 필요에 따라 시간이 지남에 따라 조정하는 것도 좋습니다. 말할 필요도 없이, 결국 어떤 전략을 선택하든 팀에게 명확하고 일관된 작업 구성 전략을 제공하여 팀의 생산성을 높이는 것을 목표로 해야 합니다.

 

 

 

 이글은 아래 사이트 번역기 돌린것입니다.

https://www.flagship.io/git-branching-strategies/

Git Branching Strategies: GitFlow, Github Flow, Trunk Based...