Git Branch 협업 방법론 정리

전략을 정리하다 보니 2개가 만들어진 것 같은데, 둘 다 괜찮은 것 같아서 공유합니다.

 

Branch 전략 정리-1

전략	장점	단점	적합한 시나리오
Gitflow	명확한 구조, 다양한 작업 유형 분리, 예정된 릴리스 지원, 병렬 릴리스 관리 가능	복잡하고 시간 소요가 많음, 브랜치 관리에 엄격한 규율 필요, 연속 배포에는 적합하지 않음	예정된 릴리스 주기가 있는 프로젝트, 여러 릴리스를 병렬로 관리해야 하는 팀에 적합​​​​
GitHub Flow	단순하고 이해하기 쉬움, 신속한 배포 가능, 자주 작은 변경을 장려	예정된 릴리스 지원 부족, 개발/스테이징/생산 간 명확한 구분 없음	연속 배포 프로젝트, 자주 작은 변경을 선호하는 팀에 적합​​​​​​
GitLab Flow	Gitflow와 GitHub Flow의 요소를 결합, 안정된 릴리스와 연속 배포 지원, 다양한 환경에서의 배포 관리 가능	제대로 관리되지 않으면 복잡해질 수 있음, 브랜치 관리에 엄격한 규율 필요	다양한 배포 환경이 있는 프로젝트, 단순함과 구조 사이의 균형이 필요한 팀에 적합​​​​​​
Trunk-Based Development (TBD)	연속 통합과 신속한 피드백을 장려, 단일 주 브랜치에 중점을 둔 브랜치 관리 간소화, 자주 커밋과 병합을 장려하여 병합 충돌 감소	장기적인 기능 브랜치 지원 부족, 커밋과 병합에 엄격한 규율 필요	연속 통합 및 배포 프로젝트, 중앙집중식 및 간소화된 워크플로우를 선호하는 팀에 적합​​​​​​
Feature Branch Workflow	간단하고 사용하기 쉬움, 작은 프로젝트나 팀에 적합, 집중적인 작은 변경을 장려	릴리스 관리에 대한 명확한 구조 부족	작은 프로젝트나 팀, 엄격한 릴리스 관리 프로세스가 필요하지 않은 프로젝트에 적합​​

Branch 전략 정리-2

워크플로우	요약	장점	단점	적합한 시나리오
Gitflow	릴리스 중심의 작업 흐름에 적합하게 설계된 브랜칭 전략으로, 각각의 브랜치에 엄격한 역할을 부여합니다.	명확한 릴리스 관리와 병렬 개발 지원으로 대형 프로젝트에 안성맞춤입니다.	소규모 프로젝트에는 오버엔지니어링이 될 수 있고, 빠른 이터레이션에는 불리할 수 있습니다.	다양한 릴리스를 동시에 관리해야 하는 대형 소프트웨어 프로젝트.
GitHub Flow	지속적 배포를 염두에 둔 간결한 브랜치 전략으로, 모든 변경사항은 ‘main’ 브랜치를 중심으로 관리됩니다.	배포 주기가 짧고, 코드베이스가 항상 배포 가능한 상태를 유지합니다.	롱런하는 다양한 프로덕션 브랜치를 유지보수해야 하는 경우에는 제약이 있을 수 있습니다.	지속적이고 빠른 배포가 필요한 스타트업 또는 애자일 개발 환경.
GitLab Flow	DevOps 및 CI/CD를 위해 Gitflow를 확장한 모델로, 각 환경에 맞춰 브랜치를 세분화합니다.	스테이징 및 프로덕션 준비 과정이 체계화되어 있어 CI/CD 파이프라인과 잘 통합됩니다.	복잡한 설정이 필요하고, 소규모 프로젝트에는 관리 부담이 클 수 있습니다.	복수의 환경(개발, 스테이징, 프로덕션)을 체계적으로 관리해야 하는 프로젝트.
Trunk-Based Development (TBD)	‘트렁크’ 브랜치에서 모든 개발이 이루어지며, 짧은 생명주기를 가진 피처 브랜치를 활용합니다.	CI/CD에 최적화되어 있으며, 개발자 간 충돌을 최소화하면서 빠른 머지를 가능하게 합니다.	엄격한 CI/CD 실행이 요구되며, 관리가 소홀할 경우 코드의 안정성에 영향을 줄 수 있습니다.	빈번한 릴리스와 빠른 피드백이 필요한 환경에서 강점을 발휘합니다.
Feature Branch Workflow	각 기능이나 이슈별로 브랜치를 생성하여 개발한 후 ‘main’ 브랜치로 합칩니다.	기능별 작업이 격리되어 병렬 개발이 용이하고, 코드 리뷰 프로세스를 강화합니다.	장기간 머지되지 않은 브랜치는 '머지 지옥’을 야기할 수 있으며, 병합 관리에 주의가 필요합니다.	다수의 개발자가 동시에 다양한 기능을 개발해야 하는 상황에 적합합니다.

Feature Branch Workflow

Feature Branch Workflow는 중앙 저장소를 가정하며, master 브랜치는 공식 프로젝트 이력을 대표합니다. 마스터 브랜치에 직접 커밋하는 대신, 개발자들은 새로운 기능 작업을 시작할 때마다 새로운 브랜치를 생성할 수 있습니다. feature 브랜치는 설명적인 이름을 가져야 합니다.

이 유형의 워크플로우를 활용하는 제안된 방법은 직원의 다양한 레벨을 구분하는 계층적 방법을 따릅니다. 브랜치가 마스터로 병합되기 전에, 오류를 검증하고 확인해야 합니다.
주니어 개발자들은 병합 요청을 생성하고 그것을 시니어 개발자 중 한 명에게 할당할 수 있습니다. 그런 다음 시니어들은 코드를 검토하고 필요한 코멘트를 남깁니다. 모든 것이 만족스럽게 진행될 것으로 보이면, 요청이 승인되고 브랜치가 병합됩니다.

• Master 브랜치: 프로젝트의 주 브랜치로, 배포 가능한 안정된 코드를 유지합니다.
• 기능 브랜치들: ‘Feature 1’, ‘Feature 2’, 등과 같이 각각의 기능 개발을 위한 브랜치들이 있으며, 각 기능이 개발될 때 'Master’에서 분기됩니다.
• 병합: 각 기능 브랜치의 개발이 완료되면, 이를 ‘Master’ 브랜치로 병합하여 모든 기능이 통합된 최신 버전을 만듭니다.

장점

• 분업화: 동시에 여러 기능을 개발할 수 있어 프로젝트의 생산성을 높일 수 있습니다.
• 코드 리뷰와 품질 관리: 각 기능 브랜치를 병합하기 전에 코드 리뷰를 통해 품질을 검증할 수 있습니다.
• 유연성: 각 기능의 개발 진행 상황에 따라 독립적으로 관리하고 우선순위를 조정할 수 있습니다.
• 충돌 최소화: 기능별로 브랜치를 나누어 작업하기 때문에, 코드 충돌의 가능성을 줄일 수 있습니다.

단점

• 병합 충돌: 여러 기능 브랜치가 'Master’로 병합될 때 충돌이 발생할 수 있습니다.
• 관리 복잡성: 많은 수의 기능 브랜치를 관리해야 하므로 프로젝트의 복잡성이 증가할 수 있습니다.
• 불규칙한 배포 주기: 기능 브랜치의 개발 진행 상황에 따라 'Master’로의 병합 시점이 달라질 수 있어 배포 주기가 불규칙해질 수 있습니다.
• 지속적 통합(CI) 도전: 각 기능 브랜치가 독립적으로 관리되므로, ‘Master’ 브랜치에서 지속적으로 통합하는 것이 어려울 수 있습니다.

Gitflow

Git Flow는 이 목록에서 가장 잘 알려진 워크플로우입니다.
이는 거의 Feature Branch 워크플로우와 유사합니다.
그러나 차이점은 개발자들이 마스터 브랜치의 하위 브랜치인 개발 브랜치에서 브랜치를 생성한다는 것입니다.*

• Master 브랜치: 언제나 배포 가능한 상태를 유지하는 브랜치입니다. 안정된 릴리스만이 이 브랜치에 병합됩니다.
• Develop 브랜치: 새로운 개발 작업을 위한 기본 브랜치입니다. 이곳에서 일상적인 개발 작업이 진행됩니다.
• Feature 브랜치들: 새로운 기능을 개발하기 위해 'Develop’에서 분기되며, 기능이 완료되면 다시 'Develop’에 병합됩니다.
• Release 브랜치: 새로운 릴리스를 준비하기 위해 'Develop’에서 생성됩니다. 릴리스 준비가 완료되면 'Master’에 병합되고, 태그가 붙여져 릴리스가 됩니다.
• Hotfix 브랜치: 'Master’에서 발생한 긴급한 문제를 수정하기 위해 생성됩니다. 수정이 완료되면 'Master’와 'Develop’에 병합됩니다.

장점

• 구조화된 워크플로우: 각 브랜치의 목적이 명확하여 프로젝트의 구조를 이해하기 쉽습니다.
• 안정적인 릴리스: 'Release’와 ‘Hotfix’ 브랜치를 통해 배포되는 코드의 안정성을 높일 수 있습니다.
• 병렬 개발: 여러 ‘Feature’ 브랜치에서 동시에 작업할 수 있어 개발 속도를 높일 수 있습니다.
• 긴급 수정 용이: ‘Hotfix’ 브랜치를 통해 긴급한 문제를 신속하게 처리할 수 있습니다.

단점

• 복잡성: 작은 팀이나 간단한 프로젝트에는 너무 복잡할 수 있습니다.
• 유지 관리: 여러 브랜치를 관리해야 하며, 브랜치 간의 병합이 빈번하게 일어나야 합니다.
• 배포 지연: 릴리스 준비 과정이 길어져서 배포까지의 시간이 길어질 수 있습니다.
• 지속적 통합(CI) 도전: 각각의 ‘Feature’ 브랜치가 'Develop’에 병합되기 전까지는 지속적 통합이 어려울 수 있습니다.

GitLab Flow

GitLab Flow와 Git Flow의 가장 큰 차이점은 GitLab Flow에 환경 브랜치(예: 스테이징과 프로덕션)가 있다는 것입니다. 이는 기능 브랜치를 병합할 때마다 프로덕션에 배포할 수 없는 프로젝트가 있기 때문입니다.

GitLab Flow는 일련의 지침과 모범 사례를 동반하여 Git Flow를 확장한 것입니다.
이는 프로세스를 더욱 표준화하는 것을 목표로 합니다.

• Master 브랜치: 모든 개발 작업이 이루어지는 기본 브랜치입니다. 이 브랜치의 코드는 스테이징 환경에 배포되어 테스트됩니다.
• Pre-Production 브랜치: 스테이징에서 검증된 코드가 프리 프로덕션으로 이동하여 추가적인 테스트와 안정성 확인을 거칩니다.
• Production 브랜치: 최종적으로, 프리 프로덕션에서 검증된 코드가 프로덕션 브랜치로 이동하여 실제 사용자에게 배포됩니다.

장점

• 단계별 배포: 개발에서 실제 배포까지 여러 단계를 거쳐 코드의 안정성을 보장합니다.
• 환경별 관리: 각 환경(스테이징, 프리 프로덕션, 프로덕션)에 맞게 코드를 관리할 수 있어 실수를 줄일 수 있습니다.
• 테스트와 검증: 프리 프로덕션 단계를 통해 실 배포 전에 충분한 테스트를 진행할 수 있습니다.
• 점진적 배포: 실제 사용자에게 영향을 주기 전에 충분히 테스트하고 점진적으로 배포할 수 있습니다.

단점

• 복잡성 증가: 여러 환경을 관리해야 하므로 워크플로우가 복잡해질 수 있습니다.
• 배포 지연: 각 단계를 거치며 배포까지 시간이 오래 걸릴 수 있습니다.
• 리소스 요구: 각각의 환경을 유지 관리하기 위한 추가적인 인프라와 리소스가 필요합니다.
• 코디네이션 필요: 여러 팀과의 협업과 각 단계 간 코디네이션이 필요합니다.

Github Flow

GitHub Flow는 Git 기반의 소프트웨어 개발 워크플로우 중 하나로, 상대적으로 단순하고 직관적인 방식을 제공합니다. 이 워크플로우는 특히 소규모 팀이나 빠르게 반복하며 개발하는 환경에 적합합니다. 아래에 GitHub Flow의 설명, 장점, 단점을 정리했습니다.

• Master 브랜치: 모든 변경 사항이 최종적으로 병합되는 주 브랜치입니다. 이 브랜치의 코드는 항상 배포 가능한 상태여야 합니다.
• Feature 브랜치: 새로운 기능 개발을 위한 브랜치로, 이 브랜치는 개발 과정 중에 'Master’로부터 분기되어 기능 개발이 완료될 때까지 독립적으로 관리됩니다.
• Bugfix 브랜치: 버그 수정을 위한 브랜치로, 'Master’에서 발견된 버그를 해결하기 위해 임시로 생성됩니다. 수정이 완료되면 다시 ‘Master’ 브랜치로 병합됩니다.

장점

• 분업화: 기능 개발과 버그 수정 작업을 동시에 진행할 수 있어 작업의 효율성을 높일 수 있습니다.
• 안정성: ‘Master’ 브랜치는 항상 안정적인 상태를 유지하며, 버그 수정이나 기능 추가가 필요할 때만 분기를 생성합니다.
• 유연성: 각 기능이나 버그 수정 작업은 독립적으로 진행되므로, 한 브랜치의 작업이 다른 브랜치에 영향을 주지 않습니다.
• 검증과 리뷰: 풀 리퀘스트를 통해 코드 리뷰 및 검증이 이루어지기 때문에, 코드 품질을 유지할 수 있습니다.

단점

• 병합 충돌: ‘Master’ 브랜치로 병합할 때 충돌이 발생할 수 있으며, 이를 해결하는 데 시간이 소요될 수 있습니다.
• 관리 복잡도: 여러 브랜치를 관리해야 하므로, 프로젝트의 복잡성이 증가할 수 있습니다.
• 통합 지연: 기능 브랜치가 'Master’에 병합되기 전까지는 다른 개발자들이 그 기능을 사용할 수 없으므로, 팀 내 협업에 장애가 될 수 있습니다.

Trunk-Based Development (TBD)

이 워크플로우에서는 모든 개발이 ‘Main’ 또는 ‘Trunk’ 브랜치를 중심으로 이루어지며, 개발자들은 짧은 생명주기를 가진 브랜치에서 작업한 후 빠르게 ‘Main’ 브랜치로 병합합니다.

• Main/Trunk 브랜치: 프로젝트의 기본 라인으로, 모든 변경 사항이 이 브랜치로 병합되어야 합니다.
• 짧은 브랜치들: 특정 기능이나 버그 수정을 위한 짧은 기간 동안만 존재하는 브랜치입니다. 작업이 끝나면, 이 브랜치들은 빠르게 'Main’에 병합됩니다.
• 빈번한 병합: 이 방법은 짧은 브랜치들이 자주 그리고 쉽게 ‘Main’ 브랜치로 병합되는 것을 장려합니다.

장점

• 빠른 통합: 변경 사항이 빠르게 ‘Main’ 브랜치로 통합되어, 지속적인 통합의 이점을 누릴 수 있습니다.
• 버그 감소: 짧은 브랜치 기간과 빈번한 병합으로 인해 버그가 발생할 여지가 줄어듭니다.
• 팀 협업 강화: 모든 개발자가 ‘Main’ 브랜치를 기준으로 작업함으로써 협업과 커뮤니케이션이 강화됩니다.
• 배포 준비성: ‘Main’ 브랜치에 있는 코드는 항상 배포 준비가 되어 있어야 하므로, 배포 프로세스가 간소화됩니다.

단점

• 주의 깊은 관리 필요: 빈번한 병합은 주의 깊은 관리를 요구하며, 충돌 해결에 대한 신속한 대응이 필요합니다.
• 짧은 브랜치의 제한: 매우 복잡하거나 오랜 시간이 필요한 기능 개발에는 적합하지 않을 수 있습니다.
• 지속적인 모니터링: ‘Main’ 브랜치로의 빈번한 병합은 지속적인 테스트와 모니터링을 요구합니다.
• 규모의 한계: 매우 큰 팀이나 프로젝트에서는 이러한 빠른 워크플로우가 관리하기 어려울 수 있습니다.

결론

브랜치 전략은 소프트웨어 개발 프로세스의 핵심적인 부분입니다. 각각의 전략은 특정한 프로젝트 요구사항, 팀의 규모, 워크플로우의 복잡성, 배포 빈도 등에 따라 장단점을 지니고 있습니다. 따라서 적절한 브랜치 전략을 선택하는 것은 프로젝트의 성공에 직접적인 영향을 미칩니다.

• 대규모 프로젝트: 릴리스 주기가 길고, 여러 버전을 동시에 관리해야 하는 경우 Gitflow가 적합합니다.
• 지속적 배포: 소규모에서 중규모 팀이 빈번한 배포를 원하는 경우 GitHub Flow 또는 GitLab Flow를 고려해야 합니다.
• CI/CD 중심 개발: Trunk-Based Development는 CI/CD를 엄격히 준수하며 빠른 피드백을 선호하는 팀에 적합합니다.
• 병렬 기능 개발: 여러 개발자가 동시에 다양한 기능을 작업하는 경우 Feature Branch Workflow를 사용하되, Mergfe 지옥을 피하기 위해 정기적으로 ‘main’ 브랜치와 동기화해야 합니다.