🙋♀️ 깃 브랜치를 운영하는 방법론
- 깃 브랜치란 브랜치를 운영하는 일종의 방법
- 협업환경에서 규칙을 만들고 매끄럽게 협업하고자함
1️⃣ gitflow : master, develop, feature, release, hotfix 브랜치를 설정하고 운영하는 방식
💡 브랜치 설명
◾ master - 프러덕션 레디 상태, 제품으로 나갈 수 있는 상태 소스 코드
◾ develop - 개발자들이 이 브랜치 기준으로 각자 작업한 기능들을 merge
◾ feature - 개발자들이 개개인 개발을 하기 위해 사용하는 브랜치
◾ release - QA, 버그 수정 과정 중 내보내기 직전에 사용하는 소스 코드 브랜치
◾ hotfix - 서비스 운영 중에 버그나 급하게 대응해야하는 이슈가 발생할 때 사용하는 브랜치
2️⃣ github flow : main(master), feature 브랜치만으로 운영하는 방식
🙋♀️ 브랜치 전략을 세우는 이유와 요령
- 하나의 프로젝트 소스코드를 여러 개발자가 다루면서 발생하는 각종 부작용을 해결
- 개발 협업을 원활하게 하기 위한 약속
💡 전략을 세울 때 고려할 수 있는 요소들
1️⃣ 이 브랜치는 제품으로 내보낼 수 있는가?
2️⃣ 이 브랜치는 빌드 실패를 허용하는가?
3️⃣ 이 브랜치는 테스트 실패를 허용하는가?
4️⃣ 이 브랜치는 임시로 운영하는가? 유지하지 않고 수시로 삭제하는가?
📃 게시판 서비스 깃 브랜치 전략 세우기 - Git Flow 전략 사용
GitFlow 전략을 사용하여 브랜치 관리
모든 브랜치는 Pull Request에 리뷰를 진행한 후 merge 진행 예정
💡 브랜치 설명
◾ master (dummy로 설정) - 배포시 사용
◾ develop (main으로 설정) - 완전히 개발이 끝난 부분에 대해서만 merge 진행
◾ feature - 기능 개발을 진행할 때 사용
◾ release - 배포를 준비할 때 사용
◾ hotfix - 배포를 진행한 후 발생한 버그를 수정할 때 사용
feature 브랜치를 만들어서 개발하고, merge 하는 전략은 ,
feature가 만들어줘서 develop으로 가는 구조를 띔.
따라서, feature가 master로 바로 가지 않음
이번 프로젝트에서는 master 브랜치는 develop에 두고, master 브랜치는 dummy로 설정함
기능정으로는 master 브랜치를 쓰지 않고, develop만 가지고 개발을 할 예정 (= develop이 main과 같은 역할을 하도록 함)
