깃플로우 전략은 CICD가 갖추어져 있을때 더 효과적입니다 영상 내용과 동일하되 master와 develop은 무조건 중간에 release 브랜치를 거치는 형식의 깃플로우 전략을 사용중입니다. 깃플로우 전략은 CICD 환경이 갖추어져있을때 더욱 강력합니다. 크게 dev, stg, prd 환경을 각각 develop, release, master 브랜치와 접목시켜서 3단 테스트 구조를 갖출 수 있습니다. 단순 온프램 환경 뿐만 아니라 클라우드환경, 쿠버 환경에서 모두 통용되어서 되려 더욱 효과적입니다
실무에서는 대부분 test 브랜치나 qa 브랜치같은 거를 만들어서 해당 브랜치에 push 했을 때 테스트 서버, qa 서버에 배포해서 테스트 할 수 있도록 합니다. 저희 실무에서는 develop은 그저 master에 배포하기전 안전한 저장소로 사용만하네요. 이것도 각자 회사에서 정책 플로우가 다르니 입사하면 문조건 깃 플로우가 어떻게 되먹었는지 확인 꼭 하셔야됩니다~
Git flow main : tag(이미 배포 된 플젝) develop : 배포 직전 완성된 플젝 브랜치 feature : 신기능 release: 배포 직전 플젝 임시 브랜치 hotfix: 버그 수정 급한 건 브랜치 Trunk based main 브랜치만 만들고 곁가지를 하나씩 생성 -> 소스 코드 여러개 관리할 필요 없음 테스트 빈번해야 함 소스가 안정화 되어 있는 경우
release 브랜치에서 버그 픽스 등을 위해 커밋이 더 쌓이면 그걸 develop 브랜치에도 merge 를 해줘야 그 이후로 develop 브랜치에서 생겨날 새 브랜치들에서도 release 에서 쌓은 버그 픽스 커밋이 반영이 된 채로 시작할 수 있으니까요. 또, 현재 release 브랜치가 아직 진행중일때, 그 다음 release 를 위해 작업하던 feature 브랜치가 develop 에 먼저 merge 된 경우, 현재 release 브랜치에서 develop 브랜치를 merge 할 때 생길 수 있는 conflict 를 resolve 할 수 있는 가장 적당한 시점이기 때문이기도 합니다.
@@d3v3r_ @데버 예전에 작업물중 클래스가 많이있는 프로젝트를 작업한적이 있었는데, 클래스끼리도 관계가 많이있고 메인에서 싱글톤을 사용하는 클래스도 많이있는 프로젝트여서 예를들어 a라는 사람이 서로 관계되어있는 클래스인줄 모르고 해당 클래스를 수정했다가 이후에 b라는 사람이 a가 수정한지 모르고 업데이트 안하고 커밋을 진행하여 해당 클래스가 컨플릭트 에러나는 경우를 여럿봐서.... 업데이트는 무조건적으로 필요하다고 생각했었어요. 제가 툴을 잘못쓰는것도 있을것 같긴한데 아직 저에게는 어렵네요 ㅠㅠ
