본문 바로가기
깃허브

8주차, Git-Flow 이해

by 호놀롤루 2022. 2. 11.

Git-Flow는 Git으로 프로젝트를 개발할 때 쓰는 방법론이다.

 

유용하지만 완벽하다곤 할 수 없으니 각자 개발 환경에 따라 수정해서 잘 쓰면 된다.

 

Git-Flow 는 총 5개 브랜치를 사용해서 운영한다.

 

・ master : 기준이 되는 브랜치, 배포용

・ develop : 개발 브랜치로 개발자들이 이 브랜치를 기준으로 각자 작업한 기능들을 병합하는 브랜치

・ feature : 단위 기능을 개발하는 브랜치로 기능 개발이 완료되면 develop 브랜치와 병합

・ release : master 브랜치에서 배포하기 전에 QA(품질검사)를 하는 브랜치

・ hotfix : master 브랜치로 배포하고, 버그가 생겼을 때 긴급 수정하는 브랜치

 

master 와 develop 이 메인 브랜치, 나머지는 필요에 의해 운영되는 브랜치다.

 

예를 들자면

1. master 브랜치에서 시작

2. 동일한 브랜치를 develop 에도 생성, 개발자들은 develop 브랜치에서 개발 진행

3. 개발 중, 로그인, 회원가입 등의 기능 구현이 필요한 경우, 개발자 1은 develop 브랜치에서 

feature 브랜치를 하나 생성해서 회원가입 기능을 구현, 개발자 2도 develop 브랜치에서 feature

브랜치를 하나 생성해서 로그인 기능을 구현

4. 완료된 feature 브랜치는 검토를 거쳐 다시 develop 브랜치에 병합

5. 이제 모든 기능이 완료되면 develop 브랜치를 release 브랜치로 만들고, QA를 하면서 보완점을

보완하고 버그 픽스

6. 모든 것이 완려되면 release 브랜치를 master 브랜치, develop 브랜치로 보낸다. master 브랜치

에서 버전 추가를 위해 태그를 하나 생성하고 배포,

7. 배포 후 미처 발견하지 못한 버그가 있을 경우 hotfix 브랜치를 만들어 긴급 수정 후 태그를 생성하고

바로 수정 배포

 

react, bootstrap 같이 규모가 있는 개발을 할 경우, 브랜치 보단 Fork 와 Pull requests 를 활용해서

구현한다.

 

Fork 는 브랜치와 비슷하지만 프로젝트를 통째로 외부로 복제해서 개발을 하는 방식이다.

 

그렇게 개발해서 브랜치처럼 병합을 바로 하는 것이 아닌, Pull requests 로 원 프로젝트 관리자에서

머지 요청을 보내면 원 프로젝트 관리자가 Pull requests 된 코드를 보고 기능을 병합하는 방식으로

개발한다.

 

 

'깃허브' 카테고리의 다른 글

깃허브 reset, revert  (0) 2022.03.02
8주차, 깃허브 명령어  (0) 2022.02.11
8주차, 깃허브 개념 이해  (0) 2022.02.11
8주차, 깃허브 remote origin 삭제  (0) 2022.02.10
8주차, 깃허브 .gitignore  (0) 2022.02.10

댓글