<aside> 📌 Git Flow 전략이란?

</aside>

• Git을 사용하여 개발하는 환경에서 Branch간의 문제없이 배포까지 안정적으로 할 수 있도록 Branch를 관리하는 전략이다.

<aside> 📌 Git Flow 설명

</aside>

1. Main(=Master)
   • 실제 운영환경에 나가있는 코드만 가지고 있다.
   • 조심스럽게 다뤄야하고 안정적인 코드만 들어가있어야 한다.
2. Dev(develop)
   • **develop브랜치**는 **main브랜치**를 base로 생성된 브랜치다.
   • 다음 배포에 사용할 코드작업 내용을 **main으로 바로merge**해서 합치는것이 아니라 **develop브랜치**에서 **feature(브랜치)**를 따서 작업을 진행하고 완성한 **feature브랜치**를 다시 **develop브랜치**에 **merge**를 해서 작업본을 전부 **develop 브랜치**에 합친 후 개발서버나 개발 환경에서 이 브랜치를 기준으로 테스트를 통해 검증하도록 하는 브랜치다.
3. Feature
   • 어떤 개발을 진행할때 **feature**를 따서 브랜치를 새로 만들고 그 브랜치 내부에서 개발을 진행하고 작업내용을 커밋하고 최종적으로 브랜치의 작업본 코드가 완성이 되었을때 완성된 **feature 브랜치**를 **dev 브랜치**에 **merge**를 하게된다.
4. Release
   • 배포하기전에 완성된 develop브랜치를 기준으로 release브랜치를 생성한다.
     • 이건 snapshot을 뜨는 느낌이다.
   • release 브랜치가 생성된 시점부터는 develop브랜치의 작업을 진행하지는 않고 release브랜치에 작업을 추가해야 한다.
   • release브랜치가 생성되었으면 develop 브랜치에서 feature를 생성하는게 아니라 release브랜치를 기준으로 feature를 따서 작업을 하고 release브랜치에 merge를 해주면 된다.
     • 이러면 당연히 develop에는 완성된 코드가 merge되어있지 않을것이다.
     • release오류를 다 수정하고 완성했으면 main branch에 merge를 해준다.
     • 이후 main에 추가된 작업 내용을 develop 브랜치에 merge하여 main과 develop 브랜치의 Sync를 맞춰준다.
       • main과 develop의 Sync를 맞추는 이유
   • 이제 서버에 배포를 하고 개발테스트까지 끝나면 이걸 다시 **main브랜치**로 **merge**하고 **main브랜치**를 운영환경에 배포하게 된다.
5. Hotfix
   • 의도치 않은 갑작스러운 장애상황이 발생했을때 다른곳에서 branch를따면 작업이 오래걸리기때문에 **main브랜치**에서 바로 **hotfix브랜치**를 따고 수정할 부분만 최소한의 코드를 수정해서 **commit**하고 **main브랜치**에 **hotfix브랜치**를 **merge**를 한 후 **main브랜치**로 다시 운영에 배포를 하게 된다.