마루옵스서버 · 네트워크 · AI 기술 노트

소개문의

[Git·GitOps 10] 원격 저장소 연결하기: clone·fetch·pull·push

노트북과 머그잔이 놓인 나무 책상

참고 사진 · 노트북과 머그잔이 놓인 나무 책상 · 사진: Ryan Riggins ryan_riggins / 원본 / CC0 · 목록용 크기 조정

커밋을 다른 PC에서도 보려면 원격 저장소가 필요합니다. origin은 Git 서버 제품의 이름이 아니라 URL에 붙인 별칭이에요. 로컬 브랜치와 서버 브랜치를 구분하면 fetch와 pull의 차이도 자연스럽게 이해할 수 있습니다.

지금은 GitHub·기존 사내 Git 서비스처럼 이미 사용 가능한 서버를 기준으로 설명합니다. 직접 만들 서버는 14~15편에서 준비합니다. URL과 사용자 이름은 서버가 제공하는 실제 값으로 바꾸고, 토큰이나 비밀번호를 URL에 넣지 않습니다.

Git·GitOps 전체 연재 · 10 / 24

이 글의 목차

새 프로젝트와 기존 로컬 프로젝트를 구분한다

서버에 이력이 있는 프로젝트라면 비어 있는 작업 경로에서 clone합니다. 아래 URL은 문법을 보여주는 예시이므로 그대로 접속되지 않습니다.

cd ~/git-lab
git clone https://git.example.com/team/project.git
cd project
git remote -v
git branch -vv

이미 gitops-demo를 로컬에서 만들었다면 서버에는 README 없이 빈 저장소를 만든 뒤 원격을 등록하는 편이 간단합니다. 서버에서도 첫 커밋을 만들면 양쪽이 별개의 시작 이력을 가져 추가 판단이 필요해요.

cd ~/git-lab/gitops-demo
git remote add origin https://git.example.com/team/gitops-demo.git
git remote -v
git push -u origin main

-u는 로컬 main의 upstream을 설정합니다. 이후 인자 없이 push나 pull할 때 참고할 관계입니다. 이미 origin이 있으면 add를 반복하지 말고 git remote get-url origin으로 확인한 뒤 필요한 경우 set-url을 사용합니다.

fetch는 조회, pull은 조회 후 통합

git fetch origin
git log --oneline --graph --decorate --all -15
git diff main..origin/main
git switch main
git pull --ff-only

origin/main은 서버를 실시간으로 보는 창이 아니라 마지막 fetch 때 갱신한 로컬 원격 추적 참조입니다. fetch는 서버 이력을 가져와도 현재 작업 브랜치를 바로 병합하지 않습니다. 먼저 비교하고 어떻게 통합할지 결정할 때 유용해요.

pull은 fetch 뒤에 병합 또는 rebase를 수행합니다. --ff-only는 분기된 로컬 이력이 있으면 멈추도록 합니다. 멈춘 상태에서 git status, 그래프를 보고 미공유 커밋을 rebase할지 merge할지 선택합니다. reset --hard origin/main으로 작업을 지우는 것을 오류 해결의 첫 단계로 삼지 않습니다.

SSH는 사용자 키와 서버 키를 따로 확인한다

Linux Bash 또는 Git Bash에서 사용자 키를 생성할 수 있습니다. 기존 파일을 덮어쓰지 않는 새 이름을 사용하고 암호문을 설정합니다. 공개 키인 .pub만 Git 서비스의 계정 설정에 등록합니다.

mkdir -p ~/.ssh
chmod 700 ~/.ssh
ssh-keygen -t ed25519 -C "git-client" -f ~/.ssh/id_ed25519_gitteam

여러 키가 있다면 ~/.ssh/config로 서버별 IdentityFile을 지정할 수 있습니다. 실제 서버 주소와 계정, 포트를 입력합니다.

Host git-team
    HostName git.example.com
    User git
    Port 22
    IdentityFile ~/.ssh/id_ed25519_gitteam
    IdentitiesOnly yes

최초 접속 시 나타나는 서버 호스트 키 지문은 관리자에게 별도 경로로 받은 값과 비교합니다. ssh-keyscan으로 키를 수집하는 것만으로 서버의 신원을 증명한 것은 아닙니다. 서버 재설치 후 경고가 났다고 기존 known_hosts 항목부터 지우지 않습니다.

push가 거절되면 다른 사람의 변경을 먼저 본다

non-fast-forward는 서버 끝이 내가 아는 위치보다 앞서거나 이력이 갈라졌다는 뜻일 수 있습니다. fetch 후 차이를 확인합니다. 내 미공유 커밋이라면 rebase로 옮길 수 있지만, 공유된 main을 강제 푸시해 덮는 방식은 피합니다.

증상먼저 볼 항목
DNS·연결 실패서버 이름, 포트, VPN, 방화벽
Permission denied (publickey)SSH 사용자, 등록한 공개 키, 사용 중인 개인 키
HTTPS 401·403토큰 만료·범위, 저장소 권한
non-fast-forwardfetch 후 양쪽 커밋 그래프

명령의 기준은 git fetch, git pull, git push입니다. HTTPS 인증은 서비스의 인증 도우미나 자격 증명 저장소를 사용하고, 접근 토큰이 화면과 셸 이력에 남지 않게 관리합니다.

이전 글 · [Git·GitOps 09] 충돌 해결하기: 공통 조상과 3-way merge · 다음 글 · [Git·GitOps 11] 팀 브랜치 전략과 Pull Request: merge·rebase의 선택 · 연재 목록과 예제 파일

댓글

답글 남기기

이메일 주소는 공개되지 않습니다. 필수 필드는 *로 표시됩니다

닉네임·이메일·댓글 내용·IP 주소·브라우저 정보는 댓글 게시 및 관리에 사용됩니다. 이메일과 접속 정보는 공개 댓글에 표시하지 않습니다. 개인정보 요청은 운영자 이메일로 보내 주세요. 개인정보처리방침