[Git] Git flow vs Github flow

GIt flow와 Github flow의 차이점을 알아보자

Git-flow

Branch의 종류

feature > develop > release > hotfix > master(main)

중심이 되는 브랜치는 develop 브랜치와 master(main) 브랜치이다.

대부분의 작업은 develop 브랜치에서 모아지고 테스트를 통해 버그나 수정사항이 없다면 master 브랜치로 merge 한다.

브랜치 별 특징

Feature branch

부모 가지: develop

병합 가지: develop

이름: master, develop, release, hotfix 를 제외한 자유롭게 네이밍

새로운 기능을 추가할 때 주로 사용한다.

Local server (개발자의 repo)에서 사용한다.

Release branch

부모 가지: develop

병합 가지: develop, master(main)

이름: release-{???}로 많이 사용한다.

새로운 제품을 배포할 때 사용한다.

버그픽스(디버그) 대한 부분만 커밋하도록 하며, 완전히 배포 준비가 완료 됐을 때 master 브랜치로 병합한다.

병합 후 tag를 통해 버전 기록을 남긴다.

Hotfix branch

부모 가지: master(main)

병합 가지: develop, master(main)

이름: hotfix-{???}로 많이 사용한다 제품에 버그가 생겼을 때 빠르게 해결하여 merge한다.

Git-flow의 장단점

장점

명령어가 명료하게 나와있다.

에디터와 IDE에 플러그인으로 많이 존재한다.

단점

브랜치가 많아서 복잡하다.

사용하지 않는 브랜치가 있다. → ex) release 애매한 포지션

Github-flow

Git-flow가 좋은 방식이지만 Github에 적용하기엔 복잡하다 생각해 만들어진 Git 관리 방식

자동화 개념이 들어가 있다는 특징이 있다.

Git-flow에 비해 흐름이 단순하고 규칙도 단순하다.

master(main) 브랜치에 규칙만 명확하다면 나머지 브랜치에는 관여하지 않는다.

PR(Pull Request) 기능을 권장한다.

특징

master(main) 브랜치는 언제나 배포 가능하다.

항상 최신 상태를 유지한다.

master(main)브랜치는 엄격한 규칙을 따른다.

새로운 작업을 시작하고자 master(main)브랜치에서 새 브랜치를 만든다면 어떤 일을 할지 명확한 브랜치 명을 사용한다.

master(main) 브랜치에 비해 자유롭지만 어떤 작업을 하는지 명확한 이름을 사용하는 것을 권장한다.

원격 서버에 수시로 push 해준다.

하고있는 작업을 지속적으로 push 함으로써 팀원들이 작업을 수월하게 확인할 수 있도록 한다.

하드웨어에 문제가 생기더라도 원격 서버에서 백업하여 프로젝트를 진행할 수 있는 장점이 있다.

피드백이나 도움이 필요할 때, 병합 준비가 완료 되었을 때 PR을 생성한다.

Pull Request는 코드리뷰를 도와주는 시스템이다.

Pull Request로 자신의 코드를 공유하며 팀원들의 피드백을 받을 수 있다.

기능에 대한 리뷰와 결재가 끝난 후 master(main)브랜치에 병합한다.

모든 작업이 완료되어 배포 준비가 끝났을 때 팀원들과 충분한 논의 후 병합한다.

master(main)브랜치로 병합 후 push되었을 때는 즉시 배포작업을 수행해야 한다.

master(main) 브랜치에 병합이 됐다면 자동으로 배포가 이루어지도록 설정해놓아야 한다.

배포 자동화가 설정되지 않았다면 수동으로 배포해야 한다.

Github-flow의 장단점

장점

branch가 단순하다.

Github 사이트에서 제공하는 기능을 모두 사용한다.

코드리뷰를 자연스럽게 할 수 있다.

배포 자동화를 사용해 진행할 수 있다.

단점

배포 자동화가 되어있지 않다면 수동으로 매번 배포를 해야한다.

프로젝트 규모가 커진다면 점점 관리에 어려움이 생길 수 있다.

🤔

Git-flow 방식의 시스템은 큰 기업, 어느정도 규모가 있는 프로젝트에서 사용하면 좋을 것 같고, Git-flow 방식은 정확한 시스템만큼 관리 비용이 더 많이 들 것 같다.

큰 기업이 아닌 작은 기업에서는 Github-flow 방식의 시스템을 사용하면 좋을 것 같다. 관리 비용 측면에서도 그렇고 크지 않은 프로젝트에서는 GIt-flow 방식의 관리는 사용하지 않는 브랜치가 있을 것이고, 너무 과한 시스템이라고 생각이 든다.

참고 사이트

https://ujuc.github.io/2015/12/16/git-flow-github-flow-gitlab-flow/

Git flow, GitHub flow, GitLab flow

https://codingtrainee.tistory.com/156

Git Flow와 GitHub Flow의 이해