깃허브(GitHub) 사용법, 저장소 만들고 첫 커밋·푸시까지 직접 해 보니

깃허브 사용법을 명령줄로 처음부터 끝까지 확인하려고, 이미 gh로 로그인된 맥에서 새 폴더에 비공개 저장소를 만들어 깃허브에 올리고 한 번 더 고쳐 올리기까지 한 번 실행했습니다. 그 결과 8단계 모두 종료 코드 0으로 끝났습니다. 한 번의 실행 기록이므로, 다른 환경에서도 같은 결과가 나온다는 보장은 아닙니다. AI 코딩 도구가 만든 코드를 처음 깃허브에 올리려는 1인 개발자라면, 먼저 실습용 새 폴더에서 해 볼지 기존 프로젝트 폴더에서 바로 할지를 정하는 편이 좋습니다. 처음이라면 빈 새 폴더를 하나 만들고 터미널에서 그 폴더로 이동한 뒤, 아래 명령을 순서대로 실행해 보는 쪽을 권합니다. 시작 전에 git --version && gh --version | head -1로 Git과 GitHub CLI(gh)가 설치돼 있는지 확인합니다. 이번 실행은 git version 2.54.0, gh version 2.103.0에서 했고, git init -b main처럼 -b로 기본 브랜치 이름을 정하는 방법은 Git 2.28.0 이상에서 쓸 수 있습니다. 이번 측정은 gh가 이미 로그인된 상태에서 했기 때문에 처음 로그인하는 과정은 담겨 있지 않습니다. 로그인 전이라면 GitHub Docs의 로컬 코드 추가 안내에 따라 명령줄 인증부터 마쳐 두는 편이 좋습니다. 또 4단계의 README 생성 명령은 실습용입니다. >로 README.md를 새로 쓰기 때문에, 기존 프로젝트에서 그대로 실행하면 원래 있던 README.md 내용을 덮어씁니다. 기존 프로젝트라면 이 명령은 건너뛰고, 비밀번호나 API 키 같은 민감한 정보가 커밋에 들어가지 않는지부터 확인하는 편이 좋습니다. 단계별 걸린 시간은 절차를 다 따라간 뒤 참고값으로 보면 됩니다.

따라 할 순서 한눈에 보기

전체 흐름은 "내 컴퓨터에 저장소 만들기 → 커밋 → 깃허브에 올리기 → 고쳐서 다시 올리기"입니다. 단계마다 쓴 명령은 다음과 같습니다.

1. 도구 버전 확인: git --version, gh --version
2. 로그인 상태 확인: gh auth status
3. 저장소 폴더 만들기: git init -b main
4. 첫 파일 커밋: git add, git commit
5. 깃허브에 만들고 올리기: gh repo create ... --private --source=. --remote=origin --push
6. 올라간 내용 확인: gh repo view, git log --oneline
7. 고쳐서 다시 올리기: git commit -am, git push
8. 깃허브의 커밋 수 확인: gh api .../commits

그럼 시간은 얼마나 걸렸을까요? 단계마다 명령을 시작해서 끝날 때까지 잰 값은 이렇습니다.

내 컴퓨터 안에서만 일하는 3·4단계는 0.0초로 찍혔고, 깃허브와 통신하는 단계에서만 시간이 걸렸습니다. 다만 5단계가 왜 가장 긴지는 이 측정만으로 가를 수 없어요. 궁금하다면 같은 명령을 몇 번 반복해서 재 보세요.

도식출처: 명령 실행 실측

함께 읽을 글

• 깃(Git) 사용법, 처음 쓰는 명령을 순서대로 직접 해 보니
• 올라마(Ollama) 로컬 AI 사용법, 맥에서 직접 돌려 보니
• GitHub Pages 사용법, 무료 배포부터 접속까지 직접 해 보니

저장소·커밋·푸시는 무엇인가요?

명령을 치기 전에 세 단어만 알아 두면 출력이 훨씬 잘 읽힙니다. GitHub Docs의 Hello World는 저장소를 파일, 이미지, 다른 폴더처럼 관련된 것들을 담는 폴더로 생각하라고 설명해요. 보통 한 프로젝트에 속한 것을 한 저장소에 모읍니다.

• 저장소(repository): 프로젝트 하나를 담는 폴더. 흔히 프로젝트를 소개하는 README 파일이 들어갑니다.
• 커밋(commit): 저장한 변경 하나. 커밋마다 왜 바꿨는지 적는 커밋 메시지가 붙고, 이 메시지가 변경 이력이 됩니다.
• 푸시(push): 내 컴퓨터 저장소의 커밋을 깃허브로 보내는 일.

AI 에이전트에게 기능을 맡기고 결과를 받을 때마다 커밋해 두면 어떨까요? 메시지에 "무엇을 왜 바꿨는지"가 남으니, 나중에 어느 변경에서 문제가 생겼는지 거슬러 찾기 쉬워진다고 볼 수 있습니다.

명령과 실제 출력, 단계별로 보기

이제 실제로 친 명령과 화면에 나온 출력을 순서대로 보겠습니다. 계정 이름은 <계정>, 만든 저장소 이름은 <저장소>로 바꿔 적었습니다.

1~2단계: 도구와 로그인 확인

$ git --version && gh --version | head -1
git version 2.54.0
gh version 2.103.0 (2026-10-21)

$ gh auth status 2>&1 | grep -v -i token
github.com
  ✓ Logged in to github.com account <계정> (keyring)
  - Active account: true
  - Git operations protocol: https

여기가 가장 막히기 쉬운 곳이에요. Logged in to github.com account 줄과 Active account: true가 보여야 5단계에서 깃허브에 저장소를 만들 수 있습니다. 이 측정에서는 gh가 이미 로그인된 상태였으니, 처음 설치했다면 이 줄부터 확인해 보세요. 명령 뒤의 grep -v -i token은 토큰이 들어간 줄을 화면에서 빼려고 붙인 것입니다.

3단계: 저장소 폴더 만들기

$ git init -b main
/private/tmp/solo-lab-nmE5cX/walk/.git/ 안의 빈 깃 저장소를 다시 초기화했습니다

-b main은 기본 브랜치 이름을 main으로 정하는 옵션이에요. 공식 문서에 따르면 Git 2.28.0 이상에서 쓸 수 있고, 그보다 낮은 버전이라면 아래처럼 씁니다.

git init && git symbolic-ref HEAD refs/heads/main

그런데 출력이 "다시 초기화했습니다"로 나왔죠? 이 기록만으로는 이유를 알 수 없습니다. 이 문구가 보이면 출력에 찍힌 경로가 의도한 프로젝트 폴더가 맞는지 먼저 확인해 보세요.

4단계: 첫 파일 커밋

$ printf '# 첫 저장소\n\n깃허브 사용법을 따라 만든 저장소입니다.\n' > README.md && git add README.md && git commit -m "첫 커밋: README 추가"
[main (최상위-커밋) c5ae788] 첫 커밋: README 추가
 1 file changed, 3 insertions(+)
 create mode 100644 README.md

git add로 커밋할 파일을 올려 두고 git commit -m으로 메시지와 함께 저장합니다. 출력의 c5ae788이 이 커밋의 이름표예요.

5단계: 깃허브에 만들고 올리기

$ gh repo create <저장소> --private --source=. --remote=origin --push
https://github.com/<계정>/<저장소>
branch 'main' set up to track 'origin/main'.
To https://github.com/<계정>/<저장소>.git
 * [new branch]      HEAD -> main

명령 한 줄로 깃허브 저장소 생성, 연결, 푸시가 끝납니다. 공식 문서 기준으로 옵션의 뜻은 이렇습니다.

• --source=.: 올릴 저장소 경로(지금 폴더)
• --private: 공개 범위. --public, --internal도 있습니다
• --remote=origin: 연결할 원격 이름
• --push: 커밋까지 바로 올리기

옵션 없이 gh repo create만 치면 질문이 차례로 나오고, 거기서 기존 로컬 저장소를 올리는 항목을 고르면 됩니다.

6단계: 올라간 내용 확인

$ gh repo view <계정>/<저장소> --json name,visibility,defaultBranchRef --jq '.name + " " + .visibility + " " + .defaultBranchRef.name' && git log --oneline
<저장소> PRIVATE main
c5ae788 첫 커밋: README 추가

PRIVATE과 main이 보이면 비공개 저장소에 기본 브랜치까지 제대로 만들어진 것입니다.

7~8단계: 고쳐서 다시 올리고 확인하기

$ printf '\n두 번째 커밋으로 줄을 더했습니다.\n' >> README.md && git commit -am "README 수정" && git push
[main fe471fa] README 수정
 1 file changed, 2 insertions(+)
To https://github.com/<계정>/<저장소>.git
   c5ae788..fe471fa  main -> main

$ gh api repos/<계정>/<저장소>/commits --jq length
2

5단계 출력에서 main이 origin/main을 추적하도록 설정됐으므로(branch 'main' set up to track 'origin/main'.), 이번 실습에서는 이후 git push만 실행해도 됩니다. c5ae788..fe471fa는 첫 커밋 다음에 새 커밋이 붙었다는 뜻이고, 깃허브에서 센 커밋 수도 2로 나왔어요.

gh 없이 git 명령만으로도 올릴 수 있나요?

네, 공식 문서는 Git 명령만으로 올리는 방법도 안내합니다. 이럴 때는 먼저 명령줄에서 깃허브 인증을 마쳐야 해요. 그다음 깃허브에서 새 저장소를 만드는데, 오류를 피하려면 README, 라이선스, gitignore 파일 없이 만들라고 문서는 권합니다. 맥 기준 명령은 이렇습니다.

git remote add origin REMOTE-URL

git remote -v

git push -u origin main

REMOTE-URL에는 깃허브 저장소의 전체 주소를 넣습니다. 이 방법은 이번에 측정하지 않았으니, 두 방식의 차이는 아래 표로만 비교해 두겠습니다.

도식출처: 근거를 바탕으로 코드가 그린 도식

git 사용법, 처음엔 어떤 명령만 알면 될까요?

혼자 제품을 만들 때 매일 쓰는 명령은 생각보다 적습니다. 이 글의 기록에 나온 것만 추리면 다음과 같아요.

• git init -b main: 폴더를 저장소로 만들기(처음 한 번)
• git add 파일: 커밋할 파일 올려 두기
• git commit -m "메시지": 변경 저장
• git push: 깃허브로 보내기
• git log --oneline: 지금까지의 커밋 한 줄씩 보기

한 가지는 꼭 지켜야 합니다. 공식 문서는 비밀번호나 API 키 같은 민감한 정보를 git add, 커밋, 푸시하지 말라고 경고해요. AI 에이전트가 키를 담은 설정 파일을 만들었다면, git add .로 한꺼번에 올리기 전에 어떤 파일이 들어가는지 확인하는 편이 안전합니다.

측정 조건과 한계

• 환경: 맥(darwin arm64) 한 대, git version 2.54.0, gh version 2.103.0 (2026-10-21)
• 계정: gh로 이미 로그인된 계정 하나, 커밋 작성자는 측정용 이름
• 대상: 새 임시 폴더 하나, 비공개 저장소 하나
• 방법: 명령을 적힌 순서대로 한 번씩 실행하고 시간, 종료 코드, 출력을 기록

모든 단계를 한 번씩만 실행했기 때문에 시간은 참고값으로 보는 게 맞습니다. 또 깃허브 웹 화면에서 저장소를 만드는 방법, Git 명령만으로 올리는 방법, 처음 로그인하는 과정은 재지 않았어요. 웹 화면으로 시작하고 싶다면 GitHub Docs의 Hello World가 브랜치와 풀 리퀘스트까지 화면 순서대로 안내합니다.