GitHub 원격 저장소 협업: push, clone, fetch, pull, Issue와 Pull Request

About this offer

로컬 Git만으로도 버전 관리는 가능하지만 여러 컴퓨터에서 작업하거나 다른 사람과 협업하려면 원격 저장소(remote repository) 가 필요하다. GitHub는 로컬 Git 저장소를 인터넷에 연결해 백업, 공유, 코드 리뷰, 이슈 관리까지 할 수 있게 해준다. 이 글에서는 로컬 저장소와 원격 저장소가 어떤 관계를 갖는지부터 push , clone , fetch , pull , Issue, Pull Request까지 하나의 흐름으로 정리한다. 로컬 저장소와 원격 저장소 구조를 단순화하면 다음과 같다. 내 컴퓨터 GitHub Local Repository <--------> Remote Repository main main │ │ └─ origin/main ---------------┘ Git은 분산 버전 관리 시스템 이기 때문에 로컬 컴퓨터에도 전체 Git 히스토리가 있고 원격 저장소에도 히스토리가 존재한다. 인터넷이 끊겨도 로컬에서 commit , branch , merge , log 같은 작업을 계속할 수 있는 이유가 여기에 있다. 원격 저장소 연결하기 GitHub에서 빈 저장소를 만든 뒤 로컬 저장소에 원격 주소를 등록한다. git remote add origin https://github.com/USER/REPOSITORY.git origin 은 원격 저장소 URL에 붙인 별명 이다. 반드시 origin이어야 하는 것은 아니지만 가장 널리 쓰이는 관례다. 등록 상태는 다음 명령으로 확인할 수 있다. git remote -v 예시는 다음과 같다. origin https://github.com/USER/REPOSITORY.git (fetch) origin https://github.com/USER/REPOSITORY.git (push) push: 로컬 커밋을 원격 저장소로 올리기 로컬에서 커밋을 만든 것만으로는 GitHub에 자동 반영되지 않는다. Local A ── B ── C ↑ main Remote A ── B ↑ origin/main C를 원격 저장소로 보내려면 push한다. git push origin main 처음 브랜치를 올리면서 upstream을 연결하려면 다음 명령이 자주 사용된다. git push -u origin main 이후에는 단순히 다음처럼 사용할 수 있다. git push origin/main은 무엇인가 origin/main 은 GitHub 서버에 직접 존재하는 브랜치 자체가 아니라 내 로컬 Git이 기억하고 있는 원격 main의 마지막 확인 상태 를 나타내는 remote-tracking branch다. 예를 들어 로컬에서만 새 커밋을 만들면 다음처럼 보일 수 있다. A ── B ── C ↑ ↑ origin/main main 이 상태는 "로컬 main이 원격에서 알고 있는 main보다 한 커밋 앞서 있다"고 해석할 수 있다. push가 성공하면 원격 저장소도 C까지 올라가고 로컬의 origin/main 도 그 상태를 반영한다. clone: 저장소를 히스토리까지 복제하기 새로운 컴퓨터에서 기존 원격 저장소로 작업을 시작하고 싶다면 clone 을 사용한다. git clone https://github.com/USER/REPOSITORY.git clone은 단순히 현재 소스 파일만 다운로드하는 것이 아니다. 프로젝트 파일 커밋 히스토리 브랜치 정보 원격 저장소 연결 정보 까지 함께 가져온다. 기본적으로 원격 저장소는 origin 이라는 이름으로 등록된다. cd REPOSITORY git remote -v 오픈소스 프로젝트를 분석할 때도 clone을 사용하면 현재 파일뿐 아니라 과거 변경 이력까지 확인할 수 있다. fetch: 원격의 최신 정보를 가져오기만 한다 협업 중 다른 사람이 원격 저장소에 커밋을 올렸다고 하자. Local main A ── B Remote main A ── B ── C 원격 상태를 확인하고 싶을 때 fetch 를 사용할 수 있다. git fetch origin fetch의 핵심은 다음과 같다. 원격 저장소의 커밋과 참조 정보를 가져오지만 현재 작업 브랜치와 Working Directory를 자동으로 병합하지 않는다. fetch 후에는 다음과 비슷해진다. A ── B ── C ↑ ↑ main origin/main 따라서 fetch 자체만으로는 일반적인 merge conflict가 발생하지 않는다. 로컬 작업 파일을 바로 합치는 단계가 없기 때문이다. 차이를 확인하려면 다음처럼 비교할 수 있다. git log main..origin/main --oneline 또는 git diff main..origin/main 원격 변경을 먼저 살펴보고 병합하고 싶을 때 유용하다. pull: 가져오고 현재 브랜치에 반영하기 pull 은 원격 변경을 가져온 뒤 현재 브랜치에 통합한다. git pull 개념적으로는 보통 다음 흐름으로 이해하면 된다. git fetch ↓ merge 또는 rebase 정확한 통합 방식은 Git 설정과 옵션에 따라 merge 또는 rebase가 될 수 있다. 중요한 점은 pull은 실제로 현재 브랜치에 원격 변경을 반영하므로 충돌이 발생할 수 있다는 것 이다. fetch → 다운로드/원격 상태 갱신 → Working Directory를 바로 합치지 않음 pull → 원격 변경 가져오기 → 현재 브랜치에 통합 → 상황에 따라 conflict 가능 협업 프로젝트에서 작업을 시작하기 전에 원격 변경을 확인하는 습관이 좋다. git switch main git pull 두 사람이 같은 저장소에서 작업한다면 간단한 협업 흐름은 다음과 같다. 개발자 A 개발자 B │ │ ├─ clone ├─ clone │ │ ├─ 작업 + commit ├─ 작업 + commit │ │ ├─ push ───────────▶ GitHub ◀────────┤ │ │ └─ pull ◀────────── GitHub ──────────┘ 여기서 양쪽이 동일한 코드 영역을 서로 다르게 수정하면 pull 또는 merge 시점에 충돌이 발생할 수 있다. 따라서 실제 팀에서는 보통 main에 직접 작업하기보다 브랜치를 만들고 Pull Request를 통해 병합한다. .gitignore : 저장소에 넣지 않을 파일 제외하기 모든 파일을 Git으로 관리할 필요는 없다. 대표적으로 다음 파일은 저장소에 포함하지 않는 경우가 많다. 환경 변수 파일 빌드 결과물 패키지 캐시 IDE 개인 설정 로그 파일 비밀키와 인증 정보 프로젝트 루트에 .gitignore 를 만들 수 있다. # 환경 변수 .env .env.* # Node.js node_modules/ # Python __pycache__/ .venv/ # 로그 *.log # 빌드 결과 build/ dist/ 중요한 점은 .gitignore 가 이미 Git이 추적 중인 파일을 자동으로 추적 해제하지는 않는다는 것 이다. 이미 커밋된 파일을 앞으로 추적하지 않게 하려면 상황에 따라 다음처럼 인덱스에서 제거해야 한다. git rm --cached .env 그리고 .gitignore 에 추가한 뒤 커밋한다. API Key, Token, Password 같은 민감 정보는 애초에 커밋하지 않는 것이 가장 중요하다. GitHub Issue로 작업 단위를 관리하기 GitHub Issue는 버그, 기능 개선, 질문, 할 일 등을 기록할 수 있는 작업 관리 도구다. 예를 들어 다음과 같은 이슈를 만들 수 있다. 제목: 검색 결과 정렬 기능 추가 내용: - 최신순/인기순 정렬 지원 - URL query parameter와 동기화 - 모바일 UI 확인 Issue에는 다음 정보를 연결할 수 있다. Assignee: 담당자 Label: bug, enhancement, docs 등 분류 Milestone: 일정 단위 Comment: 진행 과정과 논의 AI 코딩 에이전트를 사용할 때도 작업 지시를 대화창에만 남기는 것보다 Issue를 기준으로 작업하게 하면 무엇을 왜 수정했는지 기록 하기 쉽다. GitHub CLI gh 로 브라우저 없이 작업하기 GitHub CLI를 사용하면 터미널에서 GitHub 기능을 제어할 수 있다. 로그인은 다음 명령으로 시작한다. gh auth login Issue 생성 예시는 다음과 같다. gh issue create \ --title "검색 결과 정렬 기능 추가" \ --body "최신순과 인기순 정렬을 구현한다." 최근 이슈를 확인하려면 다음처럼 사용할 수 있다. gh issue list Git 명령과 gh 명령의 역할은 다르다. git → 로컬/원격 Git 저장소의 버전 관리 gh → GitHub의 Issue, Pull Request, Repository 등 서비스 기능 제어 Pull Request는 "이 브랜치를 병합해 주세요"라는 요청이다 새 기능을 브랜치에서 개발했다고 하자. git switch -c feature/search-sort # 작업 git add . git commit -m "검색 결과 정렬 기능 추가" git push -u origin feature/search-sort 이제 원격 저장소에는 main 과 feature/search-sort 가 모두 존재한다. main A ── B \ C ── D feature/search-sort Pull Request(PR)는 개념적으로 다음 요청이다. feature/search-sort 에서 작업한 내용을 검토한 뒤 문제가 없다면 main 에 병합해 주세요. PR에서는 다음을 확인할 수 있다. 어떤 파일이 바뀌었는지 어떤 줄이 추가/삭제되었는지 커밋 목록 리뷰 의견 자동 테스트 결과 병합 가능 여부 GitLab에서는 비슷한 기능을 Merge Request 라고 부른다. PR의 일반적인 협업 흐름 Issue 생성 ↓ 작업 브랜치 생성 ↓ 코드 수정 ↓ commit ↓ push ↓ Pull Request 생성 ↓ 리뷰 및 수정 ↓ merge ↓ 로컬 main에서 pull GitHub CLI로 PR을 만들 수도 있다. gh pr create \ --base main \ --head feature/search-sort \ --title "검색 결과 정렬 기능 추가" \ --body "관련 기능 구현 및 테스트 완료" PR이 GitHub에서 merge되었다면 로컬 main은 아직 그 사실을 모를 수 있다. git switch main git pull 이렇게 원격 main의 최신 병합 결과를 로컬에 가져온다. 실무에서 자주 쓰는 협업 패턴 혼자 작업하더라도 다음 흐름을 사용하면 기록과 검토가 쉬워진다. # 1. main 최신화 git switch main git pull # 2. 작업 브랜치 생성 git switch -c feature/profile-edit # 3. 작업 후 커밋 git add . git commit -m "프로필 수정 기능 추가" # 4. 원격에 브랜치 업로드 git push -u origin feature/profile-edit # 5. PR 생성 gh pr create --base main --fill 병합이 완료되면 다음처럼 정리할 수 있다. git switch main git pull git branch -d feature/profile-edit 핵심 정리 GitHub는 Git과 별개의 원격 저장소 서비스이며 GitLab, Bitbucket 같은 대안도 있다. origin 은 원격 저장소 주소에 붙이는 관례적인 별명이다. push 는 로컬 커밋을 원격 저장소로 업로드한다. clone 은 소스 코드뿐 아니라 Git 히스토리까지 포함해 저장소를 복제한다. fetch 는 원격 변경을 가져오지만 현재 Working Directory에 자동 병합하지 않는다. pull 은 원격 변경을 가져와 현재 브랜치에 통합하므로 충돌이 발생할 수 있다. .gitignore 는 추적하지 않을 파일을 정의하지만 이미 추적 중인 파일을 자동으로 해제하지 않는다. Issue는 작업을 기록하고, Pull Request는 브랜치의 변경을 검토한 뒤 병합하도록 요청하는 협업 흐름의 중심이다.