깃허브 사용법: Git과 GitHub 차이부터 첫 커밋·푸시까지

안녕하세요. 사랑받는 IT 프로덕트의 첫걸음, 똑똑한개발자입니다.

GitHub(깃허브)는 Git으로 관리하는 프로젝트를 온라인에 저장하고 다른 사람과 함께 작업할 수 있는 서비스입니다. Git이 파일의 변경 이력을 기록하는 도구라면, GitHub는 그 기록을 공유하고 검토하는 공간에 가깝습니다. 이 글에서는 기본 용어부터 첫 업로드와 오류 해결까지 살펴보겠습니다.

깃허브 사용법 전에, Git과 GitHub는 무엇이 다를까

Git은 내 컴퓨터 안의 기록 장치입니다.

GitHub 공식 문서는 Git을 파일 변경을 추적하는 버전 관리 시스템이라고 설명합니다. 문서를 고칠 때마다 "최종_진짜최종" 파일을 만들던 일을 Git이 대신해줍니다.

GitHub는 그 기록을 올려두는 클라우드 서비스입니다.

같은 문서에서 GitHub는 Git 프로젝트를 클라우드에 올리고 협업 도구를 더한 서비스로 소개됩니다. Git이 카메라라면 GitHub는 사진을 모아두고 팀과 나누는 앨범에 가깝습니다.

깃허브 초보가 먼저 알아둘 용어, 비유로 정리하면

저장소(repository)는 프로젝트 하나를 담는 폴더입니다.

파일과 함께 지금까지의 변경 이력이 전부 들어 있습니다.

커밋은 변경 내용을 기록하는 단위입니다.

커밋에 포함한 파일의 상태와 설명을 기록합니다. 기록하지 않은 파일이나 외부 데이터까지 함께 복구되는 것은 아닙니다.

푸시는 올리기, 풀은 내려받기입니다.

내 컴퓨터의 커밋을 GitHub로 올리는 일이 푸시이고, 다른 사람이 올린 변경을 내 컴퓨터로 가져오는 일이 풀입니다.

브랜치는 작업 흐름을 나누고, PR은 변경 검토를 요청합니다.

원본(main)은 그대로 두고 갈래를 하나 만들어 실험합니다. 결과가 괜찮으면 풀 리퀘스트(PR)로 "이 변경을 원본에 합쳐도 될까요"라고 검토를 받습니다.

깃허브 사용법 초보 실습, 계정부터 첫 푸시까지

github.com에서 계정을 만들고, 맥이나 윈도우에 GitHub Desktop을 설치해 로그인합니다.

GitHub Desktop으로 커밋과 푸시하기

File 메뉴의 New repository로 저장소를 만들고 파일을 넣습니다. 왼쪽 아래 Summary 칸에 메모를 적고 Commit to main을 누르면 커밋이 됩니다. 처음에는 Publish repository로 GitHub에 올리는데, Keep this code private에 체크하면 비공개 저장소가 됩니다. 그다음부터는 Push origin 한 번으로 끝납니다.

터미널에서 첫 커밋과 푸시하기

GitHub 웹에서 빈 저장소를 먼저 만듭니다. 아래 예시는 원격 저장소에 README나 라이선스 파일을 추가하지 않은 빈 저장소를 전제로 합니다. Git 설치와 사용자 이름·이메일 설정, GitHub 인증도 필요합니다. git add .는 폴더의 변경을 넓게 포함하므로 키나 비공개 자료가 섞이지 않았는지 확인한 뒤 사용합니다. 그다음 프로젝트 폴더에서 터미널을 열고 아래를 차례로 입력합니다.

git init -b main
git add .
git commit -m "First commit"
git remote add origin 저장소주소
git push -u origin main

클로드 코드를 쓰고 있다면 "이 폴더를 GitHub 저장소에 올려줘"라고 부탁해도 같은 과정을 진행해줍니다. 다만 각 줄의 뜻을 알아야 결과를 확인할 수 있습니다.

깃허브 초보가 가장 자주 막히는 오류 2가지

비밀번호를 넣었는데 인증에 실패한다면 토큰을 써야 합니다.

GitHub 공식 문서에 따르면 Git에서 비밀번호 인증은 이미 제거됐습니다. 터미널이 비밀번호를 물으면 GitHub 계정 비밀번호 대신 개인 액세스 토큰을 넣어야 합니다. 토큰은 Settings, Developer settings, Personal access tokens 순서로 들어가 만듭니다. GitHub가 권장하는 건 저장소 단위로 권한을 좁히는 Fine-grained 토큰입니다. SSH 키를 등록하는 방법도 있습니다.

rejected가 뜨면 GitHub 쪽에 내가 모르는 변경이 있다는 뜻입니다.

! [rejected] main -> main (non-fast-forward) 메시지는 다른 사람이나 웹에서 먼저 올린 커밋이 있을 때 나옵니다. 원격의 변경을 먼저 확인하고 가져와 병합하거나 팀의 기준에 따라 rebase한 뒤 다시 푸시합니다. 충돌이 생기면 해당 파일을 해결하는 과정이 필요하며, 자동으로 모두 해결되는 것은 아닙니다.

세부 설정과 지원 범위는 GitHub 첫 업로드 안내를 참고해 보세요.

팀의 프로젝트를 함께 이어갑니다

처음 코드를 올리고 나면 여러 사람이 함께 수정하고 검토하는 과정도 궁금해집니다. 작업한 내용이 다음 사람에게 잘 전달되는 구조가 필요해지는데요.

똑똑한개발자는 웹·앱을 만드는 과정에서 기획·디자인·개발을 함께 연결합니다. 팀이 사용할 기능과 협업 흐름을 살펴보고 실제 서비스로 이어가는 일을 돕습니다.

만들고 있는 프로젝트나 팀 작업 방식에 고민이 있다면 아래 똑똑한개발자 링크로 편하게 이야기 남겨주세요. 함께 살펴보겠습니다. 감사합니다. :)