Git 명령어 정리 - 리모트 브랜치 편

이 포스트와 사용된 사진은 아래의 책 내용을 기반으로 작성하였습니다.

GitHub - progit/progit2-ko

또한 크리에이티브커먼즈에 의거 CC-BY-NC-SA를 따릅니다.

 

설명보단 브랜치 상태와 명령어에 따른 변화를 보여드리겠습니다.

 

- 리모트 브랜치

$ git commit -am "A"
$ git commit -am "B"

리모트도 별개로 2개의 커밋을 함.

로컬과 서버의 커밋 히스토리는 독립적으로 움직입니다.

서버에서 커밋이 일어났다고 해서 로컬에 origin/master가 리모트의 커밋 히스토리를 따라가지 않습니다.

 

git fetch origin 명령어를 통해 origin 리모트 저장소와 동기화할 수 있습니다.

 

git remote add <remote_name> <remote_address> 명령어를 통해

remote_name의 원격 저장소를 추가할 수 있습니다.

 

git fetch teamone 명령어를 통해 teamone 리모트 저장소와 동기화할 수 있습니다.

---

- push & pull

$ git push origin serverfix

origin 리모트의 serverfix 브랜치로 현재 커밋내역을 push하는 명령어 입니다.

 

$ git fetch origin

그렇다면 다른 협업하는 사람은 업데이트 내용을 origin 리모트에서 받아오면 됩니다.

참고로 fetch 명령은 데이터만 받아올 뿐, 로컬의 워킹 디렉토리의 내용을 변경하진 않습니다.

가져온 데이터를 확인한 뒤, git merge 명령어를 추가로 입력해줘야 하는데요,

$ git pull origin

pull 명령어 사용시 fetch, merge 명령어를 한 번에 처리하는 효과를 얻을 수 있습니다.

 

$ git checkout -b serverfix origin/serverfix

이 명령어는 origin 리모트의 serverfix 브랜치 스냅샷을 가져와 로컬에 serverfix라는 브랜치로 만들고,

Head -> serverfix로 가리키게 하는 명령어 입니다.

---

- Rebase

Head -> master

$ git checkout experiment
$ git rebase master

Head -> experiment

$ git checkout master
$ git merge experiment

Head -> master

merge는 커밋을 하며 각 브랜치의 히스토리를 비교해 공통 조상을 찾아

공통 조상 커밋으로 부터 수정된 사항을 추가해 하나의 커밋으로 만들어 3-way merge를 하는 반면,

rebase는 공통 조상으로부터 rebase할 커밋(master)뒤에 수정사항을 추가한다.

 

장점이자 단점은 커밋 히스토리가 깔끔하게 변한다는 점이다.

장점인 이유를 다음 예시를 통해 알아보자.

 

Head -> server

$ git rebase --onto master server client
# master 브랜치로부터
# server 브랜치와 client 브랜치의 공통조상까지의 커밋(C3 C2)을
# client 브랜치에서 제거할 때

Head -> server

$ git checkout master
$ git merge client

Head -> master

$ git rebase master server
or 
$ git checkout server
$ git rebase master

Head -> server

$ git checkout master
$ git merge server
$ git branch -d client
$ git branch -d server

 

이제 단점인 이유도 알아보자.

협업하는 상황(공개 저장소에 push 한 커밋에 대해)에서는 절대로 rebase를 사용하면 안되는 이유이다.

 

clone 후 일부를 수정한 상태이다.

 

이 때, 누군가가 업데이트된 작업사항(C4 C5 C6)을 push하였다.

따라서 로컬에서 pull 하고 merge를 진행하였다.

 

이 때, 그 누군가가 rebase 를 한 뒤에 push하였다.

로컬에서 pull 해보니 위와 같은 상황이었다...

 

merge 결과 난장판이 되었다.

결과적으로 C4 C6 커밋은 존재하지 말아야 할 커밋이 되어버렸다. (심지어 C4 C4'는 커밋 메세지도 같다)

이 경우에는 처음에 그 누군가가 push 하기 전에 rebase로 커밋 히스토리를 깔끔하게 만들고 나서

rebase를 했어야 했다. (push하고 rebase하는 것이 아니라...)

 

그나마 사태를 수습하는 방법은 여기서 merge를 하는 것이 아닌, 나도 rebase를 하는 것이다.

$ git rebase teamone/master