[TOOL-006][기초] 원격 저장소와 Pull Request로 협업하기
페이지 정보

본문
[이번 수업]
로컬 Git 저장소를 원격과 연결해 브랜치를 주고받고, 계정 없이 Pull Request의 역할까지 이해합니다.
[선수지식]
TOOL-004의 커밋과 TOOL-005의 브랜치·병합을 알고 있어야 합니다. Git이 설치되어 있으면 됩니다.
[학습목표]
1. 로컬 저장소·원격 저장소·origin을 구분한다.
2. fetch·pull·push와 추적 브랜치의 관계를 설명한다.
3. 기능 브랜치를 올리고 Pull Request를 만드는 협업 순서를 이해한다.
[핵심개념]
원격 저장소(remote repository)는 다른 경로나 네트워크 주소로 접근하는 별도 Git 저장소입니다. 각자 만든 커밋을 공통 교환 지점에서 주고받습니다. `origin`은 clone 때 흔히 붙는 원격 이름일 뿐 고정된 서버가 아닙니다. `git remote -v`로 이름과 주소를 확인합니다.
`origin/main`은 마지막으로 확인한 원격 main 위치를 기록한 원격 추적 브랜치이며 로컬 `main`과 다릅니다. `git fetch origin`은 객체와 추적 브랜치를 갱신하지만 작업 파일에 병합하지 않습니다. `git pull`은 보통 fetch 뒤 현재 브랜치에 변경을 통합합니다.
`git push origin feature/guide`는 커밋을 보내 원격 브랜치를 갱신합니다. 첫 push에 `-u`를 쓰면 추적 대상을 기록해 이후 `git push`, `git pull`을 짧게 쓸 수 있습니다.
Pull Request(PR)는 비교(head) 브랜치의 변경을 기준(base) 브랜치에 합쳐 달라는 제안입니다. 커밋 자체가 아니며 자동 병합도 아닙니다. 차이, 설명, 리뷰, 검사 결과를 함께 확인하고 같은 기능 브랜치에 새 커밋을 push하면 PR도 갱신됩니다.
흐름은 기능 브랜치 → 커밋 → push → PR → 리뷰·검사 → 병합 → 로컬 main 갱신입니다. 필요한 승인과 검사는 저장소 규칙을 따릅니다.
[따라하기]
아래 명령은 인터넷·계정 없이 작업 파일이 없는 교환용 bare 저장소 `remote.git`을 만듭니다. 세 운영체제 터미널에서 실행할 수 있습니다.
```shell
mkdir tool006-demo
cd tool006-demo
git init --bare remote.git
git clone remote.git work
cd work
git switch -c main
git config user.name "Practice User"
git config user.email "practice@example.invalid"
echo "# Remote repository practice" > README.md
git add README.md
git commit -m "docs: add readme"
git push -u origin main
git switch -c feature/guide
echo "Pull Request practice" >> README.md
git add README.md
git commit -m "docs: add guide line"
git push -u origin feature/guide
git remote -v
git branch -vv
```
결과 끝에는 다음 형태가 보입니다.
```text
origin .../remote.git (fetch)
origin .../remote.git (push)
* feature/guide ... [origin/feature/guide] docs: add guide line
main ... [origin/main] docs: add readme
```
실제 원격에서는 안내된 HTTPS나 SSH 주소를 씁니다. 기능 브랜치를 push한 뒤 base `main`, compare `feature/guide`를 선택하고 변경 이유·검증 방법을 적어 PR을 만듭니다.
[흔한 실수]
- `origin`을 서버 자체로 생각합니다. 바꿀 수 있는 원격 이름입니다.
- fetch와 pull을 같게 봅니다. pull은 통합까지 할 수 있습니다.
- 저장소 규칙을 확인하지 않고 공유 main에 바로 push합니다.
- PR에 변경 이유, 테스트 결과, 영향 범위를 남기지 않습니다.
[보안 주의]
토큰·비밀번호를 URL, 명령줄, 커밋, PR에 넣지 마세요. 공식 자격증명 관리자나 SSH 에이전트를 쓰고 권한은 최소화합니다. push 전에 `git remote -v`, `git status`, `git diff --staged`로 대상과 내용을 확인하세요. 공유 브랜치의 강제 push를 피하고, 비밀정보가 노출되면 즉시 자격증명을 폐기·교체하고 관리자 절차를 따릅니다.
[직접 해볼 과제]
1. `feature/guide`에서 README 한 줄을 더 커밋하고 push한 뒤 `git log --oneline --all --decorate`로 로컬·원격 추적 브랜치 위치를 기록하세요.
2. 가상의 PR 설명에 변경 목적, 주요 변경, 확인 방법, 영향 범위를 각각 한 줄씩 작성하세요.
[확인문제]
1. `origin`은 Git에서 어떤 역할을 하는 이름인가요?
2. fetch와 pull의 핵심 차이는 무엇인가요?
3. PR을 만들었다고 변경이 기준 브랜치에 즉시 합쳐지지 않는 이유는 무엇인가요?
[다음 학습]
TOOL-007에서는 디버거의 중단점과 변수 관찰로 오류를 찾습니다.
[공식 참고 자료]
- Git remote 공식 문서: https://git-scm.com/docs/git-remote
- Git push 공식 문서: https://git-scm.com/docs/git-push
- Pull Request 공식 설명: https://docs.github.com/en/pull-requests/reference/pull-requests
- Pull Request 생성 공식 문서: https://docs.github.com/en/pull-requests/how-tos/create-pull-requests/creating-a-pull-request
로컬 Git 저장소를 원격과 연결해 브랜치를 주고받고, 계정 없이 Pull Request의 역할까지 이해합니다.
[선수지식]
TOOL-004의 커밋과 TOOL-005의 브랜치·병합을 알고 있어야 합니다. Git이 설치되어 있으면 됩니다.
[학습목표]
1. 로컬 저장소·원격 저장소·origin을 구분한다.
2. fetch·pull·push와 추적 브랜치의 관계를 설명한다.
3. 기능 브랜치를 올리고 Pull Request를 만드는 협업 순서를 이해한다.
[핵심개념]
원격 저장소(remote repository)는 다른 경로나 네트워크 주소로 접근하는 별도 Git 저장소입니다. 각자 만든 커밋을 공통 교환 지점에서 주고받습니다. `origin`은 clone 때 흔히 붙는 원격 이름일 뿐 고정된 서버가 아닙니다. `git remote -v`로 이름과 주소를 확인합니다.
`origin/main`은 마지막으로 확인한 원격 main 위치를 기록한 원격 추적 브랜치이며 로컬 `main`과 다릅니다. `git fetch origin`은 객체와 추적 브랜치를 갱신하지만 작업 파일에 병합하지 않습니다. `git pull`은 보통 fetch 뒤 현재 브랜치에 변경을 통합합니다.
`git push origin feature/guide`는 커밋을 보내 원격 브랜치를 갱신합니다. 첫 push에 `-u`를 쓰면 추적 대상을 기록해 이후 `git push`, `git pull`을 짧게 쓸 수 있습니다.
Pull Request(PR)는 비교(head) 브랜치의 변경을 기준(base) 브랜치에 합쳐 달라는 제안입니다. 커밋 자체가 아니며 자동 병합도 아닙니다. 차이, 설명, 리뷰, 검사 결과를 함께 확인하고 같은 기능 브랜치에 새 커밋을 push하면 PR도 갱신됩니다.
흐름은 기능 브랜치 → 커밋 → push → PR → 리뷰·검사 → 병합 → 로컬 main 갱신입니다. 필요한 승인과 검사는 저장소 규칙을 따릅니다.
[따라하기]
아래 명령은 인터넷·계정 없이 작업 파일이 없는 교환용 bare 저장소 `remote.git`을 만듭니다. 세 운영체제 터미널에서 실행할 수 있습니다.
```shell
mkdir tool006-demo
cd tool006-demo
git init --bare remote.git
git clone remote.git work
cd work
git switch -c main
git config user.name "Practice User"
git config user.email "practice@example.invalid"
echo "# Remote repository practice" > README.md
git add README.md
git commit -m "docs: add readme"
git push -u origin main
git switch -c feature/guide
echo "Pull Request practice" >> README.md
git add README.md
git commit -m "docs: add guide line"
git push -u origin feature/guide
git remote -v
git branch -vv
```
결과 끝에는 다음 형태가 보입니다.
```text
origin .../remote.git (fetch)
origin .../remote.git (push)
* feature/guide ... [origin/feature/guide] docs: add guide line
main ... [origin/main] docs: add readme
```
실제 원격에서는 안내된 HTTPS나 SSH 주소를 씁니다. 기능 브랜치를 push한 뒤 base `main`, compare `feature/guide`를 선택하고 변경 이유·검증 방법을 적어 PR을 만듭니다.
[흔한 실수]
- `origin`을 서버 자체로 생각합니다. 바꿀 수 있는 원격 이름입니다.
- fetch와 pull을 같게 봅니다. pull은 통합까지 할 수 있습니다.
- 저장소 규칙을 확인하지 않고 공유 main에 바로 push합니다.
- PR에 변경 이유, 테스트 결과, 영향 범위를 남기지 않습니다.
[보안 주의]
토큰·비밀번호를 URL, 명령줄, 커밋, PR에 넣지 마세요. 공식 자격증명 관리자나 SSH 에이전트를 쓰고 권한은 최소화합니다. push 전에 `git remote -v`, `git status`, `git diff --staged`로 대상과 내용을 확인하세요. 공유 브랜치의 강제 push를 피하고, 비밀정보가 노출되면 즉시 자격증명을 폐기·교체하고 관리자 절차를 따릅니다.
[직접 해볼 과제]
1. `feature/guide`에서 README 한 줄을 더 커밋하고 push한 뒤 `git log --oneline --all --decorate`로 로컬·원격 추적 브랜치 위치를 기록하세요.
2. 가상의 PR 설명에 변경 목적, 주요 변경, 확인 방법, 영향 범위를 각각 한 줄씩 작성하세요.
[확인문제]
1. `origin`은 Git에서 어떤 역할을 하는 이름인가요?
2. fetch와 pull의 핵심 차이는 무엇인가요?
3. PR을 만들었다고 변경이 기준 브랜치에 즉시 합쳐지지 않는 이유는 무엇인가요?
[다음 학습]
TOOL-007에서는 디버거의 중단점과 변수 관찰로 오류를 찾습니다.
[공식 참고 자료]
- Git remote 공식 문서: https://git-scm.com/docs/git-remote
- Git push 공식 문서: https://git-scm.com/docs/git-push
- Pull Request 공식 설명: https://docs.github.com/en/pull-requests/reference/pull-requests
- Pull Request 생성 공식 문서: https://docs.github.com/en/pull-requests/how-tos/create-pull-requests/creating-a-pull-request
- 이전글[PY-006][기초] 파일·JSON·CSV 안전하게 읽고 쓰기 26.09.01
- 다음글[CS-006][기초] 시간·공간복잡도로 코드 성장 읽기 26.09.01
댓글목록
등록된 댓글이 없습니다.
