Git - git flow & github flow
Git Flow
기본적인 가지의 이름은 아래의 5가지로 구분하곤 한다.
feature > develop > release > hotfix > master
위 순서들은 왼쪽으로 갈수록 포괄적인 가지이며 master branch를 병합할 경우 그 왼쪽에 있는 hotfix 등 모든 가지들에 있는 커밋들도 병합하도록 구성하게 된다.
Git Flow의 구조 및 흐름
앞에서 적었던 기본 구조 5개 중 가장 많이 사용되는 가지는 master와 develop이며 정상적인 프로젝트를 진행하기 위해서는 둘 모두를 운용해야 한다.
나머지 feature, release, hotfix branch는 사용하지 않는다면 지우더라도 오류가 발생하지 않기 때문에 깔끔한 프로젝트 진행을 원한다면 지워뒀다가 해당 가지를 활용해야 할 상황이 왔을 때 만들어줘도 괜찮다.
대부분의 작업은 develop에서 취합한다고 생각하면 된다.테스트를 통해 정말 확실하게 더 이상 변동사항이 없다 싶을 때 master로의 병합을 진행하게 된다.
master가 아닌 가지들은 master의 변동사항을 꾸준히 적용해야한다.
각 branch들의 기능
Feature branch
- branch가 뻗어나오는 곳 : develop
- 뻗어나갔던 branch가 다시 합쳐지는 곳 : develop
- 이름 설정 : master, develop, release-, hotfix-를 제외하기만 하면 자유롭게 이름 설정이 가능하다.
- 새로운 기능을 추가할 때 주로 사용하는 가지이다.
- origin에는 반영하지 않고 주로 개발자의 repo에만 존재하는 경우가 많다.
Release branch
- branch가 뻗어나오는 곳 : develop
- 뻗어나갔던 branch가 다시 합쳐지는 곳 : develop, master
- 이름 설정 : release-*
- 새로운 제품을 배포하고자 할 때 사용하는 branch
- 여태까지 개발한 기능들을 develop branch에서 종합해 release branch를 생성하고 develop에서는 다음번 배포를 위한 새로운 기능 개발에 주력하도록 만들 수 있다.
- release는 디버그에 대한 부분만 커밋하도록 하며, 완전히 배포에 대한 준비가 완료되었다고 판단되었을 때 master로의 병합을 진행하게 된다.
- 병합을 끝내고 난 뒤에는 tag명령을 통해 배포 버전에 대한 기록을 남긴다. (추가적으로 병합한 사람에 대한 정보를 남기고자 할 때는 tag명령에 더해 -s, -u
옵션을 추가한다.) - master로의 병합이 완료되었다면 develop로의 병합도 수행하며 이 때는 release에서 수정된 내용들이 develop에 반영된다.
Hotfix branch
- branch가 뻗어나오는 곳 : master
- 뻗어나갔던 branch가 다시 합쳐지는 곳 : develop, master
- 이름 설정 : hotfix-*
- 제품에서 버그가 발생했을 경우에는 처리를 위해 이 가지로 해당 정보들을 모아준다. 버그에 대한 수정이 완료된 후에는 develop, master에 곧장 반영해주며 tag를 통해 관련 정보를 기록해둔다.
- release branch가 생성되어 관리되고 있는 상태라면 해당 가지에 hotfix정보를 병합시켜 다음번 배포 시 반영이 정상적으로 이루어질 수 있도록 해준다.
- Hotfix는 보통 다급하게 버그를 고치기 위해 생성되는 가지이기 때문에 버그를 해결하면 보통 제거하는 일회성 가지다.
Git FLow의 장단점
장점
- 명령어가 명료하게 나와있다.
- 거의 모든 에디터들과 IDE들에 플러그인으로서 이미 존재하고 있다.
단점
- branch가 뻗어나가는 구조가 복잡하여 관리 등에 어려움이 있다.
- 몇몇 branch는 쓰이지 않을 경우가 있으며 또한 애매한 위치의 branch가 존재한다.
GitHub Flow
Git flow가 좋은 방식이지만 GitHub에 적용하기에는 복잡해서 만들어진 새로운 깃 관리 방식이다.
자동화 개념이 들어가 있다라는 큰 특징이 존재하며 만일 자동화가 적용되어 있지 않은 곳에서만 수동으로 진행하면 된다. Git flow에 비해 흐름이 단순해짐에 따라 그 규칙도 단순해졌다. 기본적으로 master branch에 대한 규칙만 정확하게 정립되어 있다면 나머지 가지들에 대해서는 특별한 관여를 하지 않으며 pull request기능을 사용하도록 권장한다. 
GitHub Flow의 특징
release branch가 명확하게 구분되지 않은 시스템에서의 사용이 유용하다. GitHub자체의 서비스 특성상 배포의 개념이 없는 시스템으로 되어있기 때문에 이 flow가 유용하다.
웹 서비스들에 배포의 개념이 없어지고 있는 추세이기 때문에 앞으로도 Git flow에 비해 사용하기에 더 수월할 것이다.
hotfix와 가장 작은 기능을 구분하지 않는다. 모든 구분사항들도 결국 개발자가 전부 수정하는 일들 중 하나이기 때문이다. 이 대신 구분하는 것은 우선 순위가 어떤 것이 더 높은지에 대한 것이다.
GitHub Flow의 사용 방법
master branch는 어느 때에도 배포가 가능하다. master branch는 항상 최신 상태를 유지하며 stable상태로 product에 배포되는 가지다. master branch는 특별히 엄격하게 규칙을 지정하여 사용하게 된다.
새로운 일을 시작하고자 branch를 master에서 분화한다면 이것의 이름은 어떤 일을 수행하게 될지 명확하게 작성한다. Git Flow와는 달리 feature나 develop branch가 존재하지 않는다. 새로운 기능을 추가하거나 버그를 해결하기 위해 사용하는 가지의 이름은 자세히 어느 일을 맡고 있는지에 대해 작성하는 것을 권장한다. 자세하게 이름을 작성해둔다면 추후 GitHub 페이지에서 프로젝트에 어떤 일들이 진행되고 있는지 더 명확하게 파악할 수 있게 된다.
원격 서버에 수시로 push해준다. Git Flow와 가장 차별화되는 방식으로서 원격 서버에 자신이 하고 있는 일들을 지속적으로 업로드해 팀원들이 수월하게 확인이 가능하도록 만들어야 한다. 이 방식의 장점으로는 하드웨어에 치명적인 문제가 발생해 작업하던 내용이 날아가더라도 서버에서 다시 작업 내용을 백업해 프로젝트를 진행할 수 있다는 것이다.
피드백이나 도움이 필요할 때, 그리고 병합을 위한 준비가 완료되었을 경우 pull request를 생성한다. pull request는 코드 리뷰를 도와주는 시스템이다. request를 활용해 자신의 코드를 공유하며 피드백을 받을 수 있게 된다. 또한 병합을 위한 준비가 완료되었을 때 master branch로 작업 내용을 반영하도록 요청할 때에도 활용할 수 있다.
기능에 대한 리뷰와 결재가 끝난 후 master로 병합한다. 모든 작업이 완료되어 product로서 곧장 반영될 기능이기 때문에 프로젝트에 영향을 미치고 있는 사람들과 충분한 논의를 거친 후 master branch에 반영해야 한다.
master로 병합된 후 push되었을 때는 즉시 배포작업을 수행해야 한다. GitHub Flow의 핵심 가지인 master로 병합이 일어나게 된다면 hubot을 이용해 자동으로 배포가 이루어지도록 설정해놓아야 한다.
GitHub Flow의 장단점
장점
- branch 구성 전략이 단순하다.
- 처음 git에 대해 접하는 사람에게는 좋은 시스템이 되어준다.
- Github사이트에서 제공해주는 기능을 모두 사용해 작업을 진행하게 도와준다.
- 코드 리뷰를 자연스럽게 사용할 수 있다.
- CI가 필수적이며 또한 배포를 자동으로 진행할 수 있다.
단점
- CI와 배포 자동화가 되어있지 않은 시스템에서는 사람이 해당 업무를 진행해야 한다.
- 프로젝트의 규모가 커짐에 따라 점점 관리에 어려움이 발생할 수 있다.
출처 :
https://ujuc.github.io/2015/12/16/git-flow-github-flow-gitlab-flow/
https://codingtrainee.tistory.com/156
