메인 브랜치인 master와 develop 브랜치를 사용하고 기능 개발(feature), 릴리스(release), 버그 수정(hotfix)을 위한 보조 브랜치를 사용합니다.
엄격한 브랜치 정책
각각의 브랜치가 특정한 목적을 가지고 있으며, 엄격한 브랜치 정책을 따릅니다.
롤백을 위한 태그 사용
릴리스 브랜치에서 릴리스를 태그로 표시하여 롤백을 용이하게 합니다.
긴급한 버그 수정과 유지보수에 유용합니다
hotfix 브랜치를 통해 긴급한 버그 수정과 유지보수에 유용합니다.
[ 더 알아보기 ] 💡 Git Flow에서 병렬개발을 한다는 말이 무슨 말일까?
- 여러 개발자가 동시에 다른 기능 또는 버그 수정 작업을 진행할 수 있는 것을 의미합니다. - feature 브랜치를 사용하여 각각의 개발 작업을 별도의 브랜치에서 진행합니다. 이렇게 함으로써 개발자들은 독립적으로 작업을 수행하고 개발 작업 완료되면 브랜치로 병합하여 전체적인 개발 흐름을 유지합니다
1. 주요 브랜치
💡 깃 플로우(Git Flow)의 주요 브랜치입니다.
브랜치 이름
설명
master
제품 출시 버전을 관리하는 브랜치입니다.
develop
다음 출시 버전을 개발하는 브랜치입니다.
feature
새로운 기능을 개발할 때 사용하는 브랜치입니다. develop 브랜치에서 분기합니다.
release
다음 출시 버전을 준비하는 브랜치입니다. develop 브랜치에서 분기합니다.
hotfix
긴급한 버그 수정이 필요할 때 사용하는 브랜치입니다. master 브랜치에서 분기합니다.
2. 브랜치의 흐름
💡 깃 플로우(Git Flow) 브랜치의 흐름 1. develop branch - develop 브랜치에서 시작합니다. 이 브랜치는 개발 중인 최신 코드를 포함하고 있습니다.
2. develop branch → feature branch - 기능 개발을 위해 개발자마다 feature 브랜치를 생성합니다. - feature 브랜치는 develop 브랜치에서 분기되며, 개별 기능 개발을 위한 작업을 진행하는 데 사용됩니다.
3. feature branch → (Merge) → develop branch - 기능 개발이 완료되면 feature 브랜치를 develop 브랜치로 병합합니다. - 이를 통해 새로운 기능이 develop 브랜치에 통합됩니다.
4. release branch - release 브랜치를 생성하여 다음 릴리즈를 준비합니다. - 여기서는 버그 수정, 문서 업데이트 및 준비된 기능에 대한 마지막 테스트를 수행합니다.
5. release branch → (Merge) → master branch(=main branch) - 최종적으로, release 브랜치의 코드를 master 브랜치로 병합하여 새로운 릴리즈를 생성합니다.
6. master branch(=main branch) - master 브랜치에 있는 코드는 안정적인 상태로 간주되어 프로덕션 환경에 배포됩니다.
💡 깃허브 플로우(Github Flow) - 가볍고 지속적인 통합과 빈번한 배포를 강조하는 작은 프로젝트에서 단일 브랜치를 중심으로 하는 전략으로 주로 사용이 됩니다.
- 하나의 주요 브랜치인 ‘main(=master) 브랜치’를 기반으로 기능 브랜치를 생성하고 변경 사항을 만들며 변경 사항을 주 브랜치(main)에 병합하는 전략으로 수행됩니다. - 해당 전략은 ‘Scott Chacon’이 2011년도에 제안한 방식으로 Git-flow 방식과는 다른 Git workflow 모델입니다.
개발자들이 메인 브랜치에서 작업하지 않고 각자의 브랜치에서 작업을 진행하고 이후에 메인 브랜치로 병합하는 방식으로 협업합니다.
지속적인 통합과 배포를 지원합니다
개발자들이 자신의 변경 사항이 메인 브랜치와 잘 통합되는지를 지속적으로 확인하고 필요한 경우 배포까지 자동화할 수 있습니다.
코드 리뷰를 위해 풀 리퀘스트를 사용합니다
개발자들이 자신의 변경 사항을 리뷰어에게 요청하고, 리뷰어들은 변경 사항을 검토하고 피드백을 제공할 수 있습니다. 이를 통해 품질을 향상시키고 버그를 예방할 수 있습니다.
협업과 피드백을 중요시합니다
개발자들이 각자의 브랜치에서 작업하며, 다른 개발자들과 소통하고 피드백을 주고받을 수 있습니다. 이를 통해 팀의 협업 능력을 향상시킬 수 있습니다.
롤백을 쉽게 할 수 있는 기능을 제공합니다
예기치 않은 문제가 발생한 경우, 이전의 안정된 상태로 쉽게 돌아갈 수 있는 기능을 제공합니다.
1. 주요 브랜치
💡깃허브 플로우(Github Flow)의 주요 브랜치입니다.
브랜치 이름
설명
main(=master)
주요 개발 브랜치로 실제 배포 가능한 코드가 있는 상태를 유지합니다.
feature(=새로운 기능)
새로운 기능 개발이나 버그 수정 같은 작업을 위해 생성되는 브랜치입니다.
2. 브랜치의 흐름
💡 깃허브 플로우(Github Flow) 브랜치의 흐름 1. main branch - main 브랜치에서 시작합니다. 이 브랜치는 개발 중인 최신 코드를 포함하고 있습니다.
2. main branch → feature branch - 기능 개발을 위해 새로운 브랜치를 생성합니다. - 이 브랜치는 main 브랜치에서 분기되며, 개별 기능 개발을 위한 작업을 진행하는 데 사용됩니다. 3. feature branch → (Merge) → main branch - 기능 개발이 완료되면, 개발한 기능을 main 브랜치로 병합합니다. - 이를 통해 새로운 기능이 main 브랜치에 통합됩니다.
4. main - 테스트 및 리뷰를 거친 후, 안정화된 코드를 프로덕션 환경에 배포합니다.
5. main branch → feature branch - 다른 기능을 개발하기 위해 새로운 브랜치를 생성하고, 위 과정을 반복합니다.
- 규모와 상관없이 모든 종류의 프로젝트에 적합한 전략으로 프로젝트의 작업 흐름을 시각적으로 표현하고 관리하는 데 사용됩니다.
- 이러한 시각적인 표현은 작업의 종류와 상태를 색상으로 표시하여 이해하기가 쉬우며 프로젝트 이슈, 머지, 브랜치 등을 그래프 형태로 확인할 수 있습니다. - 해당 전략은 ‘Sid Sijbrandij’가 2010년도에 제안한 방식으로 Git-flow 방식과는 다른 Git workflow 모델입니다.
[ 더 알아보기 ] 💡 깃허브 플로우(Github Flow)와 깃랩 플로우(Gitlab Flow)의 차이점은 크게 없네?
- 둘 다 main 브랜치에서 시작하여 개발 중인 코드를 관리하고 기능 개발을 위해 새로운 브랜치를 생성하며 완료된 기능을 main 브랜치로 병합하는 과정이 동일합니다. 또한 테스트와 리뷰를 거친 후 안정화된 코드를 프로덕션 환경에 배포하는 것 역시 동일합니다.
- 그러나 깃랩 플로우(Gitlab flow)가 깃 플로우(Git flow)와 깃허브 플로우(Github flow)의 특징을 결합한 방법론이라는 것입니다. - 깃랩 플로우(Gitlab flow)는 개발과 배포를 위한 유연성과 간단한 프로세스를 조합하여 팀이 더욱 효과적으로 협업하고 프로덕션 환경에 안정적인 코드를 배포할 수 있도록 지원합니다.
5) 트렁크 기반 개발(TBD: Trunk-Based Development)
💡 트렁크 기반 개발(Trunk-Based Development)
- 작은 규모의 프로젝트나 소규모 개발팀에서 주로 사용되며 릴리즈 주기가 짧은 프로젝트에 적합한 전략입니다.
- 단일 브랜치를 사용하여 개발을 진행하며 모든 개발자가 동일한 브랜치(트렁크)에서 작업을 합니다. - 개발자는 자신이 작업한 변경사항을 주기적으로 커밋하고 다른 개발자의 변경사항과 통합합니다. 이로써 지속적인 통합과 릴리즈를 강조하며 브랜치 관리에 따른 복잡성을 줄이는 장점이 있습니다.
- 그러나 브랜치 충돌이 발생할 수 있고 변경 사항이 모든 개발자에게 바로 적용되기 때문에 신중하게 사용해야 합니다. - 해당 전략은 ‘Hammant와 Dave Farley’가 제안한 방식으로 다른 Git workflow 모델입니다.
