Git 요약 7. Remote branch, Rebase (원격 브랜치, 리베이스)

Remote Branch   

Remote refs 

• 원격저장소를 참조하기 위한 포인터. 원격저장소에 있는 브랜치, 태그, 등등을 가리킨다.   
• git ls-remote [remote] Remote refs를 조회   
• Remote Refs가 있지만 보통은 리모트 트래킹 브랜치를 사용한다.  

Remote-tracking branch 추적 브랜치

• 리모트 저장소에 마지막으로 연결했던 순간에 브랜치가 무슨 커밋을 가리키고 있었는지를 가리키는 로컬 포인터.  
• 리모트 브랜치의 이름은 (remote)/(branch) 형식 ex) origin/master   
• 이 포인터는 로컬에 있지만 움직일 수 없다. 리모트 서버에 연결할 때마다 git에 의해 자동으로 위치가 옮겨진다.  

  

1. 원격 브랜치 상태 보기 

 git remote show [remote]   

• 모든 원격 브랜치 연결 상태를 보여준다.  
• 명령을 실행했을 때 나타나는 결과는 모두 마지막으로 서버에서 데이터를 가져온(fetch) 시점을 바탕으로 계산한다.  
• 원격저장소보다 커밋이 최신(up to date)인지, 뒤쳐지거나(local out of date), 앞서는지(fast-forwardable) 알 수 있다.  

 git branch -vv   

• 추적 브랜치 상태 확인  
• 명령을 실행했을 때 나타나는 결과는 모두 마지막으로 서버에서 데이터를 가져온(fetch) 시점을 바탕으로 계산한다.   
• 정확히 몇개의 커밋이 뒤쳐지거나 앞서는지 볼 수 있다.  
• 현재 시점에서 진짜 최신 데이터로 추적 상황을 알아보려면 git fetch --all; git branch -v  

  

2. 원격 브랜치로부터 저장소를 동기화  

 git fetch <remote>  

• 원격 서버로부터 저장소 정보를 동기화   
• 현재 로컬의 저장소가 갖고 있지 않은 새로운 정보가 있으면 모두 내려받고,  
• 받은 데이터를 로컬 저장소에 업데이트하고 나서,  
• origin/master 포인터의 위치를 최신 커밋으로 이동시킨다.   
• fetch한다고 해서 로컬 저장소에서 수정할 수 있는 브랜치가 새로 생기는 것이 아니다. 그저 수정 못 하는 브랜치 포인터가 생기는 것.   
• 수정하기 위해선 merge해야 한다.  

 

1. 새로 받은 브랜치의 내용을 Merge 하려면   

git merge <remote>/<remote branch>  

 

2. Merge 하지 않고 원격 브랜치에서 시작하고 수정할 수 있는 local branch를 만들려면  

git checkout -b <local branch> <remote>/<remote branch>   

 

원격 브랜치와 다른 이름으로 로컬 브랜치를 생성하고 싶을 때  

git checkout --track <remote>/<remote branch>   

 

로컬 브랜치 이름을 자동으로 생성 (입력한 브랜치가 있는 리모트가 딱 하나 있고 로컬에는 없으면 가능) 

git checkout <remote branch>   

 

git merge @{u} or @{upstream}  

이미 추적 브랜치를 설정했다면 추적 브랜치 이름을 @{upstream}이나} 이나 @{u}로 짧게 대체하여 사용할 수 있다. 트래킹 하는 대상 브랜치를 "Upstream 브랜치" 라고 부른다.  

 

git branch -u or --set -upstream-to <remote>/<remote branch>  

이미 로컬에 존재하는 브랜치가 리모트의 특정 브랜치를 추적하게 하려면 일반적으로 fetchfetch와 merge 명령을 명시적으로 사용하는 것이 pull 명령으로 한 번에 두 작업을 하는 것보다 낫다. 

 

3. 로컬의 브랜치를 서버로 전송   

git push <remote> <branch>  

• 로컬 저장소의 브랜치는 git push <remote>할 때 자동으로 리모트 저장소로 전송되지 않는다.  
• 로컬의 브랜치를 서버로 전송하려면 쓰기 권한이 있는 리모트 저장소에 따로 Push 해야 한다.   
• 따라서 리모트 저장소에 전송하지 않고 로컬 브랜치에만 두는 비공개 브랜치를 만들 수 있다.  

 

또 다른 사람과 협업하기 위해 토픽 브랜치만 전송할 수도 있다.   

git push <remote> <local branch>:<remote branch>  

 

로컬 브랜치의 이름과 리모트 서버의 브랜치 이름이 다를 때, 리모트 저장소에 다른 branch이름을 사용하고 싶을 때 

git push <remote> <local branch>:<new remote branch> 

 

git config --global credential.helper cache  

이 리모트에 접근할 때마다 매번 사용자 이름나 암호를 입력하지 않도록 할 수 있다.  

 

4. 추적 브랜치 삭제  

git push <remote> --delete <remote branch>   

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

반응형

Rebase 리베이스 

보통 리모트 브랜치에 커밋을 깔끔하게 적용하고 싶을 때 사용  

로컬 브랜치에서 작업할 때 히스토리를 정리하기 위해서 Rebase 할 수도 있는데, Push 하기 전에 정리하기 위한 것이나, 절대 공개하지 않고 혼자 Rebase 하는 경우는 위험하지 않다.  

원격 저장소 등 어딘가에 Push로 내보낸 커밋에 대해서는 절대 Rebase 하지 말아야 한다.
pull 한 commit이 rebase 되어 변경된 경우 git rebase <remote>/<local branch> 로 정리 (rebase 한 commit 내용이 이전과 동일할 경우만)

Rebase가 좀 더 깨끗한 히스토리를 만든다.   

일을 병렬로 동시에 진행해도 Rebase 하고 나면 모든 작업이 차례대로 수행된 것처럼 보인다.  

이렇게 Rebase 하고 나면 프로젝트 관리자는 어떠한 통합작업도 필요 없다. 그냥 브랜치를 Fast-forward 시키면 된다.   

Rebase를 하든지, Merge를 하든지 최종 결과물은 같고 커밋 히스토리만 다르다.   

• Rebase 의 경우는 브랜치의 변경사항을 순서대로 다른 브랜치에 적용하면서 합치고,  
• Merge 의 경우는 두 브랜치의 최종결과만을 가지고 합친다.  

 

베이스 브랜치에서 갈라진 topic A 브랜치와 topic B 브랜치의 공통 커밋을 topic B 브랜치에서 없애고 싶을 때 (어떤 브랜치에 topic B 브랜치만 가진 변경사항만 적용하고 싶을 때)

git rebase --onto <basebranch> <topic A> <topic B> 

 

git pull --rebase = git fetch + git rebase <remote>/master   

• git config --global pull.rebase true git pull 명령을 실행할 때 기본적으로 --rebase 옵션이 적용되도록  

   

Rebase의 장점  

• 중간에 conflict를 수정하다 어려움을 만나도 언제든지 git rebase --abort로 rebase 작업을 취소할 수 있고,  
• 심지어 그것 조차도 부담이 된다면, rebase 전에 임시 branch를 백업 용도로 만들었다가 rebase 후에 삭제   
• 지속적으로 conflict가 발생하는 경우라면, 아예 master에 임시 branch를 만들고 커밋별로 cherry-pick을 하기도.  

도움이 되셨다면 광고를 한 번씩 클릭 부탁드려요🥰