1. 브랜치(branch)란?

• 독립적으로 어떤 작업을 진행하기 위한 개념

• 각각의 브랜치는 다른 브랜치의 영향을 받지 않아,
  여러 작업을 동시에 진행할 수 있음

• 협업 시 다른 사람의 작업에 영향을 주거나 받지 않도록,
  메인 브랜치에서 자신의 전용 브랜치를 만듦

• 각자 작업한 후 작업이 끝나면 메인 브랜치에 자신의 브랜치의 변경 사항을 적용

• 저장소를 처음 만들면 main이라는 브랜치가 생김

• 새로운 브랜치를 만들어서 사용하는 선언, 즉 checkout 하기 전에는 main에서 작업함

2. 통합, 토픽 브랜치

• 통합 브랜치: 언제든지 배포할 수 있는 버전이 있는 브랜치,
  늘 안정적인 상태(정상 작동하는 상태) 유지해야 함
• 토픽 브랜치: 기능 추가, 버그 수정 등 단위 작업을 위한 브랜치
• 여러 작업 동시 진행 시 그 수만큼 토픽 브랜치 생성

3. merge

• main 브랜치와 new 브랜치 두 개가 있다고 할 때,
  두 브랜치 내의 변경 내용을 하나로 통합하는 것
• 변경 내용의 이력이 모두 그대로 남아 있어 이력이 복잡해짐

4. rebase

• main 브랜치와 new 브랜치 두 개가 있다고 할 때,
  두 브랜치를 하나의 줄기로 이어서 통합하는 것
• 두 브랜치의 커밋한 버전들이 충돌하는 경우,
  내용을 수정할 필요가 있음
• 이력은 단순해지지만 원래의 커밋이력이 변경되므로,
  정확한 이력을 남길 필요가 있을 경우 사용하면 안 됨

5. git branching model

http://nvie.com/posts/a-successful-git-branching-model/

1) 메인 브랜치

• main(원래는 master): 배포 가능한 상태만을 관리,
  커밋할 때에는 태그를 사용하여 배포 번호를 기록
• develop: 통합 브랜치 역할, 평소에 이 브랜치를 기반으로 개발

2) 피쳐 브랜치

• 새로운 기능 개발 및 버그 수정이 필요할 때 develop 브랜치에서 분기
• 개발이 완료되면 develop 브랜치로 병합
• 토픽 브랜치 역할

3) 릴리즈 브랜치

• 릴리즈를 위한 최종 버그 수정 등의 개발을 수행
• 관례적으로 이름 앞에 release- 를 붙임
• 배포 가능한 상태가 되면 main 브랜치로 병합시키고,
  병합한 커밋에 릴리즈 번호 태그 추가
• 배포 완료 후 develop 브랜치에 대해서도 병합 작업 수행

4) 핫픽스 브랜치

• 긴급 수정이 필요할 때 main 브랜치에서 분기
• 관례적으로 이름 앞에 hotfix- 를 붙임
  -develop 브랜치에서 수정하기엔 시간, 안정성 차원에서 어려움이 있어서 바로 배포 가능한 main 브랜치에서 직접 브랜치를 만듦