Git과 GitHub, 같은 게 아니에요
Git이랑 GitHub, 둘이 같이 들으면 같은 플랫폼처럼 느껴지죠.
사실 Git은 우리가 잘 아는 리눅스 개발자 Linus Torvalds가 2005년에 만든 프로그램이에요. 당시 리눅스 커널을 전 세계 개발자들이 함께 개발하고 있었는데, 이걸 관리할 빠르고 분산된 버전 관리 시스템(Distributed Version Control System)이 필요했거든요. 그래서 직접 만든 게 바로 Git이랍니다.
GitHub는 이 Git을 웹 서비스 형태로 감싸서, 여러 개발자가 쉽고 빠르게 코드를 공유하고 함께 작업할 수 있도록 만든 플랫폼이에요. 2008년에 만들어졌고, 2018년에는 Microsoft가 인수하기도 했죠.
쉽게 정리하면 이래요.
- Git = 코드의 변경 이력을 기록하고 관리하는 '도구(프로그램)'
- GitHub = 그 Git 저장소를 온라인에 올려서 공유하는 '호스팅 서비스'
GitHub가 Git을 직접 만든 회사는 아니지만, Git을 기반으로 서비스를 만들었기 때문에 서로 매우 밀접하게 연결되어 있는 거예요.
참고로 Git 저장소를 호스팅해주는 서비스는 GitHub만 있는 게 아니에요. GitLab, Bitbucket 같은 서비스도 똑같이 Git을 기반으로 동작해요. 그만큼 Git 자체는 특정 플랫폼에 종속되지 않는 표준 도구라고 보면 돼요.
그럼 GitHub가 있는데 굳이 왜 Git을 따로 알아야 할까요?
핵심은 GitHub만으로는 Git이 하는 일을 대신할 수 없기 때문이에요. GitHub는 어디까지나 저장소를 올려두는 '공간'일 뿐이고, 실제로 파일의 변경 이력을 추적하고 관리하는 세밀한 작업은 전부 Git이 담당해요.
예를 들어 app.py를 이렇게 수정했다고 해봐요.
처음: print("Hello")
수정 1: print("Hello World")
수정 2: print("Hello World!")
Git을 쓰면 이 변경 과정을 커밋(commit)이라는 단위로 하나씩 기록할 수 있어요.
v1 ── v2 ── v3
↑
여기로 돌아가기
그러다가 v3에서 버그가 생기면 v1이나 v2 시점으로 되돌릴 수 있죠. 이때 쓰는 명령어가 git revert(되돌리는 새 커밋을 추가하는 방식)나 git reset(커밋 이력 자체를 되돌리는 방식)이에요. 특히 git reset은 이미 GitHub에 push된 커밋에 사용하면 다른 팀원의 히스토리와 꼬일 수 있어서, 협업 중인 브랜치에서는 되도록 git revert를 쓰는 걸 추천해요.
Git의 기본 작동 구조
Git이 어떻게 파일을 관리하는지 구조를 먼저 이해하고 넘어가면 이후 명령어들이 훨씬 잘 이해돼요. Git은 크게 세 단계로 파일을 관리해요.
Working Directory → Staging Area → Repository
(실제 코드 파일) (커밋 준비 상태) (커밋 완료, 이력 저장)
git add ↑ git commit ↑
- Working Directory: 지금 눈으로 보고 수정하는 실제 코드 파일들이 있는 공간
- Staging Area(Index):
git add로 "이 파일을 다음 커밋에 포함시킬래"라고 표시해둔 임시 공간 - Repository:
git commit으로 실제 기록된, 되돌아갈 수 있는 버전들의 저장소
그리고 git push를 하면 이 로컬 Repository에 쌓인 커밋들이 GitHub 같은 원격 저장소(remote)로 업로드되는 구조예요.
브랜치(Branch)란?
Git은 브랜치라는 독립된 작업 공간에서 작업해요. 보통 모두가 main 브랜치에서 직접 작업하는 게 아니라, 각자 기능별 브랜치를 만들어 작업하고, 완료되면 GitHub에서 main으로 합치는 방식이에요.
이게 실제 GitHub의 Pull Requests 화면이에요. 각 작업자가 자신의 브랜치에서 작업한 내용을 main 브랜치로 병합해달라고 요청(Pull Request)하면, main 브랜치 권한을 가진 사람이 변경 내용을 검토한 뒤 병합(Merge)하는 구조죠.
GitHub 인증, 웹사이트 로그인과는 별개예요
GitHub 웹사이트에 로그인하는 것과, 내 컴퓨터의 Git이 GitHub에 접근할 수 있도록 인증하는 것은 서로 다른 이야기예요.
GitHub 웹사이트는 평소처럼 계정과 비밀번호(또는 2단계 인증)로 로그인하면 되지만, 터미널에서
git push
처럼 GitHub에 코드를 올리려고 하면 GitHub가 "너 정말 그 계정 주인 맞아?"를 별도로 확인해야 해요.
특히 2021년 8월부터 GitHub는 HTTPS 방식의 Git 작업(clone, push 등)에서 계정 비밀번호 인증을 더 이상 지원하지 않아요. 그래서 다음 두 방법 중 하나로 인증해야 해요.
- Personal Access Token(PAT): GitHub
Settings → Developer settings → Personal access tokens에서 발급받는 토큰이에요. 비밀번호 대신 이 토큰을 입력해서 인증해요. 처음 push할 때 GitHub 로그인 창(또는 브라우저 인증 창)이 뜨면 여기서 인증을 진행하게 돼요. - SSH Key 방식:
ssh-keygen으로 로컬에서 키 쌍을 생성하고, 공개키를 GitHub 계정에 등록해두는 방식이에요. 이후엔 비밀번호나 토큰 입력 없이[email protected]:...형태의 SSH 주소로 push/pull할 수 있어요.
그리고 한 번 인증을 마치면, OS의 자격 증명 저장소나 Git Credential Manager(GCM) 같은 도구가 토큰을 안전하게 저장해줘서 매번 다시 인증할 필요는 없어요.
협업 Git 워크플로우 실전 가이드
이제 실제로 협업할 때 어떤 순서로 Git을 쓰는지 하나씩 따라가 볼게요.
1. 저장소 클론하기
팀원이 GitHub에 https://github.com/team/project.git이라는 프로젝트를 만들어놨다고 해봐요.
GitHub 저장소 페이지에서
Code → HTTPS를 누르면 주소를 복사할 수 있어요.
작업할 폴더에서 아래 명령어를 실행해요.
git clone https://github.com/team/project.git
git clone은 단순히 현재 파일 스냅샷만 가져오는 게 아니라, Git의 전체 커밋 이력과 브랜치 정보까지 함께 가져와요. 그리고 이 원격 저장소를 origin이라는 이름으로 자동 등록해줘요.
2. 프로젝트 폴더 이동 & 원격 저장소 확인
cd project
git remote -v
실행하면 대략 이렇게 나와요.
origin https://github.com/team/project.git (fetch)
origin https://github.com/team/project.git (push)
(fetch)는 코드를 받아올 때 사용하는 주소, (push)는 코드를 올릴 때 사용하는 주소예요. 보통은 같은 주소지만, 조직에 따라 다르게 설정하는 경우도 있어요.
참고로 git branch -r을 입력하면 origin/main처럼 원격 저장소의 브랜치 목록을 확인할 수 있고, git log --oneline --graph --all을 입력하면 로컬과 원격 브랜치의 커밋 이력을 한눈에 그래프로 볼 수 있어요.
3. 브랜치 만들기
여기가 협업에서 정말 중요한 부분이에요. 팀원이 여러 명이라면 각자 이름을 딴 브랜치, 혹은 기능 단위로 나눈 브랜치에서 작업해야 해요.
보통 실무에서는 아래처럼 접두어를 붙여서 브랜치 이름을 지어요.
feature/: 새 기능 개발 (예:feature/login)fix/: 버그 수정 (예:fix/login-error)hotfix/: 배포 중 긴급 수정docs/: 문서 작업chore/: 설정, 빌드 등 기타 자잘한 작업
예를 들어 로그인 기능을 개발한다면 이렇게 하면 돼요.
git switch -c feature/login
기존 방식으로는 아래 명령어도 동일하게 동작해요.
git checkout -b feature/login
git switch는 Git 2.23 버전(2019년)부터 새로 생긴 명령어로, 기존 git checkout이 브랜치 전환·파일 복원 등 너무 많은 역할을 하다 보니 헷갈리는 문제를 줄이기 위해 브랜치 전환 기능만 따로 뗀 명령어예요. 요즘은 switch를 더 권장하는 추세지만, checkout도 여전히 널리 쓰여요.
4. 코드 수정 & 상태 확인
평소처럼 VSCode에서 코드를 수정하려면 터미널에 아래 명령어를 입력해요.
code .
만약 code .이 동작하지 않는다면, VSCode를 열고 Ctrl + Shift + N으로 새 창을 연 뒤 Ctrl + K, O로 프로젝트 폴더를 직접 선택해서 열면 돼요.
코드를 다 수정했다면 아래 명령어로 어떤 파일이 바뀌었는지 확인할 수 있어요.
git status
여기서 한 걸음 더 나아가 실제로 어느 줄이 어떻게 바뀌었는지 궁금하다면 아래 명령어를 함께 써보세요.
git diff
5. 변경사항 스테이징 & 커밋
git add .
이렇게 하면 마지막 커밋 이후 변경된 파일들을 커밋할 준비 상태(Staging Area)로 올려줘요. 특정 파일만 올리고 싶다면 git add 파일명처럼 선택적으로 지정할 수도 있어요.
git commit -m "로그인 기능 추가"
이렇게 하면 해당 변경사항이 로컬 Git 저장소에 실제로 기록돼요. 여기까지는 전부 내 컴퓨터 안에서만 일어난 일이라, 아직 GitHub에는 올라가지 않았고 별도로 로그인할 필요도 없어요.
커밋 메시지는 최대한 구체적으로 적는 습관을 들이면 좋아요. 실무에서는 Conventional Commits 같은 규칙을 많이 써요.
feat: 로그인 기능 추가 fix: 로그인 시 세션 만료 오류 수정 docs: README에 설치 방법 추가 refactor: 로그인 로직 함수 분리반면 아래처럼 애매한 커밋 메시지는 나중에 롤백하거나 리뷰할 때 어떤 내용인지 파악하기 어려워요.
git commit -m "사이트 전체 개발 완료" git commit -m "20260810 업데이트"이렇게 커밋 제목이 애매하면, 나중에 이 커밋을 보는 팀원은 정확한 내용을 이해하기 위해 코드를 한 줄씩 다시 해석해야 할 수도 있어요.
6. GitHub에 푸시하기
git push -u origin feature/login
여기서
feature/login은 예시일 뿐이니, 실제로 내가 작업한 브랜치 이름으로 바꿔서 실행하면 돼요.-u옵션은 이 로컬 브랜치와 원격 브랜치를 연결(upstream 설정)해주는 옵션이라, 다음번부터는git push만 입력해도 알아서 같은 브랜치로 올라가요.
이때 Git에 GitHub 인증 정보가 없다면, 로그인 창(또는 브라우저 인증 창)이 뜨면서 인증을 진행하게 돼요.
만약 push하려는 저장소가 내 소유가 아니라면 어떻게 될까요? 원래 원본 저장소에 쓰기 권한이 없다면 git push는 그냥 권한 오류(permission denied)로 실패해요. 자동으로 포크가 만들어지는 게 아니라, 아래 순서로 직접 진행해야 해요.
- 원본 저장소 페이지에서 GitHub의 Fork 버튼을 눌러 내 계정으로 저장소를 복사해요.
- 복사된 내 Fork 저장소를
git clone으로 받아와요. - 코드를 수정하고 커밋한 뒤, 내 Fork 저장소(
origin)로git push해요. - 원본 저장소로 가서 Pull Request(PR)를 올려요. 이때 원본 저장소를 최신 상태로 계속 반영받고 싶다면,
git remote add upstream 원본저장소주소로 원본을upstream이라는 이름의 원격 저장소로 추가해두고,git fetch upstream→git merge upstream/main으로 동기화하면 돼요.
원본 저장소에 대한 쓰기 권한이 이미 있는 협업 프로젝트라면, 그냥 내가 만든 브랜치를 바로 push하고 원본 저장소에서 PR을 올리면 돼요. 저장소 관리자(또는 팀원)가 변경사항을 확인하고 승인해주면 병합되는 구조예요. 보통 실무에서는 Pull Request를 풀어서 부르지 않고 줄여서 PR이라고 불러요.
7. 다른 사람의 작업 내용 가져오기
다른 팀원이 main에 코드를 병합했다고 해봐요. 하지만 내 컴퓨터가 GitHub와 실시간으로 연결되어 있는 구조는 아니기 때문에, 아직 내 로컬에는 그 변경사항이 없어요.
git switch main
git pull origin main
git pull은 사실 두 단계로 이루어져 있어요.
git fetch: 원격 저장소의 변경사항을 로컬로 다운로드만 하고, 아직 내 코드에 반영하지는 않아요.git merge: 다운로드한 원격 변경사항을 현재 브랜치에 병합해요.
git pull은 이 두 과정을 한 번에 실행해주는 명령어예요. 만약 병합 대신 커밋 이력을 깔끔하게 한 줄로 유지하고 싶다면 git pull --rebase 옵션을 쓰기도 해요.
8. 충돌(Merge Conflict) 해결하기
여러 명이 같은 파일의 같은 부분을 각각 수정하고 병합하려 하면, Git이 어느 쪽 내용이 맞는지 판단하지 못해서 충돌(Conflict)이 발생해요. 이때 당황하지 말고 아래 순서로 해결하면 돼요.
1) 충돌이 난 파일을 열면 아래처럼 표시가 나와요.
<<<<<<< HEAD
(내 브랜치의 코드)
=======
(병합하려는 브랜치의 코드)
>>>>>>> feature/login
2) 두 코드를 비교해서 최종적으로 남길 내용으로 직접 수정하고, <<<<<<<, =======, >>>>>>> 표시는 지워요.
3) 수정이 끝나면 다시 스테이징하고 커밋(또는 병합 계속 진행)해요.
git add .
git commit -m "fix: 로그인 로직 충돌 해결"
충돌은 협업하다 보면 자연스럽게 겪는 과정이니, 너무 걱정하지 않아도 돼요. 다만 다음에 설명할 것처럼 작업 전에 최신 코드를 먼저 받아두면 충돌 빈도를 크게 줄일 수 있어요.
실무 협업에서 꼭 지켜야 할 습관
첫 번째, main에서 직접 작업하지 않는 거예요.
main은 실제 서비스에 배포할 수 있는 상태의 코드만 유지하는 게 원칙이에요. 그래서 개발 중인 기능, 테스트 중인 기능, 배포 준비된 기능을 구분해서 각각 브랜치로 작업하는 게 중요해요. GitHub에는 아예 main 브랜치를 보호(Branch Protection Rule)해서, PR 리뷰 없이는 직접 push하지 못하도록 막는 설정도 있어요.
두 번째, 커밋 메시지를 명확하게 적는 거예요.
앞서 본 것처럼 "사이트 전체 개발 완료" 같은 애매한 커밋보다는, feat:, fix:, docs: 같은 접두어를 붙여서 어떤 종류의 변경인지 한눈에 알 수 있게 적는 걸 추천해요.
세 번째, 작업 전에 항상 최신 코드를 받아오는 거예요.
내가 작업을 시작하기 전에 최신 코드로 업데이트(git pull)하지 않으면, 다른 팀원이 이미 작업해둔 내용이 내 오래된 코드에 덮여서 사라질 수도 있어요.
네 번째, .gitignore로 불필요한 파일은 아예 관리 대상에서 빼는 거예요.
node_modules/, .env, .DS_Store, 빌드 결과물 같은 파일들은 저장소에 올라가면 안 되는 경우가 많아요. 프로젝트 루트에 .gitignore 파일을 만들어서 이런 파일들을 미리 제외해두면, 실수로 민감한 정보(API 키 등)나 불필요한 파일이 GitHub에 올라가는 걸 막을 수 있어요.
다섯 번째, PR은 가능하면 작게 나눠서 올리는 거예요.
한 번에 너무 많은 변경사항을 담은 PR은 리뷰하는 사람 입장에서 부담이 커요. 기능 단위로 PR을 작게 쪼개면 리뷰도 빨라지고, 문제가 생겼을 때 원인을 찾기도 훨씬 쉬워져요.
마무리
지금까지 클론, 브랜치, 커밋, 푸시, Pull Request, 충돌 해결까지 협업할 때 실제로 쓰이는 Git 흐름을 전체적으로 살펴봤어요. 이렇게만 보면 기초적인 내용처럼 느껴질 수 있지만, 실제 협업 현장에서는 이 중 하나만 빼먹어도 코드가 꼬이거나 작업물이 날아가는 사고로 이어지는 경우가 정말 많아요.
참고로 보안 등의 이유로 GitHub를 쓰지 않는 조직이라도, 대부분의 협업 코딩 도구는 결국 Git을 기반으로 동작하기 때문에 여기서 다룬 뼈대는 그대로 적용돼요. 그리고 협업이 아니라 혼자 관리하는 개인 저장소라도, 브랜치·커밋·버전을 깔끔하게 정리해두면 나중에 다시 코드를 봐도 이해하기 쉽고, 다른 사람에게 내 저장소를 소개하거나 인용하기에도 훨씬 편해져요.
