Git
[Git] 브랜치 전략
HU_717
2024. 11. 4. 18:47
https://github.com/jeong-sys/BeSum/blob/main/Git/git.md
위의 링크에 들어가면 git에 대한 특강을 듣고 git에 대한 전반적인 내용을 정리해두었다.
그 중 Git의 브랜치 전략에 대해 정리가 필요할 것 같아 정리하려고 한다
Git 브랜치 전략
- 개발자들은 협업을 진행할 때 동일한 소스코드를 다루게 되고, 이때 동시에 여러 작업을 진행할 수 있도록 브랜치를 사용한다
- 여기서, 브랜치 전략이란 여러 개발자가 하나의 저장소를 사용하는 환경에서 저장소를 효과적으로 활용하기 위한 work-flow이다.
- 브랜치 전략이 없다면 개발 과정에서 어떤 기준으로 개발을 수정해야 하고, 배포를 하는 과정에서 어려움을 겪을 수 있다.
Git-Flow 전략
- Git-flow에는 5가지 종류의 브랜치가 있다
- 메인 브랜치인 master, develop / 보조 브랜치(feature, release, hotfix)로 볼 수 있다
- main : 운영 환경에 배포될 수 있는 코드
- develop : 다음 버전 기능이 담긴 코드
- feature : 새로운 기능을 개발하기 위한 브랜치
- release : 새로운 버전의 배포를 위한 브랜치
- hotfix : 운영환경에서 수정해야할 오류가 있을때 생성
Git-Flow 흐름
- 대부분의 작업은 develop에서 취합하며, 더이상 변동사항이 없는 경우 master로의 병합을 진행한다
- 신규 기능 개발
- develop 브랜치로부터 feature 브랜치 생성
- feature 브랜치에서 기능 완성시, develop 브랜치에 merge 진행
- 라이브 서버로 배포
- 모든 feature 브랜치가 develop 브랜치에 merge된 경우 release 브랜치 생성
- release 브랜치에서 오류가 확인된 경우, release 브랜치에서 수정 진행
- QA, 테스트가 모두 통과시, release 브랜치는 master 브랜치로 merge
- release 브랜치 내부에서 오류 수정이 진행 됐을 경우, 동기화를 위해 develop브랜치에서도 merge
- 배포 후 관리
- 배포된 라이브 서버(master)에서 버그 발생시, hotfix 브랜치를 생성하여 버그 픽스 진행
- 종료된 버그 픽스를 master와 develop 양 쪽에서 merge하여 동기화
Github-Flow 전략
- 일반적으로 웹 애플리케이션은 롤백이 되지 않고, 다양한 버전을 제공할 필요가 없다
- Git-Flow사용시, 사용하지 않을 브랜치의 규칙도 학습해야하므로 비효율 적이다
- 이에 Github-Flow를 사용하므로써 잦은 배포 주기를 가지는 프로젝트에 사용할 수 있다
- 자동화 개념이 들어가 있다는 큰 특징이 존재한다
Github-Flow 흐름
- 브랜치 생성
- 새로운 브랜치는 항상 master 브랜치에서 만든다
- feature 브랜치나 develop 브랜치가 존재하지 않는다
- 개발 & 커밋 & 푸쉬
- 개발을 진행하며 커밋을 남긴다
- PR(Pull Request) 생성
- pull request는 코드 리뷰를 도와주는 시스템으로 자신의 코드를 공유하고, 리뷰 받는다
- merge 준비가 완료된경우, master 브랜치로 반영을 요구한다
- 리뷰 & 토의
- 테스트 & 최종 Merge
지금까지 프로젝트를 진행하면서 Git을 많이 사용했었는데 전략이 대표적으로 2가지로 나뉜다는 것을 알게되었다
이전에는 main과 develop에서 feature을 생성한 후, 바로 main으로 merge를 진행했었는데
지금 다시 살펴보니 많은 과정을 빼먹었다는 것을 알게 되었다
또한, 복잡한 Git-Flow와 달리 Github-Flow를 통해 간편하고 쉽게 배포 과정까지 이를 수 있다는 것을 배웠다