참고사이트
지옥에서 온 깃
https://www.youtube.com/watch?v=hFJZwOfme6w&list=PLuHgQVnccGMA8iwZwrGyNXCGy2LAAsTXk우아한 기술 블로그 - git work flow
https://techblog.woowahan.com/2553/git data transport commands
workspce
- 코딩을 하는 공간
index
- add 를 해놨을 때, 저장되는 공간
local repository
- 커밋을 했을 때, 저장되는 공간
remote repository
- gitHub 와 같은 공간
git work flow
repository 설명
- upstream repository (remote repository)
- origin repository (remote, forked upstream)
- computer local repository
전반적인 work flow 설명
- upstream repository 생성
- upstream repository를 fork한 origin repository 생성
- origin repository를 local로 clone
- local repository 에서 작업을 완료한다.
- 완료한 브랜치 를 origin repository 에 푸시 한다.
- origin repository에서 upstream으로 pull request 보낸다.
- upstream repository 에서 pull request 를 받는다.
- 코드 리뷰 후에 merge 한다.
- 다시 local 에서 pull 한다.
약속들
- Jira 티켓을 생성 한다.
- 하나의 티켓은 하나의 커밋 으로
- 커밋 그래프 는 최대한 단순히 가져 간다.
- 커밋 그래프 는 함부러 변경 하지 않는다.
- 리뷰는 꼭 받는다.
- pull request 는 스스로 merge 한다.
branch 전략
- master : 배포용
- develop : 다음 배포 버전을 만들기 전 개발 브랜치
- feature : 기능 개발 브랜치
- release : 이번 배포 버전을 준비 하는 브랜치
- hotfix : 배포 버전 에서 발생한 버그를 수정 하는 브랜치
- main 과 develop 브랜치 생성
- develop 에는 버그 수정 한 커밋들 추가
- 기능 추가를 할 경우, develop 에서 feature 브랜치 생성
- feature 기능 구현 완료 시, develop 으로 merge
- 모든 기능 구현 시, develop 에서 release branch
- release 에서 QA 진행 후, release 브랜치 를 main 과 develop 에서 merge
+
rebase?
- rebase 를 해야 commit graph가 단순해 진다.
개발합시다