[Git] 깃플로우 개념

깃플로우[Git Flow]란?

- Git으로 개발할 때 거의 표준과 같이 사용되는 방법론이다.

- Git-flow는 기능이 아니고 서로간의 약속인 방법론이다.

Git-flow 방법론에서 사용되는 총 5가지의 브랜치

Git-flow 방법론을 사용하여 Git을 사용할 경우, 2개의 핵심 branch(master, develop)와 선택적으로 사용되는 3개의 브랜치 종류를 사용하여, 운영된다.

• master : 기준이 되는 브랜치로 제품을 배포하는 브랜치 입니다.
• develop : 개발 브랜치로 개발자들이 이 브랜치를 기준으로 각자 작업한 기능들을 합(Merge)칩니다.
  [master에서 나와서(Clone? Branch), release로 갔다가, master로 합쳐짐]
• feature : 단위 기능을 개발하는 브랜치로 기능 개발이 완료되면 develop 브랜치에 합(Merge)칩니다.
  [develop에서 나와서(Clone? Branch), develop로 합쳐짐]
• release : 배포를 위해 master 브랜치로 보내기 전에 먼저 QA(품질검사)를 하기위한 브랜치 입니다.
  [develop에서 나와서(Clone? Branch), 반영 내용을 master, develop로 양쪽으로 보내서 합침]
• hotfix : master 브랜치로 배포를 했는데 버그가 생겼을 떄 긴급 수정하는 브랜치 입니다.
  [master에서 나와서(Clone? Branch), 반영 내용을 master, develop로 양쪽으로 보내서 합침]

master와 develop가 중요한 매인 브랜치이고 나머지는 필요에 의해서 운영하는 브랜치라고 보면 된다

Git-flow 브랜치 전략

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 브랜치를 만들어 긴급 수정 후 태그를 생성하고 바로 수정 배포를 합니다.

다른 Git-flow 진행 방식

- 규모가 큰 개발을 할 경우 브랜치 보다는 Fork와 Pull requests를 활용하여 구현을 합니다.

 

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

- 그렇게 개발을 해서 브랜치처럼 머지(Merge)를 바로 하는 것이 아니라 Pull requests로 원 프로젝트 관리자에서 머지 요청을 보내면 원 프로젝트 관리자가 Pull requests된 코드를 보고 적절하다 싶으면 그때 그 기능을 붙히는 식으로 개발을 합니다.

- PR을 위해서는 개발자의 원격저장소가 필요한 듯?

 

Fork와 Clone의 차이

Fork    : 남의 원격 저장소를 내 "원격 저장소"로 가져오는것
- fork는 남의 원격 저장소(Github Repository)에 불만이 있어서 고쳐보고 싶을 때 사용한다

 

Clone : 어떤 원격 저장소를 내 "로컬 저장소"로 가져오는것

- clone은 어떤 원격 저장소를 내 로컬 저장소에 복사하는것이다

- clone 하기 전의 commit 이력 등의 로그는 보지 못한다

- Fetch와 push로 변경 이력을 업로드 할 수 있다(저장소 내 쓰기 권한이 있는 경우)

- 사용자에게 쓰기 액세스 권한이 없는 경우 분기된 요청을 통해서만 이동할 수 있다. 따라서 이 경우 복제된 리포지토리에서 변경된 사항이 먼저 포크된 리포지토리로 푸시된 다음 풀 요청이 생성된다.

 

** Pull Request(PR)

- 내가 고친게 원본보다 낫다! 싶으면 PR(Pull Request)을 origin에게 보내고, origin의 관리자 또한 그것이 맘에 들면 해당 PR을 받아들여 그 변경사항들이 commit, merge된다

 

 

출처

- https://uxgjs.tistory.com/183?category=832417 [UX 공작소]