[Git] Git Branching Strategy(feat. 브랜치 전략)

목차

ppt로 작성하려고 했으나 너무 시간이 오래 걸릴 것 같아서 그림은 이걸로 하고 텍스트로 보충

master branch 😎

실제 운영서버에 올라가는 최종 릴리즈 버전 브랜치

---

candidate branch 😭

QA Server에 배포해서 실서버 반영 전 검증하는 브랜치

candidate branch에서 최종 검증이 되면 그 때 master에 반영

master branch에 올라가기 바로 전 소스

---

dev branch 🙄

개인 브랜치에서 로컬 검증 후 개발서버에서 돌리는 용도의 브랜치

개발서버에서 돌려보는 용도라서 온갓 잡다한 소스가 다 있을 수 있다.(버그가 있는 소스 등등)

절대 이 branch는 master나 candidate branch로 반영하면 안된다.

---

persnal branch 😛

개발자 각자 개발하는 용도의 branch

이 branch에서 dev에 올려서 개발서버에서 검증 후 cherry-pick, rebase 등으로 candidate branch에 반영

그 후 QA Server에서 충분히 검증 후 최종적으로 master에 반영 후 실서버 배포

master에 최종 배포한 다음 이 브랜치는 삭제 후 추가 개발 시 candidate branch에서 신규로 브랜치 생성

---

branch 작업 환경 구성 시나리오 🤡

개인 branch, dev, master branch의 소스코드 동기화(

개인 branch -> dev에 반영, dev -> master에 반영)

그 후 master에서 candidate branch를 생성(최초 1번) 후 candidate branch에서 개인 branch 생성 후 개발 소스코드는 dev branch에 올린다.

dev에서 충분히 검증이 되면 개인 branch의 소스를 candidate branch에 반영한다.

QA Server에서 충분히 검증을 한다.

그 과정에 나오는 버그나 수정사항들은 개인 branch에서 dev에 반영한다.위 과정을 반복한 후 QA Server에서 충분히 검증이 되면 master branch에 배포 후 실서버에서 테스트 한다.

개인 branch끼리는 서로 merge하지 않는다.(만일 같은 기능을 건드릴 경우엔 dev에 올려서 반드시 pull한 다음 반영)

---

이 전략은 정답이 아니고 개발팀 내부의 정책을 따릅니다.