- 내가 작업하던 브랜치
feature/10000
개발브랜치로 여기를 쓰고 있었으면 이걸 메인으로 잡고 가야한다.
여기서 브랜치를 따서 스스로 작업을 하고,
이 브랜치에서 develop 브랜치로 넣을 때 PR 날려서 리뷰 및 피드백을 받는 것.
기획자가 QA를 하면서 수정을 요청해오는 것이 feature/11000이라 칠 때,
feature/10000에서 feature/11000을 따서 수정 개발을 진행하여야 한다.
그리고 수정작업이 끝날 시 feature/11000을 바로 develop에 합치지 말고
feature/10000에 합친 다음에 이 브랜치로 develop에 합친다.
develop
기획자들이 QA를 진행하는 곳으로 dev 웹으로 배포되고 있다.
단, 이 곳에서는 아직 개발이 진행중이어서 배포가 이루어지면 안 되는 작업도 있기 때문에 이걸로 배포를 진행하지는 않는다.
개발자들과 기획자들의 테스트를 위해서 사용되는 페이지이다.
merge
develop페이지에서 개발자와 기획자의 테스트 및 수정 개발이 모두 완료되었다면, 이를 merge 브랜치에 올려 스테이징 시킨다.
이 브랜치를 따로 만든 이유는 위에서 말했다시피, develop 브랜치에는 아직 배포가 될 수 없는 작업이 진행중이거나 또는 기능 수정으로 인해 삭제되어야 할 작업들이 있는데 바쁜 와중 이를 하나하나 수정할 수 없기 때문이다.
즉, release 브랜치로 가기 전의 최종 브랜치라고 할 수 있다.
만약 관련 작업을 다시 시작하게 된다면 여기서 브랜치를 따야하는 것이지 develop에서 따면 안 된다.
release
말 그대로 배포를 위한 브랜치이며 여기서 버전 관리 및... 백엔드 작업 등등(못 알아들음^^;;;)을 진행한다.
이것을 기준으로 배포를 진행한 후에
release 브랜치를 develop과 master에 합쳐 각 브랜치를 가장 최신의 상태로 유지시킨다.
원래 release 브랜치는 배포되고 master에 합친 이후에는 삭제되는 것이 보통이기는 한데,
지금의 회사에서는 할 때도 있고 안 할 때도 있다고 한다.
master
이 브랜치로 직접 배포하지는 않고 배포가 완료되어 문제가 없는 소스코드들이 가장 최신의 형태로 존재하는 브랜치이다.
