저번에 한 번 정리했었는데...
어제 revert 하면서 얘기하다보니까 사수가 말 안 해줬던 부분이 있어서 다시 정리...
브랜치 정리
- 회사는 release, merge, master, develop 이렇게 네 가지로 프로젝트를 관리한다.
- release 에서는 버전관리와 릴리즈 하는 시스템...?이 연결되어 있다.
- merge 는 release에 머지 할 작업 브랜치를 합치는 곳이다. 작업을 시작할 때 여기서 브랜치를 따서 시작한다.
- master 는 실질적으로 아무것도 손 대지 않는 브랜치이며 release 브랜치로 배포 후 문제가 없는 것이 확인되면 그 때 release 브랜치를 합치면서 코드 관리만 이루어진다.
- develop 은 개발하면서 수시로 배포하고 테스트 하는 브랜치이다.
작업순서
1. REMOTE/merge 에서 새로운 브랜치를 생성한다.
(이미 LOCAL 에 가지고 있다면 반드시 pull을 해 와서 REMOTE 와 맞춘 후 새로운 브랜치를 생성)
2. LOCAL/newBranch 에서 작업
3. LOCAL/develop 에 merge 후 테스트
(작업하기 전 항상 pull 해 와서 REMOTE와 맞춤)
4. 문제 없이 작업이 완료되었다면 LOCAL/newBranch를 commit & push 해서
REMOTE/newBranch를 생성
5. LOCAL/merge 에 LOCAL/newBranch 를 merge & push
6. LOCAL/release 브랜치 삭제
7. LOCAL/merge 에서 새로운 브랜치 생성하며 이름을 LOCAL/release 만듦
8. REMOTE/release 삭제
9. LOCAL/release 브랜치로 이동하여 commit & push
// 이렇게 하면 로컬과 리모트의 release가 같은 곳에서 나온 것이므로 맞춰짐
10. 버전 생성이 되면 LOCAL/release 에서 package.json의 버전 부분만 바꾸고
commit message 규칙에 따라서 작성 후 commit & push
// 버전을 바꾸는 부분의 commit & push는 오직 버전만 바꿔야 한다.
// 버전 관리를 위한 것이므로 다른 것과 독립적으로 되어 있어야 롤백 등의 조치가 필요할 때 이용 가능
11. 배포가 되고 잘 작동하는지 확인.
12. 문제가 없다면,
LOCAL/release 브랜치를 아래의 브랜치들에 각각 merge & push
REMOTE/master
REMOTE/merge
REMOTE/develop사수가 로컬에 있는 release 브랜치를 지우라고 가르쳐주지는 않았고
그냥 pull 받아오면 된다고 가르쳐줬었는데 같이 일하는 분은 리모트는 안 지우셔도 로컬은 지우면서 작업하셨다고 한다...
왜죠... 저한테는 왜...?
나도 앞으로는 똑바로 하기 위해서... 적어놓음...
그니까, 로컬이랑 리모트를 똑바로 구분하면서 해야 함!
물론 Pull 받아오면 로컬이랑 리모트는 같아지기는 하지만 그래도 어디에서 작업하고 있는지 인지를 해야!
