학교 과제를 할 때 깃을 사용했는데 혼자 하는 프로젝트다 보니 commit,push 만 알고 있었다. 최근 동기와 같이 프로젝트를 시작했는데 이를 위해 git workflow를 찾다가 전략이 몇 가지 있다는 것을 알게 되었다. Git Flow, GitHub Flow, GitLab Flow 3가지가 있다. 어떤 특징이 있는지 살펴보자
구조와 흐름
feature
>develop
>release
>hotfix
>master
5가지 종류의 브랜치가 존재한다. 병합 순서는 앞에서 뒤로 진행된다.
중심이 되는 브랜치는master
와develop
브랜치이며, 이 두개의 브랜치는 무조건 있어야한다. 보조역할을 하는 브랜치인feature
,release
,hotfix
는 병합을 한 후에 삭제한다. 이제 각각의 브랜치에 대해 알아보자
1. master branch
제품으로 출시될 수 있는 브랜치
- 브랜치 나오는 곳:
develop
,hotfix
,release
- 브랜치 들어가는 곳:
develop
,hotfix
- 이름 지정:
master
그대로 사용
2. develop branch
다음 출시 버전을 개발하는 브랜치
- 브랜치 나오는 곳:
master
,hotfix
,release
- 브랜치 들어가는 곳:
feature
,release
- 이름 지정:
develop
그대로 사용
3. feature branch
새로운 기능을 추가할 때 사용하는 브랜치
feature
는 개발자의 reop에서만 존재하도록 한다.(origin에 반영 X)
- 브랜치 나오는 곳:
develop
- 브랜치 들어가는 곳:
develop
- 이름 지정:
develop
,master
,release-*
,hotfix-*
를 제외한 나머지
4. release branch
이번 출시 버전을 준비하는 브랜치
- 브랜치 나오는 곳:
develop
- 브랜치 들어가는 곳:
develop
,master
- 이름 지정:
master
그대로 사용
5. hotfix branch
발생한 버그들에 대한 작업을 하는 브랜치
수정이 끝나면,develop
,master
에 반영하고master
에는tag
를 해준다.(tag: 주로 릴리즈할 때 사용한다 한다) 만약release
브랜치가 존재한다면,release
에hotfix
를 병합하여 릴리즈 될 때 반영이 될 수 있도록 한다.
- 브랜치 나오는 곳:
master
- 브랜치 들어가는 곳:
master
,develop
- 이름 지정:
hotfix-*
장점
- 명령어가 나와있다.
- 웬만한 데이터와 IDE에 플러그인으로 존재한다.
단점
- 브랜치가 많기에 복잡하다
- 안 쓰는 브랜치가 있으며, 몇몇은 애매한 포지션이다.
GitHub flow는 1개의
master
브랜치와pull request
방식을 활용한 단순한 브랜치이다.master
는 제품이 릴리즈 되는 가장 최신 버전의 브랜치이며, 모든 개발 내용이master
를 중심으로 이루어진다.(git flow의 나머지 브랜치들에 대한 개념이 없다. 그냥 master와 그 이외의 브랜치들로 구성된다)
1. master 브랜치는 언제든 배포가 가능
master
는 항상 최신 버전의 상태이며 제품이 릴리즈 되는 브랜치이다.2. master에서 브랜치를 딴다면 이름을 명확히 할 것
Gitflow와 달리
feature
나develop
이 존재하지 않는다. 새로운 기능을 추가하거나 버그를 해결하기 위한 브랜치의 이름은 자세하게 어떤 일을 하는지에 대해 작성한다. Github에서 그 브랜치에서 어떤 일을 진행하는지 알 수 있도록 말이다.3. 원격 브랜치로 수시로 push할 것
항상 origin에 자신이 하고 있는 일들을 올려 다른 사람들도 확인할 수 있도록 한다.
4. 피드팩이나 도움이 필요할 때, 병합 준비가 완료되었을 때 pull reauest를 생성한다
pull request
는 코드 리뷰를 도와주는 시스템이다. 위 상황이 닥친다면pull request
를 날리자.5. 충분한 리뷰와 토의 후에 master에 병합한다
바로 master에 병합되는 것이기 때문에 충분한 리뷰와 토의 후 반영한다.
6. master로 병합되고 푸시되었을 대는 즉시 배포되어야 한다.
master
로 병합이 일어나면hubot
(Github에서 지원해주는 배포 자동화 도구)을 이용하여 자동으로 배포가 되도록 설정해 놓는다.
장점
- 브랜치 전략이 단순
- 코드 리뷰를 자연스럽게 사용할 수 있다.
*CI(빌드 프로세스를 관리하는 서버)가 필수적이며, 배로는 자동으로 진행할 수 있다.
단점
- CI와 배포 자동화가 되어있지 않은 시스템에서는 사람이 관련된 업무를 진행한다.
Github flow는 배포, 환경 구성, 릴리즈, 통합에 이슈가 많았다. GitLab flow을 통해 이를 보완할 수 있다. Git flow와 Github flow의 절충안 정도로 생각하면 되시겠다.
아래 그림과 같이
production
브랜치를 둔다. Github flow의master
의 역할을 한다.production
은 배포만을 담당한다.
여기에
pre-production
브랜치를 두어 개발한 내용을 곧장 반영하지 않고 시간을 두고 반영할 수 있도록 한다.