Git flow에 관해 간략하게 정리했습니다.

Git Flow 맛보기 정리

git flow는 형상 관리의 전략 중 한가지입니다.

비슷한 예로 MVC를 들어보면

Model, View, Controller로 구성하지 않고 Controller에서 다 해도 되지만

MVC 패턴 같은 전략이 일반적인 경우에 효율적이고

변화에 유연하게 대처할 수 있게 하는 것과 같은 것을

생각해보면 이해하기 쉽습니다. (서버 프로그램 구성에 대한 전략)

이와 유사하게 git flow를 생각해보면,

하나의 프로젝트에 소스코드를 하나로 관리하고

개발자마다 브랜치를 하나씩 따가서 코딩하고

PullRequest로 관리자에게 소스코드 merge하는 전략으로 할 수도 있지만,

git flow 전략을 통해서 관리하는 것이

더 효율적이고 변화에 더 유연하다는 장점이 있습니다.

(협업을 위한 형상 관리 전략)

정리하면, 소스 코드 형상/이력 관리를 효율적으로하고

협업할 때 발생할 수 있는 문제점을 최소화할 수 있는 전략이 Git flow입니다.

git flow 전략 외에도 github flow 와 gitlab flow 전략등도 있다. 
각자에게 맞는 전략을 선택해서 사용하는게 가장 중요하다.

git flow 는 Vicent Driessen 이 제안한 git 의 workflow 디자인에
기반한 브랜칭 모델입니다.

git flow의 종류

git-flow 에서 사용하는 브랜치의 종류는 5가지이며,

크게 항상 유지되는 메인브렌치(master, develop)와

일정 기간 유지되는 보조 브랜치(feature, realease, hotfix)로 나뉩니다.

• master branch : 배포되었거나 배포될 소스가 저장되는 브랜치
• develop branch : 다음 배포를 위해서 개발을 진행하는 브랜치

두 개의 브랜치는 remote repository에 항상 유지되는 브랜치입니다.

master 브랜치는 배포가 될 때마다 태그만 달아주는 형식으로 관리를 합니다.

develop 브랜치는 여러 명의 개발자가 함께 공유하면서 개발을 진행하는 브랜치입니다.

• feature branch : 각 개발자에 의해 기능 단위 개발이 진행되는 브랜치
• hotfixs branch : 배포 버전에 생긴 문제로 긴급한 트러블슈팅이 필요할 때 개발이 진행되는 브랜치
• release branch : 내부적으로 배포할 준비가 되었다고 생각되는 소스가 저장되는 브랜치

feature 브랜치는 프로젝트를 여러 명의 개발자들과 함께 진행할 때,

요구사항에 있는 여러 기능을 적절히 분배해서 개발자들과 일을 나누고 개발한다고 가정해봅시다.

내가 ‘회원가입’ 기능을 개발해야한다면 remote repository에

develop 브랜치로부터 회원가입 기능을 위한 브랜치를 내 로컬에 생성해서 진행한다면,

이 때 내 로컬에 기능을 위해서 생성한 브랜치가 feature 브랜치입니다.

중간에 개발이 진행되면서 “domain 생성”, “db연동”, “암호화 적용” 등의

commit 메세지를 남길 것이고 완료되면 remote repository의 develop 브랜치로

merge되고 이 브랜치는 사라지게 됩니다.

hotfixs 브랜치는 배포버전에 문제가 발생해서 긴급하게 해당 기능만 수정이 필요할 때 사용하는 브랜치입니다.

release 브랜치는 QA로 넘길 소스라고 보면됩니다.

회고.

1월.. 이전에 이미 동기들에게 설명해줬던 내용이고,

해당 과정을 겪으면서 프로젝트를 했음에도 불구하고

갑자기 질문을 받으니 긴장을 해서 대답을 못했습니다.

반성하면서 복습하는 계기가 되었습니다.