오늘은 gitflow-workflow에 대해 배웠다.
다음주면 프로젝트 기간에 접어들텐데, 이제 '진짜 github'를 사용할 시기가 다가온 것 같다. 지금까지 내가 사용해 온 git은, 하나의 branch에 내 소스를 push하고, 코드캠프에서 진행하는 알고리즘 테스트나 과제를 pull request하는게 다였다. 크게 어떻게 git에서 관리되는지 이해를 크게 못했는데, 오늘에서야 전반적인 흐름을 이해할 수 있었다.
왜 git을 이용하면 협업시 유리한지, 어떤식으로 각각의 소스코드를 하나의 파일로 합칠 수 있는지 등 평소 궁금증을 해소할 수 있었던 아주 유익한 시간이었다.
하지만 아직 프로젝트를 해본 것이 아니라 이론 중심으로 내가 이해한 내용을 적어보겠다.
gitflow-workflow 실제 과정
기존의 내가 사용하던 유일한 branch인
master는 협업시에는 프로덕션에 배포할 준비가 된 상태만 올리도록 한다.
그리고 실제 개발은 master 브랜치에서 나온dev브랜치에서 이루어진다.이 과정을 협업하는 상황에 대입하면, 팀장이 git repository를 하나 만들고, 이를 모든 팀원들이
fork한 뒤,git clone을 해서 팀원들마다 각자 맡은 기능별 브랜치를 만들어서 기능을 구현하는 것이다.각자 개발을 마친 후 ,
pull request를 통해 dev 브랜치에서 합친다. 이를 다음날 코드리뷰를 하면서merge하던지 아니면, reject한다.이런 반복적인 과정을 거쳐 프로덕션에 배포할 준비가 되면 master 브랜치와 다시 합치면 된다.
추가적으로 hotfix와 release branch 역할을 하는 branch를 생성해 이용하는 경우도 있다고 한다.
hotfix 브랜치
hot-fix 브랜치는 말 그래도 긴급하게 에러를 고치기 위해 만드는 브랜치로, 이 브랜치는 master 브랜치에서 바로 만들어서 프로덕션에서 생긴 이슈를 고치고 master 브랜치로 합쳐서 배포할 수 있도록 한다.
release 브랜치
release 브랜치는 dev 브랜치에서 생성해 dev 브랜치에서 feature 브랜치들을 만들어서 기능들을 모두 개발하고 합치는 역할을 한다. 그 다음에 dev 브랜치에서 release 브랜치를 생성하고, 프로덕션을 출시하기 위해서 필요한 코드들만 덧붙이고 master 브랜치에 합친다. 또한 dev 브랜치에서는 release 브랜치를 합쳐서 최신 버전으로 유지해야 한다.
참고자료
: https://nvie.com/posts/a-successful-git-branching-model/
: 코드캠프 강의자료
