3-1. Git을 서버와 연결해서 실제로 사용하는 법
Git 활용 3-1: GitHub 연결과 여러 PC에서 사용하는 법
앞선 글에서 Git의 개념과 저장 구조를 살펴봤다면, 이제 실제 개발 환경으로 나가볼 차례다.
이번 편에서는 내 PC의 Git 저장소를 GitHub와 연결하고, 다른 PC에서 clone하여 이어서 작업하는 과정을 실제 명령 흐름을 따라가며 정리한다. 중요한 것은 명령어 암기가 아니다. 각 명령을 실행할 때 내 PC와 GitHub 서버 사이에서 무엇이 생기고 무엇이 움직이는지를 이해하는 것이다.
1. Git과 GitHub는 같은 것이 아니다
Git
→ 내 컴퓨터에서 파일의 버전과 커밋 역사를 관리
GitHub
→ Git 저장소를 인터넷 서버에 보관·공유하는 서비스GitHub가 없어도 Git은 사용할 수 있다. git init, git add, git commit, git branch 등은 모두 로컬에서 동작한다. GitHub는 여기에 원격 저장소(remote repository)라는 공간을 추가할 뿐이다.
2. 처음 프로젝트를 GitHub에 올리는 과정
프로젝트 폴더에서 Git 저장소를 만든다.
cd C:\site\gitstudy
git initgit init은 현재 폴더를 Git이 관리하는 저장소로 만드는 명령이다. GitHub에서 내려받는 명령이 아니라는 점에 주의하자.
첫 파일을 스테이징하고 커밋한다.
git add README.md
git commit -m "first commit"필요하다면 기본 브랜치를 main으로 정리한다.
git branch -M mainGitHub에 만들어 둔 원격 저장소를 로컬 저장소에 등록한다.
git remote add origin https://github.com/사용자명/gitstudy.git마지막으로 첫 push를 한다.
git push -u origin main3. origin은 GitHub의 예약어일까?
아니다. origin은 원격 저장소 주소에 붙이는 별칭일 뿐이다.
긴 GitHub 주소
https://github.com/사용자명/gitstudy.git
↓
origin관례적으로 처음 연결한 원격 저장소를 origin이라 부르기 때문에 거의 표준처럼 보이는 것뿐이다. 등록된 원격 저장소는 다음으로 확인할 수 있다.
git remote -v4. git push -u origin main을 풀어 읽기
git push -u origin main
│ │ │ │
│ │ │ └─ 로컬 main 브랜치
│ │ └──────── 원격 저장소 별칭
│ └───────────── upstream 설정
└────────────────── Git 명령-u로 추적 관계를 설정하면 이후에는 보통 git push, git pull처럼 짧게 사용할 수 있다.
5. 이미 GitHub에 있는 프로젝트를 다른 PC에서 사용하려면?
git init부터 다시 해야 할까?아니다. 이미 원격 저장소가 존재한다면 일반적으로 clone한다.
C:\site> git clone https://github.com/사용자명/gitstudy.gitclone은 단순한 파일 다운로드가 아니다. 프로젝트 파일뿐 아니라 Git의 커밋 역사와 저장소 정보, 기본적인 원격 연결까지 함께 가져와 새로운 로컬 저장소를 만든다.
GitHub repository
↓ git clone
C:\site\gitstudy
├─ 프로젝트 파일
├─ .git
├─ 커밋 역사
└─ origin 연결이미 존재하는 원격 저장소를 내 PC에 가져온다 → git clone
6. clone했는데 git status가 안 된다?
이 부분도 처음 Git을 쓰면 자주 헷갈리는 지점이다.
C:\site> git clone ...
...
C:\site> git status
fatal: not a git repository ...clone이 실패한 것이 아니다. 저장소는 C:\site\gitstudy에 생겼는데, 현재 명령을 C:\site에서 실행했기 때문이다.
cd gitstudy
git status저장소 안으로 들어간 뒤에는 다음처럼 정상적으로 확인된다.
On branch main
Your branch is up to date with 'origin/main'.
nothing to commit, working tree clean즉 Git 명령은 현재 내가 어느 디렉터리에 서 있는가도 중요하다.
7. main과 origin/main은 무엇이 다른가?
main
→ 내 PC에서 작업하는 로컬 브랜치
origin/main
→ 마지막으로 받아온 원격 main의 위치를
로컬에서 나타내는 원격 추적 브랜치처음에는 둘이 같은 커밋을 가리킬 수 있다.
A ── B ── C
↑
main
↑
origin/main그러나 다른 PC가 GitHub에 D를 push했다면, 현재 PC의 정보는 자동으로 갱신되지 않는다.
8. fetch는 ‘먼저 받아보고 확인하기’
git fetch originfetch는 원격의 새로운 커밋과 참조 정보를 가져오지만, 현재 로컬 main에 바로 병합하지는 않는다.
A ── B ── C ── D
↑ ↑
main origin/main이제 다음처럼 무엇이 추가됐는지 볼 수 있다.
git log main..origin/main
git diff main origin/main확인 후 필요하면 다음으로 합칠 수 있다.
git merge origin/main9. pull = fetch 후 반영
git pull
≈ git fetch + git merge기본 동작을 이해하기 위한 식이다. 설정에 따라 pull이 rebase를 사용할 수도 있지만, 입문 단계에서는 원격 변경을 받아와 현재 브랜치에 반영한다고 이해하면 충분하다.
10. push는 로컬 커밋을 서버로 보내는 것
Working Tree
↓ add
Staging Area
↓ commit
Local Repository
↓ push
GitHub Remote Repository파일을 수정했다고 바로 GitHub가 바뀌는 것도 아니고, git commit했다고 바로 GitHub가 바뀌는 것도 아니다. push까지 해야 원격 저장소에 로컬 커밋이 전달된다.
11. 회사 PC와 집 PC를 오가며 작업한다면
회사 PC
수정 → add → commit → push
↓
GitHub
↓
pull
↓
집 PC
수정 → add → commit → push
↓
GitHub
↓
pull
↓
회사 PC따라서 같은 브랜치를 여러 PC에서 작업할 때는 작업 시작 전 pull, 작업 완료 후 commit + push를 기본 습관으로 두는 것이 좋다.
12. Git 작성자 정보와 GitHub 인증은 다르다
git config --global user.name "이름"
git config --global user.email "이메일"이것은 GitHub 로그인 정보가 아니라 커밋에 기록할 작성자 정보다. GitHub 서버에 push할 때의 인증과는 별개의 개념이다.
credential.helper cache 설정을 무조건 따라 할 필요는 없다.13. 3-1편의 전체 지도
┌──── GitHub ────┐
│ Remote main │
└──────┬─────────┘
↑ push
↓ fetch / pull
┌────────────── 내 PC ──────────────┐
│ │
│ Working Tree │
│ ↓ git add │
│ Staging Area │
│ ↓ git commit │
│ Local Repository │
│ main / origin/main │
└───────────────────────────────────┘3-1편 핵심
GitHub 연동은 Git의 기본 구조 위에 원격 저장소 하나를 더 연결하는 것이다.
처음 로컬 프로젝트 시작 → git init
이미 있는 서버 저장소 사용 → git clone
로컬 변경 기록 → add → commit
서버로 전송 → push
서버 정보만 받아보기 → fetch
서버 변경 받아서 반영 → pull이 구조를 이해하면 GitHub는 더 이상 Git과 뒤섞인 막연한 서비스가 아니라, 내 로컬 Git 저장소와 커밋을 주고받는 원격 저장소로 보이기 시작한다.