로컬 저장소와 원격 저장소의 관계
이전 장에서 우리는 파일을 수정하고, 변경 사항을 스테이징하고, 커밋으로 기록하는 흐름을 배웠습니다. 여기서 중요한 점이 있습니다. 커밋은 아직 내 컴퓨터 안에만 저장된 기록입니다.
GitHub에 내 작업을 올리려면 한 단계가 더 필요합니다. 바로 원격 저장소와 연결하고 push하는 것입니다.
간단히 정리하면 다음과 같습니다.
| 개념 | 의미 |
|---|---|
| 로컬 저장소 | 내 컴퓨터에 있는 Git 저장소 |
| 원격 저장소 | GitHub에 있는 Git 저장소 |
| push | 로컬 커밋을 GitHub로 올리기 |
| pull | GitHub의 변경 사항을 내 컴퓨터로 가져와 합치기 |
| clone | GitHub 저장소 전체를 내 컴퓨터로 복사하기 |
이 장의 목표는 명확합니다. 내 컴퓨터의 Git 저장소와 GitHub 저장소를 연결하고, 서로 동기화하는 방법을 익히는 것입니다.

기존 폴더를 Git 저장소로 만들기
먼저 내 컴퓨터에 있는 일반 폴더를 Git 저장소로 바꿔 보겠습니다.
터미널에서 실습용 폴더를 만들고 이동합니다.
mkdir github-remote-practice
cd github-remote-practice간단한 파일을 하나 만듭니다.
echo "# GitHub Remote Practice" > README.md이 폴더는 아직 Git 저장소가 아닙니다. Git 저장소로 만들려면 다음 명령어를 실행합니다.
git initgit init은 현재 폴더 안에 Git이 변경 이력을 관리할 수 있는 공간을 만듭니다. 겉으로는 크게 달라 보이지 않지만, 내부에는 .git이라는 숨김 폴더가 생깁니다. 이 폴더가 Git 기록을 저장하는 핵심 공간입니다.
이제 상태를 확인합니다.
git statusREADME.md 파일이 아직 추적되지 않은 파일로 표시될 것입니다. 이 파일을 커밋으로 기록합니다.
git add README.md
git commit -m "프로젝트 시작"여기까지 하면 로컬 저장소에는 첫 번째 커밋이 생겼습니다. 하지만 아직 GitHub에는 아무것도 올라가지 않았습니다.
GitHub 저장소 만들기
이제 GitHub에서 원격 저장소를 만듭니다.
GitHub 웹사이트에서 다음 순서로 진행합니다.
GitHub에 로그인합니다.
오른쪽 위의
+버튼을 누릅니다.New repository를 선택합니다.저장소 이름을 입력합니다. 예:
github-remote-practice공개 여부를 선택합니다.
Create repository를 누릅니다.
여기서 한 가지 주의할 점이 있습니다.
이미 내 컴퓨터에서 README.md 파일을 만들고 커밋했으므로, GitHub 저장소를 만들 때는 가능하면 README, .gitignore, license를 추가하지 않은 빈 저장소로 시작하는 것이 쉽습니다.
GitHub 저장소가 만들어지면 다음과 같은 주소가 보입니다.
https://github.com/사용자명/github-remote-practice.git이 주소가 원격 저장소의 위치입니다.
origin으로 원격 저장소 연결하기
이제 내 컴퓨터의 로컬 저장소와 GitHub의 원격 저장소를 연결합니다.
git remote add origin https://github.com/사용자명/github-remote-practice.git여기서 origin은 원격 저장소의 별칭입니다.
매번 긴 GitHub 주소를 입력하기는 번거롭습니다. 그래서 Git은 원격 저장소 주소에 이름을 붙여 사용할 수 있게 해 줍니다. 보통 첫 번째 원격 저장소의 이름은 관례적으로 origin을 사용합니다.
즉, 다음 두 표현은 같은 대상을 가리키는 셈입니다.
originhttps://github.com/사용자명/github-remote-practice.git연결이 제대로 되었는지 확인하려면 다음 명령어를 사용합니다.
git remote -v결과는 대략 이렇게 나옵니다.
origin https://github.com/사용자명/github-remote-practice.git (fetch)
origin https://github.com/사용자명/github-remote-practice.git (push)여기서 fetch는 가져올 때 사용하는 주소이고, push는 올릴 때 사용하는 주소입니다. 대부분의 경우 같은 주소가 표시됩니다.
중요한 점은 이것입니다. remote add는 연결만 하는 명령어입니다. 파일을 GitHub에 올리는 명령어가 아닙니다.
올리는 작업은 다음에 배울 push가 담당합니다.
git push로 GitHub에 업로드하기
로컬 저장소에 있는 커밋을 GitHub로 올려 보겠습니다.
먼저 현재 브랜치 이름을 main으로 맞춥니다.
git branch -M main그리고 push합니다.
git push -u origin main이 명령어를 나누어 보면 다음과 같습니다.
| 부분 | 의미 |
|---|---|
git push | 로컬 커밋을 원격 저장소로 올린다 |
origin | 올릴 대상 원격 저장소 |
main | 올릴 브랜치 이름 |
-u | 다음부터 기본 연결로 기억한다 |
처음 push할 때는 로그인이 필요할 수 있습니다. GitHub 계정으로 브라우저 인증을 하거나, 환경에 따라 토큰 인증을 요구할 수 있습니다.
push가 성공하면 GitHub 저장소 페이지를 새로고침해 보세요. 내 컴퓨터에서 만든 README.md 파일이 GitHub에 표시됩니다.
이 순간 로컬 저장소와 원격 저장소가 연결되었습니다.
앞으로 같은 브랜치에서 작업한다면 매번 긴 명령어를 쓰지 않아도 됩니다.
git push처음에 -u origin main으로 연결을 기억해 두었기 때문입니다.
실전 예시: 수정하고 다시 올리기
이번에는 파일을 수정한 뒤 다시 GitHub에 올려 보겠습니다.
README.md 파일에 내용을 추가합니다.
echo "로컬 저장소와 원격 저장소 연결을 연습합니다." >> README.md변경 상태를 확인합니다.
git status수정된 README.md가 표시됩니다. 이제 평소의 Git 흐름대로 진행합니다.
git add README.md
git commit -m "README 설명 추가"
git push순서는 항상 비슷합니다.
파일을 수정한다.
git status로 확인한다.git add로 스테이징한다.git commit으로 로컬에 기록한다.git push로 GitHub에 올린다.
여기서 초보자가 자주 헷갈리는 부분이 있습니다.
commit은 로컬 저장이고, push는 GitHub 업로드입니다.
커밋만 해서는 GitHub에 보이지 않습니다. GitHub 웹에서 확인하려면 push까지 해야 합니다.
git clone으로 저장소 내려받기
이번에는 반대 상황을 생각해 보겠습니다.
이미 GitHub에 저장소가 있습니다. 새 컴퓨터에서 작업하거나, 회사 컴퓨터에서 이어서 작업하거나, 다른 사람의 저장소를 내 컴퓨터에 내려받고 싶을 수 있습니다.
이때 사용하는 명령어가 git clone입니다.
먼저 GitHub 저장소 주소를 복사합니다.
https://github.com/사용자명/github-remote-practice.git그리고 원하는 위치에서 다음 명령어를 실행합니다.
git clone https://github.com/사용자명/github-remote-practice.git그러면 현재 위치에 저장소 이름과 같은 폴더가 생깁니다.
cd github-remote-practicegit clone은 단순히 파일만 내려받는 명령어가 아닙니다. 저장소의 커밋 기록과 브랜치 정보도 함께 가져옵니다. 또한 원격 저장소 주소가 자동으로 origin이라는 이름으로 등록됩니다.
확인해 봅니다.
git remote -v직접 git remote add origin ...을 하지 않아도 이미 연결되어 있을 것입니다.
정리하면 다음과 같습니다.
| 상황 | 사용할 명령어 |
|---|---|
| 내 컴퓨터 폴더를 새 Git 저장소로 만들 때 | git init |
| GitHub 저장소를 내 컴퓨터로 통째로 받을 때 | git clone |
이미 clone한 폴더 안에서 다시 git init을 실행할 필요는 없습니다.
git fetch와 git pull의 차이
원격 저장소와 연결하면 내 작업을 올리는 것뿐 아니라, GitHub에 있는 변경 사항을 가져오는 일도 중요해집니다.
이때 자주 나오는 명령어가 fetch와 pull입니다.
둘의 차이는 간단히 말해 다음과 같습니다.
| 명령어 | 의미 |
|---|---|
git fetch | 원격 저장소의 최신 기록을 가져오되, 내 작업 파일에는 바로 합치지 않는다 |
git pull | 원격 저장소의 변경 사항을 가져와 내 작업 폴더에 합친다 |
비유하면 fetch는 택배가 도착했는지 확인하고 보관 위치를 업데이트하는 것에 가깝고, pull은 택배를 실제로 받아서 집 안에 들여놓는 것에 가깝습니다.
예를 들어 GitHub 웹에서 README.md를 직접 수정했다고 해 봅시다. 내 컴퓨터의 파일은 아직 바뀌지 않았습니다.
먼저 원격 저장소에 새 변경 사항이 있는지 확인하고 싶다면 다음 명령어를 실행합니다.
git fetch origin이 명령어는 GitHub의 최신 커밋 정보를 가져오지만, 내 작업 파일을 바로 바꾸지는 않습니다. 즉, 안전하게 "원격에 새 기록이 있구나"를 확인할 수 있습니다.
반대로 GitHub의 변경 사항을 내 컴퓨터에 실제로 반영하고 싶다면 다음 명령어를 실행합니다.
git pull origin main처음 push할 때 -u origin main으로 기본 연결을 설정했다면 더 짧게 쓸 수도 있습니다.
git pull초보자에게는 다음 습관을 추천합니다.
git status
git pull작업을 시작하기 전에 현재 상태를 확인하고, GitHub에 새 변경 사항이 있다면 먼저 가져오는 것입니다. 이렇게 하면 나중에 충돌이 생길 가능성을 줄일 수 있습니다.
다만 내 컴퓨터에서 수정 중인 파일과 GitHub의 변경 사항이 같은 부분을 건드렸다면 충돌이 날 수 있습니다. 충돌 해결은 뒤의 장에서 자세히 다룹니다.
자주 만나는 문제와 해결 방법
remote origin already exists
이미 origin이라는 원격 저장소가 등록되어 있는데 다시 추가하려고 하면 다음과 비슷한 메시지가 나올 수 있습니다.
error: remote origin already exists.이때는 현재 연결 상태를 먼저 확인합니다.
git remote -v주소가 잘못되어 있다면 새 주소로 바꿀 수 있습니다.
git remote set-url origin https://github.com/사용자명/새저장소명.gitpush했는데 거절되는 경우
가끔 push할 때 원격 저장소에 내가 가지고 있지 않은 커밋이 있어서 거절될 수 있습니다.
이럴 때는 보통 먼저 원격 변경 사항을 가져와야 합니다.
git pull origin main그다음 다시 push합니다.
git push만약 같은 파일의 같은 부분을 서로 다르게 수정했다면 충돌이 발생할 수 있습니다. 이 경우에는 충돌을 해결한 뒤 다시 커밋해야 합니다.
nothing to commit
git commit을 했는데 다음과 같은 메시지가 나올 수 있습니다.
nothing to commit, working tree clean이것은 오류가 아닙니다. Git이 보기에 새로 기록할 변경 사항이 없다는 뜻입니다. 이미 커밋했거나, 파일을 수정하지 않은 상태일 수 있습니다.
이번 장 정리
이 장에서는 로컬 저장소와 GitHub 원격 저장소를 연결하는 방법을 배웠습니다.
핵심만 다시 정리하면 다음과 같습니다.
git init은 기존 폴더를 Git 저장소로 만든다.origin은 원격 저장소 주소에 붙이는 기본 별칭이다.git remote -v로 원격 저장소 연결 상태를 확인한다.git push는 로컬 커밋을 GitHub에 올린다.git clone은 GitHub 저장소 전체를 내 컴퓨터에 내려받는다.git fetch는 원격 저장소의 최신 기록을 가져오지만 내 작업 파일에는 바로 합치지 않는다.git pull은 원격 변경 사항을 가져와 내 작업 폴더에 합친다.
이제 혼자 작업한 내용을 GitHub에 올릴 수 있고, 다른 컴퓨터에서도 같은 저장소를 내려받아 이어서 작업할 수 있습니다.
다음 장에서는 브랜치를 사용해 안전하게 실험하는 방법을 배웁니다. 브랜치를 이해하면 기존 코드를 망가뜨릴 걱정을 줄이고, 새로운 기능을 더 편하게 시도할 수 있습니다.
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.
