GitHub 사용 규칙
- Local Repository에서 작업을 완료한 한 후 작업 브랜치를 Origin Repository에 push한다.
- Origin Repository에 push한 브랜치를 Upstream Repository로 merge하는 Pull Request를 생성하고 코드리뷰를 거친 후 merge 한다.
- 다시 새로운 작업을 할 때 Local Repository에서 Upstream Repository를 pull 한다.
- 제품으로 출시될 수 있는 브랜치
- 배포 가능한 상태만을 관리한다.
- 다음 출시 버전을 개발하는 브랜치
- develop 브랜치는 통합 브랜치의 역할을 하며, 평소에는 이 브랜치를 기반으로 개발을 진행한다.
- 기능을 개발하는 브랜치
- develop 브랜치로부터 분기한다.
- feature 브랜치는 그 기능을 다 완성할 때까지 유지하고, 다 완성되면 develop 브랜치로 merge한다.
- 이번 출시 버전을 준비하는 브랜치
- develop 브랜치에 이번 버전에 포함되는 기능이 merge 되었다면 QA를 위해 develop 브랜치에서부터 release 브랜치를 생성한다.
- 배포를 위한 최종적인 버그 수정 등의 개발을 수행한다.
- 배포 가능한 상태가 되면 master 브랜치와 develop 브랜치로 병합시키고, 출시된 master 브랜치에 버전 태그를 추가한다.
- 출시 버전에서 발생한 버그를 수정 하는 브랜치
- master 브랜치에서 분기하는 브랜치한다.
- hotfix 브랜치에서의 변경 사항은 develop 브랜치에도 merge하여 문제가 되는 부분을 처리해 주어야 한다.
로그인 기능을 만든다.
내가 맡은 역할을 로그인 api를 만드는 것이다.
- 현재 upstream에 feature-login 브랜치가 존재한다면 1,2번은 생략해도 된다.
-
로컬에 feature-login 브랜치 생성
git checkout develop
git branch feature-login -
upstream에 feature-login 브랜치 생성
git push --set-upstream upstream feature-login -
자신이 구현할 기능에 대한 브랜치 생성
git fetch upstream
git checkout feature-login
git checkout -b login-api -
기능 구현
git commit -
작업 브랜치를 upstream/feature-login에 rebase한다.
git add . 현재 작업중인 내용을 tracked 상태로 만든다. (git status 에서 변경사항이 없다면 안해도 됨)
git stash 현재 작업중인 내용을 저장한다. (git status 에서 변경사항이 없다면 안해도 됨)
git pull --rebase upstream feature-login
git push origin 브렌치명
git stash pop 현재 작업중이던 내용을 pop 하여 다시 불러온다. (git status 에서 변경사항이 없다면 안해도 됨) -
작업 브랜치를 origin에 push 한다.
git push origin login-api -
Github에서 login-api 브랜치를 feature-login에 merge하는 Pull Request를 생성한다.
-
팀원들에게 코드리뷰, 승인을 받으면 merge
5번 작업이 필요한 이유
동료와 같이 같은 기능을 개발하면 하나의 feature 브랜치에 커밋을 하게 됩니다.
서로 같은 커밋에서 시작했다가 feature 브랜치에 하나씩 merge 되기도 하고 얽히고설켜서 merge 되기도 합니다.
그러면 커밋 그래프가 복잡해지고 이력 확인을 할 때도 어렵게 됩니다.
그래서 커밋을 순차적으로 만들기 위해서 작업한 커밋이 feature의 최신 상태에서 시작하도록 rebase를 수행합니다.