깃플로우
- Gitflow workflow => 오래된, 유명한 방식
- Trunk Based Deveplopment => CI/CD 가 추세가 되면서 구글,페이스북 등 최신방식이다!!
- git brance
- master
- git checkout -b qqq
qqq란 폴더를 만들어서 들어가줘 - git branch
master
*qqq - git add .
- git commit -m ''
- 브랜치 별로 파일을 가지고 있다.
- 브랜치를 여러 개 만드는 이유는 파일을 따로따로 가지고 있기 위함이다.
- 그러한 여러 브랜치를 나중에 머지 해줌
- 다 merge해서 마스터를 통해 최종 배포를 해준다.
- 버그가 나면 그 부분에서 브랜치를 만들어서 핫픽스 해준다.
GitFlow Branch
- 메인 브랜치( 기본 = 사라지지 않는 브랜치)
-master : 배포 가능한 브랜치(production상태와 일치)
이 브랜치의 HEAD는 항상 production 상태와 일치함
-develop: 다음 버전 출시를 위해 개발한 브랜치
이브랜치의 HEAD는 최신 개발 변경 사항을 제공합니다.
릴리즈 할 준비가 되면 모든 변경 사항을 master브랜치에 병합한다.
- 보조 브랜치(필요에 따라 생성/삭제 하는 브랜치)
병렬 개발을 지원하고, 이를 관리하기 위해 있는 브랜치들
기능 개발을 하거나 프로덕션 배포를 준비하고, 라이브 프로덕션 문제를 신속하게 수정하는 등 브랜치를 통해 관리한다.
-
feature: 기능을 개발하는 브랜치
- branch off from develop : 분기 시작하는 브랜치는 devlelop을 사용합니다.
- merge back into develop : 개발 완료 후 develop 브랜치로 병합합니다.
-
release : 배포를 위해 최종 수정을 하는 브랜치
이 브랜치에서는 주로, 버그수정 및 기타 릴리자 지향 작업만 포함되어야 합니다.-
branch off from develop
: 분기 시작하는 브랜치는 devlelop을 사용합니다.
(develop 브랜치가 개발이 새 릴리즈 사항에 대해서 원하는 상태일 때) -
merge back into develop 또는 master
: 개발 완료 후 develop/master 브랜치로 병합합니다. -
release-{버전번호} 와 같이 branch 이름 규칙을 갖습니다.
-
forking repository
-
메인레파지토리에 있던 내용을 fork를 통해 각자 자신의 레파지토리에 복사를 한다.
-
자신의 vscode에 clone을 하고 각자 자신의 api를 만든다.
-
api를 만들면 자신의 레파지토리로 push한다.
-
메인레파지토리(회사계정)에 pull을 요청한다.
- pull request(pr) 버튼을 누른다.
-
메인레파지토리에서 승인후 merge를 하면 그때가 되서야 합쳐지는 것이다.
-
그다음 자신이 만든 api아니고 승인이 된 api를 pull 받아서 자신의 VSCODE에 넣는다.
git pull upstream develop
-
다 만들어져 가면 release에 옮기고 최종 main/master로 옮기고 배포한다. 버그 생기면 hotfix후 재배포
-
hotfix : 출시 버전(master)에서 빠르게 패치해야 하기 위해 사용하는 브랜치
: relase 브랜치와 유사, 하지만 master 브랜치에서 분기하는 유일한 브랜치
: hotfix 브랜치를 사용 하면, 긴급하게 수정해야 하는 버그에 대해서 다음 릴리즈 주기를 기다리지 않고, 문제 상황에 대해서 대처 할 수 있습니다.
-
branch off from master : 분기 시작하는 브랜치는 master을 사용합니다.
-
merge back into develop 또는 master
: 개발 완료 후 develop/master 브랜치로 병합합니다. -
hotfix-{버전번호} 와 같이 branch 이름 규칙을 갖습니다.
