브랜치(Branch)
독립적으로 어떤 작업을 진행하기 위한 개념.
필요에 의해 만들어지고 없어지는 각각의 브랜치는 다른 브랜치의 영향을 받지 않기 때문에 여러 사람이 여러 작업을 동시에 진행할 수 있다.
이러한 브랜치들은 다른 브랜치와 merge 함으로써 새로운 하나의 브랜치로 합칠 수도 있다.
아래의 그림은 각각의 브랜치를 merge 하는 예시이다.
통합 브랜치(Integration Branch)
언제든 배포가 가능하도록 하는 브랜치. 그래서 늘 안정적인 상태여야 한다.
만약 어플리케이션에서 어떤 문제가 발생되거나 새로운 기능이 추가되면, '토픽 브랜치(Topic Branch)'를 만들 수 있다.
통합 브랜치 > 토픽 브랜치를 만들어냄.
일반적으로 저장소를 처음 만들었을 때 생기는 'master 혹은 main'브랜치를 통합 브랜치로 사용한다.
토픽 브랜치(Topic Branch)
기능 추가나 버그 수정과 같은 작업을 위한 브랜치로 여러 작업을 동시에 진행할 때, 동시 진행하는 수만큼 토픽 브랜치를 생성할 수 있다.
보통 통합 브랜치로부터 파생되며, 토픽 브랜치에서 작업을 완료하면, 다시 통합브랜치에 merge하는 방식으로 진행된다.
이러한 토픽 브랜치는 feature 브랜치라고도 한다.
메인 브랜치(main)
'master(main)'브랜치와 'develop'브랜치를 보통 메인 브랜치로 사용한다.
- master(main) : 배포 가능한 상태만 관리. 커밋할 때는 태그 혹은 배포 번호를 기록한다.
- develop : 통합 브랜치의 역할을 하며, 평소엔 이 브랜치 기반으로 개발 진행한다.
피처 브랜치(feature)
토픽 브랜치 역할. 새로운 기능 개발 혹은 버그 수정이 필요할 때 'develop' 브랜치로부터 분기한다. 피처 브랜치에서 작업은 기본적으로 개발이 완료되면 'develop' 브랜치로 병합하여 다른 사람들과 공유한다.
릴리즈 브랜치(Release)
릴리즈 브랜치에서는 버그 수정, 혹은 새로운 기능을 포함한 상태로 모든 기능이 정상적으로 동작하는지 확인한다.
관례적으로 브랜치 이름 앞에 'release-'를 붙여 사용하고, 다음 릴리즈릴 위한 개발 작업은 'develop' 브랜치에서 계속 진행한다.
릴리즈 브랜치에서는 릴리즈를 위한 최종적 버그 수정의 개발을 진행하고, 배포 가능한 상태가 되면 'master' 브랜치로 병합한 후, 병합한 커밋에 릴리즈 번호 태그를 추가한다.
릴리즈 브랜치에서 기능점검하다가 발견한 버그 수정은 'develop'브랜치에도 적용해야 한다.
핫픽스 브랜치(Hotfix)
배포한 버전에 긴급하게 수정해야 할 경우, 'master'브랜치에서 분기하여 'hotfix-' 란 이름을 붙여 브랜치를 생성한다.
브랜치 전환하기
HEAD
HEAD란 현재 사용 중인 브랜치의 선두 부분을 뜻 함. 즉, 현재 체크아웃된 브랜치의 가장 최신 커밋을 뜻한다.
HEAD -> emma 의 뜻은, 현재 체크아웃되어있는 브랜치는 emma이고, 현재 HEAD가 emma 브랜치의 최신 커밋을 바라보고 있다는 의미입니다.
- 커밋을 지정할 때, ~(틸드)와 ^(캐럿)기호를 사용하여 현재 커밋으로부터 특정 커밋 위치를 가리킬 수 있다.
- HEAD~2 : 헤드로부터 2세대 앞 커밋까지 가리킴
- HEAD~1^2 : 헤드로부터 1세대 앞 커밋 중, 2번째 원본.
stash
파일 변경 내용을 일시적으로 저장해두는 영역. 작업트리와 인덱스 내에서 아직 커밋하지 않은 변경을 일시적으로 저장해둘 수 있다. stash에 저장된 변경 내용은 나중에 다시 불러와 원래의 브랜치나 다른 브랜치에 커밋할 수 있다.
참고 자료
누구나 쉽게 이해할 수 있는 Git 입문
