Git flow 전략 공부

출처

https://gmlwjd9405.github.io/2018/05/12/how-to-collaborate-on-GitHub-3.html

[GitHub] GitHub로 협업하는 방법[3] - Gitflow Workflow - Heee's Development Blog

 

 

 

Gitflow 란?

 

nive.com 의 "빈센트 드리센"이 제한한 것으로 Gitflow Workflow 라고 부른다. Feature Branch Workflow 보다 복잡하지만, 대형 프로젝트에도 적용할 수 있는 좀 더 엄격한 작업 절차를 가진다.

 

Gitflow Workflow 도 Feature Branch Worflow 와 같이 팀 구성원 간의 협업을 위한 창구로 중앙 원격 저장소를 사용한다. 즉, 다른 Workflow 와 마찬가지로 로컬 브랜치에서 작업하고 중앙 원격 저장소에 push 한다.

 

중앙 원격 저장소, 자신의 원격 저장소, 로컬 저장소의 개념

 

중앙 원격 저장소

 

여러 명이 같은 프로젝트를 관리하는데 사용하는 그룹 계정의 중립된 원격 저장소. Organization 을 만드는 방법은 GitHub 페이지 오른쪽 위에 있는 "+" 아이콘을 클릭하고 메뉴에서 "New Organization"을 선택한다. Organization 의 사용자와 저장소는 팀으로 관리되고 저장소의 권한 설정도 팀으로 관리한다.
(내 원격 저장소가 아닌, 집단 소유의 원격 저장소라고 생각하면 될 듯 하다.)

 

자신의 원격 저장소

 

remote repository 라고 불린다. 파일이 GitHub 전용 서버에서 관리되는 원격 저장소이다.

 

 

로컬 저장소

 

local repository 라고 불린다. 내 파일이 저장되는 개인 전용 저장소

 

Gitflow 흐름

 

프로젝트 참여자는 git clone 명령으로 로컬 저장소를 생성한다.

 

git clone 명령으로 중앙 원격 저장소 (remote repository) 를 복제하여 자신의 로컬 저장소 (local repository) 를 만들 수 있다. 프로젝트 참여자는 이 로컬 저장소에서 작업을 수행한다.

 

 

이 때, fetch 와 pull 의 차이

* fetch :  원격 저장소의 데이터를 로컬에 가져오기만 하기

* pull : 원격 저장소의 내용을 가져와 자동으로 병합 작업을 실행

=> pull = fetch + merge

즉, 단순히 원격 저장소의 내용을 확인만 하고 로컬 데이터와 병합은 하고 싶지 않은 경우, fetch 명령어를 사용한다.

 

 

핵심이 되는 Develop Branch 를 만든다.

 

master 브랜치를 기준으로 develop 브랜치를 만든다. 평소에 develop 브랜치를 기반으로 개발을 진행하기 때문에 develop 브랜치를 default 로 설정한다. 

 

 

팀 구성원 모두가 Gitflow Workflow 를 적용할 준비를 한다.

 

이제 팀 구성원 모두가 develop 브랜치를 local 에 내려 받는다 (checkout)

 

새로운 기능 개발을 위해 격리된 branch 를 만든다.

 

master 브랜치에서 기능 개발을 위한 브랜치를 따는 것이 아니라, develop branch  에서 따야 한다. 로컬 저장소에서 branch 를 따고, 코드를 수정하고, 변경 내용을 커밋한다. 이 기능을 하는 브랜치 이름이 feature 이다.

 

로컬 저장소의 새로운 기능 브랜치를 중앙 원격 저장소에 push 한다.

 

팀이 풀 리퀘스트 (pull request) 를 이용하는 경우, 프로젝트 관리자에게 자신이 개발한 내용을 develop 에 반영해 달라는 풀 리쿼스트를 던진다. 관리자는 개발 내용에 대한 의견을 나눈 뒤, develop 에 병합하는 작업을 한다.

 

=> 만약 pull request 를 이용하지 않는다면, 팀원은 자신이 만든 브랜치를 develop 와 머지한 뒤, push 하는 방법이 있다.

 

중앙 원격 저장소와 자신의 로컬 저장소를 동기화하기 위해 로컬 저장소의 branch 를 develop branch 로 이동한다.

 

 

중앙 원격 저장소의 코드 베이스에 있는 새로운 커밋에 대한 내용을 pull 로 가져온다.

 

이제 새로운 작업을 한 때에는 해당 코드 베이스의 branch 에서 새로운 branch 를 따오면 된다. 그리고, 필요 없어진 feature 브랜치는 삭제한다.

 

 

배포하기

 

만약 develop 브랜치에서 버전 1.2 에 대한 기능이 모두 구현되어 있으면 배포를 위한 전용 브랜치를 사용 배포를 위한 전용 브랜치를 사용해서, 배포 과정을 캡슐화 한다. (배포에 필요한 브랜치만의 Tag 만 노출 할 것이기 때문)

이렇게 함으로써 한팀이 해당 배포를 준비하는 동안 다른 팀은 다음 배포를 위한 기능 개발을 계속 할 수 있다.

버전 번호를 부여한 새로운 release branch 를 develop branch 로 부터 생성해서 배포를 위한 준비를 한다.

=> 이렇게 배포할 준비가 완료되면 master 에 merge 해서 하나의 제품이 될 수 있는 커밋이 되고 develop 모두에도 merge 한다.

 

 

 

버그 수정하기

 

배포한 버전에 긴급하게 수정을 해야할 필요가 있을 때, master 브랜치에서 직접 브랜치를 만들어 필요한 부분만을 수정한 후 다시 master 브랜치에 병합하여 이를 배포해야 한다.

develop 브랜치에 문제가 되는 부분을 수정하여 배포 가능한 버전을 만들기에는 시간도 많이 소요 되고 안정성을 보장하기도 어렵기 때문이다.