Git 기본 명령어 사용법: init부터 branch·pull·push까지
3줄 요약Git은 파일의 변경 이력을 커밋 단위로 기록하고, 여러 작업을 브랜치로 분리할 수 있는 분산 버전 관리 시스템이다.가장 중요한 기본 흐름은상태 확인 → 변경 선택 → 커밋이며, 명령으로는git status → git add → git commit이다.원격 저장소와 협업할 때는 강제 푸시부터 시도하지 말고git fetch로 차이를 확인한 뒤 팀 정책에 맞게 병합하고git push한다.
Git을 처음 배우면 init, add, commit, branch, pull, push 같은 명령어가 한꺼번에 등장한다. 각각의 문법만 외우면 간단한 작업은 할 수 있지만, 오류가 났을 때 현재 변경이 어디에 있는지 몰라 더 위험한 명령을 실행하기 쉽다.
Git은 명령어 목록보다 변경이 이동하는 흐름으로 이해하는 편이 쉽다.
작업 디렉터리 → 스테이징 영역 → 로컬 저장소 → 원격 저장소
- 작업 디렉터리에서 파일을 수정한다.
git add로 다음 커밋에 넣을 변경을 스테이징한다.git commit으로 스테이징한 변경을 로컬 이력에 기록한다.git push로 로컬 커밋을 GitHub·GitLab·Gitea 같은 원격 저장소에 보낸다.
이 글에서는 새 저장소를 만드는 순간부터 브랜치 작업, 원격 동기화, 충돌 해결과 안전한 되돌리기까지 하나의 실무 흐름으로 정리한다. 공식 문서 확인 기준일은 2026년 8월 28일이다.
1. Git과 GitHub·GitLab은 무엇이 다른가
먼저 Git과 저장소 호스팅 서비스를 구분해야 한다.
- Git: 내 PC에서도 독립적으로 동작하는 버전 관리 프로그램이다.
- GitHub·GitLab·Gitea: Git 저장소를 서버에 보관하고 공유하며 코드 리뷰, 이슈, 권한 관리 같은 협업 기능을 제공하는 서비스다.
- 저장소(repository): 프로젝트 파일과 Git 이력이 보관되는 공간이다.
- 커밋(commit): 특정 시점의 변경 내용과 작성자, 메시지를 기록한 이력 단위다.
- 브랜치(branch): 기존 이력에서 갈라져 기능이나 버그 수정을 독립적으로 진행하는 작업선이다.
- 원격 저장소(remote): 네트워크를 통해 연결한 다른 Git 저장소다. 보통 서버에 있지만 다른 로컬 경로일 수도 있다.
인터넷 연결이 없어도 로컬 저장소에서 add, commit, branch, merge, log를 사용할 수 있다. 원격이 HTTPS·SSH 같은 네트워크 경로에 있을 때는 clone, fetch, pull, push에 네트워크 연결이 필요하다. 다른 로컬 경로를 원격으로 사용한다면 이 명령들도 네트워크 없이 동작할 수 있다.
2. 처음 한 번 확인하고 설정할 항목
설치된 Git 버전을 먼저 확인한다.
git --version
커밋에 기록할 이름과 이메일을 설정한다.
git config --global user.name "Hong Gildong"
git config --global user.email "you@example.com"
git config --global init.defaultBranch main
현재 전역 설정은 다음 명령으로 확인한다.
git config --global --list
user.name과 user.email은 GitHub나 GitLab에 로그인하는 아이디와 비밀번호가 아니다. 커밋의 작성자 정보로 남으며 공개 저장소에서는 외부에 보일 수 있다. 회사와 개인 프로젝트의 이메일 정책이 다르다면 저장소 폴더에서 --global을 빼고 해당 저장소에만 별도로 설정한다.
git config user.name "Hong Gildong"
git config user.email "work@example.com"
git config --local --list
비밀번호나 액세스 토큰을 git config에 직접 기록하지 않는다. HTTPS 인증은 운영체제의 자격 증명 관리자나 Git Credential Manager를 사용하고, SSH를 쓴다면 개인키를 저장소에 넣지 않는다.
init.defaultBranch main은 앞으로 만드는 저장소의 초기 브랜치 이름을 통일하기 위한 설정이다. 기존 저장소의 브랜치 이름을 자동으로 바꾸지는 않는다. 팀 저장소의 기본 브랜치는 서버 설정과 팀 규칙을 먼저 확인한다.3. 저장소 시작하기: init과 clone
새 프로젝트를 Git으로 관리하기
새 폴더를 만들고 그 안에서 Git 저장소를 시작한다.
mkdir git-practice
cd git-practice
git init -b main
git status
git init -b main은 현재 폴더에 .git 디렉터리를 만들고 초기 브랜치 이름을 main으로 지정한다. 프로젝트 파일을 삭제하거나 변경하지는 않는다.
git init을 실행하기 전에 현재 위치를 확인하는 습관이 중요하다. 상위 폴더에서 실수로 실행하면 의도보다 넓은 범위의 파일이 하나의 저장소에 포함될 수 있다.
기존 원격 저장소 내려받기
이미 서버에 있는 프로젝트는 clone한다.
git clone https://git.example.com/team/sample.git
cd sample
git status
git remote -v
git clone은 파일만 내려받는 명령이 아니다. 커밋 이력과 원격 추적 정보까지 복제하고, 원격 저장소를 일반적으로 origin이라는 이름으로 등록한다. clone한 폴더 안에서 다시 git init할 필요는 없다.
비공개 저장소 주소에 실제 토큰을 포함하지 않는다.
https://사용자명:실제토큰@git.example.com/team/sample.git
이런 URL은 셸 기록, 로그, 화면 캡처나 프로세스 정보에 남을 수 있다. 토큰이 노출됐다면 저장소에서 문자열만 지우는 것으로 끝내지 말고 즉시 폐기·재발급한다.
4. 첫 커밋 전에 .gitignore 만들기
빌드 결과물, 내려받은 의존성, 운영체제 임시 파일과 비밀 설정은 보통 Git으로 추적하지 않는다. 프로젝트 루트의 .gitignore에 패턴을 작성한다.
node_modules/
dist/
.env
.DS_Store
*.log
.gitignore 자체는 팀과 공유할 프로젝트 설정이므로 첫 커밋에 포함한다.
git add .gitignore
git status
프로젝트 종류에 맞지 않는 패턴을 무조건 복사하지는 않는다. 예를 들어 빌드 결과물을 배포 저장소에서 직접 관리하는 팀도 있으므로 저장소 정책을 먼저 확인한다.
.env, 인증서 개인키, 클라우드 키, API 토큰, 데이터베이스 비밀번호는 .gitignore에 추가하는 것과 별개로 안전한 비밀 저장소에서 관리한다.
이미 추적 중인 파일에는 .gitignore가 소급 적용되지 않는다. 로컬 파일은 남기고 Git 추적만 중단해야 한다면 다음처럼 처리할 수 있다.
git rm --cached .env
git commit -m "chore: 환경 설정 파일 추적 제외"
단, 비밀 값이 한 번이라도 커밋됐다면 이력에 남아 있을 수 있다. 키를 즉시 폐기·재발급하고, 이력 정리가 필요하다면 공동 작업자와 영향 범위를 확인한 뒤 별도 절차로 진행한다.
5. 가장 자주 쓰는 기록 루틴: status → add → commit
Git 작업에서 가장 자주 반복하는 흐름이다. 예를 들어 README.md를 수정했다면 다음 순서로 확인하고 기록한다.
git status
git diff
git add README.md
git diff --staged
git commit -m "docs: README에 실행 방법 추가"
git status: 현재 상태 확인
git status
git status --short
git status는 수정된 파일, 스테이징된 파일, 아직 추적하지 않는 파일과 현재 브랜치를 보여 준다. 작업 전후와 오류 발생 직후에 가장 먼저 실행할 명령이다.
--short는 상태를 간단한 기호로 보여 준다. 처음에는 기본 출력을 읽는 데 익숙해진 뒤 사용해도 된다.
git diff: 실제 변경 내용 확인
git diff
git diff --staged
git diff HEAD
git diff: 아직 스테이징하지 않은 변경을 확인한다.git diff --staged: 다음 커밋에 실제로 들어갈 변경을 확인한다.git diff HEAD: 마지막 커밋 이후의 스테이징·비 스테이징 변경을 함께 확인한다.
status가 어떤 파일이 바뀌었는지를 보여 준다면 diff는 파일 안의 어느 줄이 바뀌었는지를 보여 준다.
git add: 다음 커밋에 넣을 변경 선택
git add README.md
git add src/
git add -p
git add는 파일을 영구 저장하는 명령이 아니라 현재 내용을 스테이징 영역에 복사해 다음 커밋에 포함하도록 선택하는 명령이다. git add 후 같은 파일을 다시 수정하면 나중에 수정한 내용은 자동으로 스테이징되지 않으므로 다시 확인해야 한다.
git add .는 현재 폴더 아래의 변경을 한꺼번에 스테이징한다. 편리하지만 디버그 로그나 비밀 파일까지 포함할 수 있으므로 실행 뒤 반드시 git status와 git diff --staged를 확인한다.
git add -p는 변경 덩어리별로 포함 여부를 고를 수 있어 서로 다른 목적의 수정을 작은 커밋으로 나눌 때 유용하다.
git commit: 선택한 변경 기록
git commit -m "feat: 로그인 입력 검증 추가"
git commit은 스테이징된 내용만 새 커밋으로 기록한다. 커밋 메시지는 무엇을 했는지만 적기보다 변경 목적이 드러나도록 작성한다.
나쁜 예: 수정, 작업, test
좋은 예: fix: 빈 이메일 로그인 요청 차단
git commit -am "메시지"는 이미 추적 중인 파일의 수정과 삭제를 스테이징해 커밋하지만, 새로 만든 미추적 파일은 포함하지 않는다. 초보 단계에서는 status → add → diff --staged → commit 순서를 명시적으로 밟는 편이 안전하다.
6. 커밋 이력과 특정 변경 확인하기
간단한 이력은 다음처럼 본다.
git log --oneline
git log --oneline --graph --decorate --all
git show HEAD
git log --oneline: 커밋을 한 줄씩 표시한다.--graph: 브랜치가 갈라지고 합쳐진 흐름을 간단한 그래프로 표시한다.--decorate: 브랜치와 태그 이름을 함께 보여 준다.--all: 현재 브랜치뿐 아니라 다른 로컬·원격 추적 브랜치도 포함한다.git show HEAD: 현재 브랜치의 최신 커밋 내용을 보여 준다.
특정 커밋은 로그에 표시된 해시의 구분 가능한 앞부분으로 조회할 수 있다.
git show a1b2c3d
로그가 페이지 형태로 열렸다면 q를 눌러 종료한다.
7. 브랜치로 작업 분리하기
기능 개발이나 버그 수정은 기본 브랜치에서 바로 진행하기보다 별도 브랜치를 만드는 편이 좋다.
git switch main
git switch -c feature/login
git branch
git branch: 로컬 브랜치 목록을 확인한다.git switch main: 기존main브랜치로 전환한다.git switch -c feature/login: 새 브랜치를 만들고 바로 전환한다.
git branch feature/login은 브랜치만 만들고 현재 브랜치를 전환하지 않는다. 명령 뒤 git status 또는 git branch --show-current로 현재 작업 위치를 확인한다.
기능을 구현한 뒤 해당 브랜치에서 커밋한다.
git status
git add src/
git diff --staged
git commit -m "feat: 로그인 입력 검증 추가"
로컬에서 병합할 때는 어느 브랜치가 결과를 받을지 먼저 확인한다. 다음 명령은 feature/login의 변경을 main에 합친다.
git switch main
git merge feature/login
git branch -d feature/login
git branch -d는 대상 브랜치가 현재 HEAD 또는 설정된 upstream에 완전히 병합되지 않았다면 삭제를 거부한다. -D는 강제로 삭제하므로 이유를 확인하지 않은 채 사용하지 않는다.
기존 자료에서 많이 보이는 git checkout도 여전히 유효하다. 다만 브랜치 전환과 파일 복원이라는 서로 다른 역할을 함께 수행하므로, 처음 배울 때는 목적이 분명한 git switch와 git restore를 우선 사용하는 편이 이해하기 쉽다.
8. 원격 저장소 연결과 fetch·pull·push
로컬 저장소에 원격 주소 등록하기
새 로컬 저장소를 서버의 빈 저장소와 연결한다.
git remote add origin https://git.example.com/team/sample.git
git remote -v
git push -u origin main
origin은 첫 원격 저장소에 관례적으로 붙이는 이름이지 예약어는 아니다. -u는 현재 로컬 브랜치와 원격 브랜치의 upstream 관계를 설정한다. 이후에는 원격과 브랜치가 명확하면 인자 없는 git push와 git pull을 사용할 수 있다.
원격 변경을 먼저 확인하기
fetch는 원격 커밋과 참조를 가져오지만 현재 작업 브랜치에 자동으로 합치지 않는다.
git fetch origin
git log --oneline --graph --decorate --all
git diff main..origin/main
원격 변경을 확인한 뒤 현재 main이 원격보다 뒤처지기만 한 상태라면, 방금 확인한 origin/main으로 fast-forward만 허용해 동기화할 수 있다.
git switch main
git merge --ff-only origin/main
검토 과정이 필요 없다면 git fetch와 git merge 대신 git pull --ff-only origin main 한 번으로 같은 종류의 동기화를 수행할 수 있다. git pull은 내부적으로 원격 변경을 fetch한 뒤 현재 브랜치에 통합한다. --ff-only는 별도 병합 커밋이나 이력 재작성이 필요한 상황에서 자동 진행하지 않고 멈춘다. 팀에 따라 merge 방식의 --no-rebase 또는 rebase 방식의 --rebase를 사용할 수 있으므로 프로젝트 규칙을 따른다.
로컬 커밋을 원격에 보내기
git push
기능 브랜치를 처음 올린다면 upstream을 함께 설정한다.
git push -u origin feature/login
공유 저장소에서는 기능 브랜치를 원격에 올리고 Pull Request나 Merge Request로 검토한 뒤 기본 브랜치에 병합하는 방식을 많이 사용한다.
원격 저장소 연결 자체가 실패한다면 Git 명령을 반복하기보다 DNS, 포트, HTTPS 인증과 SSH 키를 단계별로 구분해야 한다. 관련 진단 절차는 GitLab git clone 연결 오류 해결: 내부 IP·포트·HTTPS·SSH 점검 순서에서 확인할 수 있다.
9. 병합 충돌이 발생했을 때
서로 다른 브랜치에서 같은 부분을 다르게 수정하면 Git이 어느 내용을 남길지 자동으로 결정하지 못할 수 있다. 먼저 상태를 확인한다.
git status
충돌 파일에는 다음과 비슷한 표식이 들어간다.
<<<<<<< HEAD
현재 브랜치의 내용
=======
병합하려는 브랜치의 내용
>>>>>>> feature/login
두 변경의 의도를 확인해 최종 코드를 직접 만들고 충돌 표식을 모두 제거한다. 테스트를 수행한 뒤 해결된 파일을 스테이징하고 병합을 계속한다.
git add src/LoginForm.ts
git merge --continue
병합을 취소해야 한다면 다음 명령을 사용한다.
git merge --abort
병합 전 작업 디렉터리가 깨끗해야 취소와 복구가 단순해진다. 미커밋 변경이 있는 상태에서 병합하면 --abort가 원래 상태를 완전히 복원하지 못할 수 있으므로 먼저 커밋하거나 stash하고 진행한다.
충돌은 오류라기보다 Git이 사람의 판단을 요청하는 상태다. 두 내용 중 하나를 무조건 지우지 말고 코드의 의도, 호출 관계와 테스트 결과를 확인한다.
10. 작업 중인 변경을 잠시 보관하는 stash
아직 커밋하기 어려운 변경이 있는데 다른 브랜치로 잠시 이동해야 한다면 stash를 사용할 수 있다.
git stash push -m "로그인 화면 작업 중"
git stash list
git switch main
다시 돌아와 적용한다.
git switch feature/login
git stash pop
git stash apply는 적용 후에도 보관 항목을 남기고, git stash pop은 성공적으로 적용되면 해당 항목을 제거한다. 기본 stash에는 미추적 파일이 포함되지 않으므로 필요하다면 -u 옵션을 명시한다.
git stash push -u -m "새 파일을 포함한 임시 작업"
stash는 장기 보관소나 백업이 아니다. 어떤 작업인지 메시지를 남기고 가능한 한 빨리 브랜치와 커밋으로 정리한다.
11. 실수를 안전하게 되돌리는 방법
되돌리기 명령은 대상이 작업 파일인지, 스테이징인지, 커밋 이력인지에 따라 다르다. 실행 전에 git status와 git diff로 잃게 될 내용을 확인한다.
스테이징만 취소하고 파일 수정은 유지
git restore --staged README.md
git status
restore --staged는 다음 커밋 대상에서 파일을 빼지만 작업 디렉터리의 수정 내용은 유지한다.
첫 커밋이 아직 없는 빈 저장소에서는 기준이 될 HEAD가 없어 위 명령이 실패할 수 있다. 처음 추가한 파일의 스테이징만 취소할 때는 작업 파일을 남기는 다음 명령을 사용한다.
git rm --cached -- README.md
스테이징하지 않은 작업 파일 수정 폐기
git diff README.md
git restore README.md
git restore README.md는 스테이징되지 않은 작업 파일 변경을 덮어쓴다. 폐기한 미커밋 내용은 Git으로 복구하기 어려우므로 diff를 확인한 뒤 실행한다.
이전 커밋이 있는 저장소에서 스테이징한 변경과 이후 작업 파일 변경을 모두 HEAD 상태로 덮어써야 한다면 다음 명령을 사용할 수 있다. 두 영역의 미커밋 변경을 함께 잃으므로 백업이나 별도 브랜치가 필요하지 않은지 확인한 뒤 실행한다.
git restore --source=HEAD --staged --worktree README.md
이미 공유한 커밋을 취소
git log --oneline
git revert <커밋-해시>
git revert는 기존 커밋을 삭제하지 않고 반대 변경을 담은 새 커밋을 만든다. 다른 사람이 이미 내려받았을 수 있는 공유 브랜치에서는 과거 이력을 이동시키는 reset보다 안전하다.
revert 도중 충돌이 발생하면 파일을 해결하고 스테이징한 뒤 계속한다. 취소하면 revert 시작 전 상태로 돌아간다.
git add <충돌을-해결한-파일>
git revert --continue
# revert 전체 취소
git revert --abort
reset --hard와 강제 푸시는 왜 조심해야 하나
git reset은 현재 브랜치가 가리키는 커밋을 이동시킬 수 있다. 특히 git reset --hard는 브랜치, 스테이징 영역과 작업 파일을 함께 맞추면서 미커밋 변경을 버릴 수 있다.
git push --force는 원격 이력을 덮어써 다른 사람의 커밋을 사라진 것처럼 만들 수 있다. 복구 가능성을 확인하지 않은 상태에서 push 거절을 해결하려고 사용하지 않는다. 공유 이력 재작성이 꼭 필요한 팀 작업이라면 영향 범위를 합의하고 원격 상태를 확인한 뒤 --force-with-lease를 검토하되, 이 옵션도 무조건 안전한 것은 아니다.
12. 초보자가 자주 만나는 오류
fatal: not a git repository
Git 저장소가 아닌 폴더에서 명령을 실행했다는 뜻이다. 저장소를 다시 만들기 전에 현재 위치와 상위 경로를 확인한다.
pwd
git status
Windows PowerShell에서는 pwd 대신 Get-Location도 사용할 수 있다.
Please tell me who you are
커밋 작성자 정보가 설정되지 않았다. user.name과 user.email을 설정하고 적용 범위를 확인한다.
git config user.name
git config user.email
src refspec main does not match any
아직 첫 커밋이 없거나 현재 브랜치 이름이 main이 아닐 수 있다.
git status
git branch --show-current
git log --oneline
상태를 확인한 뒤 첫 커밋을 만들거나 실제 브랜치 이름으로 push한다.
non-fast-forward 또는 push rejected
원격에 로컬이 모르는 커밋이 있거나 원격 이력과 로컬 이력이 갈라진 상태일 수 있다. 즉시 강제 푸시하지 말고 원격 상태를 가져와 비교한다.
git fetch origin
git log --oneline --graph --decorate --all
git status
그다음 팀 정책에 맞춰 merge 또는 rebase로 통합하고 테스트한 뒤 push한다.
Permission denied (publickey) 또는 인증 실패
SSH 공개키 등록, 사용 중인 개인키, SSH 포트와 저장소 권한을 확인한다. HTTPS에서는 계정 비밀번호 대신 토큰을 요구하는 서비스가 있으므로 해당 호스팅 서비스의 공식 인증 방법을 따른다. 인증서 검증을 끄거나 토큰을 URL에 넣는 방식으로 우회하지 않는다.
13. 10분 동안 따라 하는 기본 실습
빈 폴더에서 시작한다.
mkdir git-practice
cd git-practice
git init -b main
편집기로 README.md를 만들고 간단한 설명을 한 줄 작성한 뒤 상태를 확인한다.
git status
git add README.md
git diff --staged
git commit -m "docs: 첫 README 작성"
새 문서 브랜치를 만든다.
git switch -c docs/usage
README.md에 사용법을 추가하고 다시 커밋한다.
git status
git diff
git add README.md
git commit -m "docs: 사용법 추가"
두 브랜치의 이력을 확인하고 main에 병합한다.
git log --oneline --graph --decorate --all
git switch main
git merge docs/usage
git branch -d docs/usage
마지막으로 상태가 깨끗한지 확인한다.
git status
이 실습만 반복해도 저장소 생성, 상태 확인, 스테이징, 커밋, 브랜치와 병합이라는 핵심 흐름을 익힐 수 있다.
14. 매일 사용하는 Git 작업 순서
협업 저장소에서 기능 작업을 시작할 때는 다음 순서가 실용적이다.
git switch main
git status
git fetch origin
git merge --ff-only origin/main
git switch -c feature/my-task
작업 중에는 작은 단위로 확인하고 커밋한다.
git status
git diff
git add -p
git diff --staged
git commit -m "feat: 작업 목적을 설명"
원격에 기능 브랜치를 올린다.
git push -u origin feature/my-task
팀의 Pull Request 또는 Merge Request에서 검토하고 병합한다. 기본 브랜치를 직접 push하도록 허용하는 저장소도 있지만, 보호 브랜치와 리뷰 정책이 있다면 그 규칙을 우선한다.
15. 목적별 핵심 명령어 모음
저장소 시작
git init -b main: 현재 폴더에서main브랜치로 새 저장소 시작git clone <URL>: 원격 저장소와 이력을 새 폴더에 복제
상태와 변경 확인
git status: 현재 브랜치와 변경 상태 확인git diff: 스테이징 전 변경 확인git diff --staged: 다음 커밋 내용 확인git log --oneline --graph --decorate --all: 전체 브랜치 이력 확인
변경 기록
git add <경로>: 다음 커밋에 넣을 변경 선택git add -p: 변경 덩어리별 선택git commit -m "메시지": 스테이징된 변경 커밋
브랜치 작업
git branch: 로컬 브랜치 목록 확인git switch <브랜치>: 브랜치 전환git switch -c <브랜치>: 브랜치 생성과 전환git merge <브랜치>: 지정 브랜치를 현재 브랜치에 병합
원격 협업
git remote -v: 원격 저장소 주소 확인git fetch origin: 원격 이력만 가져와 확인git pull --ff-only: fast-forward 가능한 경우에만 동기화git push: 로컬 커밋을 연결된 원격 브랜치로 전송
안전한 정리와 복구
git restore --staged <파일>: 스테이징만 취소git restore <파일>: 미커밋 파일 변경 폐기git revert <커밋>: 반대 변경을 새 커밋으로 기록git stash push -m "설명": 작업 중 변경 임시 보관
자주 묻는 질문
git add .과 git commit만 기억하면 충분한가
기록은 가능하지만 무엇이 커밋되는지 놓치기 쉽다. 최소한 git status와 git diff --staged를 사이에 넣어 의도하지 않은 파일과 비밀 값이 포함되지 않았는지 확인한다.
git fetch와 git pull의 차이는 무엇인가
fetch는 원격 이력과 참조만 가져와 현재 브랜치를 바꾸지 않는다. pull은 fetch한 뒤 현재 브랜치에 통합한다. 원격 변경을 먼저 검토하고 싶다면 fetch가 적합하다.
커밋하면 서버에도 바로 올라가는가
아니다. commit은 로컬 저장소에 기록한다. 원격 저장소에 보내려면 push가 필요하다.
브랜치를 바꾸면 파일도 바뀌는가
그렇다. git switch는 해당 브랜치가 가리키는 파일 상태로 작업 디렉터리를 전환한다. 미커밋 변경과 충돌할 수 있으므로 먼저 git status를 확인한다.
모든 명령어를 외워야 하는가
그럴 필요 없다. 처음에는 status, diff, add, commit, switch, fetch, pull --ff-only, push의 역할을 익히고, 위험한 상황에서는 실행 전 공식 문서의 옵션과 현재 상태를 확인한다.
마무리
Git의 핵심은 명령어를 많이 외우는 것이 아니라 변경이 현재 어느 단계에 있는지 확인하는 것이다. 작업 전후에 git status를 실행하고, git diff와 git diff --staged로 실제 내용을 검토한 뒤 하나의 목적을 작은 커밋으로 남기면 대부분의 실수를 줄일 수 있다.
원격 이력이 다르다고 바로 강제 푸시하지 않고 fetch로 차이를 살펴보며, 공유된 커밋은 revert로 되돌리는 습관도 중요하다. 이 기본 흐름이 익숙해진 뒤 rebase, reflog, signed commit, tag와 고급 브랜치 전략을 학습하면 된다.
직접 재현한 환경과 결과
이 글의 핵심 명령 흐름은 2026년 8월 29일 별도의 삭제 가능한 임시 저장소에서 다시 실행했다. 실제 프로젝트나 운영 저장소에는 영향을 주지 않았고, 작성자 정보도 .invalid 예시 주소로 해당 저장소에만 설정했다.
- 환경: Ubuntu 24.04.3 LTS, x86_64, Linux 6.18.35
- Git: 2.51.1
- 검증한 흐름:
init → status → add → diff --staged → commit → switch → fast-forward merge → branch -d - 원격 검증: 로컬 bare 저장소를
origin으로 사용해push -u, 두 번째 clone의 push,fetch,merge --ff-only를 확인 - 제외 범위: 실제 GitHub·GitLab·Gitea의 HTTPS 토큰, SSH 키, 보호 브랜치 권한
$ git --version
git version 2.51.1
$ git status --short
?? README.md
$ git diff --staged --stat
README.md | 3 +++
1 file changed, 3 insertions(+)
$ git commit -m "docs: add validation README"
[main (root-commit) 253ae25] docs: add validation README
1 file changed, 3 insertions(+)
create mode 100644 README.md
$ git switch -c docs/usage
Switched to a new branch 'docs/usage'
$ git merge --ff-only docs/usage
Updating 253ae25..05b114c
Fast-forward
README.md | 4 ++++
1 file changed, 4 insertions(+)
$ git push -u origin main
To ../remote.git
* [new branch] main -> main
branch 'main' set up to track 'origin/main'.
두 번째 clone에서 새 커밋을 push한 뒤 원래 저장소가 한 커밋 뒤처진 상태도 재현했다.
$ git fetch origin
From ../remote
05b114c..f37ff7f main -> origin/main
$ git status --short --branch
## main...origin/main [behind 1]
$ git merge --ff-only origin/main
Updating 05b114c..f37ff7f
Fast-forward
$ git status --short --branch
## main...origin/main
같은 줄을 두 브랜치에서 다르게 수정했을 때 git merge는 종료 코드 1과 UU README.md를 반환했다. git merge --abort 뒤에는 작업 트리가 다시 깨끗해졌다. 커밋 해시는 저장소 내용과 실행 시점에 따라 달라진다.
