Git branch 전략

moontag·2024년 3월 23일

GITHUB-FLOW Trunk Based Development git flow

Git

목록 보기

2/2

토스 프론트엔드 챕터 노션을 구경하다가
초면인 것을 발견(?!)했다.
저게 뭔지 모르기 때문에 검색하다가 글을 쓰게 됐다.

토스 프론트엔드 챕터 노션 페이지

먼저 Trunk-based Development는 git branch 전략 중의 하나이다.
비교를 위해서 git branch 전략의 하나인 Git Flow를 먼저 살펴보겠다.
밑 그림은 git branch 전략을 구글링하다보면 가장 많이 접해봤을 그림이다.

Git Flow

A successful Git branching model - Vincent Driessen이 제안한 브랜치 전략(2010년)
master(main) : 배포된 프로덕션 브랜치
develop : 다음 버전 개발 완료 후 main 브랜치로 머지
features(feature/branch-name) : 기능 개발 후 develop 브랜치로 머지
releases(release/v1.1)
: develop 브랜치에서 따와서 bugfix나 수정을 하고 배포 준비 테스트를 마치면 main, develop 브랜치에 머지
hotfixes(hotfix/v1.1)
: 배포 후 문제 발생 시 main에서 가져와서 문제해결 후 main, develop 브랜치에 머지

💁 누가 사용하는 것이 적합한가요?

안정적으로 관리 가능한 장기간의 릴리스 주기를 가진 팀
병렬적으로 다중 버전관리가 필요한 앱, 라이브러리/프레임워크 등에 적합할 수 있다.
- 앱을 사용자가 업데이트 안할 수도 있기 때문에 이전 버전도 지원해야 함
- 라이브러리/프레임워크들은 특정 버전으로 설치가 가능함.
  예) npm -D react@^16.8.0 react-dom@16.8.0

웹 개발자들은 Git Flow가 복잡해요 🤯

웹 어플리케이션 개발자들은 ...

하루에 여러 번 배포하기도 하는데
복잡한 git flow는 작업 속도를 늦추고, 빠른 개발 사이클과 안맞기 때문입니다.

병렬적으로 다중 버전관리가 아닌, 가장 최신의 단일 버전만을 관리하면 되기 때문입니다.

Vincent Driessen님의 글 상단 "반성문"이라는 코멘트에서 내용을 확인할 수 있다.

GitHub Flow

: GitHub 활용하여 PR, 코드리뷰와 연관되고 빠른 개발 사이클을 돌릴 수 있는 간단한 전략

master(main) : 배포된 브랜치
features : 기능 브랜치
: master에서 파생 - PR - 자동 CI - 테스트 성공 및 코드리뷰 후 머지 - CD

Trunk-based Development

Google, Facebook에서 사용하는 90년대부터 알려진 모델
빠른 릴리스가 가능

trunk(나무 줄기:주요코드)라는 명칭과 branch(나뭇가지:기능,변경사항)를 비유로 사용.

trunk(or main)
features : 짧은 주기를 가진 기능 브랜치
PR - 자동 CI - 테스트 성공 및 코드리뷰 후 머지 - CD

🤔 Github Flow와 똑같은데?

단일 브랜치를 사용한다는 점에서 Github Flow랑 다른게 뭐지?하고 의문이 생겼다. 여기에 대해서 이미 trunkbaseddevelopment 사이트에서도 다뤄주고 있었다.

결론 = 차이점은 release가 진행되는 위치!