깃허브는 개인 과제를 할 때 코드 저장용으로만 사용했었는데, 이번에 처음 프로젝트에 참여하게 되어 깃 브랜치에 대해 알아보았다.
github workflow
핵심 컨셉은 remote 저장소에서 master, develop 두 개의 메인 브랜치를 이용한다는 것.
fetch 와 pull 의 차이
- fetch : 원격 저장소의 데이터를 로컬에 가져오기만 하기
- pull : 원격 저장소의 내용을 가져와 로컬과 자동으로 병합 (fetch + merge)
Git Branch 종류
master
출시 가능한 브랜치
배포 가능한 상태의 코드만을 관리
develop
다음 출시 버전을 개발하는 브랜치
기능 개발을 위한 브랜치들을 병합하기 위해 사용. 평소에는 해당 브랜치를 기반으로 개발 진행. 배포 가능한 상태라면 master 브랜치에 머지함
feature
기능을 개발하는 브랜치
새로운 기능 개발 및 버그 수정이 필요할 때마다 develop 브랜치로부터 분기함
공유할 필요는 없기 때문에 기본적으로 로컬 저장소에서 관리됨
- develop branch 로부터 새로운 기능에 대한 feature 브랜치를 분기
- 작업 수행
- develop branch 로 병합
- 해당 feature branch를 remote 저장소에 push
- feature branch 이름: [ feature/기능요약 ] ex) feature/login
git checkout -b feature/login develop
/* 작업 수행 */
git checkout develop
git merge --no-ff feature/login
/* --no-ff option : feature branch에 존재하는 커밋 이력을
하나의 커밋 객체로 만들어 develop 브랜치로 병합 */
git branch -d feature/login
/* -d option: 브랜치 삭제 */
git push origin develop
release
배포 전용 브랜치
develop branch 로부터 분기
이번 출시 버전을 위한 브랜치로 한 팀이 해당 배포를 준비하는 동안 다른 팀은 다음 배포를 위한 기능 개발을 할 수 있음
hotfix
출시 버전에서 발생한 버그를 수정하는 브랜치
master branch 로부터 분기하여 필요한 부분만을 수정한 후 다시 병합
References
[GitHub] GitHub로 협업하는 방법[1] - Feature Branch Workflow
[GitHub] Git 브랜치의 종류 및 사용법 (5가지)
