1. Git Flow 전략
- Vincent Driessen이 그의 블로그에 2010년 올린 "A successful Git branching model" 글의 브랜치 전략.
Main
- 이 브랜치는 항상 제픔 릴리즈 버전을 나타낸다.
- 출시 가능한 프로덕션 코드를 모아두는 브랜치.
- 프로젝트 시작시 생성되며, 개발 프로세스 전반에 걸쳐 유지된다.
- 배포된 각 버전을 Tag를 이용해 표시해둔다.
- 모든 코드 변경사항은 이 브랜치로 머지되어 배포된다.
Develop
- 개발중인 코드의 최신 버전을 포함하고 있다.
- 다음 버전 개발을 위한 코드를 모아두는 브랜치.
- 새로운 기능 추가나 버그 수정과 같은 모든 작업은 Develop 브랜치에서 시작하며 통합/테스트 후 Main브랜치로 머지된다.
Feature
- 각 새로운 기능은 별도의 Feature브랜치에서 개발된다.
- 하나의 기능을 개발하기 위한 브랜치.
- 이 브랜치는 Develop브랜치에서 파생된다.
- 기능 개발이 완료되면 Feature브랜치는 Develop브랜치로 머지된다.
- 머지할 때 Fast-Forward로 머지하지 않고, Merge Commit을 생성하여 머지해주어야 히스토리가 특정 기능 단위로 묶이게된다.
- 브랜치 이름은 "feature/branch-name"과 같은 형태로 짓는다.
Release
- 새로운 릴리즈를 준비하기 위해 사용된다.
- 이 브랜치는 릴리즈 버전을 준비하는 동안 사소한 버그 수정과 버전이름 등의 릴리즈 관련 문제를 처리하는데 사용된다.
- 보통 Realease브랜치는 Develop브랜치에서 파생되며, 마지막 준비가 끝나면 Main 브랜치와 Develop브랜치 둘 다에 머지된다.
- 이 때 Main브랜치에는 태그를 이용해 버전을 표시한다.
- Release브랜치를 따로 운용함으로써, 배포업무와 관련없는 팀원들은 병렬적으로 Feature 브랜치에서 이어서 기능을 개발할 수 있다.
- 브랜치 이름은 "release/v1.1" 과 같은 형태로 짓는다.
Hotfix
- 프로덕션 환경에서 발견된 긴급한 버그 수정을 위한 브랜치.
- Hotfi브랜치는 Main브랜치에서 파생되며, 수정이 완료되면 Main 브랜치와 Develop 브랜치로 둘 다에 머지된다.
- Hotfix 브랜치를 따로 운용함으로써 핫픽스 업무와 관련없는 팀은 병렬적으로 기능개발을 할 수 있다.
- 브랜치 이름은 hotfix/v1.0.1 과 같은 형태로 짓는다.
2. GitHub Flow
- GitFlow 전략에 비해 더 간단하고 쉬운 구조.
- GitHub자체의 서비스 특성상 배포개념이 없는 시스템으로 되어있기 때문에, GitHub Flow가 유용하다.
- 개발팀이 소규모일 경우, 또는 제품이 단일 릴리즈 버전밖에 존재하지 않을 경우 GitHub Flow가 적절하다.
- 대부분의 웹 어플리케이션은 여러 버전을 관리하지 않고, 가장 최신 버전 하나만을 사용자가 사용하기때문에 GitHub Flow가 적합하다.
- 자동화를 적극 활용한다.
Main
- 언제 배포하든 문제가 없는 상태를 항상 유지한다.(stable한 상태)
- 언제든 브랜치를 새로 만들어도 문제가 없어야한다.
- Main브랜치의 모든 커밋은 빌드가 되고, 테스트를 통과해야한다.
- 다른 브랜치를 만들 경우, 항상 Main브랜치에서 만들어야한다.
Topic
- 새로운 기능을 개발하는 브랜치.
- Main브랜치로부터 파생된다.
- GitFlow 전략의 Feature브랜치와 동일한 역할을 한다.
- 버그수정도 Topic브랜치에서 진행한다.
- 이 때 Topic 브랜치의 이름은 기능을 설명하는 명확한 이름으로 지어야한다.
- Topic브랜치의 커밋은 기능이 완성되지 않았더라도 꾸준히 push한다.
- 노트북 분실 등의 위험으로부터 코드 유실을 막기위해
- 구성원 모두가 끊임없이 커뮤니케이션 할 수 있도록
PR생성
- 기능개발 중 언제든 PR을 개설할 수 있다.
- 피드백이나 도움이 필요할 때에 생성할 수도 있다.
- 코드의 변경 없이 스크린샷, 아이디어 공유를 원할때에도 생성할 수 있다.
- 코드리뷰와 토의를 도와주는 시스템이다.
- 코드리뷰와 토의가 끝났다면 다른사람들의 approval을 얻고 Main브랜치에 자신의 Topic브랜치를 머지한다.
- 이 때, Topic브랜치는 자동화된 CI빌드를 통과해야 머지가 가능하다.
3. GitLab Flow
- GitHub Flow에 배포, 릴리즈 등의 조금 복잡한 이슈를 보완하기 위해 나온 전략.
Main
- GitFlow의 develop 브랜치와 동일한 역할.
- feature브랜치에서 병합된 기능을 테스트한다.
- 전체적인 테스트가 진행되어 기능에 대한 보장이 되었다면 production브랜치로 머지한다.
- 만약 staging단계를 원한다면 pre-production브랜치로 머지한다.
Feature
- 모든 기능을 구현하는 브랜치.
- main브랜치에서 파생되어 main브랜치로 머지된다.
Production
- GitFlow의 main브랜치와 동일하다.
- 테스트가 끝난 기능에 대해 배포를 하기 위한 브랜치.
Pre-production
- main -> production 브랜치 사이에 pre-production브랜치를 두어 변경사항을 바로 production에 배포하지 않는다.
- 테트스서버에 배포하여 통합테스트를 진행하거나 시간을 두고 반영하는 브랜치.
4. (Scaled)Trunk Based Development
- 언제나 릴리즈 가능한 상태인 Trunk브랜치에서 모든 개발자들이 각자 자기 작업을 진행 후 커밋한다.
- 단일브랜치에서 모든 작업을 할 수도 있고, 짧은 주기의 Feature브랜치를 생성하여 작업을 진행할 수도 있다.
필요요소
- 자동화 빌드
- 작업한 내용을 실시간 빌드하면서 코드에러가 발생하는 부분이 없는지 확인이 가능해야한다.
- trunk에 반영되기 전에 로컬에서 돌아간 결과를 바탕으로 문제가 없다는 것이 확인이 된 후 반영되어야한다.
- 문제가 없다면 바로 운영환경에 배포된다.
- TDD
- TDD방식으로 작업함으로써, 작업내용이 trunk에 반영되기 전 에러를 파악하고 미리 조치해야한다.
- 실시간 코드 리뷰 및 페어 프로그래밍
- 작업사항이 빠르게 검토되고 빠르게 반영되어야한다.
참조:
https://hudi.blog/git-branch-strategy/
https://brownbears.tistory.com/605
https://velog.io/@fzerome240/Trunk-Based-DevelopmentTBD-%EC%A0%84%EB%9E%B5%EC%9D%B4%EB%9E%80
'Git' 카테고리의 다른 글
| Git - branch merge 방법 (1) | 2023.09.14 |
|---|---|
| Git / GitHub (정의, 시작하기) (0) | 2023.09.13 |
| 크라켄, 이클립스 관련 (0) | 2023.03.13 |
| Git/ Github (0) | 2023.03.13 |
