Git과 GitHub: 무엇이 다르고 어떻게 연결되나요

Git과 GitHub는 자주 혼동되지만 서로 다른 층위의 도구입니다. Git은 컴퓨터에 설치하는 버전 관리 프로그램으로, 프로젝트의 저장된 상태를 기록하고 언제든 되돌아갈 수 있게 해 줍니다. GitHub는 Git 저장소의 사본을 보관하고, 그 주위에 협업 도구를 얹은 웹 서비스입니다. 쉽게 기억하려면 이렇게 생각하세요. Git은 엔진이고, GitHub는 그 엔진을 올려놓는 정비소입니다.

Git이란 무엇인가

Git은 분산 버전 관리 시스템입니다. Linus Torvalds가 2005년 Linux 커널 개발을 위해 만들었고, 이후 업계 표준이 되었습니다. Git은 완전히 로컬에서 동작합니다. 히스토리는 프로젝트 안의 숨김 폴더 .git에 저장되며, 대부분의 작업에는 인터넷이 필요하지 않습니다.

핵심 단어는 "분산"입니다. 프로젝트에 참여하는 모든 사람의 컴퓨터에는 최신 파일뿐 아니라 전체 히스토리를 포함한 저장소의 완전한 사본이 있습니다. 서버가 사라져도 작업 중인 어느 컴퓨터에서든 프로젝트를 복구할 수 있습니다.

Git만으로 할 수 있는 일:

• 커밋으로 변경 사항을 기록하기. 커밋은 작성자, 날짜, 설명이 붙은 프로젝트 스냅샷입니다;
• 어떤 줄을 누가, 언제, 왜 바꿨는지 보기(git log, git blame);
• 브랜치로 여러 개발 흐름을 병렬로 진행하고 합치기;
• 나머지 작업을 잃지 않고 실수를 되돌리기;
• git push, git pull, git fetch로 다른 저장소와 히스토리 주고받기.

Git은 명령줄 도구입니다. 그래픽 클라이언트와 편집기 내장 패널(VS Code, IntelliJ IDEA)은 같은 명령을 감싼 껍데기일 뿐입니다.

GitHub란 무엇인가

GitHub는 Git 저장소를 호스팅하는 클라우드 플랫폼이며, 현재 Microsoft 소유입니다. 저장소를 만들고, git push로 로컬 코드를 올리면, 동료, 채용 담당자, 또는 저장소가 공개라면 전 세계가 볼 수 있습니다.

하지만 GitHub의 가치는 저장에만 있지 않습니다. 저장소 주위에 Git 자체에는 없는 기능을 더합니다.

• Pull request — 브랜치를 합치기 전에 코드 줄마다 토론하고 리뷰하는 요청;
• Issues — 프로젝트에 붙는 작업 항목과 버그 리포트;
• GitHub Actions — CI/CD: push할 때마다 테스트, 빌드, 배포를 자동 실행;
• 접근 관리 — 누가 읽고, 쓰고, 보호된 브랜치에 합칠 수 있는지;
• 개발자 프로필 — 활동 그래프와 공개 프로젝트, 채용 담당자가 보는 곳;
• GitHub Pages — 저장소에서 바로 정적 사이트를 무료로 호스팅.

"git hub"나 "github git"처럼 검색하는 경우에는 대부분 이 서비스, 즉 github.com을 말합니다. Git 자체의 공식 사이트는 git-scm.com이며, 설치 파일도 그곳에서 받습니다.

Git과 GitHub 비교표

Git과 GitHub는 어떻게 함께 동작하나

둘을 잇는 것은 remote, 즉 원격 저장소입니다. 로컬 저장소에는 GitHub 저장소의 주소가 짧은 이름으로 저장되며, 기본 이름은 origin입니다. 이후 교환은 세 가지 명령으로 이루어집니다.

• git push — 내 새 커밋을 서버로 보내기;
• git fetch — 남의 커밋을 내려받되 내 파일은 건드리지 않기;
• git pull — 내려받고 현재 브랜치에 바로 합치기(사실상 fetch + merge 또는 rebase).

중요: push하기 전까지 GitHub는 여러분의 코드를 볼 수 없습니다. 첫 git push 전까지 커밋은 로컬에만 존재합니다. 그래서 초보자가 자주 하는 말이 "커밋했는데 GitHub에 아무것도 없어요"입니다.

로컬 프로젝트를 GitHub에 올리는 기본 과정

# 1. 로컬에서 저장소 만들기
cd my-project
git init
git add .
git commit -m "첫 커밋"

# 2. github.com에 빈 저장소 만들기(README 없이)
#    주소를 복사해 remote로 연결
git remote add origin git@github.com:username/my-project.git

# 3. 브랜치 이름을 main으로 바꾸고 올리기
git branch -M main
git push -u origin main

-u 옵션(전체 이름 --set-upstream)은 로컬 main을 원격 main과 연결합니다. 이후에는 인수 없이 git push와 git pull만 쓰면 됩니다.

반대 방향: GitHub의 저장소에서 시작하기

프로젝트가 이미 GitHub에 있다면 새로 만들 필요 없이 클론하면 됩니다.

git clone https://github.com/username/my-project.git
cd my-project

명령은 전체 히스토리를 내려받고, remote origin을 자동으로 설정합니다.

인증: SSH 또는 HTTPS

2021년부터 GitHub는 Git 작업의 HTTPS 방식에서 계정 비밀번호를 받지 않습니다. 동작하는 방법은 두 가지입니다.

HTTPS + Personal Access Token. 계정 설정(Settings → Developer settings)에서 토큰을 만들고, 비밀번호 대신 입력합니다. 매번 입력하지 않으려면 자격 증명 관리자를 씁니다. Windows에서는 Git for Windows와 함께 설치됩니다.

SSH 키. 채용 담당자가 직접 설정할 줄 알기를 기대하는 방식입니다.

# 키 생성
ssh-keygen -t ed25519 -C "you@example.com"

# 공개 키를 출력해서 GitHub에 등록
# Settings → SSH and GPG keys → New SSH key
cat ~/.ssh/id_ed25519.pub

# 연결 확인
ssh -T git@github.com

성공하면 GitHub가 로그인 아이디를 포함한 인사말을 보내고, shell 접근은 제공되지 않는다고 알려 줍니다. 이는 정상입니다. 이때 저장소 주소는 https://가 아니라 git@github.com:user/repo.git 형식을 써야 합니다.

이미 HTTPS로 연결된 저장소를 SSH로 바꾸려면 명령 하나면 됩니다.

git remote set-url origin git@github.com:username/my-project.git

GitHub, GitLab 등 다른 서비스와의 차이

GitHub만 Git 호스팅 서비스는 아닙니다. 모든 서비스가 같은 Git을 사용하므로, 저장소를 한 곳에서 다른 곳으로 옮겨도 히스토리는 그대로 유지됩니다. 차이는 코드 주변의 도구에 있습니다.

GitLab은 pull request 대신 merge request라고 부르지만, 목적은 같습니다. 브랜치의 변경을 합치기 전에 제안하고 논의하는 것입니다. 용어는 다르지만 Git 명령은 같습니다.

하나의 로컬 저장소에 remote를 여러 개 두고, 예를 들어 GitHub와 GitLab에 같은 프로젝트를 함께 올릴 수도 있습니다.

git remote add gitlab git@gitlab.com:username/my-project.git
git push gitlab main
git remote -v

혼자 작업해도 GitHub가 필요할까

기술적으로는 필요 없습니다. Git은 로컬에서도 완벽하게 동작합니다. 하지만 혼자 하는 프로젝트라도 원격 저장소에는 세 가지 큰 이점이 있습니다.

• 백업. 노트북이 고장 나도 코드와 전체 히스토리는 서버에 남아 있습니다;
• 여러 기기에서 작업. 집과 사무실에서 push와 pull로 동기화합니다;
• 포트폴리오. 주니어 채용에서는 이력서보다 GitHub 프로필을 먼저 보는 경우가 많습니다. 실제 프로젝트, 의미 있는 커밋 메시지, README가 있는지 확인합니다.

초보자는 어떤 순서로 배워야 할까

Git과 GitHub를 동시에 배울 필요는 없습니다. 순서가 중요합니다. 먼저 로컬 흐름을 익히세요. git init, git status, git add, git commit, git log, 브랜치와 병합입니다. 힌트 없이 할 수 있게 되면 GitHub에 가입하고, SSH를 설정하고, push, pull, fetch를 익히세요. 마지막 단계는 팀 프로세스입니다. 포크, 작업별 브랜치, pull request, 리뷰.

채용 담당자는 GitHub에서 무엇을 볼까

초록색 활동 칸은 중요하지 않습니다. 경험 많은 리뷰어는 몇 분 안에 다른 것을 봅니다.

• "fix", "123", "수정" 대신 명확한 커밋 메시지;
• "프로젝트 업로드"라는 거대한 커밋 하나 대신 작고 논리적인 커밋들;
• 프로젝트를 실행하는 방법이 적힌 README;
• .gitignore: 저장소에 node_modules, 비밀번호가 든 .env, IDE 파일이 없는지;
• 학습용 프로젝트라도 브랜치와 pull request가 있다면, 팀 프로세스를 알고 있다는 증거가 됩니다.

초보자가 자주 하는 실수

"fatal: not a git repository"

Git 저장소가 아닌 곳에서 명령을 실행했습니다. 프로젝트 폴더로 이동하거나 git init을 실행하세요. GitHub 가입과는 상관없는, 로컬 오류입니다.

"Permission denied (publickey)"

SSH 키가 없거나, GitHub에 등록되지 않았거나, ssh-agent에 올라가 있지 않습니다. ssh -T git@github.com과 계정 설정의 키 목록을 확인하세요.

push할 때 "rejected … (fetch first)"

서버에 여러분에게 없는 커밋이 있습니다. 예를 들어 README를 넣어서 GitHub에 저장소를 만든 경우입니다. 먼저 git pull --rebase origin main으로 받은 뒤 다시 git push를 하세요. 무엇을 덮어쓰는지 확실히 모른다면 --force는 쓰지 마세요.

공개 저장소의 비밀 정보

한 번 커밋된 비밀번호나 API 키는 파일을 나중에 지워도 히스토리에 남습니다. 그런 키는 즉시 재발급해야 하며, .env는 미리 .gitignore에 넣어 두세요.

정리

Git은 내 컴퓨터에서 버전을 관리하는 도구이고, GitHub는 저장소를 클라우드에 보관하고 협업을 도와주는 서비스입니다. GitLab과 Bitbucket은 GitHub의 대안이지 Git의 대안이 아닙니다. 모든 서비스가 같은 커밋, 브랜치, 명령을 쓰기 때문입니다. 로컬 Git부터 시작하고, remote를 연결하고, SSH를 설정하세요. 로컬 저장소와 GitHub 연결, push, pull, fetch는 Git 강의에서 실습으로 다룹니다.