Git Branch(3)

브랜치 관리

 

이제 브랜치를 관리하는데 필요한 명령어를 공부한다.

 

git branch 명령은 단순히 브랜치를 만들고, 삭제하는데만 사용되지는 않는다. 

옵션 없이 사용되면 브랜치의 목록을 보여주고 * 표시는 현재 checkout 해서 작업하는 브랜치가 나온다.

 

검색 필터도 존재하는데 현재 브랜치에 Merge하지 않은 브랜치를 살펴보려면 --no-merged 옵션을 추가하면 된다.

 

만약 특정 브랜치 기준으로 Merge되거나 No-Merge 된 브랜치의 정보를 보려면 명령에 브랜치 이름을 추가해주면 된다.

 

 

장기간에 걸쳐서 한 브랜치를 다른 브랜치와 여러번 Merge 하기 쉽다는 점이 개발 과정에서 필요한 용도에 따라 브랜치를 만들어 두고 계속 사용할 수 있다. 이런 방법 중 개발자가 많이 선호하는 워크플로가 하나가 있다.

 

배포했거나, 배포할 코드만 master브랜치에 Merge해서 안정 버전의 코드만  master브랜치에 둔다. 개발을 진행하고 안정화하는 브랜치는 develop이나 next라는 이름으로 추가해서 사용한다. 만약 이 개발 브랜치들이 안정화가 됐다고 판단할 시 master브랜치에 Merge 한다. 

 

즉 안정화된 master는 호흡이 길고, develop는 호흡이 중간이며 topic브랜치는 짧다.

 

여기까지는 전부 로컬 브랜치라는 걸 염두해두어야 한다.

 

리모트 브랜치

 

리모트Refs는 리모트 저장소에 있는 포인터인 레퍼런스이다. git ls-remote [remote] 명령으로 모든 리모트 Refs를 조회할 수 있다.

 

git remote show [remote] 명령은 모든 리모트 브랜치와 그 정보를 보여준다.

 

 

여기서 알아둬야할 것이 로컬과 서버의 커밋 히스토리는 독립적이라는 것이다.

리모트 서버로부터 저장소 정보를 동기화하려면 git fetch origin이라는 명령을 사용한다.

명령을 실행하면 우선 origin 서버의 주소 정보를 찾아서 현재 로컬의 저장소가 갖고 있지 않은 새로운 정보가 있으면 모두 내려받고, 받은 데이터를 로컬 저장소에 업데이트하고 나서, origin/master 포인터의 위치를 최신 커밋으로 이동시킨다.

 

로컬 브랜치를 서버로 전송하려면 쓰기 권한이 있는 리모트 저장소에 push해야한다. 또한 로컬 저장소의 브랜치는 자동으로 리모트 저장소로 전송되지 않기 때문에 명시적으로 브랜치를 push 해야 된다.

git push <remote> <branch> 명령을 사용한다.

여기서 짚고 넘어가야 할 게 있다. Fetch 명령으로 리모트 트래킹 브랜치를 내려받는다고 해서 로컬 저장소에 수정할 수 있는 브랜치가 새로 생기는 것이 아니다.  새로 받은 브랜치의 내용을 Merge 하려면 git merge origin/branchName 명령을 사용한다. 내 브랜치를 서버 origin/brachName이라는 브랜치와 merge 해야 한다는 것이다.

그럼 이제 여기서 시작할 수 잇는 로컬 브랜치가 만들어진다.

 

로컬 브랜치와 서버의 저장소와 해당 브랜치와 연결되면 자동으로 트래킹 브랜치가 만들어진다. 이 트래킹 브랜치는 리모트 브랜치와 직접적으로 연결고리가 있는 로컬 브랜치이어서, 누군가 리모트 저장소에 push 해 정보가 업데이트 됐다면 git pull 명령으로 데이터를 내려받아 자동으로 Merge 한다.

 

 

서버로부터 저장소를 Clone 하면 git은 자동으로 master브랜치를 origin/master 브랜치의 트래킹 브랜치로 만든다.

추적 브랜치가 현재 어떻게 설정되어 있는지 확인하려면 git branch 명령에 -vv 옵션을 더한다. 이 명령을 실행하면 로컬 브랜치 목록과 로컬 브랜치가 추적하고 있는 리모트 브랜치도 함께 보여준다. 게다가, 로컬 브랜치가 앞서가는지 뒤쳐지는지에 대한 내용도 보여준다.

$ git branch -vv 
iss53 7e424c3 [origin/iss53: ahead 2] forgot the brackets 
master 1ae2a45 [origin/master] deploying index fix 
* serverfix f8674d9 [teamone/server-fix-good: ahead 3, behind 1] this should do it 
testing 5ea463a trying something new

위의 결과를 보면 iss53 브랜치는 origin/iss53 리모트 브랜치를 추적하고 있다는 것을 알 수 있고 “ahead” 표시를 통해 로컬 브랜치가 커밋 2개 앞서 있다(리모트 브랜치에는 없는 커밋이 로컬에는 존재)는 것을 알 수 있다. master 브랜치는 origin/master 브랜치를 추적하고 있으며 두 브랜치가 가리키는 커밋 내용이 같은 상태이다. 로컬 브랜치 중 serverfix 브랜치는 server-fix-good 이라는 teamone 리모트 서버의 브랜치를 추적하고 있으며 커밋 3개 앞서 있으며 동시에 커밋 1개로 뒤쳐져 있다. 이 말은 serverfix 브랜치에 서버로 보내지 않은 커밋이 3개, 서버의 브랜치에서 아직 로컬 브랜치로 머지하지 않은 커밋이 1개 있다는 말이다. 마지막 testing 브랜치는 추적하는 브랜치가 없는 상태이다.

 

이 결과는 마지막으로 서버에서 데이터를 fetch 한 시점으로 가져온다. 로컬에 저장된 서버의 캐시 데이터를 사용한다.

git fetch --all; 

git branch -vv 명령을 이어서 사용해야 정확하다.

Pull 하기

 

git fetch 명령을 실행하면 서버에는 존재하지만, 로컬에는 아직 없는 데이터를 받아와서 저장한다. 이때 워킹 디렉터리의 파일 내용은 변경되지 않고 그대로 남는다. 서버로부터 데이터를 가져와서 저장해 두고 사용자가 Merge 하도록 준비만 해둔다. 간단히 말하면 git pull 명령은 대부분 git fetch 명령을 실행하고 나서 자동으로 git merge 명령을 수행하는 것뿐이다. 바로 앞 절에서 살펴본 대로 clone 이나 checkout 명령을 실행하여 추적 브랜치가 설정되면 git pull 명령은 서버로부터 데이터를 가져와서 현재 로컬 브랜치와 서버의 추적 브랜치를 Merge 한다.

일반적으로 fetch 와 merge 명령을 명시적으로 사용하는 것이 pull 명령으로 한 번에 두 작업을 하는 것보다 낫다.

리모트 브랜치 삭제

동료와 협업하기 위해 리모트 브랜치를 만들었다가 작업을 마치고 master 브랜치로 Merge 했다. 협업하는 데 사용했던 그 리모트 브랜치는 이제 더 이상 필요하지 않기에 삭제할 수 있다. git push 명령에 --delete 옵션을 사용하여 리모트 브랜치를 삭제할 수 있다. serverfix 라는 리모트 브랜치를 삭제하려면 아래와 같이 실행한다.

$ git push origin --delete serverfix To https://github.com/schacon/simplegit - [deleted] serverfix

위 명령을 실행하면 서버에서 브랜치(즉 커밋을 가리키는 포인터) 하나가 사라진다. 서버에서 가비지 컬렉터가 동작하지 않는 한 데이터는 사라지지 않기 때문에 종종 의도치 않게 삭제한 경우에도 커밋한 데이터를 살릴 수 있다.