커밋을 다른 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-forward | fetch 후 양쪽 커밋 그래프 |
명령의 기준은 git fetch, git pull, git push입니다. HTTPS 인증은 서비스의 인증 도우미나 자격 증명 저장소를 사용하고, 접근 토큰이 화면과 셸 이력에 남지 않게 관리합니다.
이전 글 · [Git·GitOps 09] 충돌 해결하기: 공통 조상과 3-way merge · 다음 글 · [Git·GitOps 11] 팀 브랜치 전략과 Pull Request: merge·rebase의 선택 · 연재 목록과 예제 파일

![[Git·GitOps 24] Git·CI/CD·GitOps 운영 흐름 완성하기: 장애별 판단과 복구](https://blog.maruops.com/wp-content/uploads/2026/10/maruops-git-photo-12-768x510.webp)
![[Git·GitOps 23] 비밀 값 관리: Secret의 base64와 SOPS·age 암호화](https://blog.maruops.com/wp-content/uploads/2026/10/maruops-git-photo-2-768x512.webp)
![[Git·GitOps 22] 변경 감지와 복구: 자동 Sync·selfHeal·prune·Git revert](https://blog.maruops.com/wp-content/uploads/2026/10/maruops-git-photo-10-768x576.webp)
답글 남기기