1. Git Flow 개념
1) 개념 정리
-
Git Flow는 Git을 통해 효율적으로 협업할 수 있는 방법론 중 하나로,
현재 Git으로 개발할 때 거의 표준과 같이 사용되는 방법론이다. -
서로간의 약속인 방법론이기에 각자 개발 환경에 따라 수정하고 변형해서 활용하면 된다.
Git Flow 브랜치 종류
- master: 기준이 되는 브랜치로 제품을 배포하는 브랜치
- develop: 개발 브랜치로 개발자들이 이 브랜치를 기준으로 각자 작업한 기능(feature)들을 합칩니다.(merge)
- feature: 단위 기능을 개발하는 브랜치로, 기능 개발이 완료되면 develop 브랜치에 합칩니다.
- release: 배포를 위해 master 브랜치로 보내기 전에 먼저 QA를 하기 위한 브랜치
- hotfix: master 브랜치로 배포를 했는데 버그가 생겼을 때 긴급 수정하는 브랜치
🔗 출 처: UX 공작소
1. 일단 master 브랜치에서 시작을 합니다.
2. 동일한 브랜치를 develop에도 생성을 합니다. 개발자들은 이 develop 브랜치에서 개발을 진행합니다.
3. 개발을 진행하다가 회원가입, 장바구니 등의 기능 구현이 필요할 경우 A개발자는 develop 브랜치에서 feature 브랜치를 하나 생성해서 회원가입 기능을 구현하고 B개발자도 develop 브랜치에서 feature 브랜치를 하나 생성해서 장바구니 기능을 구현합니다.
4. 완료된 feature 브랜치는 검토를 거쳐 다시 develop 브랜치에 합칩니다.(Merge)
5. 이제 모든 기능이 완료되면 develop 브랜치를 release 브랜치로 만듭니다. 그리고 QA(품질검사)를 하면서 보완점을 보완하고 버그를 픽스합니다.
6. 모든 것이 완료되면 이제 release 브랜치를 master 브랜치와 develop 브랜치로 보냅니다. master 브랜치에서 버전추가를 위해 태그를 하나 생성하고 배포를 합니다.
7. 배포를 했는데 미처 발견하지 못한 버그가 있을 경우 hotfixes 브랜치를 만들어 긴급 수정 후 태그를 생성하고 바로 수정 배포를 합니다.
2) 적용하기
위 개념을 이번주에 작업했던 인증 / 인가 develop에 적용시켜 본다면?
- 우선 master 브랜치에서 시작한다.
- 동일한 브랜치를 develop에도 생성한다.
- 이 때 develop은 인증 / 인가 develop에 해당
- 개발을 진행하며 feature 브랜치를 생성한다.
- feature-signup
- feature-login
- feature-oauth2.0
- 완료된 feature 브랜치는 검토 (pull-requests 신청과 같은 검토)를 거쳐 develop에 merge한다.
- 모든 기능( 위에 회원가입, 로그인, oauth2.0 기능들)이 완료되면 release 브랜치로 checkout 한다.
- 이 때 발생하는 간단한 버그들은 release 브랜치에서 해결한다.
- 모든 버그 수정이 완료되면 release 브랜치를 master와 develop 브랜치로 보내준다.
- 이 경우 master에서는 Tag를 만들어주며, 해당 버전의 태그를 명시해주면 좋다.
- 만약 배포를 했는데 미처 발견하지 못한 버그가 있을 경우, hotfix 브랜치를 생성하여 긴급 수정 후 태그를 생성하고 바로 수정 배포를 한다.
3) 실제 작업과정과 비교
-
우리 팀은 물론 Git Flow에 대해 늦게 접했지만 (오늘 알았다..) 그래도 그동안 협업해오며 체감했던 불편함을 바탕으로 위와 같이 기능 별 브랜치를 생성하여 작업하고 pull-requests를 통해 서로의 코드를 검토(리뷰)하며 master 브랜치에 merge하는 방법을 택했다.
-
오늘 Git Flow에 대해 공부해보니, 그래도 우리가 작업한 것은 master - feature 브랜치 정도는 구현했구나 라는 생각이 들었다.
- 개인적인 생각이지만 사실 3명이 협업하고 있기에 그렇게 문제가 될 것 같진 않다.
-
다만 협업의 규모가 커지거나, 실제 회사에 들어가서 개발을 하게 된다면 적어도 Git Flow와 같은 명확하고 체계적인 Git 사용 규칙이 필요할 것 같다는 생각이 들었다.
-
개발은 혼자하는 것이 아니므로! 나중에 다시 참고하기 위해 정리했다.
4) 개발 현황
- 현재 MVP 목표로 잡았던 서버 API들을 대부분 구현한 것 같다.
- 아무래도 그동안 체감했던 불편함을 바탕으로 최대한 효율적으로 협업하는 방법을 터득한 것 같다.
- 물론 팀원들과 합이 잘 맞아서 더욱 효과적으로 작업이 진행된 점도 있다.
- 원래 목표는 MVP 서버 API를 빠르게 구현하고 웹 소켓 혹은 웹 RTC에 대한 학습을 이어나가는 것이었는데, 이 속도라면 충분히 도전해볼만 할 것 같다.
- 이제 실전 프로젝트 4일차..! 나머지 기간도 화이팅!!!
