깃허브 입문 가이드 — 개발자 필수 협업 툴

버전 관리는 더 이상 선택이 아니라 개발자의 기본 소양입니다. 혼자 진행하는 사이드 프로젝트든 여러 명이 참여하는 실무 프로젝트든, Git과 GitHub를 다루는 방식은 거의 동일한 표준 흐름을 따릅니다. 이 글에서는 비유나 트러블슈팅 스토리 없이, 실무에서 실제로 통용되는 정석적인 협업 워크플로를 순서대로 정리합니다.

Git과 GitHub, 무엇이 다른가?

Git은 파일의 변경 이력을 시간순으로 기록하고 되돌릴 수 있게 해주는 로컬 버전 관리 시스템(VCS)입니다. 인터넷 연결 없이도 내 컴퓨터 안에서 커밋을 만들고, 브랜치를 나누고, 이력을 조회할 수 있습니다. 반면 GitHub는 이 Git 저장소를 클라우드에 올려 여러 사람이 함께 접근하고 협업할 수 있도록 만든 원격 호스팅 서비스입니다. Pull Request, 이슈 트래커, 코드 리뷰, CI/CD 연동 같은 협업 기능은 Git 자체가 아니라 GitHub(혹은 GitLab, Bitbucket 등 동종 서비스)가 제공하는 부가 기능입니다.

정리하면 다음과 같습니다.

• Git = 버전 관리 엔진 (로컬에서 동작, 명령어로 조작)
• GitHub = Git 저장소를 위한 원격 저장 공간 + 협업 플랫폼

Git 없이 GitHub만 쓸 수는 없고, GitHub 없이 Git만 로컬에서 쓰는 것은 가능합니다. 다만 실무에서는 팀원 간 코드 공유와 리뷰가 필수이므로 거의 항상 두 가지를 함께 사용합니다.

핵심 개념 정리: 저장소부터 병합까지

다음 다섯 가지 개념은 서로 연결되어 있으며, 이 관계를 이해하면 이후 명령어와 워크플로가 훨씬 쉽게 이해됩니다.

즉, 저장소 안에서 브랜치를 만들고, 그 브랜치에 커밋을 쌓은 뒤, Pull Request를 통해 리뷰를 거쳐, 최종적으로 merge로 합치는 것이 전체 흐름입니다. 이 흐름을 이해했다면 이제 실제 절차를 단계별로 살펴보겠습니다.

표준 협업 워크플로 7단계

실무 팀 대부분이 따르는 기본 협업 절차는 다음과 같습니다. 프로젝트마다 세부 규칙(브랜치 명명 규칙, 리뷰어 수 등)은 다를 수 있지만 큰 골격은 동일합니다.

1. Clone (저장소 복제) — 원격 저장소를 로컬 컴퓨터로 내려받아 작업 환경을 만듭니다.
2. Branch 생성 — main(또는 develop) 브랜치에서 새 작업용 브랜치를 분기합니다. 기능 하나, 브랜치 하나가 원칙입니다.
3. Commit — 작업 단위별로 변경 사항을 스테이징하고 의미 있는 메시지와 함께 커밋합니다.
4. Push — 로컬 브랜치의 커밋 이력을 원격 저장소(GitHub)로 업로드합니다.
5. Pull Request 생성 — 작업 브랜치를 main에 병합해달라는 PR을 올리고, 변경 내용과 목적을 설명합니다.
6. 코드 리뷰 — 팀원이 변경 사항을 검토하며 코멘트를 남기고, 필요하면 추가 커밋으로 수정합니다.
7. Merge — 리뷰가 승인되면 PR을 병합하고, 더 이상 필요 없는 작업 브랜치는 삭제합니다.

이 7단계는 개인 프로젝트든 대규모 오픈소스든 거의 동일하게 적용됩니다. 차이가 있다면 리뷰어 수, 자동화된 테스트(CI) 통과 여부, 브랜치 보호 규칙 정도입니다.

기본 명령어 총정리

위 7단계를 실제 명령어로 옮기면 다음과 같습니다. 터미널에서 순서대로 입력하면 됩니다.

git clone https://github.com/사용자명/저장소명.git

git checkout -b feature/login

git status

git add .

git commit -m "feat: 로그인 기능 추가"

git push origin feature/login

git pull origin main

git branch -a

git merge feature/login

git log --oneline

실제로는 git add . → git commit -m "메시지" → git push 세 명령어를 가장 자주 반복하게 됩니다. 이 조합만 익숙해져도 일상적인 커밋 작업의 대부분을 처리할 수 있습니다.

초보자가 자주 헷갈리는 개념

Fork vs Branch

Branch(브랜치)는 같은 저장소 안에서 작업 흐름을 나누는 것이고, Fork(포크)는 저장소 자체를 내 계정으로 통째로 복사하는 것입니다. 팀 프로젝트처럼 저장소에 대한 쓰기 권한이 있으면 브랜치만으로 충분하지만, 오픈소스 프로젝트처럼 권한이 없는 저장소에 기여하려면 먼저 fork로 내 계정에 복사한 뒤, 그 복사본에서 브랜치를 만들어 작업하고 원본 저장소로 PR을 보내는 방식을 사용합니다.

Merge vs Rebase

두 방법 모두 브랜치 이력을 합치는 데 사용되지만 결과물이 다릅니다. Merge는 두 브랜치의 이력을 그대로 유지한 채 병합 커밋을 하나 추가하여 합치는 방식이라 이력이 그래프 형태로 남습니다. Rebase는 한 브랜치의 커밋들을 다른 브랜치 끝에 재배치하여 마치 순서대로 하나씩 작업한 것처럼 이력을 일직선으로 만듭니다. 협업 브랜치(main처럼 다른 사람도 사용 중인 브랜치)에는 rebase를 함부로 사용하지 않는 것이 일반적인 규칙이며, 개인 작업 브랜치를 정리할 때 주로 사용합니다.

Pull vs Fetch

git fetch는 원격 저장소의 변경 사항을 로컬로 가져오기만 하고 현재 작업 중인 브랜치에는 반영하지 않습니다. git pull은 fetch에 이어 자동으로 merge까지 수행합니다. 즉 git pull = git fetch + git merge라고 이해하면 됩니다.

자주 묻는 질문 (FAQ)

Q. 브랜치는 어떤 기준으로 나눠야 하나요?

기능 단위(feature/기능명), 버그 수정 단위(fix/이슈명)로 나누는 것이 표준 관례입니다. 하나의 브랜치가 여러 작업을 동시에 담당하지 않도록 하는 것이 리뷰와 롤백을 쉽게 만드는 핵심입니다.

Q. Pull Request는 작업이 완전히 끝난 뒤에만 올려야 하나요?

아닙니다. 작업 중간에 피드백을 받고 싶다면 초안(Draft) 상태의 PR을 미리 올려 진행 상황을 공유하는 것도 실무에서 흔한 방식입니다. 완성된 PR만 고집할 필요는 없습니다.

Q. 커밋 메시지는 어떤 규칙을 따라야 하나요?

많은 팀이 feat: 기능 추가, fix: 버그 수정, docs: 문서 변경, refactor: 리팩터링처럼 타입 접두어 + 요약 형태의 컨벤션(Conventional Commits)을 사용합니다. 팀에 정해진 규칙이 없다면 이 방식을 기본값으로 삼아도 무방합니다.

오늘 첫 커밋을 남겨보세요

Git과 GitHub는 개념 자체는 단순하지만, 손에 익기까지는 실제로 반복해보는 것이 가장 빠릅니다. clone부터 merge까지 7단계를 직접 한 번 따라 해보는 것만으로도 실무 협업 흐름의 8할은 이해하게 됩니다. 깃허브 입문 강의에서 실습 중심으로 표준 워크플로를 하나씩 따라가 보세요.