서론
이전에 작성했던 fork 저장소 관리 포스팅 에서는 전반적인 fork 저장소를 관리하는 과정에 대해서 살펴보았지만 이번 포스팅에서는 fork 저장소를 관리할 때 접하게 되는 용어들, pull 명령어를 통해 관리하는 방법과 pull, fetch, merge, rebase 명령어에 대해 깊이 알아보자 한다.
본론
upstream
외부 repo 에서 본인의 remote repo 로 fork 를 코드 작성을 통해 contribute 하는 과정에서 upstream 이라는 용어를 접하게 된다. upstream 은 forked 된 외부 repo 를 upstream 이라고 하고, fork 한 본인의 remote repo 를 downstream 이라고 지칭한다.
origin
필자는 처음 git 을 접할 때 구글링을 통한 명령어 입력으로 repo 를 관리했었기에 주로 push, pull 에 등장하는 origin 의 정확한 의미를 파악하지 못했었다.
origin 은 바로가기의 개념과 거의 똑같다해도 무방하며, local 에 repo 를 clone 했을 때 해당 repo 의 주소를 일일이 입력할 필요 없이 origin 이라는 바로가기를 통해 짧은 명령어로 target repo 에 push, pull 할 수 있다.
pull
pull 명령어는 fetch 와 merge 를 함축시킨 명령어로 fetch 와 merge 에 대해서 바로 알아보자.
fetch
repo branch 를 원하는 곳 (remote repo branch, local) 에 가져오는 명령어로 FETCH_HEAD 라는 branch 를 자동으로 생성(이 부분은 실제로 테스트 해보지 않아서 정확하지 않다...)하여 repo branch 의 내용을 바로 merge 하지 않고 확인할 수 있다. 필자는 아직 fetch 의 필요성을 못느끼고 있는 단계라 현 수준에서는 단순히 pull 명령어를 통해 repo 의 내용을 가져오고 merge 하는 것이 좋다고 생각한다.
개인적으로 드는 생각은 fetch 는 pull 과 달리 merge 를 바로 하지 않기 때문에 merge conflict 를 일어나기 전에 remote repo 의 commit 상태 (변경사항)를 확인하고 조금 더 안전하게 merge 를 진행하는 과정이라고 생각하면 되겠다.
rebase
rebase 명령어는 merge 명령어의 결과와 완전 동일하지만 commit history 에 차이가 있다. merge 의 경우부터 살펴보면 c1 이라는 base 가 존재하고 해당 base 를 기준으로 c2, c3 라는 2개의 branch 로 분기 후 c4 로 merge 된다고 가정하자. 이 과정이 되기 단순해 보이지만 대규모 회사에서 프로젝트를 진행한다고 가정했을 때 branch -> merge 과정이 수 도 없이 많을텐데 실제로 gui 버전으로 commit history 를 살펴보면 미로처럼 생긴 history 를 마주하게 될 것이다. 이를 보완하기 위해 rebase 라는 명령어가 쓰이는데 명령어 이름에서 알 수 있듯이 base 를 다시 설정한다는 뜻으로 c2 또는 c3 를 base 로 다시 설정하고 c1 -> c2 -> c3 -> c4 (c1 -> c3 -> c2 -> c4) 와 같이 일렬로 commit history 가 쌓이기 때문에 한눈에 알아보기 좋다는 장점이 있다.
결론
이번 포스팅에서는 fork 저장소를 관리할 때 사용되는 git 명령어에 대해 살펴보았다. 굉장히 얕게 살펴보았는데 지금은 단순히 pull 을 사용하는걸 권장하는 바이다. 지금은 이런 과정이 있다고만 인지하고 안드로이드 개발에 좀 더 깊이 있는 포스팅을 연재할 것이다.
pull, fetch, merge, rebase 에 대한 얕지만 기본적인 개념을 알게되었으니 오늘도 필자는 성장했다.
