Branch 방을 따로 파자

먼저,

< Shared Repository Model >
- 깃허브에서 협업할 상대에게 권한 주고, 같이 push pull 하면서 작업하는 것

( 깃허브 권한주기 => 해당Repository - setting - collaborator )

 

여기에 Branch 가 더해지면서 Git이 꽃을 피운다.

Branch : 특정 Commit 을 가리키는 포인터

 

git push origin master - "origin (깃허브 주소)의 master 브랜치로 push 하겠다"

기본 default 로 생성되있는 브랜치가 master 이고,

 

보통 서비스에서 이 master 브랜치가

master => "상용" 버전! => download 가능 / 고객에게 제공하는 버전

으로 쓰인다.

 

새로운 기능개발 /버그, 에러 수정
=> 이런 것들은 실제 고객들에게 뿌려질 master 에서 작업 하는게 아니라
완벽하게 분리된 공간인 branch 를 따로 생성해서 거기서 작업한다.

작업이 끝나면 다시 master로 합쳐준다.

---

git bracnh 이름 - 브랜치 생성
(git checkout 이름 - 브랜치 이동
git checkout -b 이름 - 브랜치 생성 + 이동) // git권고 : checkout -> switch
git switch 이름 - 브랜치 이동
git switch -c 이름 - 브랜치 생성 + 이동
git branch - 브랜치 목록 확인
git branch -d 이름 - 브랜치 삭제

---

메인 서비스가 잘 돌아가고 있는 master 브랜치가 있다.

이미 잘 만들어진 도자기가 몇 십개 들어있는 방이다.

근데 그 방에서, 추가로 도자기를 만들려다 발 한번 헛디디면 만들어놓은 도자기가 다 깨질 수도 있다.

그래서 그 방은 그대로 저장해두고, 옆에 새로운 방에서 새로운 도자기를 만드는 것이다.

 

 

모든 개발은 로컬에서 이루어진다.

 

기본적으로 이 Branch 는 로컬 전용 개념이다.
내가 로컬에서 개발을 하면서 편하고 안전하게 하기 위해서 방을 따로 파는거다.

 

내 개인 깃허브에 저장해 놓는것도, 그냥 로컬의 영역이다.
Branch 를 따로 만들어서 개발하다가, 그대로 내 깃허브에 올리면
깃허브는 Branch도 그대로 받아서 저장만 해줄 뿐, 아직까지도 그냥 로컬의 영역이다.

 

Branch를 이용해서안전하게 로컬에서 작업을 끝내면
merge 를 통해 내 대표 Branch 로 다 합친다.

 

그렇게 완성된 내 대표 Branch 를 드디어

서비스 전용 깃허브에 입장 시키고자 할 때, 로컬 => Remote 원격의 영역으로 들어가는 거다.

( 이 서비스 전용 허브에서도 PR 이 많아서 Branch를 따로파서 관리를 하기도 한다.
기본적인 Branch 의 효용은 로컬에서 발휘된다. )

 

( 결국 git/ github 는 저장소다.
저장소는 저장소의 역할을 할 뿐이다. )