branch
여러 개발자가 동시에 서로 다른 작업을 할 수 있게 만들어 주는 기능이 바로 '브랜치(Branch)'
협업을 하는 상황 뿐만 아니라, 기존의 소스 코드를 해치지 않으면서 다른 작업을 시도해보고 싶을 때에도 이 브랜치 기능을 활용 가능
feature 브랜치에서 완성한 코드를 기존 소스 코드에 반영해도 문제가 없다면, 그 때 병합(merge) 가능
브랜치 기능의 장점
- 한 소스 코드에서 동시에 다양한 작업을 할 수 있게 해준다.
- 소스 코드의 한 시점과 동일한 상태를 만들고, 브랜치를 넘나들며 작업을 수행할 수 있다.
- 각각의 브랜치에서 생긴 변화가 다른 브랜치에 영향을 주지 않고 독립적으로 코딩을 진행할 수 있다.
'작업 단위', 즉 브랜치로 그 작업의 내용들이 모두 기록되기 때문에 문제가 발생했을 때 원인이 되는 작업을 찾아내거나 그에 따른 대책을 세우기 쉬워짐
브랜치 종류
1. 통합 브랜치 (Integration Branch)
배포될 소스 코드가 기록되는 브랜치
Github Repository를 생성하게 되면 기본적으로 main 브랜치가 생김 (기존 Repository의 경우 master로 되어 있는 곳도 많음)
해당 프로젝트의 모든 기능이 정상적으로 작동하는 상태의 소스코드가 담겨 있다.
2. 피처 브랜치 (Feature Branch)
기능 추가, 버그 수정과 같이 단위 작업을 위한 브랜치
통합 브랜치로부터 만들어내며, 피처 브랜치에서 하나의 작업이 완료가 되면 다시 통합 브랜치에 병합하는 방식으로 진행된다. 토픽 브랜치라고도 함
브랜치 명령어
- 새로운 브랜치 생성
$ git branch 새로운 브랜치 이름
- 새로운 브랜치 생성 후 해당 브랜치로 전환
$ git switch -c 새로운 브랜치 이름
$ git checkout -b 새로운 브랜치 이름
- 브랜치 목록 확인
$ git branch
- 브랜치 목록과 각 브랜치의 최근 커밋 확인
$ git branch -v
- 브랜치 삭제
$ git branch -d 삭제할 브랜치 이름
$ git branch -D해당 명령어는 병합하지 않은 브랜치를 강제 삭제하는 방법
- 브랜치 전환
$ git switch 브랜치 이름
$ git checkout 브랜치 이름
- 브랜치 병합
master 브랜치로 dev 브랜치를 병합할 때 (master ← dev)
$ git checkout master
$ git merge dev
- 로그에 모든 브랜치를 그래프로 표현
$ git log --branches --graph --decorate
- 아직 commit 하지 않은 작업을 스택에 임시로 저장
$ git stash
fast-forward / merge commit
브랜치를 병합할때 상위 브랜치가 추가 커밋이 없을 경우 브랜치가 분기될 필요가 없으므로 자동적으로 fast-forward 방식으로 병합이 이뤄짐
fast-forward 방식이란 별도의 커밋을 생성하지 않고 상위 브랜치가 가리키는 커밋을 하위 브랜치가 생성한 커밋으로 바꾸는 작업
상위 브랜치에 별도의 커밋이 있었다면, fast-forward가 아닌 merge commit 방식으로 병합
이는 각 브랜치가 줄기처럼 분기한 후, 병합의 모양새를 가짐
merge / rebase 차이
merge
변경 내용의 이력이 모두 그대로 남아 있기 때문에 이력이 복잡함
rebase
말 그대로 branch base를 이동시킨다는 뜻으로, 머지처럼 브랜치 통합을 목적으로 하지만, 특정 시점으로 브랜치가 가리키는 곳을 변경하는 기능 (fast-forward와도 같음)
- rebase : 커밋의 베이스를 다시 정하고 싶은 경우
- squash : 여러 개의 커밋 로그를 하나로 묶고 싶은 경우
- revert : 커밋 여러 개의 변경 사항을 취소하고 싶은 경우
- cherry-pick : 원하는 커밋만 가져오고 싶은 경우
- --amend : 최근 커밋 메시지를 수정하고 싶은 경우
Project workflow
Local에서 새로운 브랜치를 생성하고 작업이 끝나면 Remote Repository 로 Push
=> Project Upstream Repository에 반영(merge)될 수 있도록 Pull Request
만약 작업하던 중간에 Remote upstream 에 업데이트가 생긴다면 Local 로 pull
