코드를 작성하다 보면 '어제 버전이 더 나았는데'라고 후회한 경험, 한 번쯤 있을 겁니다. 파일을 복사해서 _v2, _최종, _진짜최종으로 관리하던 시절은 이제 끝내야 합니다. 깃허브 시작하기 가이드를 통해 코드 관리의 기본기를 잡아 보겠습니다.
깃허브란 무엇인가
깃허브(GitHub)는 Git이라는 버전 관리 시스템을 기반으로 한 온라인 코드 저장 플랫폼입니다. 2024년 기준 전 세계 개발자 1억 명 이상이 사용하고 있으며, 오픈소스 프로젝트의 90% 이상이 깃허브에서 관리됩니다.
쉽게 말하면 코드 전용 클라우드 드라이브입니다. 단순 저장뿐 아니라 변경 이력 추적, 팀 협업, 코드 리뷰까지 한 곳에서 가능합니다.
Git과 GitHub의 차이
| 구분 | Git | GitHub |
|---|---|---|
| 유형 | 버전 관리 프로그램 (로컬 설치) | 웹 기반 호스팅 서비스 |
| 역할 | 코드 변경 이력 기록 | Git 저장소를 온라인에 보관·공유 |
| 비용 | 완전 무료 | 개인 무료, 팀 유료 플랜 있음 |
| 설치 | PC에 직접 설치 | 웹 브라우저로 접속 |
| 오프라인 | 사용 가능 | 인터넷 필수 |
Git은 도구이고, GitHub는 그 도구를 활용하는 서비스라고 이해하면 됩니다.
깃허브 계정 만들기
깃허브 시작하기 가이드의 첫 단계는 계정 생성입니다. 5분이면 충분합니다.
- 1단계: github.com에 접속하여 Sign up 버튼을 클릭합니다
- 2단계: 이메일 주소를 입력합니다. 업무용과 개인용 이메일을 구분해서 등록하는 것을 추천합니다
- 3단계: 비밀번호를 설정합니다. 영문 대소문자, 숫자, 특수문자를 조합해 15자 이상으로 만드세요
- 4단계: 사용자명(username)을 정합니다. 이 이름이 프로필 URL이 되므로 신중하게 선택하세요
- 5단계: 이메일 인증 코드를 입력하면 가입 완료입니다
무료 플랜으로 충분한가
개인 사용자라면 무료 플랜(Free)으로 충분합니다. 비공개 저장소 무제한 생성, 월 2,000분의 자동화(Actions) 시간, 500MB 패키지 저장 공간이 제공됩니다. 팀 단위 협업이 필요해지면 그때 Team 플랜(월 $4/인)을 검토해도 늦지 않습니다.
저장소 생성과 기본 구조 이해
계정을 만들었으면 저장소(Repository)를 생성할 차례입니다. 저장소는 프로젝트 하나를 담는 폴더라고 생각하면 됩니다.
- Repository name: 프로젝트를 설명하는 짧은 영문 이름 (예: my-first-project)
- Description: 프로젝트 설명 한 줄. 선택사항이지만 적어두면 나중에 정리가 편합니다
- Public / Private: 공개 여부 선택. 학습용이라면 Public으로 시작해 보세요
- Add a README file: 반드시 체크하세요. 프로젝트 소개 문서가 자동 생성됩니다
저장소 핵심 파일 구조
| 파일/폴더 | 역할 | 필수 여부 |
|---|---|---|
| README.md | 프로젝트 소개, 사용법 안내 | 필수 |
| .gitignore | Git이 무시할 파일 목록 | 권장 |
| LICENSE | 오픈소스 라이선스 명시 | 공개 시 권장 |
| src/ | 소스 코드 폴더 | 프로젝트에 따라 다름 |
깃허브 저장소는 단순히 코드를 올려놓는 곳이 아닙니다. README 하나만 잘 써도 프로젝트의 가치가 달라집니다. 채용 담당자가 가장 먼저 보는 것도 README입니다.
첫 커밋과 푸시 실습
이제 실제로 코드를 저장소에 올려 보겠습니다. PC에 Git이 설치되어 있어야 합니다. git-scm.com에서 운영체제에 맞는 버전을 다운로드하세요.
터미널 기본 명령어 5가지
- git clone [URL] - 원격 저장소를 내 PC로 복사
- git add . - 변경된 모든 파일을 스테이징(준비 상태)에 추가
- git commit -m "메시지" - 변경 사항을 기록. 메시지는 무엇을 바꿨는지 간단히 작성
- git push - 로컬 커밋을 원격 저장소(깃허브)에 업로드
- git pull - 원격 저장소의 최신 변경 사항을 내 PC로 가져오기
순서를 정리하면 이렇습니다. clone으로 가져오고, 파일을 수정하고, add로 준비하고, commit으로 기록하고, push로 업로드합니다. 이 흐름만 기억하면 기본적인 코드 관리는 가능합니다.
커밋 메시지 작성 요령
커밋 메시지는 미래의 나를 위한 메모입니다. "수정함", "업데이트"처럼 모호하게 쓰면 나중에 어떤 변경이었는지 알 수 없습니다. "로그인 페이지 비밀번호 유효성 검사 추가"처럼 구체적으로 쓰는 습관을 들이세요.
협업 기능 활용하기
깃허브의 진짜 힘은 협업에 있습니다. 혼자 작업할 때도 이 기능들을 익혀두면 팀 프로젝트에서 바로 활용할 수 있습니다.
Branch - 독립된 작업 공간
브랜치는 메인 코드에 영향을 주지 않고 새로운 기능을 개발할 수 있는 독립 공간입니다. main 브랜치는 항상 안정적인 상태를 유지하고, feature/login 같은 이름으로 기능별 브랜치를 만들어 작업합니다.
Pull Request - 코드 리뷰의 시작
작업이 끝나면 Pull Request(PR)를 생성합니다. 이 과정에서 다른 팀원이 코드를 검토하고, 개선 의견을 남기고, 승인하면 main에 병합됩니다. 혼자 공부할 때도 PR을 만들어 보면 실무 감각을 익힐 수 있습니다.
Issues - 할 일 관리
버그 신고, 기능 요청, 작업 목록을 Issues로 관리합니다. 프로젝트 진행 상황을 추적하고 우선순위를 정하는 데 유용합니다. 특히 D-Day 계산기로 프로젝트 마감일까지 남은 일수를 체크하면서 Issues를 관리하면 일정 관리가 한결 수월해집니다.
입문자가 자주 하는 실수와 해결법
깃허브 시작하기 가이드를 따라 하다 보면 누구나 한 번쯤 겪는 문제들이 있습니다.
| 실수 | 원인 | 해결법 |
|---|---|---|
| push가 거부됨 | 원격에 로컬에 없는 변경 사항 존재 | git pull 먼저 실행 후 push |
| .env 파일을 올려버림 | .gitignore 미설정 | git rm --cached .env 후 .gitignore에 추가 |
| 커밋 메시지 오타 | 급하게 작성 | git commit --amend -m "수정 메시지" |
| 잘못된 브랜치에서 작업 | 브랜치 확인 안 함 | git stash 후 올바른 브랜치로 이동 |
| merge conflict 발생 | 같은 파일을 동시에 수정 | 충돌 파일을 직접 열어 수동 병합 |
.env, API 키, 비밀번호 같은 민감 정보는 절대 저장소에 올리지 마세요. 한 번 올라간 파일은 커밋 이력에 남아서 삭제해도 흔적이 남습니다. .gitignore를 프로젝트 시작과 동시에 설정하는 것이 안전합니다.
깃허브는 처음에 낯설지만, 저장소 하나를 만들고 커밋 10개만 쌓아 보면 흐름이 잡힙니다. 오늘 당장 github.com에 접속해서 계정을 만들고, README 하나를 작성해 보세요. 그 작은 첫 커밋이 개발 습관의 시작점이 됩니다.