Git 기초 실습: status와 diff부터 첫 GitHub push까지

목차

• 저장 버튼과 커밋은 무엇이 다를까요?
• 빈 폴더에서 첫 커밋 만들기
• 수정과 스테이징을 일부러 다르게 만들기
• 네트워크 없이 원격 저장소와 push 연습하기
• 본인 GitHub 저장소로 첫 push 하기
• 막혔을 때 확인할 위치와 다음 연습

저장 버튼과 커밋은 무엇이 다를까요?

에디터에서 저장하면 현재 파일이 바뀝니다. Git 커밋은 선택한 파일들의 상태를 하나의 이력으로 남깁니다. GitHub는 그 이력을 다른 컴퓨터와 공유하는 서비스입니다. 파일을 저장했다고 커밋되거나 GitHub에 자동 업로드되지는 않습니다.

위치	이번 실습에서 확인할 것	주요 명령
작업 트리	에디터로 수정한 index.html	git diff
스테이징 영역	다음 커밋에 넣기로 고른 내용	git diff --cached
로컬 저장소	이미 기록한 커밋	git log
원격 저장소	push로 전달한 이력	git remote -v

스테이징은 파일 이름만 예약하는 동작이 아닙니다. git add를 실행한 시점의 내용을 선택합니다. 나중에 파일을 다시 수정하면 스테이징된 내용과 작업 파일이 서로 다를 수 있습니다. Git: Recording Changes에서 설명하는 이 차이를 아래 실습에서 직접 만듭니다.

빈 폴더에서 첫 커밋 만들기

Git이 없다면 Git 공식 설치 안내에서 운영체제에 맞게 설치한 뒤 터미널을 새로 엽니다. git --version이 버전 번호를 출력하는지 확인하세요. 아래 셸 문법은 macOS·Linux의 bash 또는 Windows Git Bash 기준입니다. 기존 프로젝트 안이 아닌 새 연습 공간에서 명령을 순서대로 실행합니다. 같은 이름의 폴더가 있으면 다른 빈 위치를 사용하세요.

아래 블록은 터미널에 입력할 명령입니다. printf가 index.html과 .gitignore를 만드므로 별도 파일을 미리 만들 필요는 없습니다. 작성자 이름과 이메일은 이 연습 저장소에만 적용됩니다. GitHub에 본인 작성자로 기록하려면 아래 블록을 실행하기 전에 이름과 이메일을 본인 값으로 바꾸세요. 이메일은 GitHub 설정에서 확인한 공개용 또는 비공개용 커밋 이메일을 사용합니다. 첫 commit부터 이 값이 이력에 저장됩니다. 나중에 git config를 바꿔도 이미 만든 커밋의 작성자 정보는 바뀌지 않으며 이후 새 커밋에 적용됩니다.

01-init.sh

mkdir publisher-git
cd publisher-git
git init -b main
git config user.name "Publisher Learner"
git config user.email "learner@example.com"
printf '%s\n' '<h1>My portfolio</h1>' > index.html
printf '%s\n' '.env' 'node_modules/' > .gitignore
git status --short
git add index.html .gitignore
git diff --cached
git commit -m "Create portfolio page"

처음 status --short에서는 새 파일 앞에 ??가 보입니다. add 후의 cached diff에는 처음 저장할 HTML과 무시 규칙이 표시됩니다. commit이 끝나면 커밋 식별자와 생성한 파일 목록이 나옵니다. 명령을 실행한 뒤에도 현재 위치는 publisher-git 폴더여야 합니다.

.gitignore는 아직 추적하지 않는 파일을 제외하는 규칙입니다. 이미 커밋한 .env를 나중에 이 목록에 넣어도 과거 이력에서 비밀 값이 없어지지 않습니다. 이 실습은 실제 .env나 키를 만들지 않으며, 다음 단계에서도 index.html만 고릅니다.

수정과 스테이징을 일부러 다르게 만들기

첫 커밋 뒤 아래 블록을 같은 폴더에서 실행합니다. 제목을 고쳐 add한 다음 설명 문단을 추가하여 두 상태를 만듭니다. 중간의 restore --staged는 커밋 대상 선택만 해제하며 작업 파일은 유지합니다.

02-edit.sh

printf '%s\n' '<h1>Frontend portfolio</h1>' > index.html
git status --short
git diff
git add index.html
git diff --cached
printf '%s\n' '<h1>Frontend portfolio</h1>' '<p>Learning Git</p>' > index.html
git status --short
git diff
git diff --cached
git restore --staged index.html
git status --short
git add index.html
git commit -m "Describe frontend learning"
git log --oneline -2

확인 시점	예상 관찰	해석
제목만 수정	M index.html	작업 파일만 바뀜
제목 add 후 문단 추가	MM index.html	스테이징과 작업 파일 양쪽에 변경
git diff	추가한 설명 문단	아직 스테이징하지 않은 차이
git diff --cached	제목 변경	다음 커밋에 들어갈 차이
restore --staged 후	M index.html	파일 내용은 남고 스테이징 해제

마지막 add는 제목과 문단을 함께 선택합니다. 두 번째 commit 후에는 git status --short가 비어 있어야 합니다. 빈 출력은 작업 파일과 스테이징에 미기록 변경이 없다는 뜻이며, 아직 push하지 않았다는 사실과는 별개입니다.

커밋에는 어느 시점의 파일이 들어갔을까요?

앞 단계에서 add 뒤에 문단을 더 썼을 때 MM이 나온 이유는 비교 기준이 둘이기 때문입니다. 왼쪽 열은 HEAD와 index, 오른쪽 열은 index와 작업 파일을 비교합니다. 이 차이를 이해하면 “수정했는데 커밋에서 빠진 파일”을 찾을 수 있습니다.

터미널에서 실행할 명령

git show HEAD:index.html
git diff HEAD -- index.html
git status --porcelain

두 번째 커밋까지 마쳤다면 show에는 최종 제목과 Learning Git 문단이 함께 나옵니다. diff와 status는 빈 출력이 정상입니다. show는 현재 디스크 파일이 아니라 커밋에 저장된 내용을 읽으므로 업로드 대상 점검에 적합합니다.

추가 실험으로 index.html 끝에 임시 문단 한 줄을 저장한 뒤 status와 show를 다시 비교하세요. 파일에는 새 문단이 있어도 show 결과는 그대로입니다. 이 상태의 push는 미커밋 문단을 전송하지 않습니다. 이번에는 에디터에서 방금 추가한 문단만 지워 원상태로 돌아오세요. 작업 파일 전체를 버리는 restore 명령을 습관적으로 쓰지 않습니다.

실습 완료 후 답해 보세요. “add 뒤 다시 저장했다면 무엇을 다시 확인해야 하나요?” 정답은 작업 diff와 cached diff를 비교한 뒤 필요한 변경만 다시 add하는 것입니다.

네트워크 없이 원격 저장소와 push 연습하기

원격은 다른 저장소의 주소를 이름으로 등록한 것입니다. 이 연습에서는 형제 폴더에 bare 저장소를 만들고 origin으로 등록합니다. bare 저장소는 일반 작업 파일 없이 이력을 보관하므로 직접 HTML을 열어 수정하는 장소가 아닙니다. 로컬 경로도 원격이 될 수 있다는 점은 Git: Working with Remotes에 명시되어 있습니다.

03-local-remote.sh

git init --bare -b main ../publisher-remote.git
git remote add origin ../publisher-remote.git
git remote -v
git push -u origin main
git status -sb
git --git-dir=../publisher-remote.git log --oneline main -2

git remote add는 주소를 기록할 뿐 파일을 보내지 않습니다. 실제 전송은 git push -u origin main에서 일어납니다. -u는 로컬 main이 추적할 원격 브랜치를 설정합니다. 마지막 두 로그의 커밋 식별자가 일치하면 로컬에서 만든 이력이 원격에도 도착한 것입니다.

이 상태에서 다시 push하면 새 커밋이 없으므로 up-to-date 안내가 나옵니다. 작업 파일만 고치고 커밋하지 않은 상태에서도 push할 새 커밋은 없습니다. “업로드했는데 수정이 안 보인다”면 status, log, remote 주소를 차례로 확인하세요.

본인 GitHub 저장소로 첫 push 하기

GitHub에서 본인 계정으로 새 저장소를 만들고 공개 범위를 선택합니다. 로컬 이력이 이미 있으므로 README·라이선스·.gitignore 자동 생성은 선택하지 않아 빈 저장소로 만듭니다. 저장소의 HTTPS 주소를 복사하세요. 절차의 기준은 GitHub: Adding locally hosted code입니다.

앞의 로컬 원격 연습을 했다면 origin이 이미 있으므로 아래처럼 주소를 교체합니다. 따옴표 안의 URL은 예시 문자열을 그대로 쓰지 말고 방금 복사한 본인 저장소 URL로 바꿉니다. 이 주소에는 토큰이나 비밀번호를 넣지 않습니다.

git remote set-url origin "https://github.com/YOUR_ACCOUNT/YOUR_REPOSITORY.git"
git remote -v
git push -u origin main

로컬 원격 연습을 건너뛰어 git remote -v가 비어 있는 경우에만 set-url 대신 git remote add origin "복사한 저장소 HTTPS 주소"로 최초 등록합니다. 둘을 연달아 실행하지 않습니다. HTTPS 인증은 GitHub가 지원하는 자격 증명 관리자나 인증 방식으로 진행하며 GitHub 계정 비밀번호를 Git 비밀번호처럼 사용하지 않습니다. 인증 값은 문서·채팅·명령 URL에 남기지 마세요.

성공 후 GitHub의 main에서 index.html과 두 커밋을 확인합니다. 이 글을 준비하면서 실행한 push는 로컬 bare 원격까지입니다. GitHub 로그인·외부 push 성공은 검증하지 않았으므로 이 마지막 단계는 본인 계정에서 완료 여부를 확인해야 합니다.

막혔을 때 확인할 위치와 다음 연습

증상	먼저 확인	대응
Author identity unknown	git config user.name / user.email	저장소에 본인 작성자 정보 설정
src refspec main does not match any	git log, git branch --show-current	첫 커밋 유무와 실제 브랜치 이름 확인
remote origin already exists	git remote -v	새로 add하지 말고 올바른 URL로 set-url
Authentication failed / repository not found	저장소 URL·로그인 계정·쓰기 권한	인증과 주소를 확인한 뒤 재시도
non-fast-forward 거절	git fetch origin 후 git log --all --graph --oneline	원격 이력을 확인하고 다음 브랜치·병합 실습으로 이어가기

원격에 다른 커밋이 있다고 push가 거절되면 강제 push로 덮지 않습니다. Git은 공유 이력을 잃을 수 있는 업데이트를 멈춘 것입니다. 자신의 새 빈 저장소가 맞는지부터 확인하고, 이미 README를 만든 저장소라면 그 이력을 가져와 통합하는 과정을 배운 뒤 진행하세요.

완료 기준은 “두 번 커밋했다”만이 아닙니다. 작업 변경과 cached diff를 구분하고, staging을 해제해도 파일이 남는 것을 확인하며, 로컬·원격의 커밋 식별자를 비교할 수 있어야 합니다. 이후 브랜치와 PR을 익힌 뒤 Git Alias 설정 글에서 자주 쓰는 명령을 줄여 보세요.