[웹앱 실무 76] Git - 원격 저장소

노트북을 잃어버린 적 있으세요? 저는 카페에서 가방째 도둑맞은 적이 있어요. 다행히 코드는 전부 원격 저장소(remote repository)에 올려둬서 새 노트북에서 git clone 한 방으로 복구했죠. 원격 저장소는 백업이자 팀 협업의 중심이에요. 오늘은 이 원격을 연결하고, 올리고, 받는 흐름을 실제 명령으로 돌려볼게요.

76.1 원격 저장소가 왜 필요한가요?

지금까지 git commit으로 저장한 건 전부 내 컴퓨터 안에만 있어요. 컴퓨터가 고장 나면 히스토리째 사라지죠. 원격 저장소는 그 커밋들을 인터넷 어딘가의 서버에 똑같이 보관하는 공간이에요. 깃허브(GitHub), 깃랩(GitLab) 같은 서비스가 이 서버를 대신 운영해주고요.

원격이 있으면 두 가지가 풀려요. 하나는 백업이에요. 내 노트북이 사라져도 서버에 코드가 남아 있죠. 다른 하나는 협업이에요. 동료가 같은 원격을 바라보면, 내가 올린 커밋을 동료가 받고 동료가 올린 걸 내가 받아요. 원격은 팀이 같이 보는 공용 창고라고 생각하면 편해요.

76.2 원격을 어떻게 연결하나요?

깃허브에서 빈 저장소를 하나 만들면 주소를 줘요. 그 주소를 내 로컬 저장소에 연결하는 게 git remote add예요. 관례상 이 원격의 별명을 origin이라고 붙여요.

$ git remote add origin https://github.com/team/app.git

제대로 붙었는지는 git remote -v로 확인해요. 가져올 주소(fetch)와 올릴 주소(push)가 같이 나와요.

$ git remote -v
origin https://github.com/team/app.git (fetch)
origin https://github.com/team/app.git (push)

origin은 그냥 별명이라 다른 이름을 붙여도 돼요. 회사 서버와 깃허브를 동시에 쓸 땐 origin, backup처럼 원격을 여러 개 달기도 해요. 처음엔 origin 하나면 충분하고요.

76.3 내 커밋을 어떻게 올리나요?

올리는 명령은 git push예요. 처음 올릴 땐 -u 옵션을 붙여서 내 로컬 main이 원격의 main을 추적(track)하도록 짝지어줘요. 한 번 짝지어두면 다음부터는 git push만 쳐도 알아서 그 짝으로 올라가요.

$ git push -u origin main
To https://github.com/team/app.git
* [new branch] main -> main
branch 'main' set up to track 'origin/main'.

짝이 잘 지어졌는지는 git branch -vv로 봐요. 대괄호 안에 [origin/main]이 붙어 있으면 추적 중이라는 뜻이에요.

$ git branch -vv
* main 1bd8f36 [origin/main] docs: README 추가

여기서 자주 헷갈리는 게 커밋과 push는 별개라는 거예요. git commit은 내 컴퓨터에만 저장이고, 그게 서버에 올라가려면 반드시 git push를 한 번 더 해야 해요. 커밋만 하고 push를 잊어서 종일 작업이 원격에 없던 경험, 다들 한 번쯤 하죠.

76.4 남이 올린 걸 어떻게 받나요?

남의 저장소를 통째로 처음 받을 땐 git clone이에요. 주소만 주면 히스토리까지 싹 복제해서 폴더를 만들어줘요. 아까 도둑맞은 노트북 이야기의 그 명령이죠.

$ git clone https://github.com/team/app.git

이미 clone 받은 뒤 동료의 새 커밋을 받을 땐 두 갈래가 있어요. git fetch는 원격의 변화를 가져오기만 하고 내 작업에는 손대지 않아요. 내려받은 걸 확인하고 나서 합칠지 정할 수 있죠. git pull은 fetch에 merge를 붙인 명령이에요. 가져와서 곧바로 내 브랜치에 합쳐줘요.

$ git fetch # 가져오기만, 내 코드는 그대로
$ git pull # 가져와서 바로 합침

저는 협업할 땐 pull보다 fetch를 먼저 쓰는 편이에요. 원격에 뭐가 바뀌었는지 git log origin/main으로 눈으로 보고, 내 작업과 안 부딪히겠다 싶으면 합치죠. 갑자기 pull 했다가 충돌 화면을 마주하는 것보다 마음이 편하거든요. 물론 혼자 쓰는 저장소라면 pull 한 방이 빠르고요.

참고로 git pull --rebase도 자주 써요. 그냥 pull은 원격 변경을 merge로 합치면서 합침 커밋을 만드는데, --rebase는 내 커밋을 원격 위에 다시 얹어 히스토리를 한 줄로 유지해줘요. 리베이스 편에서 본 그 원리를 pull에 붙인 거죠. 팀 히스토리를 깔끔하게 두고 싶을 때 좋아요.

76.5 원격 브랜치는 로컬이랑 어떻게 다른가요?

여기서 헷갈리는 이름이 하나 나와요. main과 origin/main. main은 내 컴퓨터의 브랜치고, origin/main은 내가 마지막으로 원격과 소통했을 때 원격이 어디까지 와 있었는지를 기억하는 표식이에요. 그래서 origin/main은 실시간이 아니에요. 동료가 방금 push했어도, 내가 git fetch를 하기 전까지 내 origin/main은 옛날 그 자리에 멈춰 있어요.

git fetch를 하는 순간 이 origin/main이 원격의 진짜 최신으로 갱신돼요. 그래서 fetch는 원격의 사진을 새로 찍는 일이라고 생각하면 편해요. 사진을 새로 찍은(fetch) 다음, 그 사진과 내 작업을 합칠지(merge) 말지를 내가 정하는 거죠. pull은 이 두 단계를 한꺼번에 해주는 거고요. 이 관계만 잡히면 fetch와 pull이 왜 다른지 자연스럽게 이해돼요.

76.6 인증은 어떻게 하나요?

처음 push할 때 Authentication failed(인증 실패, 401) 같은 걸 마주치면 대개 인증 문제예요. 원격에 접근하는 방법은 크게 둘이에요. 하나는 HTTPS 주소로 접속해 개인 토큰(personal access token)을 비밀번호 대신 넣는 방식이에요. 예전엔 깃허브 비밀번호를 그대로 썼는데, 지금은 막혀서 토큰을 발급해 써야 해요.

다른 하나는 SSH 방식이에요. 내 컴퓨터에서 열쇠 한 쌍(공개 키와 비밀 키)을 만들어 공개 키를 깃허브에 등록해두면, 그 다음부턴 비밀번호도 토큰도 안 물어봐요. 주소가 [email protected]:team/app.git 모양이면 SSH예요. 매번 인증하기 귀찮다면 SSH를 한 번 설정해두는 걸 추천해요. 처음 세팅만 조금 번거롭지 그 뒤론 아주 편하거든요.

76.7 원격, 이것만 기억해요

흐름으로 외우면 안 잊어버려요. 첫째, git remote add origin 주소로 원격을 연결하고 git remote -v로 확인해요. 둘째, git push -u origin main으로 처음 올리며 추적 짝을 만들고, 이후엔 git push만으로 올려요. 커밋과 push는 별개라는 것도요.

셋째, 처음 받을 땐 git clone, 이후 갱신은 git fetch(가져오기만)나 git pull(가져와 합치기)이에요. 이 다섯 명령이면 원격 저장소 일상은 거의 다 돌아가요. 원격을 잘 쓰면 노트북이 사라져도, 팀원이 열 명이어도 코드가 한곳에서 안전하게 흘러요.