Git remote 협업: clone · fetch · pull · upstream · push rejected

핵심 원리

remote 협업에서 pull을 만능 명령처럼 쓰면 현재 branch와 원격 상태를 놓치기 쉽습니다. fetch로 원격 정보를 가져온 뒤 local과 remote의 차이를 확인하면 push rejected 같은 문제를 더 안전하게 진단할 수 있습니다.

명령을 실행하기 전에는 항상 현재 상태를 먼저 확인합니다.

git status --short
git branch --show-current
git log --oneline --decorate -5

출력 결과를 보지 않고 다음 명령을 연속으로 입력하면 무엇이 바뀌었는지 추적하기 어렵습니다. 이번 회차에서는 각 명령 뒤에 상태를 다시 확인하면서 작업 전후 차이를 기록합니다.

원격 이력을 확인한 뒤 동기화하기

git status -sb
git remote -v
git branch -vv
git fetch origin
git log --graph --oneline --decorate --all -15
git log --left-right --oneline main...origin/main

fetch는 원격 정보를 가져오지만 현재 작업 트리를 자동 병합하지 않습니다. 마지막 비교에서 왼쪽은 local에만, 오른쪽은 원격 추적 branch에만 있는 commit입니다. working tree가 깨끗하고 local main에 고유 commit이 없을 때만 다음처럼 fast-forward 동기화를 선택합니다.

git switch main
git pull --ff-only origin main
git status -sb

양쪽 이력이 갈라지면 --ff-only는 실패합니다. 이때 실패를 강제 push로 덮지 않습니다. 3편의 merge 또는 8편의 공유 여부를 고려한 rebase 중 팀 정책에 맞는 절차를 정합니다. branch의 upstream이 없다면 대상이 맞는지 확인한 뒤 git branch --set-upstream-to=origin/main main을 사용할 수 있습니다.

clone을 비교하려면 기존 프로젝트 안이 아닌 별도 상위 폴더에서 진행합니다. taskflow-peer 폴더가 이미 있으면 실행하지 않습니다. 본인 원격의 읽기 권한을 확인하고 실제 clone 주소를 입력합니다.

read -r -p "본인의 GitHub clone 주소: " TASKFLOW_REMOTE
if [ -n "$TASKFLOW_REMOTE" ] && [ ! -e taskflow-peer ]; then
  git clone "$TASKFLOW_REMOTE" taskflow-peer
else
  printf '%s\n' '주소와 새 대상 폴더를 확인하세요.'
fi

두 clone의 branch와 remote-tracking 상태를 비교합니다. push rejected를 재현하려면 본인의 연습용 원격에 한쪽 clone에서 변경을 먼저 push한 뒤 다른 clone에서 이전 상태를 기준으로 push하는 순서를 사용합니다. 이는 원격을 변경하는 선택 실습입니다. 검수 과정에서는 원격을 만들거나 push하지 않았습니다.

공식 근거: https://git-scm.com/docs/git-fetch · https://git-scm.com/docs/git-pull · https://git-scm.com/docs/git-clone · https://git-scm.com/docs/git-push

직접 확인해야 할 기준

같은 bare remote 또는 GitHub 저장소를 두 폴더에 clone하여 두 명이 작업하는 상황을 재현합니다.
A에서 push한 뒤 B에서 fetch 전후 origin/main 차이를 관찰합니다.

실습에서는 성공 명령만 기록하지 않습니다. 의도적으로 한 번 실패하거나 충돌 상황을 만들고, 오류 메시지와 현재 저장소 상태를 함께 확인합니다. Git 문제는 오류 문구만 검색하기보다 HEAD가 어디를 가리키는지, working tree와 index가 어떤 상태인지, local과 remote history가 어떻게 다른지를 먼저 확인하는 편이 안전합니다.

git status -sb
git remote -v
git fetch origin
git log --left-right --oneline main...origin/main

독립 학습 변형 과제: fetch 직후와 merge 직후를 나누어 git log --left-right --oneline main…origin/main을 확인합니다. fetch만으로 작업 파일이 바뀌지 않는지 비교합니다.

git-step-03-branch-merge

Before
- 이전 체크포인트 상태
- 현재 branch와 working tree 확인

Change
- 이번 회차의 Git 작업 수행
- status / diff / log로 변화 확인

After
- 작업 결과 검증
- 다음 회차가 이어받을 상태 저장

# git-step-04-remote-sync 문서 체크포인트

이 ZIP은 Git·GitHub 실습 안내와 관련 설정 파일을 모은 자료입니다. `.git` 이력, 실제 branch/tag/stash/worktree, 원격 저장소, 사용자 계정이나 TaskFlow 앱 전체를 포함하지 않습니다. 별도의 개발환경 과정 TaskFlow 프로젝트에서 실습 안내를 읽고 명령을 단계별로 적용하세요. 이 폴더 자체를 완성된 Git 저장소로 간주하거나 명령을 한꺼번에 실행하지 마세요.

01~13 필수 과정의 이 회차까지 문서를 누적합니다.

검증 범위는 명령 문법·설정 형식·공식 문서 및 기존 프로젝트 스크립트 대조입니다. 실제 init/commit/branch/stash/worktree/reset/rebase/merge/push/PR/Release/서명 작업을 수행했다는 기록이 아닙니다. 개인 키·토큰·비밀번호는 포함하지 않습니다.

# 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을 내려받았다는 사실만으로 실습 완료가 성립하지 않습니다.

# Git·GitHub 02 실습 안내

이 파일은 독자가 상태를 확인하며 따라갈 Markdown 문서입니다. 자동 실행 스크립트나 검수 과정에서 실행한 Git 이력 로그가 아닙니다.

## 목적별 commit을 만드는 실습

1편 이후 README.md에 서로 떨어진 두 문단을 수정합니다. 하나는 실행 방법, 다른 하나는 오타 수정으로 구분합니다. 이미 공유한 commit을 재작성하지 않도록 이 실습에서는 아직 push하지 않은 새 변경만 사용합니다.

```bash
git diff --stat
git diff -- README.md
git add -p README.md
git diff --cached
git diff -- README.md
```

대화형 질문에서 y는 현재 hunk를 staging하고 n은 남깁니다. 한 hunk에 섞였으면 s로 분할할 수 있는지 확인하고, 분할되지 않으면 편집기에서 변경을 다시 나눕니다. cached diff에 첫 목적만 남았을 때 commit하고 나머지 변경을 두 번째 commit으로 만듭니다.

```bash
git commit -m "docs: clarify TaskFlow startup"
git add README.md
git diff --cached
git commit -m "docs: correct wording"
git log --oneline -2
```

이어서 README 한 줄을 다시 수정하고 git add README.md로 stage합니다. 이 추가 변경을 다음 명령으로 index에서만 되돌립니다. 작업 트리의 수정은 남아 있는지 status와 diff로 확인합니다.

```bash
git add README.md
git restore --staged README.md
git status --short
git diff -- README.md
```

마지막 commit의 메시지만 바꾸려면 staged 변경이 없는지 확인한 다음 실행합니다. 방금 unstage한 작업 트리 수정은 이 amend에 포함되지 않고 그대로 남습니다. amend는 새 commit을 만들어 ID를 바꾸며 이미 push한 이력에는 기본 절차로 적용하지 않습니다. --no-edit도 staged 내용까지 기존 commit에 합칠 수 있습니다.

```bash
git diff --cached
git rev-parse HEAD
git commit --amend -m "docs: fix TaskFlow guide wording"
git rev-parse HEAD
git show --stat HEAD
```

.gitignore는 미추적 파일의 추가를 막는 규칙입니다. 이미 추적한 일반 파일을 추적에서 빼는 git rm --cached는 별도의 삭제 commit을 만들므로 대상과 영향을 확인해야 합니다. 비밀이 이미 공개됐다면 ignore 변경만으로 과거 이력이 사라지지 않습니다. 우선 자격증명을 폐기·교체하고 저장소 관리 절차로 대응합니다. 학습 중 실제 비밀을 만들거나 commit하지 않습니다.

공식 근거: https://git-scm.com/docs/git-add · https://git-scm.com/docs/git-restore · https://git-scm.com/docs/git-commit · https://git-scm.com/docs/gitignore

## 체크포인트 기준

git-step-02-clean-commit: 위 실습의 관찰 기준을 본인의 연습 환경에서 확인한 뒤 사용합니다. 이 ZIP을 내려받았다는 사실만으로 실습 완료가 성립하지 않습니다.

# Git·GitHub 03 실습 안내

이 파일은 독자가 상태를 확인하며 따라갈 Markdown 문서입니다. 자동 실행 스크립트나 검수 과정에서 실행한 Git 이력 로그가 아닙니다.

## fast-forward와 merge commit 비교 실습

working tree가 깨끗한지 먼저 확인합니다. 아래 학습용 branch 이름이 이미 있으면 중단하고 기존 작업을 확인합니다. 먼저 feature/a를 만들고 편집기에서 새 문서 docs/branch-a.md에 기능 설명을 작성합니다. docs 폴더가 없으면 편집기로 만듭니다.

```bash
git status --short
git switch -c feature/a
```

파일 작성 후 해당 파일만 commit하고 main으로 돌아와 병합합니다. 이 사이 main에 다른 commit을 만들지 않습니다.

```bash
git add docs/branch-a.md
git commit -m "docs: add branch A notes"
git switch main
git merge --ff-only feature/a
git log --graph --oneline --decorate -5
```

새 merge commit 없이 main이 feature/a의 끝으로 이동하는 것이 fast-forward입니다. 다음에는 같은 main에서 feature/b를 만들고 docs/branch-b.md를 작성해 commit합니다.

```bash
git switch -c feature/b
```

파일 작성 뒤 다음을 실행합니다.

```bash
git add docs/branch-b.md
git commit -m "docs: add branch B notes"
git switch main
```

main에서는 다른 파일 docs/main-notes.md를 작성해 commit합니다. 양쪽에 서로 다른 commit이 생긴 다음 feature/b를 병합합니다.

```bash
git add docs/main-notes.md
git commit -m "docs: add main notes"
git merge feature/b -m "Merge branch feature/b"
git log --graph --oneline --decorate --all -10
git show --no-patch --format='%h %p' HEAD
```

마지막 commit의 부모 ID가 두 개라면 merge commit입니다. --no-ff는 fast-forward가 가능해도 merge commit을 만들도록 선택하는 옵션이며, 이번 두 번째 예제는 이미 갈라진 이력이므로 없어도 merge commit이 생깁니다. 병합을 확인한 branch만 git branch -d로 정리할 수 있지만 삭제는 실습 완료의 필수 조건이 아닙니다.

공식 근거: https://git-scm.com/docs/git-switch · https://git-scm.com/docs/git-merge · https://git-scm.com/docs/git-branch

## 체크포인트 기준

git-step-03-branch-merge: 위 실습의 관찰 기준을 본인의 연습 환경에서 확인한 뒤 사용합니다. 이 ZIP을 내려받았다는 사실만으로 실습 완료가 성립하지 않습니다.

# Git·GitHub 04 실습 안내

이 파일은 독자가 상태를 확인하며 따라갈 Markdown 문서입니다. 자동 실행 스크립트나 검수 과정에서 실행한 Git 이력 로그가 아닙니다.

## 원격 이력을 확인한 뒤 동기화하기

origin은 저장소 주소의 별명이고 origin/main은 마지막 fetch 시점에 관찰한 원격 main입니다. 실시간 서버 상태 자체가 아닙니다. 기존 TaskFlow 저장소에서 먼저 다음을 확인합니다.

```bash
git status -sb
git remote -v
git branch -vv
git fetch origin
git log --graph --oneline --decorate --all -15
git log --left-right --oneline main...origin/main
```

fetch는 원격 정보를 가져오지만 현재 작업 트리를 자동 병합하지 않습니다. 마지막 비교에서 왼쪽은 local에만, 오른쪽은 원격 추적 branch에만 있는 commit입니다. working tree가 깨끗하고 local main에 고유 commit이 없을 때만 다음처럼 fast-forward 동기화를 선택합니다.

```bash
git switch main
git pull --ff-only origin main
git status -sb
```

양쪽 이력이 갈라지면 --ff-only는 실패합니다. 이때 실패를 강제 push로 덮지 않습니다. 3편의 merge 또는 8편의 공유 여부를 고려한 rebase 중 팀 정책에 맞는 절차를 정합니다. branch의 upstream이 없다면 대상이 맞는지 확인한 뒤 git branch --set-upstream-to=origin/main main을 사용할 수 있습니다.

clone을 비교하려면 기존 프로젝트 안이 아닌 별도 상위 폴더에서 진행합니다. taskflow-peer 폴더가 이미 있으면 실행하지 않습니다. 본인 원격의 읽기 권한을 확인하고 실제 clone 주소를 입력합니다.

```bash
read -r -p "본인의 GitHub clone 주소: " TASKFLOW_REMOTE
if [ -n "$TASKFLOW_REMOTE" ] && [ ! -e taskflow-peer ]; then
  git clone "$TASKFLOW_REMOTE" taskflow-peer
else
  printf '%s\n' '주소와 새 대상 폴더를 확인하세요.'
fi
```

두 clone의 branch와 remote-tracking 상태를 비교합니다. push rejected를 재현하려면 본인의 연습용 원격에 한쪽 clone에서 변경을 먼저 push한 뒤 다른 clone에서 이전 상태를 기준으로 push하는 순서를 사용합니다. 이는 원격을 변경하는 선택 실습입니다. 검수 과정에서는 원격을 만들거나 push하지 않았습니다.

공식 근거: https://git-scm.com/docs/git-fetch · https://git-scm.com/docs/git-pull · https://git-scm.com/docs/git-clone · https://git-scm.com/docs/git-push

## 체크포인트 기준

git-step-04-remote-sync: 위 실습의 관찰 기준을 본인의 연습 환경에서 확인한 뒤 사용합니다. 이 ZIP을 내려받았다는 사실만으로 실습 완료가 성립하지 않습니다.

git-step-04-remote-sync

다음 학습

05 Git 브랜치와 PR 충돌 해결

다음 회차로 이동하기 전에 working tree에 의도하지 않은 변경이 남아 있지 않은지 다시 확인합니다.