깃허브를 사용해서 프로젝트를 진행하다 보면, 브랜치가 너무 여러개 만들어지고 각각의 브랜치가 어떤 역할을 하는지 명확히 이해를 하지 못했던 경험이 있다. 이런 문제는 브랜치 전략을 통해서 해결이 가능하다. 브랜치 전략이란 repo 를 효율적으로 활용하기 위해 브랜치에 규칙을 부여하는 것이다. 예제를 통해서 하나씩 이해해보자.
Gitflow
-
gitflow 에서는 master, hotfixe, release, develop, feature 총 5개의 브랜치가 있다.
-
master: 최종 배포 코드가 담겨 있는 브랜치
-
hotfix: 배포 환경에서 문제가 발생했을 때 빠르게 오류 수정을 위해 사용하는 브랜치
-
release: 배포 이전에 (master 브랜치로 보내기 이전) 요구사항들을 점검하는 브랜치로 develop 브랜치를 merge 해서 만든다.
-
develop: feature 브랜치에서 기능 개발이 완료된 후 (테스트를 거친 후에) 합쳐지는 개발 브랜치
-
feature: 기능 개발을 하는 브랜치
feature & develop 브랜치 예시
1) feature-login 브랜치에서 로그인 기능에 필요한 코드를 작성하고, 테스트를 진행
2) 로그인 기능 개발이 완료되고 충분한 테스트를 거친 후, feature-login 브랜치를 develop 브랜치로 병합
Gitflow 전략은 각 역할이 명확하게 구분되는 브랜치 구조를 기반으로 효율적인 개발이 가능하다. 따라서 개발자들은 서로의 작업에 영향을 주지 않고, 병렬적으로 개발을 진행할 수 있다. 하지만 다양한 브랜치를 사용하기 때문에 복잡성이 높고 develop 브랜치에 통합되고, 새로운 릴리스는 release 브랜치에서 이루어지다보니 검증이나 테스트 과정이 추가되어 개발의 속도가 느리다는 단점이 있다.
Github flow
Git-flow가 Github에서 사용하기에는 복잡하다고 나온 브랜치 전략이다. 신속한 배포와 효율적인 협업을 지원하는 것을 목표로 한다. Git-flow는 master 브랜치에서 분기하고 분기한 브랜치는 master 브랜치로 merge 하는 단순한 구조를 가진다.
-
master: 이 브랜치는 항상 배포 가능한 상태를 유지한다. 모든 개발이 완료되고 충분히 테스트된 코드만이 master 브랜치에 병합된다.
-
feature: 새로운 기능 개발이나 버그 수정을 위한 작업이 이루어지는 브랜치
-
hotfix: 프로덕션 환경에서 긴급하게 수정해야 할 버그가 발견되면, master 브랜치로부터 hotfix 브랜치를 분기하여 문제를 해결한다. 수정이 완료되면, 이 브랜치는 바로 master 브랜치로 병합
Github flow는 간단하고 직관적인 구조를 가짐으로써 전략에 대한 이해와 사용이 쉽워 프로젝트를 빠르게 시작할 수 있다. 또한 여러 개발자가 동시에 develop 브랜치에서 작업할 수 있어 충돌을 최소화 할 수 있다. 하지만 develop 브랜치에서 master로 바로 머지할 수 있기 때문에 잠재적인 위험성을 내포할 수 있다.
fork & pull request
규모가 있는 프로젝트인 경우 Fork와 Pull requests를 활용하여 구현을 한다. 메인 저장소를 통채로 Fork를 떠서 각자만의 repo 에서 개발을 진행하는 방식이다. 그리고 개발이 완료되면 pull request를 날린다.
📄 Reference
