Git status와 diff를 읽고 첫 commit과 GitHub push까지 어떻게 진행하나요?
Git은 파일 수정, 다음 커밋에 선택한 변경, 저장된 커밋, 원격 저장소를 서로 다른 상태로 관리합니다. status와 diff로 현재 위치를 읽고 필요한 변경만 add·commit한 뒤 push하세요.
적용 조건·범위: Git 설치는 공식 다운로드 안내를 따릅니다. Windows 명령은 Git Bash 기준입니다. 첫 commit에서 작성자 정보가 없다는 오류가 나오면 아래 입력 절차를 이 연습 저장소 안에서 실행한 후 commit을 다시 시도합니다.
본문 근거: 공식 다운로드 안내 · git-scm.com/docs/git-init · docs.github.com/en/get-started/git-basics/set-up-git
핵심 원리
Git에서 중요한 것은 명령어 암기보다 작업 트리, staging area, commit, remote가 서로 다른 상태라는 점을 구분하는 것입니다. 같은 파일이라도 저장했는지, stage했는지, commit했는지, push했는지에 따라 Git이 보는 상태가 달라집니다.
아래 관찰 명령은 init 후 사용합니다. 첫 commit 전 log가 실패하는 것은 이력이 아직 없기 때문입니다. 최초 설치·init·기본 설정은 이어지는 실습 절차부터 진행합니다.
git status --short
git branch --show-current
git log --oneline --decorate -5
출력 결과를 보지 않고 다음 명령을 연속으로 입력하면 무엇이 바뀌었는지 추적하기 어렵습니다. 이번 회차에서는 각 명령 뒤에 상태를 다시 확인하면서 작업 전후 차이를 기록합니다.
직접 확인해야 할 기준
새 폴더에서 두 번의 commit을 만들고 add 뒤 파일을 다시 수정해 MM 상태를 관찰합니다.
bare remote 또는 GitHub 원격을 연결해 local과 remote commit ID가 일치하는지 확인합니다.
실습에서는 성공 명령만 기록하지 않습니다. 의도적으로 한 번 실패하거나 충돌 상황을 만들고, 오류 메시지와 현재 저장소 상태를 함께 확인합니다. Git 문제는 오류 문구만 검색하기보다 HEAD가 어디를 가리키는지, working tree와 index가 어떤 상태인지, local과 remote history가 어떻게 다른지를 먼저 확인하는 편이 안전합니다.
독립 실습: 빈 폴더에서 첫 push까지
Git 설치는 공식 다운로드 안내를 따릅니다. Windows 명령은 Git Bash 기준입니다. 첫 commit에서 작성자 정보가 없다는 오류가 나오면 아래 입력 절차를 이 연습 저장소 안에서 실행한 후 commit을 다시 시도합니다.
read -r -p "commit 작성자 이름: " PRACTICE_AUTHOR
read -r -p "commit 작성자 이메일: " PRACTICE_EMAIL
if [ -n "$PRACTICE_AUTHOR" ] && [ -n "$PRACTICE_EMAIL" ]; then
git config --local user.name "$PRACTICE_AUTHOR"
git config --local user.email "$PRACTICE_EMAIL"
fi
TaskFlow 파일이 없어도 이 실습을 시작할 수 있습니다. 아래 명령은 새 연습 폴더에서만 실행합니다. Git이 설치되어 있고 본인의 GitHub 계정이 필요합니다. commit 작성자 정보가 없다면 앞의 로컬 설정 안내대로 본인 이름과 이메일을 먼저 설정합니다.
mkdir git-first-push-practice
cd git-first-push-practice
git init -b main
echo '# Git 첫 실습' > README.md
git status --short
예상: README.md가 ??로 보입니다. 아직 추적하지 않는 파일이므로 git diff에는 나타나지 않습니다.
git add README.md
git diff --cached -- README.md
git commit -m "docs: add practice README"
echo '첫 변경' >> README.md
git add README.md
echo '두 번째 변경' >> README.md
git status --short
git diff -- README.md
git diff --cached -- README.md
예상: status의 README.md 앞에 MM이 보입니다. 첫 번째 M은 stage한 변경, 두 번째 M은 그 뒤 작업 폴더에서만 한 변경입니다. 두 diff의 추가 줄이 서로 다르면 확인에 성공한 것입니다. 두 변경을 모두 포함하려면 다시 add한 뒤 commit합니다.
git add README.md
git commit -m "docs: record two changes"
git log --oneline -2
GitHub에서 README와 초기 commit이 없는 빈 저장소를 만든 다음, 그 저장소의 clone URL을 복사합니다. 연습 폴더에서 git remote add origin 뒤에 복사한 URL을 입력합니다. 주소는 본인 저장소인지 git remote -v로 확인합니다. 이어서 git push -u origin main을 실행합니다. 비밀번호나 토큰을 URL에 넣지 않습니다.
git remote -v
git push -u origin main
git rev-parse HEAD
git ls-remote origin refs/heads/main
완료 기준: 마지막 두 명령의 commit ID가 같고 GitHub에서 README.md의 두 변경이 보입니다. push가 거절되면 강제 push하지 않고 원격 저장소가 비어 있는지 확인합니다. 원격 push 결과는 독자가 본인 계정에서 확인하며, 이 글 작성 과정에서 대리 실행한 결과가 아닙니다.
독립 학습 변형 과제: README를 add한 뒤 한 줄을 더 바꿔 보세요. 일반 diff와 cached diff에서 서로 다른 줄이 보이는 이유를 작업 트리와 index로 설명합니다.
선택 실습: 같은 프로젝트로 연습하기
이 선택 실습은 TaskFlow 개발 과정을 Git 저장소와 협업 기록으로 남기는 연습입니다. Git 이력은 직접 명령을 실행해 만듭니다.
이번 주제: Git 기초 실습: status와 diff부터 첫 GitHub push까지.
선택: 연재 프로젝트와 전체 자료
연재 프로젝트를 이어 만드는 분을 위한 자료입니다. 이 글의 개념과 예제만 찾으셨다면 필요한 파일과 실행 방법만 펼쳐보세요.
TaskFlow 프로젝트 적용
시작 체크포인트: 개발환경 과정에서 실제 실행되는 TaskFlow 로컬 폴더를 준비한 뒤 아래 최초 연결 절차를 진행합니다. 다운로드 ZIP은 문서·설정 참고 자료이며 commit 이력·branch·remote·PR 상태를 복원하지 않습니다. 현재 저장소의 status·log와 아래 시작 조건을 직접 대조합니다.
첫 저장소부터 원격 연결까지
Git 공식 설치 안내에서 운영체제에 맞는 Git을 설치합니다. Windows 명령 예제는 Git Bash 기준입니다. 이후 회차도 같은 셸을 사용합니다. 먼저 개발환경 과정에서 만든 TaskFlow 폴더를 편집기로 열고 그 폴더에서 터미널을 엽니다. 이미 .git이 있는 프로젝트라면 아래 init을 반복하기보다 현재 이력과 브랜치를 먼저 확인합니다.
git --version
git init -b main
git status --short
이름과 이메일은 이 저장소의 commit 작성자 정보입니다. GitHub 인증 비밀번호가 아닙니다. 공개 이메일을 원하지 않으면 GitHub Settings의 Emails에서 본인의 noreply 주소를 확인합니다. 아래 입력은 실제 값을 화면에 재출력하지 않고 저장소 로컬 설정에만 기록합니다.
read -r -p "commit 작성자 이름: " GIT_AUTHOR_LABEL
read -r -p "commit 작성자 이메일 또는 본인 noreply 주소: " GIT_AUTHOR_MAIL
if [ -n "$GIT_AUTHOR_LABEL" ] && [ -n "$GIT_AUTHOR_MAIL" ]; then
git config --local user.name "$GIT_AUTHOR_LABEL"
git config --local user.email "$GIT_AUTHOR_MAIL"
else
printf '%s\n' '빈 작성자 정보로 진행하지 않습니다.'
fi
편집기에서 README.md에 TaskFlow의 목적 한 줄을 작성합니다. 기존 파일은 덮어쓰지 않고 내용을 읽고 수정합니다. .gitignore에는 기존 개발환경의 node_modules, 빌드 산출물, 실제 환경변수 파일 제외 규칙을 유지합니다. 첫 commit은 README만 명시적으로 선택합니다.
git status --short
git add README.md
git diff --cached
git commit -m "docs: describe TaskFlow"
git log --oneline -1
처음에는 README가 untracked라서 일반 git diff에 나오지 않을 수 있습니다. add 후 cached diff는 첫 commit에 들어갈 내용을 보여 줍니다. 이제 README에 실행 방법 한 줄을 추가해 add하고, commit하기 전에 다른 설명 한 줄을 더 수정합니다.
git add README.md
git status --short
git diff
git diff --cached
이때 예상하는 MM의 첫 M은 staging, 두 번째 M은 staging 이후 작업 트리 변경입니다. 두 diff를 비교한 뒤 두 변경 모두 포함하려면 다시 add하고 두 번째 commit을 만듭니다.
git add README.md
git diff --cached
git commit -m "docs: add TaskFlow usage"
GitHub에서는 본인 계정에 빈 저장소를 만들고 README나 초기 commit을 추가하지 않습니다. 저장소 화면의 HTTPS 또는 SSH 주소를 복사합니다. HTTPS는 Git Credential Manager 등 공식 인증 흐름을, SSH는 이미 등록한 키를 사용합니다. 비밀번호나 토큰을 URL에 넣지 않습니다. 아래는 독자가 본인 원격 저장소를 연결할 때 실행하는 절차이며 이 글의 검수에서 push한 결과가 아닙니다.
read -r -p "본인의 빈 GitHub 저장소 clone 주소: " TASKFLOW_REMOTE
if [ -n "$TASKFLOW_REMOTE" ]; then
git remote add origin "$TASKFLOW_REMOTE"
else
printf '%s\n' '원격 주소가 없어 연결하지 않습니다.'
fi
git remote -v
origin이 이미 존재하면 add 실패를 무시하지 말고 기존 주소가 본인의 대상인지 확인합니다. 주소와 commit 내용을 검토한 뒤에만 첫 push를 실행합니다.
git push -u origin main
git status -sb
git rev-parse HEAD
git ls-remote origin refs/heads/main
마지막 두 출력의 commit ID가 같고 GitHub 파일 화면이 일치하면 첫 연결 기준을 충족합니다. 빈 원격이 아니어서 rejected가 발생했다면 강제 push하지 않고 4편의 fetch/이력 비교로 이동합니다. init 전에는 status가 실패하고 첫 commit 전에는 log가 실패하는 것이 정상일 수 있습니다.
공식 근거: https://git-scm.com/docs/git-init · https://git-scm.com/docs/git-add · https://git-scm.com/docs/git-commit · https://docs.github.com/en/get-started/git-basics/set-up-git
필수 선수 지식은 편집기와 터미널을 여는 방법입니다. Git 설치부터 이 글에서 시작합니다. TaskFlow 로컬 프로젝트는 독립 실습에는 필요하지 않고 하단 누적 적용을 따라갈 때만 준비합니다.
이전 체크포인트:
개발환경 과정의 TaskFlow 로컬 프로젝트
Before: 로컬 프로젝트만 존재
After: main · origin · 첫 commit · GitHub 저장소 연결
검증: git status -sb · git log --oneline · git remote -v · GitHub 파일/commit 확인
변경 전후를 다음 기준으로 남깁니다.
Before
- 이전 체크포인트 상태
- 현재 branch와 working tree 확인
Change
- 이번 회차의 Git 작업 수행
- status / diff / log로 변화 확인
After
- 작업 결과 검증
- 다음 회차가 이어받을 상태 저장
자주 발생하는 실수
- 파일 저장 ≠ staging ≠ commit ≠ push
- .gitignore는 이미 commit된 비밀을 지우지 않음
- push 실패 시 강제 push보다 remote history 확인이 우선
문제를 해결할 때는 먼저 git status, git log, git diff, 필요하면 git reflog로 관찰 가능한 사실을 모읍니다. 그다음 변경 범위가 가장 작은 복구 방법을 선택합니다.
학습 완료 체크리스트
- 상태 모델을 그림 없이 말로 설명할 수 있고, staging 전후 diff를 구분하며 첫 push까지 스스로 수행할 수 있어야 합니다.
전체 파일·코드 보기
실습 프로젝트 전체 코드
이 회차는 Git 명령 실습을 위한 문서·설정 자료입니다. ZIP에는 실제 Git 이력이나 앱 전체가 없습니다. 아래 Markdown 문서는 자동 실행 스크립트가 아니며, 각 명령의 전제와 예상 상태를 읽고 본인의 연습 환경에서 단계별로 확인합니다.
README.md
# git-step-01-first-push 문서 체크포인트
이 ZIP은 Git·GitHub 실습 안내와 관련 설정 파일을 모은 자료입니다. `.git` 이력, 실제 branch/tag/stash/worktree, 원격 저장소, 사용자 계정이나 TaskFlow 앱 전체를 포함하지 않습니다. 별도의 개발환경 과정 TaskFlow 프로젝트에서 실습 안내를 읽고 명령을 단계별로 적용하세요. 이 폴더 자체를 완성된 Git 저장소로 간주하거나 명령을 한꺼번에 실행하지 마세요.
01~13 필수 과정의 이 회차까지 문서를 누적합니다.
검증 범위는 명령 문법·설정 형식·공식 문서 및 기존 프로젝트 스크립트 대조입니다. 실제 init/commit/branch/stash/worktree/reset/rebase/merge/push/PR/Release/서명 작업을 수행했다는 기록이 아닙니다. 개인 키·토큰·비밀번호는 포함하지 않습니다.
docs/git-step-01.md
# Git·GitHub 01 실습 안내
이 파일은 독자가 상태를 확인하며 따라갈 Markdown 문서입니다. 자동 실행 스크립트나 검수 과정에서 실행한 Git 이력 로그가 아닙니다.
## 첫 저장소부터 원격 연결까지
Git 공식 설치 안내에서 운영체제에 맞는 Git을 설치합니다. Windows 명령 예제는 Git Bash 기준입니다. 이후 회차도 같은 셸을 사용합니다. 먼저 개발환경 과정에서 만든 TaskFlow 폴더를 편집기로 열고 그 폴더에서 터미널을 엽니다. 이미 .git이 있는 프로젝트라면 아래 init을 반복하기보다 현재 이력과 브랜치를 먼저 확인합니다.
```bash
git --version
git init -b main
git status --short
```
이름과 이메일은 이 저장소의 commit 작성자 정보입니다. GitHub 인증 비밀번호가 아닙니다. 공개 이메일을 원하지 않으면 GitHub Settings의 Emails에서 본인의 noreply 주소를 확인합니다. 아래 입력은 실제 값을 화면에 재출력하지 않고 저장소 로컬 설정에만 기록합니다.
```bash
read -r -p "commit 작성자 이름: " GIT_AUTHOR_LABEL
read -r -p "commit 작성자 이메일 또는 본인 noreply 주소: " GIT_AUTHOR_MAIL
if [ -n "$GIT_AUTHOR_LABEL" ] && [ -n "$GIT_AUTHOR_MAIL" ]; then
git config --local user.name "$GIT_AUTHOR_LABEL"
git config --local user.email "$GIT_AUTHOR_MAIL"
else
printf '%s\n' '빈 작성자 정보로 진행하지 않습니다.'
fi
```
편집기에서 README.md에 TaskFlow의 목적 한 줄을 작성합니다. 기존 파일은 덮어쓰지 않고 내용을 읽고 수정합니다. .gitignore에는 기존 개발환경의 node_modules, 빌드 산출물, 실제 환경변수 파일 제외 규칙을 유지합니다. 첫 commit은 README만 명시적으로 선택합니다.
```bash
git status --short
git add README.md
git diff --cached
git commit -m "docs: describe TaskFlow"
git log --oneline -1
```
처음에는 README가 untracked라서 일반 git diff에 나오지 않을 수 있습니다. add 후 cached diff는 첫 commit에 들어갈 내용을 보여 줍니다. 이제 README에 실행 방법 한 줄을 추가해 add하고, commit하기 전에 다른 설명 한 줄을 더 수정합니다.
```bash
git add README.md
git status --short
git diff
git diff --cached
```
이때 예상하는 MM의 첫 M은 staging, 두 번째 M은 staging 이후 작업 트리 변경입니다. 두 diff를 비교한 뒤 두 변경 모두 포함하려면 다시 add하고 두 번째 commit을 만듭니다.
```bash
git add README.md
git diff --cached
git commit -m "docs: add TaskFlow usage"
```
GitHub에서는 본인 계정에 빈 저장소를 만들고 README나 초기 commit을 추가하지 않습니다. 저장소 화면의 HTTPS 또는 SSH 주소를 복사합니다. HTTPS는 Git Credential Manager 등 공식 인증 흐름을, SSH는 이미 등록한 키를 사용합니다. 비밀번호나 토큰을 URL에 넣지 않습니다. 아래는 독자가 본인 원격 저장소를 연결할 때 실행하는 절차이며 이 글의 검수에서 push한 결과가 아닙니다.
```bash
read -r -p "본인의 빈 GitHub 저장소 clone 주소: " TASKFLOW_REMOTE
if [ -n "$TASKFLOW_REMOTE" ]; then
git remote add origin "$TASKFLOW_REMOTE"
else
printf '%s\n' '원격 주소가 없어 연결하지 않습니다.'
fi
git remote -v
```
origin이 이미 존재하면 add 실패를 무시하지 말고 기존 주소가 본인의 대상인지 확인합니다. 주소와 commit 내용을 검토한 뒤에만 첫 push를 실행합니다.
```bash
git push -u origin main
git status -sb
git rev-parse HEAD
git ls-remote origin refs/heads/main
```
마지막 두 출력의 commit ID가 같고 GitHub 파일 화면이 일치하면 첫 연결 기준을 충족합니다. 빈 원격이 아니어서 rejected가 발생했다면 강제 push하지 않고 4편의 fetch/이력 비교로 이동합니다. init 전에는 status가 실패하고 첫 commit 전에는 log가 실패하는 것이 정상일 수 있습니다.
공식 근거: https://git-scm.com/docs/git-init · https://git-scm.com/docs/git-add · https://git-scm.com/docs/git-commit · https://docs.github.com/en/get-started/git-basics/set-up-git
## 체크포인트 기준
git-step-01-first-push: 위 실습의 관찰 기준을 본인의 연습 환경에서 확인한 뒤 사용합니다. 이 ZIP을 내려받았다는 사실만으로 실습 완료가 성립하지 않습니다.
실행·검증 범위
이 자료는 독자가 실행할 절차와 기대 관찰 기준입니다. 제공 ZIP에는 Git 이력·실제 원격 저장소·CI 성공 기록이 포함되지 않습니다. 이번 원문 검수에서 branch/worktree/stash/reset/삭제/commit/push 또는 보안·서명 설정을 실행하지 않았습니다. 실제 수행 결과는 독자가 자신의 연습용 저장소와 권한을 확인하여 기록합니다.
완료 체크포인트
git-step-01-first-push
이 체크포인트는 명령을 한 번 실행했다는 뜻이 아니라, 결과를 status, diff, log 등으로 확인한 상태를 의미합니다.
다음 학습
02 Git staging과 commit 제대로 이해하기
다음 회차로 이동하기 전에 working tree에 의도하지 않은 변경이 남아 있지 않은지 다시 확인합니다.
체크포인트 다운로드
git-step-01-first-push 문서·설정 ZIP 다운로드
ZIP은 명령 안내와 설정 자료이며 Git 이력·브랜치·원격 저장소 상태를 복원하지 않습니다.
글 소개·학습 준비·전체 목차
Git·GitHub · 1 / 17 · 초급
Git 기초 실습 status와 diff부터 첫 GitHub push까지
Git이 파일을 어떻게 추적하는지 상태 모델부터 이해합니다.
작업 트리 → staging area → commit → remote repository 흐름을 직접 재현하고 TaskFlow를 GitHub에 최초 push합니다.
이번 글에서 배우는 내용
- git init과 .git 폴더
- tracked / untracked / modified / staged 상태
- git status와 status
--short - git diff / git diff
--cached - git add와 staging snapshot
- git commit과 commit object 개념
- git log / git show 기초
- remote / origin / upstream tracking
- git push -u origin main
- .gitignore 기본
- 인증 실패, remote already exists, refspec 오류, non-fast-forward의 첫 진단
선수 지식
편집기와 Git Bash를 여는 방법만 필요합니다. Git 설치와 첫 저장소 준비는 아래에서 진행합니다.
목차
이 글이 도움이 되었나요?
읽음 기록
읽음 — / 전체 18개 · 필수 15개
새 글 받아보기
RSS 리더에서 BlogFlow의 새 글을 확인할 수 있습니다.
