코딩애플의 깃 강의를 보고 정리한 글입니다.
사공이 많으면 배가 산으로 간다는 말이 있습니다.
개발할 때에도 똑같다고 생각합니다. 브랜치가 많으면 프로그램이 산으로 가지 않겠습니까??
개발자 100명이서 브랜치를 마구잡이로 만들고 개발하면 관리하기도 어렵고 추적도 힘이 듭니다.
이런 상황을 관리하기 위해 똑똑한 분들이 만들어 놓은 전략(방법론)들이 있습니다.
이런 방법들을 채택함으로써
- 간편한 브랜치 관리
- 많은 인원들의 개발 절차를 매끄럽게 할 수 있음
등등 많은 이득을 얻을 수 있습니다.
한번 알아봅시다.
git flow
정의
안정적으로 운영이 필요한 개발일 경우에는 git flow 전략이 맞을 수 있습니다.
git flow 전략은 대략 5개의 브랜치로 운용합니다.
- main 브랜치
- develop 브랜치
- feature 브랜치
- release 브랜치
- hotfix 브랜치
- 제일 먼저 개발을 위해 사본을 만들어야 하기 때문에 개발을 위한 develop 브랜치를 생성합니다. 이 develop 브랜치에서 개발을 진행하게 됩니다.
- 여기서 신기능 등을 만들기 위해서 develop 브랜치에서 feature 브랜치를 만들어 기능을 구현하고 develop 브랜치에 merge 하는 방식으로 진행합니다.
- 어느정도 목표를 달성하게 되면 배포를 하기 전 테스트를 하기 위해 release 브랜치를 만들어 여기서 테스트를 하고 보완점을 수정합니다.
- 완료가 되면 main 브랜치에 merge를 진행해 사용자들에게 배포합니다. 또한 개발을 계속해야 하기 때문에 develop 브랜치에도 똑같이 merge를 해줍니다.
- 만약에 배포한 부분에서 급하게 해결해야 할 문제들이 발생한 경우에는 develop 브랜치를 건너뛰어 hotfix 브랜치를 만들어 빠르게 수정하고 main 브랜치에 merge를 합니다. 또한 위에 부분과 똑같이 develop 브랜치에도 merge를 합니다.
요즘은 잘 안쓰는 추세라는데??
Please stop recommending Git Flow!
Git Flow에서 트렁크 기반 개발으로 나아가기 - 맘시터 기술블로그
너무 복잡하고 브랜치가 오래 유지되기 때문에 merge에 어려움이 있다고 합니다.
자세한 내용은 윗 글들을 보시면 될 거 같습니다.
trunk-based
github flow 와도 유사한 전략으로 위에서 본 git flow의 복잡성과 오래 걸리는 배포 라는 단점을 해결해주는 전략입니다.
continuous delivery(지속적 배포) 에 근간을 두어 빠르게 개발을 하고, 검증 후 배포하는 과정들을 진행합니다.
git flow와 다르게 develop 브랜치가 없으며 기능을 개발하고 바로 main 브랜치에 합치게 됩니다.
여기서 생명은 브랜치를 가능한 짧게 쓰는 것 입니다.
또한 바로 main 브랜치에 합치는 만큼 빠른 코드 리뷰와 테스트가 필요합니다. 다시 말해 빠르고 안정적인 커밋을 위한 환경이 구축되어야 한다고 생각합니다.
관리하는 브랜치가 거의 없어 브랜치 관리에 드는 시간을 절감할 수 있으며, 자주 main 브랜치에 합치기 때문에 conflict가 거의 발생하지 않습니다.
하지만 거의 실시간으로 main 브랜치에 merge 하고 배포하는 만큼 테스트등을 자동화 해 놓아야 제대로 사용이 가능합니다.
gitlab flow
git flow와 trunk-based 사이 쯤 되는 전략입니다.
- Master(Main) 브랜치 : develop 브랜치로 여기서 개발을 진행합니다. git flow와 비슷하게 feature 브랜치를 만들어 개발하고 합치는 형식입니다.
- Pre-production 브랜치 : 개발이 완료되었을 때 테스트를 진행하는 브랜치 입니다. git의 staging area 같은 공간입니다.
- Production 브랜치 : 테스트, 검증이 끝난 후 배포를 위한 브랜치로 최종적으로 배포가 되는 곳 입니다.
상남자
코딩 고수들 같은 상남자는 그런거 없고 바로 커밋하고 배포합니다.
