branch
branch는 직역하면 가지를 의미한다.
개발이라는 긴 줄기에서 가지를 뻗어 각자 자신의 길로 나아가보고 다시 하나의 줄기로 합쳐질 수 있다.
여러명이서 하나의 프로젝트를 진행하게 되면 적절한 branch의 활용은 선택이 아니라 필수라고 생각한다.
협업의 과정에서 다른 브랜치의 변경 내용과 독립적으로 개발이 가능하기 때문이다.
Git branch 전략
이런 branch를 좀 더 효율적으로 사용하기 위해서는 새로운 branch를 만들거나, 여러 branch를 병합할 때 사용할 기준이 필요하다.
어떤 branch를 기준으로 새로운 branch를 만들어야할 지, 지금까지 개발한 내용을 어디에 병합시켜야할 지 명확하게 정해놓지 않으면 결국 branch를 사용하지 않는 것과 효율면에서 크게 다를 것 없이 merge에 대한 스트레스만 쌓일 것이다.
이런 기준을 제시한 것 중 가장 유명한 사례는 Git Flow이다.
Git Flow
Git Flow는 가장 널리 사용되는 Branch 전략 중 하나로
A successful Git branching model이라는 글에서 소개되었다.
사용하는 branch
- master: 프로덕션에 배포할 수 있는 안정된 코드
- develop: 최신 개발 버전
- feature: 새로운 기능 개발, 기능 개발이 완료되면 devleop에 merge
feature/기능이름 - release 배포 준비, 준비가 완료되면 devlop와 master에 함께 merge
- hotfix: 긴급 버그 수정용
GitHub Flow
GitHub Flow는 여러 버전의 어플리케이션을 유지보수할 경우에는 유용하지만 그렇지 않을 때는 너무 복잡하다는 단점이 있다. 이런 단점을 해결하고자 Git Flow 보다 좀 더 간단하고 유연한 전략이 GitHub Flow가 나왔다.
사용하는 branch
- master: 프로덕션에 배포할 수 있는 안정된 코드
- feature(topic): 새로운 기능 개발
작업 흐름
- feature branch 생성
- 개발 및 테스트
- pull request
- 코드 리뷰 및 \merge
- 배포
TODO
현재 진행 중인 프로젝트는 비교적 간단한 프로젝트이고 지난 버전에 대한 유지보수가 필요하지 않으니 GitHub Flow를 사용해서 PR을 적극적으로 활용해봐야겠다.
GitHub Action 쪽에서 merge 전 format check를 알아봐야겠다.
main에 merge할 때 squash 할 것인지, merge 기반으로 할지 rebase 기반으로 할 지 얘기해봐야겠다.
