GitFlow와 Github Flow

들어가며..

 

처음 국비 학원에서 팀 프로젝트를 진행할 때, Git에 대해 잘 알지 못해 어려움을 겪은 경험이 많았습니다. 설정을 잘못해서 프로젝트 결과물이 날아간 적도 있었고, 그때는 Git이 어렵고 두렵게만 느껴졌습니다.

 

“왜 이렇게 복잡한 도구를 써야 하지?“라는 생각을 했던 제가, 지금은 Git 없이는 협업을 상상할 수 없을 정도로 의존하게 되었습니다.

 

이 글은 Git에 대해 막연한 두려움을 느끼는 분들께 도움이 되고자 작성한 블로그입니다.

 

 

 

 

GitFlow

다양한 개발자와 협업을 한다면, 서로 규칙을 정해서 Git을 사용하게 되는데 이를 Git 브랜치 전략이라고 부릅니다.

Git-Flow는 대표적인 브랜칭(branching) 전략 중 하나로 2010년 Vicent Driessen는 Git 작업 절차에 대해 말씀 드리겠습니다. Git-Flow는 브랜치를 크게 5가지로 나누어져있습니다.

 

1. main(master)
2. develop
3. featrue
4. release
5.  hotfix

 

이제 각각의 브랜치에 대해 소개하고, 어떻게 활용할 수 있는지 알아보겠습니다.

 

main 브랜치

제품의 최종 배포 상태를 유지하는 브랜치입니다. 항상 안정적인 상태를 유지해야 하며, 사용자는 main 브랜치의 코드만 직접적으로 사용할 수 있습니다. 그리고 배포된 코드만 포함되기 때문에 배포 태그(e.g., v1.0, v1.1)가 추가됩니다.

 

 

 

develop 브랜치

기능 개발이 통합되는 중간 브랜치로, 모든 기능(feature) 브랜치가 머지되는 곳입니다. 배포 가능한 상태를 유지하지만, 반드시 최종 안정성은 보장되지 않습니다.

 

 

 

Feature 브랜치

특정 기능 개발을 위해 사용되는 브랜치입니다. 보조 브랜치는 새로 변경될 개발코드를 분리하고 각각 보존하는 역할을 합니다. 즉 보조 브랜치는 기능을 다 완성할 때까지 유지하고, 다 완성되면 develop 브랜치로 merge 하고 결과가 좋지 못하면 버리는 방향을 취합니다. 보조 브랜치는 보통 개발자 저장소에만 있는 브랜치고, origin에는 push하지 않습니다.

• 작명 규칙 브랜치 이름: feature/{기능명}

 

 

release 브랜치

배포를 준비하기 위해 develop 브랜치에서 생성됩니다. 마지막 테스트 및 QA 작업이 수행되며, 버전 태그가 추가됩니다. 준비가 완료되면 main에 병합하여 배포되고, develop에도 병합됩니다.

 

 

 

 

hotfix 브랜치

프로덕션 환경에서 발생한 긴급한 문제를 수정하기 위한 브랜치입니다. main 브랜치에서 생성되며, 수정이 완료되면 main과 develop에 병합됩니다. 신속한 배포가 필요할 때 사용됩니다.

 

 

 

장점

브랜치 관리의 명확성

feature, develop, release, hotfix, master 등의 명확하게 구분되는 브랜치 구조를 제공합니다.

 

배포 안정성

release 브랜치에서의 테스트와 QA 과정을 통해 안정성이 검증된 기능들이 master 브랜치로 병합되어 배포되기에 안정성이 높습니다.

 

협업 효율성

여러 개발자가 동시에 작업할 수 있는 환경을 제공을 하거나 개발자들은 서로의 작업에 영향을 주지 않고, 병렬적으로 개발을 진행할 수 있습니다.

 

버전 관리와 롤백

각 버전에 대한 태그를 사용하여 제품의 버전을 관리하며, 이를 통해 특정 버전의 코드를 쉽게 확인하고, 필요한 경우 이전 버전으로 롤백할 수도 있습니다.

 

유지 보수에 용이

hotfix 브랜치를 통해 긴급한 버그 수정이나 보안 취약점에 대한 조치를 즉각적으로 적용할 수 있으며, 이를 통해 문제를 빠르게 해결하고 유지 보수할 수 있습니다.

 

 

단점

복잡성

다양한 브랜치를 사용하기 때문에 초기 설정이 복잡하며, 팀원들이 이해하고 따르기 어려울 수 있습니다. 특히 작은 규모의 프로젝트나 단기적인 작업에는 지나치게 복잡한 구조일 수 있습니다.

 

다소 높은 진입장벽

깃 플로우를 처음 접할 경우, 적응에 어려움이 있을 수 있으며, 각각의 브랜치의 역할과 용도를 이해하고 적절하게 사용하기 위해서는 시간과 노력이 필요합니다.

 

느린 릴리스

주요 기능은 develop 브랜치에 통합되고, 새로운 릴리스는 release 브랜치에서 이루어지다보니 검증이나 테스트 과정이 추가되어 개발의 속도가 느립니다. 따라서 빠른 배포가 필요한 프로젝트에는 적합하지 않을 수 있습니다.

 

팀 규모에 대한 제한

대형 팀이나 복잡한 프로젝트에는 잘 맞을 수 있지만, 작은 팀이나 개인 프로젝트에 적용하기에는 많은 브랜치와 과정이 불필요하고 부담스러울 수 있습니다.

 

유연성의 한계

깃 플로우는 비교적 엄격한 브랜치 전략을 사용합니다. 따라서 예외 상황이나 특별한 요구사항에 대한 대응이 제한적일 수 있는데, 특정 기능이나 수정을 빠르게 배포해야 할 경우에는 깃 플로우의 구조적인 제약으로 인해 어려움을 겪을 수 있습니다.

 

 

GitHub Flow

Github Flow는 깃허브(GitHub)를 기반으로 한 간단하고 유연한 개발 워크플로우로 주요 목표는 신속한 배포와 효율적인 협업을 지원하는 것이다. Github Flow는 Git Flow와 달리 단일 브랜치를 사용하여 개발하는데, 이는 하나의 버전이 만들어지면 바로 배포될 수 있다는 의미이다.

 

 

장점

간단하고 직관적인 구조

일반적으로 master와 develop 두 개의 브랜치만 사용하는 간단한 구조를 가지는데, 전략에 대한 이해와 사용이 쉽고, 프로젝트를 빠르게 시작할 수 있습니다.

 

지속적인 배포

깃헙 플로우는 지속적인 배포(CD)를 촉진합니다.작은 단위로 개발한 기능이나 수정사항을 빠르게 develop 브랜치에서 main로 머지하여 배포할 수 있습니다.

 

유연성과 빠른 피드백

깃헙 플로우는 작은 규모의 변경 사항을 빠르게 테스트하고 검증할 수 있는 환경을 제공하며, 신속하게 사용자에게 제품을 전달하고 피드백을 받을 수 있습니다.

 

충돌 최소화

깃헙 플로우에서는 여러 개발자가 동시에 develop 브랜치에서 작업할 수 있으며, 각각의 작업은 독립적인 브랜치에서 진행되기 때문에 충돌이 발생할 가능성이 줄어듭니다.

 

 

단점

대규모 프로젝트에 제한적

깃헙 플로우는 작은 규모의 프로젝트나 개인 프로젝트에 적합한 전략입니다. 대규모 프로젝트에서는 복잡한 작업 흐름이나 추가적인 브랜치 전략이 필요할 수 있습니다.

 

배포 위험성

깃헙 플로우에서는 develop 브랜치에서 main로 바로 머지할 수 있습니다. 이는 테스트와 검증 절차를 거치지 않았기 때문에 잠재적인 위험성을 포함할 수 있습니다. 따라서 테스트와 검증 과정을 강화하는 방법을 도입하는 게 좋습니다.

 

배포 관리의 어려움

깃헙 플로우는 단일 master 브랜치를 사용하여 배포를 관리하는데요, 이는 동일한 코드 베이스에서 여러 버전을 관리하거나 배포 관리를 세밀하게 제어하는데 어려움을 줄 수 있습니다. 복잡한 배포 요구사항이 있는 프로젝트에는 다른 전략을 고려해야 할 수 있습니다.

 

 

 

따라서 진행하려는 프로젝트의 규모, 배포 방식, 협업 형태, 유지보수 필요성, 그리고 팀원들의 경험과 선호도 등을 종합적으로 고려하여 가장 적합한 Git 브랜치 전략을 선택하는 것이 중요합니다.

 

Git은 단순히 도구일 뿐이지만, 어떻게 사용하느냐에 따라 팀의 생산성과 협업의 효율성이 크게 달라질 수 있습니다. 프로젝트의 성공적인 진행을 위해 팀에 맞는 전략을 찾아 적용해 보시는것을 추천드립니다!!

 

 

 

 

출처

https://velog.io/@gmlstjq123/Git-Flow-VS-Github-Flow

https://sunrise-min.tistory.com/entry/Git-Flow-vs-Github-Flow-%EB%B8%8C%EB%9E%9C%EC%B9%98-%EC%A0%84%EB%9E%B5 

https://overcome-the-limits.tistory.com/7