Git Branch Strategy(깃 브랜치 전략)

Just Do It·2022년 1월 23일
0

CS 면접 준비

목록 보기
3/4

학교 과제를 할 때 깃을 사용했는데 혼자 하는 프로젝트다 보니 commit,push 만 알고 있었다. 최근 동기와 같이 프로젝트를 시작했는데 이를 위해 git workflow를 찾다가 전략이 몇 가지 있다는 것을 알게 되었다. Git Flow, GitHub Flow, GitLab Flow 3가지가 있다. 어떤 특징이 있는지 살펴보자

1. Git flow

구조와 흐름

feature > develop > release > hotfix > master 5가지 종류의 브랜치가 존재한다. 병합 순서는 앞에서 뒤로 진행된다.
중심이 되는 브랜치는 masterdevelop 브랜치이며, 이 두개의 브랜치는 무조건 있어야한다. 보조역할을 하는 브랜치인 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 브랜치가 존재한다면, releasehotfix를 병합하여 릴리즈 될 때 반영이 될 수 있도록 한다.

  • 브랜치 나오는 곳: master
  • 브랜치 들어가는 곳: master, develop
  • 이름 지정: hotfix-*

Git flow 특징

장점

  • 명령어가 나와있다.
  • 웬만한 데이터와 IDE에 플러그인으로 존재한다.

단점

  • 브랜치가 많기에 복잡하다
  • 안 쓰는 브랜치가 있으며, 몇몇은 애매한 포지션이다.

2. GitHub flow

구조와 흐름

GitHub flow는 1개의 master브랜치와 pull request방식을 활용한 단순한 브랜치이다. master는 제품이 릴리즈 되는 가장 최신 버전의 브랜치이며, 모든 개발 내용이 master를 중심으로 이루어진다.(git flow의 나머지 브랜치들에 대한 개념이 없다. 그냥 master와 그 이외의 브랜치들로 구성된다)


사용 방법

1. master 브랜치는 언제든 배포가 가능

master는 항상 최신 버전의 상태이며 제품이 릴리즈 되는 브랜치이다.

2. master에서 브랜치를 딴다면 이름을 명확히 할 것

Gitflow와 달리 featuredevelop이 존재하지 않는다. 새로운 기능을 추가하거나 버그를 해결하기 위한 브랜치의 이름은 자세하게 어떤 일을 하는지에 대해 작성한다. Github에서 그 브랜치에서 어떤 일을 진행하는지 알 수 있도록 말이다.

3. 원격 브랜치로 수시로 push할 것

항상 origin에 자신이 하고 있는 일들을 올려 다른 사람들도 확인할 수 있도록 한다.

4. 피드팩이나 도움이 필요할 때, 병합 준비가 완료되었을 때 pull reauest를 생성한다

pull request는 코드 리뷰를 도와주는 시스템이다. 위 상황이 닥친다면 pull request를 날리자.

5. 충분한 리뷰와 토의 후에 master에 병합한다

바로 master에 병합되는 것이기 때문에 충분한 리뷰와 토의 후 반영한다.

6. master로 병합되고 푸시되었을 대는 즉시 배포되어야 한다.

master로 병합이 일어나면 hubot(Github에서 지원해주는 배포 자동화 도구)을 이용하여 자동으로 배포가 되도록 설정해 놓는다.


특징

장점

  • 브랜치 전략이 단순
  • 코드 리뷰를 자연스럽게 사용할 수 있다.
    *CI(빌드 프로세스를 관리하는 서버)가 필수적이며, 배로는 자동으로 진행할 수 있다.

단점

  • CI와 배포 자동화가 되어있지 않은 시스템에서는 사람이 관련된 업무를 진행한다.

3. GitLab flow

Github flow는 배포, 환경 구성, 릴리즈, 통합에 이슈가 많았다. GitLab flow을 통해 이를 보완할 수 있다. Git flow와 Github flow의 절충안 정도로 생각하면 되시겠다.

구조와 흐름

아래 그림과 같이 production브랜치를 둔다. Github flow의 master의 역할을 한다. production은 배포만을 담당한다.

여기에 pre-production 브랜치를 두어 개발한 내용을 곧장 반영하지 않고 시간을 두고 반영할 수 있도록 한다.

4. 참고자료

ujuc님 깃허브
우아한 형제들 기술 블로그
hyeon9mak님 깃허브

profile
조급해 하지 말고 한 계단 한 계단 오르기

0개의 댓글