gitflow workflow
gitflow를 검색하면 위 이미지와는 달라도 다 비슷한 위 구조를 가진 이미지들이 나온다
복잡해 보이지만 저 동그라미 하나하나 가 브랜치를 뜻한다 하나씩 알아보자
dev / master
이제 master 브랜치는 프로덕션에 배포할 준비가 된 상태만 올리도록 합니다.
그리고 master 브랜치에서 나온 dev 브랜치에서 개발을 합니다.
개발을 마치고, 프로덕션에 배포할 준비가 되면 master 브랜치와 다시 합치게됩니다.(merge)
feature
dev 브랜치에서 기능별로 feature 브랜치를 빼서 개발하고 기능 개발이 완료되면 dev 브랜치에 합칩니다.
hotfix
hot-fix 브랜치는 말 그래도 긴급하게 에러를 고치기 위해 만드는 브랜치입니다. 이 브랜치는 master 브랜치에서 바로 만들어서 프로덕션에서 생긴 이슈를 고치고 master 브랜치로 합쳐서 배포할 수 있도록 합니다.
release
release 브랜치는 dev 브랜치에서 생성합니다. dev 브랜치에서 feature 브랜치들을 만들어서 기능들을 모두 개발하고 합칩니다. 그 다음에 dev 브랜치에서 release 브랜치를 생성하고, 프로덕션을 출시하기 위해서 필요한 코드들만 덧붙이도록 합니다. 그후 master 브랜치에 합칩니다. 또한 dev 브랜치에서는 release 브랜치를 합쳐서 최신 버전으로 유지합니다.
Git Fork Workflow - Forking Repository
위의 브랜치를 이용한 과정들은 한 개의 저장소에서 이루어 지는데 Git Fork Workflow는 저장소를 fork(복제) 해서 협업하는 작업 과정을 말합니다.
위 이미지 처럼 포크한 레퍼지토리에서 각자 개발을 진행 후 메인 레퍼지토리에 합치는 협업 방식이다
위 과정에 gitflow를 적용하여 협업을 진행하는 방식이 가장 안정성이 좋다
참조
