> ## Content Index
> Fetch the complete content index at: https://mlog.me/llms.txt
> Use this file to discover other available public pages before exploring further.

# Git 기본 명령어 사용법: init부터 branch·pull·push까지
- URL: https://mlog.me/git-basic-commands-beginner-guide/
- Published: 2026-08-28T07:35:42.000Z
- Updated: 2026-09-08T22:25:08.000Z
- Description: Git 명령어를 외우기보다 실제 작업 흐름으로 익혀보세요. 저장소 생성부터 커밋, 브랜치, 원격 저장소, 충돌 해결과 안전한 되돌리기까지 한 번에 정리했습니다.
- Author: mLog
- Tags: 개발, Git·GitLab, #Git

> **3줄 요약**Git은 파일의 변경 이력을 커밋 단위로 기록하고, 여러 작업을 브랜치로 분리할 수 있는 분산 버전 관리 시스템이다.가장 중요한 기본 흐름은 `상태 확인 → 변경 선택 → 커밋`이며, 명령으로는 `git status → git add → git commit`이다.원격 저장소와 협업할 때는 강제 푸시부터 시도하지 말고 `git fetch`로 차이를 확인한 뒤 팀 정책에 맞게 병합하고 `git push`한다.

임시 저장소에서 두 번째 `clone`의 새 커밋을 `push`한 뒤 원래 저장소에서 `git fetch`를 실행하고, `git status`로 ‘한 커밋 뒤처짐’ 상태를 확인했다. 두 브랜치에서 같은 줄을 다르게 수정했을 때는 병합 충돌이 났고, `git merge --abort` 뒤에는 작업 트리가 다시 깨끗해졌다. 이 글은 이렇게 직접 확인한 상태 변화를 따라 Git 명령을 연결해 설명한다.

재현은 2026년 8월 29일 Ubuntu 24.04.3·Git 2.51.1에서 삭제 가능한 임시 저장소와 로컬 `bare` 원격 저장소로 진행했다. 실제 프로젝트에는 영향을 주지 않았으며, GitHub·GitLab·Gitea의 HTTPS 토큰·SSH 인증과 보호 브랜치 정책은 검증 범위에 포함하지 않았다. 상세 환경과 출력은 마지막의 ‘직접 재현한 환경과 결과’에 남겼다.

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 버전을 먼저 확인한다.

```bash
git --version

```

커밋에 기록할 이름과 이메일을 설정한다.

```bash
git config --global user.name "Hong Gildong"
git config --global user.email "you@example.com"
git config --global init.defaultBranch main

```

현재 전역 설정은 다음 명령으로 확인한다.

```bash
git config --global --list

```

`user.name`과 `user.email`은 GitHub나 GitLab에 로그인하는 아이디와 비밀번호가 아니다. 커밋의 작성자 정보로 남으며 공개 저장소에서는 외부에 보일 수 있다. 회사와 개인 프로젝트의 이메일 정책이 다르다면 저장소 폴더에서 `--global`을 빼고 해당 저장소에만 별도로 설정한다.

```bash
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 저장소를 시작한다.

```bash
mkdir git-practice
cd git-practice
git init -b main
git status

```

`git init -b main`은 현재 폴더에 `.git` 디렉터리를 만들고 초기 브랜치 이름을 `main`으로 지정한다. 프로젝트 파일을 삭제하거나 변경하지는 않는다.

`git init`을 실행하기 전에 현재 위치를 확인하는 습관이 중요하다. 상위 폴더에서 실수로 실행하면 의도보다 넓은 범위의 파일이 하나의 저장소에 포함될 수 있다.

### 기존 원격 저장소 내려받기

이미 서버에 있는 프로젝트는 `clone`한다.

```bash
git clone https://git.example.com/team/sample.git
cd sample
git status
git remote -v

```

`git clone`은 파일만 내려받는 명령이 아니다. 커밋 이력과 원격 추적 정보까지 복제하고, 원격 저장소를 일반적으로 `origin`이라는 이름으로 등록한다. clone한 폴더 안에서 다시 `git init`할 필요는 없다.

비공개 저장소 주소에 실제 토큰을 포함하지 않는다.

```text
https://사용자명:실제토큰@git.example.com/team/sample.git

```

이런 URL은 셸 기록, 로그, 화면 캡처나 프로세스 정보에 남을 수 있다. 토큰이 노출됐다면 저장소에서 문자열만 지우는 것으로 끝내지 말고 즉시 폐기·재발급한다.

## 4\. 첫 커밋 전에 `.gitignore` 만들기

빌드 결과물, 내려받은 의존성, 운영체제 임시 파일과 비밀 설정은 보통 Git으로 추적하지 않는다. 프로젝트 루트의 `.gitignore`에 패턴을 작성한다.

```gitignore
node_modules/
dist/
.env
.DS_Store
*.log

```

`.gitignore` 자체는 팀과 공유할 프로젝트 설정이므로 첫 커밋에 포함한다.

```bash
git add .gitignore
git status

```

프로젝트 종류에 맞지 않는 패턴을 무조건 복사하지는 않는다. 예를 들어 빌드 결과물을 배포 저장소에서 직접 관리하는 팀도 있으므로 저장소 정책을 먼저 확인한다.

`.env`, 인증서 개인키, 클라우드 키, API 토큰, 데이터베이스 비밀번호는 `.gitignore`에 추가하는 것과 별개로 안전한 비밀 저장소에서 관리한다.

이미 추적 중인 파일에는 `.gitignore`가 소급 적용되지 않는다. 로컬 파일은 남기고 Git 추적만 중단해야 한다면 다음처럼 처리할 수 있다.

```bash
git rm --cached .env
git commit -m "chore: 환경 설정 파일 추적 제외"

```

단, 비밀 값이 한 번이라도 커밋됐다면 이력에 남아 있을 수 있다. 키를 즉시 폐기·재발급하고, 이력 정리가 필요하다면 공동 작업자와 영향 범위를 확인한 뒤 별도 절차로 진행한다.

## 5\. 가장 자주 쓰는 기록 루틴: `status → add → commit`

Git 작업에서 가장 자주 반복하는 흐름이다. 예를 들어 `README.md`를 수정했다면 다음 순서로 확인하고 기록한다.

```bash
git status
git diff
git add README.md
git diff --staged
git commit -m "docs: README에 실행 방법 추가"

```

### `git status`: 현재 상태 확인

```bash
git status
git status --short

```

`git status`는 수정된 파일, 스테이징된 파일, 아직 추적하지 않는 파일과 현재 브랜치를 보여 준다. 작업 전후와 오류 발생 직후에 가장 먼저 실행할 명령이다.

`--short`는 상태를 간단한 기호로 보여 준다. 처음에는 기본 출력을 읽는 데 익숙해진 뒤 사용해도 된다.

### `git diff`: 실제 변경 내용 확인

```bash
git diff
git diff --staged
git diff HEAD

```

- `git diff`: 아직 스테이징하지 않은 변경을 확인한다.
- `git diff --staged`: 다음 커밋에 실제로 들어갈 변경을 확인한다.
- `git diff HEAD`: 마지막 커밋 이후의 스테이징·비 스테이징 변경을 함께 확인한다.

`status`가 어떤 파일이 바뀌었는지를 보여 준다면 `diff`는 파일 안의 어느 줄이 바뀌었는지를 보여 준다.

### `git add`: 다음 커밋에 넣을 변경 선택

```bash
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`: 선택한 변경 기록

```bash
git commit -m "feat: 로그인 입력 검증 추가"

```

`git commit`은 스테이징된 내용만 새 커밋으로 기록한다. 커밋 메시지는 무엇을 했는지만 적기보다 변경 목적이 드러나도록 작성한다.

```text
나쁜 예: 수정, 작업, test
좋은 예: fix: 빈 이메일 로그인 요청 차단

```

`git commit -am "메시지"`는 이미 추적 중인 파일의 수정과 삭제를 스테이징해 커밋하지만, 새로 만든 미추적 파일은 포함하지 않는다. 초보 단계에서는 `status → add → diff --staged → commit` 순서를 명시적으로 밟는 편이 안전하다.

## 6\. 커밋 이력과 특정 변경 확인하기

간단한 이력은 다음처럼 본다.

```bash
git log --oneline
git log --oneline --graph --decorate --all
git show HEAD

```

- `git log --oneline`: 커밋을 한 줄씩 표시한다.
- `--graph`: 브랜치가 갈라지고 합쳐진 흐름을 간단한 그래프로 표시한다.
- `--decorate`: 브랜치와 태그 이름을 함께 보여 준다.
- `--all`: 현재 브랜치뿐 아니라 다른 로컬·원격 추적 브랜치도 포함한다.
- `git show HEAD`: 현재 브랜치의 최신 커밋 내용을 보여 준다.

특정 커밋은 로그에 표시된 해시의 구분 가능한 앞부분으로 조회할 수 있다.

```bash
git show a1b2c3d

```

로그가 페이지 형태로 열렸다면 `q`를 눌러 종료한다.

## 7\. 브랜치로 작업 분리하기

기능 개발이나 버그 수정은 기본 브랜치에서 바로 진행하기보다 별도 브랜치를 만드는 편이 좋다.

```bash
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`로 현재 작업 위치를 확인한다.

기능을 구현한 뒤 해당 브랜치에서 커밋한다.

```bash
git status
git add src/
git diff --staged
git commit -m "feat: 로그인 입력 검증 추가"

```

로컬에서 병합할 때는 **어느 브랜치가 결과를 받을지** 먼저 확인한다. 다음 명령은 `feature/login`의 변경을 `main`에 합친다.

```bash
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`

### 로컬 저장소에 원격 주소 등록하기

새 로컬 저장소를 서버의 빈 저장소와 연결한다.

```bash
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`는 원격 커밋과 참조를 가져오지만 현재 작업 브랜치에 자동으로 합치지 않는다.

```bash
git fetch origin
git log --oneline --graph --decorate --all
git diff main..origin/main

```

원격 변경을 확인한 뒤 현재 `main`이 원격보다 뒤처지기만 한 상태라면, 방금 확인한 `origin/main`으로 fast-forward만 허용해 동기화할 수 있다.

```bash
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`를 사용할 수 있으므로 프로젝트 규칙을 따른다.

### 로컬 커밋을 원격에 보내기

```bash
git push

```

기능 브랜치를 처음 올린다면 upstream을 함께 설정한다.

```bash
git push -u origin feature/login

```

공유 저장소에서는 기능 브랜치를 원격에 올리고 Pull Request나 Merge Request로 검토한 뒤 기본 브랜치에 병합하는 방식을 많이 사용한다.

원격 저장소 연결 자체가 실패한다면 Git 명령을 반복하기보다 DNS, 포트, HTTPS 인증과 SSH 키를 단계별로 구분해야 한다. 관련 진단 절차는 [GitLab git clone 연결 오류 해결: 내부 IP·포트·HTTPS·SSH 점검 순서](https://mlog.me/gitlab-git-clone-connection-error-private-ip-port/)에서 확인할 수 있다.

## 9\. 병합 충돌이 발생했을 때

서로 다른 브랜치에서 같은 부분을 다르게 수정하면 Git이 어느 내용을 남길지 자동으로 결정하지 못할 수 있다. 먼저 상태를 확인한다.

```bash
git status

```

충돌 파일에는 다음과 비슷한 표식이 들어간다.

```text
<<<<<<< HEAD
현재 브랜치의 내용
=======
병합하려는 브랜치의 내용
>>>>>>> feature/login

```

두 변경의 의도를 확인해 최종 코드를 직접 만들고 충돌 표식을 모두 제거한다. 테스트를 수행한 뒤 해결된 파일을 스테이징하고 병합을 계속한다.

```bash
git add src/LoginForm.ts
git merge --continue

```

병합을 취소해야 한다면 다음 명령을 사용한다.

```bash
git merge --abort

```

병합 전 작업 디렉터리가 깨끗해야 취소와 복구가 단순해진다. 미커밋 변경이 있는 상태에서 병합하면 `--abort`가 원래 상태를 완전히 복원하지 못할 수 있으므로 먼저 커밋하거나 stash하고 진행한다.

충돌은 오류라기보다 Git이 사람의 판단을 요청하는 상태다. 두 내용 중 하나를 무조건 지우지 말고 코드의 의도, 호출 관계와 테스트 결과를 확인한다.

## 10\. 작업 중인 변경을 잠시 보관하는 `stash`

아직 커밋하기 어려운 변경이 있는데 다른 브랜치로 잠시 이동해야 한다면 stash를 사용할 수 있다.

```bash
git stash push -m "로그인 화면 작업 중"
git stash list
git switch main

```

다시 돌아와 적용한다.

```bash
git switch feature/login
git stash pop

```

`git stash apply`는 적용 후에도 보관 항목을 남기고, `git stash pop`은 성공적으로 적용되면 해당 항목을 제거한다. 기본 stash에는 미추적 파일이 포함되지 않으므로 필요하다면 `-u` 옵션을 명시한다.

```bash
git stash push -u -m "새 파일을 포함한 임시 작업"

```

stash는 장기 보관소나 백업이 아니다. 어떤 작업인지 메시지를 남기고 가능한 한 빨리 브랜치와 커밋으로 정리한다.

## 11\. 실수를 안전하게 되돌리는 방법

되돌리기 명령은 대상이 **작업 파일인지, 스테이징인지, 커밋 이력인지**에 따라 다르다. 실행 전에 `git status`와 `git diff`로 잃게 될 내용을 확인한다.

### 스테이징만 취소하고 파일 수정은 유지

```bash
git restore --staged README.md
git status

```

`restore --staged`는 다음 커밋 대상에서 파일을 빼지만 작업 디렉터리의 수정 내용은 유지한다.

첫 커밋이 아직 없는 빈 저장소에서는 기준이 될 `HEAD`가 없어 위 명령이 실패할 수 있다. 처음 추가한 파일의 스테이징만 취소할 때는 작업 파일을 남기는 다음 명령을 사용한다.

```bash
git rm --cached -- README.md

```

### 스테이징하지 않은 작업 파일 수정 폐기

```bash
git diff README.md
git restore README.md

```

`git restore README.md`는 스테이징되지 않은 작업 파일 변경을 덮어쓴다. 폐기한 미커밋 내용은 Git으로 복구하기 어려우므로 diff를 확인한 뒤 실행한다.

이전 커밋이 있는 저장소에서 스테이징한 변경과 이후 작업 파일 변경을 모두 `HEAD` 상태로 덮어써야 한다면 다음 명령을 사용할 수 있다. 두 영역의 미커밋 변경을 함께 잃으므로 백업이나 별도 브랜치가 필요하지 않은지 확인한 뒤 실행한다.

```bash
git restore --source=HEAD --staged --worktree README.md

```

### 이미 공유한 커밋을 취소

```bash
git log --oneline
git revert <커밋-해시>

```

`git revert`는 기존 커밋을 삭제하지 않고 반대 변경을 담은 새 커밋을 만든다. 다른 사람이 이미 내려받았을 수 있는 공유 브랜치에서는 과거 이력을 이동시키는 `reset`보다 안전하다.

revert 도중 충돌이 발생하면 파일을 해결하고 스테이징한 뒤 계속한다. 취소하면 revert 시작 전 상태로 돌아간다.

```bash
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 저장소가 아닌 폴더에서 명령을 실행했다는 뜻이다. 저장소를 다시 만들기 전에 현재 위치와 상위 경로를 확인한다.

```bash
pwd
git status

```

Windows PowerShell에서는 `pwd` 대신 `Get-Location`도 사용할 수 있다.

### `Please tell me who you are`

커밋 작성자 정보가 설정되지 않았다. `user.name`과 `user.email`을 설정하고 적용 범위를 확인한다.

```bash
git config user.name
git config user.email

```

### `src refspec main does not match any`

아직 첫 커밋이 없거나 현재 브랜치 이름이 `main`이 아닐 수 있다.

```bash
git status
git branch --show-current
git log --oneline

```

상태를 확인한 뒤 첫 커밋을 만들거나 실제 브랜치 이름으로 push한다.

### `non-fast-forward` 또는 push rejected

원격에 로컬이 모르는 커밋이 있거나 원격 이력과 로컬 이력이 갈라진 상태일 수 있다. 즉시 강제 푸시하지 말고 원격 상태를 가져와 비교한다.

```bash
git fetch origin
git log --oneline --graph --decorate --all
git status

```

그다음 팀 정책에 맞춰 merge 또는 rebase로 통합하고 테스트한 뒤 push한다.

### `Permission denied (publickey)` 또는 인증 실패

SSH 공개키 등록, 사용 중인 개인키, SSH 포트와 저장소 권한을 확인한다. HTTPS에서는 계정 비밀번호 대신 토큰을 요구하는 서비스가 있으므로 해당 호스팅 서비스의 공식 인증 방법을 따른다. 인증서 검증을 끄거나 토큰을 URL에 넣는 방식으로 우회하지 않는다.

## 13\. 10분 동안 따라 하는 기본 실습

빈 폴더에서 시작한다.

```bash
mkdir git-practice
cd git-practice
git init -b main

```

편집기로 `README.md`를 만들고 간단한 설명을 한 줄 작성한 뒤 상태를 확인한다.

```bash
git status
git add README.md
git diff --staged
git commit -m "docs: 첫 README 작성"

```

새 문서 브랜치를 만든다.

```bash
git switch -c docs/usage

```

`README.md`에 사용법을 추가하고 다시 커밋한다.

```bash
git status
git diff
git add README.md
git commit -m "docs: 사용법 추가"

```

두 브랜치의 이력을 확인하고 `main`에 병합한다.

```bash
git log --oneline --graph --decorate --all
git switch main
git merge docs/usage
git branch -d docs/usage

```

마지막으로 상태가 깨끗한지 확인한다.

```bash
git status

```

이 실습만 반복해도 저장소 생성, 상태 확인, 스테이징, 커밋, 브랜치와 병합이라는 핵심 흐름을 익힐 수 있다.

## 14\. 매일 사용하는 Git 작업 순서

협업 저장소에서 기능 작업을 시작할 때는 다음 순서가 실용적이다.

```bash
git switch main
git status
git fetch origin
git merge --ff-only origin/main
git switch -c feature/my-task

```

작업 중에는 작은 단위로 확인하고 커밋한다.

```bash
git status
git diff
git add -p
git diff --staged
git commit -m "feat: 작업 목적을 설명"

```

원격에 기능 브랜치를 올린다.

```bash
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 키, 보호 브랜치 권한

```text
$ 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한 뒤 원래 저장소가 한 커밋 뒤처진 상태도 재현했다.

```text
$ 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` 뒤에는 작업 트리가 다시 깨끗해졌다. 커밋 해시는 저장소 내용과 실행 시점에 따라 달라진다.

## 공식 문서

- [Git 명령어 공식 레퍼런스](https://git-scm.com/docs?ref=mlog.me)
- [Pro Git 한국어판](https://git-scm.com/book/ko/v2?ref=mlog.me)
- [Git 공식 튜토리얼](https://git-scm.com/docs/gittutorial?ref=mlog.me)
- [일상적인 Git 명령 모음](https://git-scm.com/docs/giteveryday?ref=mlog.me)
- [git add 공식 문서](https://git-scm.com/docs/git-add?ref=mlog.me)
- [git switch 공식 문서](https://git-scm.com/docs/git-switch?ref=mlog.me)
- [git restore 공식 문서](https://git-scm.com/docs/git-restore?ref=mlog.me)
- [reset, restore, revert 비교](https://git-scm.com/docs/git?ref=mlog.me#%5Freset%5Frestore%5Fand%5Frevert)