Git 브랜치 | git branch
git branch 명령어
지점과는 독립적인 개발 라인을 의미한다. 지점이 튜토리얼 시리즈의 첫 번째 챕터 인 Git의 기본 설명한 편집 / 스테이지 / 커밋 프로세스에 대한 추상적 개념이다. 이것은 작업 디렉터리 및 스테이징 영역 프로젝트 기록을 전적으로 창조하는 수단이라고 생각할 수도 있다. 새 커밋은 현재 브랜치의 이력에 기록되어 프로젝트 이력의 분기를 형성한다.
git branch는 분기 생성, 보기, 이름 변경, 삭제하는 명령이다. 이 명령은 브랜치를 전환하는 기능도 분기 한 이력을 통합하고 실행 취소 기능도 없다. 따라서 git branch 명령은 많은 경우 git checkout 명령과 git merge 명령과 함께 사용된다.
사용법
git branch
저장소의 모든 지점을 나열한다.
git branch <branch>
<branch> 라는 이름의 새 지점을 만든다. 새로 생성 된 브란트의 체크 아웃되지 않는다.
git branch -d <branch>
지정한 지점을 삭제한다. 지점에 병합되지 않은 변경이 남아있는 경우는 Git이 삭제를 거부하기 때문에 이 명령은 “안전한” 작업이다.
git branch -D <branch>
지정한 지점에 병합되지 않은 변경이 남아 있었다고 해도 이를 강제로 삭제하는 명령이다. 이 명령은 특정 개발 라인에서 만들어진 모든 커밋을 완전히 삭제하려는 경우에 사용한다.
git branch -m <branch>
현재 브랜치의 이름을 <branch>으로 변경한다.
보충 설명
Git은 브랜치는 일상적인 개발 프로세스의 요소이다 새로운 기능 개발 및 버그 수정을 할 경우 그 규모의 대소를 불문하고 변경을 캡슐화하는 지점을 만든다. 이는 불안정한 코드가 메인 코드베이스에 커밋되는 것을 방지하고 또한 master 브랜치에 병합하기 전에 기능의 기록을 정리 할 수 있다.
Git 튜토리얼 : git branch 예를 들어, 위의 그림은 작은 기능 개발과 장기의 기능 개발을 지원하는 두 개의 독립적 인 개발 라인을 갖는 저장소를 시각화 한 것이다 이러한 개발 작업을 분기함으로써이 둘을 동시에 진행시킬 수있는뿐만 아니라 기본 master 브랜치 를 불완전한 코드로부터 보호 할 수 있다.
분기 끝
Git 브랜치의 배경에있는 설계 사상은 SVN에서 분기보다 훨씬 가벼운 것이다 SVN에서 디렉터리간에 직접 파일을 복사 할 반면 Git의 브랜치는 커밋에 대한 참조로 저장됩니다. 이런 의미에서 브랜치는 커밋 컨테이너가 아닌 일련의 노력의 끝 을 나타내는 것이라고 말할 수 있다. 하나의 브랜치의 기록은 커밋의 상호 관계를 통해 외부 삽됩니다.
이 것은 Git 병합 모델에 매우 큰 영향을 미친다. SVN의 병합은 파일 기반에서 이루어지는 반면 Git은 커밋을 추상화 수준에서 작업을 수행한다. 사실, 프로젝트 이력의 병합은 독립적 확약 기록 결합이라고 생각할 수 있다.
사용 예
지점 만들기
분기가 단순한 커밋에 대한 포인터 임을 이해할 필요가 있다. 브랜치를 생성했다고 해도, Git이 할 포인터의 생성이며, 저장소를 변경할 수 없다. 따라서 먼저 아래 그림과 같은 저장소가 있다고 한다 :
그리고 다음의 명령을 사용하여 분기를 작성하는 것으로 한다 :
git branch crazy-experiment
여기에서는 저장소의 기록에는 아무런 변경도 이루어지지 않습니다. 새롭게 만들어지는 것은 현재 커밋에 대한 포인터 만 :
Git 튜토리얼 : 신규 지점 만들기
이 작업은 단순히 신규 지점을 만든 뿐임을 명심하자. 이 지점에 커밋 추가를 시작하기 위해서는 git checkout 명령을 사용하여 그것을 선택해야 다음에 일반 git add 명령과 git commit 명령을 사용한다. 자세한 내용은 이 장의 git checkout 을 참조한다
지점 삭제
지점에서의 작업이 완료 master 브랜치에 병합이 완료되면 지점을 삭제 기록을 잃지 않는다 :
git branch -d crazy-experiment
그러나 지정된 지점의 병합이 완료되지 않은 경우 위 명령을 실행하면 오류 메시지가 나타난다 :
error: The branch 'crazy-experiment' is not fully merged.
If you are sure you want to delete it, run 'git branch -D crazy-experiment'.
따라서 이러한 커밋에 대한 참조의 상실, 즉 작은 과실에 의한 개발 라인 전체에 대한 액세스 수단의 상실을 방지 할 수 있다. 브랜치를 삭제해도 좋다는 확신이있는 경우 (예를 들어 그 지점에서 실시한 실험적인 개발이 실패했을 경우)는 대문자 -D 플래그를 사용한다 :
git branch -D crazy-experiment
이 명령을 실행하면 브랜치의 상태에 관계없이 어떠한 경고없이 삭제하는 신중하게 사용해야 한다.
Git Branch 종류
Master Branch
- 제품으로 출시될 수 있는 브랜치
- 배포(Release) 이력을 관리하기 위해 사용. 즉, 배포 가능한 상태만을 관리한다.
Develop Branch
- 다음 출시 버전을 개발하는 브랜치
- 기능 개발을 위한 브랜치들을 병합하기 위해 사용. 즉, 모든 기능이 추가되고 버그가 수정되어 배포 가능한 안정적인 상태라면 develop 브랜치를 ‘master’ 브랜치에 병합(merge)한다.
- 평소에는 이 브랜치를 기반으로 개발을 진행한다.
Feature branch
- 기능을 개발하는 브랜치
- feature 브랜치는 새로운 기능 개발 및 버그 수정이 필요할 때마다 ‘develop’ 브랜치로부터 분기한다. feature 브랜치에서의 작업은 기본적으로 공유할 필요가 없기 때문에, 자신의 로컬 저장소에서 관리한다.
- 개발이 완료되면 ‘develop’ 브랜치로 병합(merge)하여 다른 사람들과 공유한다.
Release Branch
- 이번 출시 버전을 준비하는 브랜치
- 배포를 위한 전용 브랜치를 사용함으로써 한 팀이 해당 배포를 준비하는 동안 다른 팀은 다음 배포를 위한 기능 개발을 계속할 수 있다. 즉, 딱딱 끊어지는 개발 단계를 정의하기에 아주 좋다.
- 예를 들어, ‘이번 주에 버전 1.3 배포를 목표로 한다!’라고 팀 구성원들과 쉽게 소통하고 합의할 수 있다는 말이다.
Hotfix Branch
- 출시 버전에서 발생한 버그를 수정 하는 브랜치
- 배포한 버전에 긴급하게 수정을 해야 할 필요가 있을 경우, ‘master’ 브랜치에서 분기하는 브랜치이다. ‘develop’ 브랜치에서 문제가 되는 부분을 수정하여 배포 가능한 버전을 만들기에는 시간도 많이 소요되고 안정성을 보장하기도 - - 어려우므로 바로 배포가 가능한 ‘master’ 브랜치에서 직접 브랜치를 만들어 필요한 부분만을 수정한 후 다시 ‘master’브랜치에 병합하여 이를 배포해야 하는 것이다.-