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