안녕하세요, "악덕"입니다.
오늘은 Git Flow와 GitHub Flow에 대해서 포스팅하겠습니다.
Branch 전략?
Git Branch 전략
여러 개발자가 하나의 저장소에 작업을 할 때, 협업을 좀 더 효과적으로 하기 위해 git branch에 대한 규칙을 정하고 저장소를 잘 활용하기 위한 workflow를 정의하는 것을 바로 git branch 전략이라고 한다. 소프트웨어 개발 팀에서는 프로젝트의 특성에 따라 적절한 브랜치 배포 전략을 채택하는 것이 중요하다.
Git Branch 전략의 필요성
Git branch 전략은 여러 명의 개발자가 동시에 작업할 때 특히 유용하다. 각자 다른 기능을 담당하는 브랜치를 사용하여 작업하면, 개발 중인 기능이나 수정사항이 서로 독립적으로 진행될 수 있다. 또한, 각각의 브랜치가 특정 기능, 이슈에 대응하여 특정 작업을 추적하고, 필요한 경우 작업 단위의 Rollback이 가능하여 프로젝트 관리의 유연성을 향상시켜준다. 각각의 태그는 Release를 원하는 버전 단위로 관리할 수 있도록 하여, 배포 안정성을 향상시켜준다.
Git Flow
브랜치 종류
- master: 제품 출시 버전을 관리하는 메인 브랜치
- develop: 다음 출시 버전을 위해 개발하는 브랜치
- feature: 새로운 기능을 개발하는 브랜치
- release: 다음 출시 버전을 준비하는 브랜치
- hotfix: 출시된 제품의 버그를 고치기 위한 브랜치
Git Flow의 개발 흐름
- 신규 기능 개발을 위해 개발자는 develop 브랜치를 기준으로 feature 브랜치를 따서 작업을 진행한다.
- 작업이 완료된 feature 브랜치는 develop 브랜치로 병합(Merge)된다. 일반적으로 프로젝트 진행 시 Pull Request를 통해 작업 내용을 Review 받은 후 해당 PR을 Merge하는 방식으로 진행한다.
- 다음 출시 버전을 위해 개발 중인 develop 브랜치에서 release 브랜치를 따서 배포를 준비한다. 이 때 발견되는 버그들은 release 브랜치에서 바로 반영한다.
- 충분한 테스트 후, 일정한 주기로 master 브랜치로 Merge하여 제품을 출시한다.
- 상용 배포 이후, release 브랜치에서 미처 발견되지 못한 새로운 버그들은 hotfix 브랜치에 바로 반영한다.
GitHub Flow
GitHub Flow는 쉽게 요약하자면, 브랜치를 하나의 base 브랜치(master)와 master에 기능을 추가하기 위한 브랜치(feature) 두 개만으로 운영하여 훨씬 간단하지만 빠르게 수정 배포할 수 있는 전략이다.
Git Flow와 비교하였을 때 훨씬 간단하다. Git Flow는 다양한 종류의 브랜치를 사용하는 반면, GitHub Flow는 단일 브랜치(master)를 사용한다. 배포는 Git Flow와 동일하게 master 브랜치에서 수행되지만, 그 외의 release, hotfix 등의 다른 브랜치들 대신 하나의 feature 브랜치만이 존재한다.
GitHub Flow의 개발 흐름
master 브랜치는 배포를 위한 소스코드를 관리하는 브랜치이다. 신규 기능 개발이 필요할 때, feature 브랜치를 따서 작업을 진행한다. 태스크가 완료되면, Pull Request를 생성하여 Review를 요청한다. 이 때의 타겟은 master 브랜치이다. 리뷰가 완료되고, 피드백이 모두 반영되면 해당 feature 브랜치를 master 브랜치로 Merge한다.
Git Flow와 GitHub Flow 중 어떤 전략을 사용해야 할까?
Git Flow와 GitHub Flow 다양한 관점에서 두 전략 비교
- 브랜치 수: Git Flow는 다양한 종류의 브랜치를 사용하는 반면, GitHub Flow는 단일 브랜치(master)를 사용한다.
- 배포 방식: Git Flow는 release와 hotfix 브랜치를 통해 명확한 배포 절차를 갖추고 있다. 반면에, GitHub Flow는 단순하며 지속적인 배포를 강조하여 master 브랜치에서 배포를 수행한다.
- 복잡성: Git Flow는 복잡한 프로젝트나 대규모 팀에서 사용하기 좋다. 그러나 이는 작은 팀이나 개인 프로젝트에 적용하기에는 많은 브랜치와 과정이 불필요하고 부담스러울 수 있다. GitHub Flow는 단순하며 빠른 개발 및 배포를 위해 사용된다.
마치며
- ✅ 각각의 전략은 장단점이 존재하기에 프로젝트의 규모, 요구 사항 및 팀의 작업 방식에 맞추어 적절하게 채택하는 것이 좋다.
- ✅ Git Flow는 더 많은 제어와 복잡성을 가지고 있어 특정 기능이나 수정을 빠르게 배포해야 할 경우 등에서 유연성이 다소 떨어진다. 그러나 그만큼 배포 안정성과 버전 관리 및 롤백 등 체계적인 운영이 가능하다.
- ✅ GitHub Flow는 테스트와 검증 절차를 거치지 않고 바로 master 브랜치로 Merge 되므로 위험성을 가지고 있다. 하지만 그만큼 단순하고 빠르게 기능을 테스트하고 Agile 하게 배포할 수 있기 때문에, 주로 각 환경의 구분이 명확하지 않고 작은 규모의 프로젝트에 적합한 전략이다.
📚 공부한 내용을 작성하다 보니 피드백은 언제나 환영입니다!!!
원본링크:https://virtue14.tistory.com/entry/Git-Flow-VS-GitHub-Flow
'ETC' 카테고리의 다른 글
| Github Subtree 과연 이슈 발행도 적용될까? (0) | 2024.07.29 |
|---|