git flow
이번 글은 Vicent Driessen의 글로부터 정리하게되었다. 거의 그냥 번역해놓은 글이라고 생각해도 무방할 수 있다.
https://nvie.com/posts/a-successful-git-branching-model/
들어가기전에
학교에서 프로젝트를 진행할때 git을 교수님이 쓰라고 하셔서 써본 기억이 있다.
평소에 repo를 그냥 code 저장소로 사용하기만 했었기 때문에 협력 툴로써 git은 처음 사용하는 거였다.
뭐 모든 팀플이 그러듯 해당 과정에서 branch의 의미는 무색해졌고 결국에는 4명이 모두 main에서 작업하는 경이로운 프로젝트가 되었었다.
당시에 이 글만 읽고 진행했어도 더 좋은 git관리를 했을 텐데 아쉬움이 느껴진다.
왜 git일까?
이건 뭐 사실 유튜브에 치기만 해도 엄청나게 좋은 영상들이 많다. 진짜 많아도 너무 많다. 그래서 그냥 유튜브에 검색하는걸 추천한다.
아님 이거 보는것도 좋을거 같다.
한마디로 요약하면 코드의 버전 관리를 위한 툴이고 이걸 활용해서 branching과 merging을 할 수 있는데 이게 협력 툴로써 강력한 기능을 제공해주기 때문에 사용하는 것이 좋다고 볼 수 있다.
탈중앙화와 중앙화를 동시에
프로젝트로 작업하다보면 프로젝트 내에 각자의 역할이 존재한다. 그렇다고 모두가 같은 파일로 이를 진행할 수는 없을 것이다. 하지만 git을 사용하면 각자의 로컬 저장소에서 코드를 수정, 실험 할 수 있다. 그냥 branch를 따서 하거나 fork를 해서 사용하면 될 것이다. 이렇듯 git을 사용하면 탈중앙화된 코딩 환경을 조성할 수 있다. 하지만 결국에는 코드를 합쳐야하기 때문에 pull과 push를 진행할것이다. 따라서 프로젝트의 소스 코드는 중앙화가 될 것이다.
그럼 어떻게 branch를 조성하고 프로젝트를 진행해야 효율적인 프로젝트 관리가 될까? 이제부터 그 이야기를 진행할 것이다.
먼저 전체적인 branch의 개요는 다음과 같다.
Main branch
전체적인 프로젝트의 소스코드를 담당하는 브랜치들로 프로젝트가 생기고 항상 유지되는 브랜치들 이다.
크게 2가지 브랜치가 존재한다.
master배포 하기 바로 전 단계의 브랜치로 최종 검토, 리뷰 등이 완성된 코드들이 모여있다. 프로젝트의 배포 코드들이 이에 해당한다.
developmaster 브랜치는 배포 가능한 코드들이 모여있어야 한다. 그렇다고 여러 branch가 바로 master 브랜치로 merge한다고 항상 코드가 안정적일까? 그러면 참 좋겠다.. 하지만 우리는 merge를 하고 안정화 작업을 해야한다. 따라서 master branch에서 처음 시작지점에 새롭게 branch를 따서 전체적인 개발과정을 진행하는 브랜치를 develop 브랜치라고 하고 대부분의 개발은 이 브랜치에서 진행된다.
Supporting branch
이제 그럼 그냥 develop 브랜치에서 코딩을 하면되겠다! 라고 생각 할 수도 있다. develop 브랜치는 여러 기능들이 합쳐졌을 때 이를 시험하는 브랜치이다. 따라서 우리가 실제로 코딩을 진행할 브랜치들이 존재해야하는데 이들을 Supporting branch라고 이야기한다.
Supporting branch에는 크게 3가지의 브랜치가 존재한다.
- Feature branches
- Release branches
- Hotfix branches
각각의 branch들은 잠시 만들어졌다가 없어지기 때문에 이들이 수행하고 있는 작업에 따라 branch이름이 정해진다.
Feature branch
프로젝트 내에 어떤 기능이 추가어야 할때, 즉 에자일보드에서 티켓이 추가되었을때 생성되는 브랜치로 develop branch로 부터 파생되어진다.
이러한 브랜치는 프로젝트 내에 기능이 개발되는 동안 유지되었다가 기획자가 필요없는 기능이라 하면 버려지거나 아니면 결국에 최종적으로 develop 브랜치에 합쳐질 수 있다.
💡 Branch 이름 [feature/기능요약] ex) feature/login
Release branch
배포를 위한 브랜치로 주로 버그 수정이나 문서 정리등의 업무를 진행하는 branch이다. 여기서 중요한것은 해당 브랜치에서는 많은 기능을 추가하거나 고치지 않는다는 것이다.
단순히 배포를 위한 branch이기 때문에 그러한 기능들은 애초에 feature branch에서 추가되고 develop에 넘어온 상태에 develop에서 안정화 까지 끝난 상태를 가정하고 분기한다.
develop에서 안정화가 된 코드에서 버전 관리와 관련된 내용만 수정되고 나면 이를 master branch와 merge 시켜 최종 배포 코드를 완성 시킨다.
💡 Branch 이름 [release-*] ex) release-1.0Hotfix branches
배포를 한다고 해도 버그가 없을 순 없다. 서비스가 진행됨에 따라 여러 문제 상황이 발생할 수 있기 때문이다. 따라서 배포 버전에서 버그를 수정하는 branch를 만들게 되는데 이를 hotfixes 브랜치라고 한다.
해당 브랜치는 물론 master branch에 적용이 되어야하지만 develop branch에도 적용이 되어야한다. master branch에서 받아오겠다고 현재 개발하는 코드를 빠르게 마무리 짓기는 어렵기 때문이다.
💡 Branch 이름 [hotfix-*] ex) hotfix-1.2.1
전체적인 흐름도를 만들어보면 다음과 같이 표현할 수 있을 것이다.
다음 글은 관련 내용을 실습하는 내용을 정리해보겠다.
