git-flow.txt

다수의 개발자가 협업을 할 때 branch를 남용하면 개발 과정이 개판이 되기 십상이다.

그래서 git branch를 깔끔하게 만들어주는 방법론이 있는데
gitflow / github flow / gitlab flow / trunk-based 등등... 이 있다.

이런 걸 도입하면 ->
1. branch 관리가 쉬워짐
2. 팀원이 개 많아져도 개발 절차가 매끄러워짐



우선 gitflow 개발전략이 뭔지 알아보자

1. main
2. develop (개발 용도)
3. feature (develop에 기능 추가 용도)
4. release (develop을 main에 합치기 전 테스트 용도)
5. hotfix (main에서 발견된 버그 수정 용도)

크게 5가지의 branch를 운용하는 전략이다.

1. main
최종 빌드 branch, 여기서 개발하지 말 것

2. develop
개발할 때 사용할 branch

3. feature
개발 빌드에 새로운 기능을 추가하고 싶을 때 생성하는 branch
기능이 완성되었다 싶으면 develop에 merge

4. release
develop 빌드가 충분히 완성되었다 싶을 때
main에 merge하기 전에 최종 작업을 수행하는 branch
release 준비가 끝나면 main과 develop에 merge

5. hotfix
main 빌드에서 발견된 치명적인 버그를 급히 수정해야 할 때 사용하는 branch
hotfix 수정이 끝나면 main과 develop에 merge


장점 : 안정적인 버전별 배포 가능
단점 : CI/CD 선호하는 곳에선 안 좋아함



다음으로 trunk-based 전략을 알아보자

main branch를 중심으로 새 기능이 필요할 때 마다 새 branch를 생성했다 merge하는 식으로 작업하면서
main branch를 적절한 때 마다 release하는 전략이다.

github flow도 이와 유사함


장점 : 여러 개의 소스코드를 관리할 필요가 없음
단점 : 테스트를 많이, 자주 수행해야 함 (자동화 반 필수)