안녕하세요! GitHub 입문 1편에 이어, 오늘은 여러분의 소중한 코드를 로컬 PC 환경에서 GitHub으로 올리고 관리하는 구체적인 방법을 알아볼 시간입니다. 🚀 1편에서 GitHub 계정을 만들고 첫 번째 저장소(my-first-repo)까지 성공적으로 생성하셨죠? 이제 그 저장소를 내 컴퓨터로 가져오고, 코드를 수정하며 GitHub과 동기화하는 핵심 과정을 마스터해 봅시다!
Git 명령어들이 처음에는 조금 낯설 수 있지만, 몇 번 따라 하다 보면 금방 익숙해지실 거예요. 자, 그럼 시작해볼까요? 😊
🛠️ 사전 준비: Git 설치하기
GitHub 저장소와 내 컴퓨터를 연결하려면 가장 먼저 Git이라는 프로그램이 여러분의 PC에 설치되어 있어야 합니다. Git은 1편에서 설명했듯이 버전 관리 시스템 그 자체입니다.
- 설치 확인: 터미널(Windows: Git Bash 또는 cmd/PowerShell, macOS/Linux: Terminal)을 열고 git --version 명령어를 입력해보세요. 버전 정보가 나오면 이미 설치된 것입니다.
- 설치: 설치되어 있지 않다면, Git 공식 웹사이트에서 여러분의 운영체제에 맞는 설치 파일을 다운로드하여 설치해주세요. 설치 과정은 대부분 기본 옵션으로 진행해도 무방합니다.
Git 설치가 완료되었다면, 이제 본격적으로 GitHub 저장소를 로컬 환경으로 가져올 준비가 되었습니다!
🔗 원격 저장소(Remote)와 로컬 저장소 연결하기
GitHub에 있는 저장소를 원격 저장소(Remote Repository) 라고 부릅니다. 내 PC에 있는 프로젝트 폴더는 로컬 저장소(Local Repository) 가 되죠. 이 둘을 연결하는 가장 일반적인 방법은 원격 저장소를 로컬로 복제(Clone)하는 것입니다.
1. GitHub 저장소 복제 (git clone):
가장 쉽고 일반적인 방법입니다. 원격 저장소의 모든 내용과 버전 기록을 그대로 내 컴퓨터로 가져오면서, 자동으로 원격 저장소 연결 설정까지 완료해 줍니다.
- 저장소 URL 확인: 1편에서 만들었던 my-first-repo 저장소 GitHub 페이지로 이동합니다. 초록색 '<> Code' 버튼을 클릭하면 'HTTPS' 또는 'SSH' 방식의 URL을 확인할 수 있습니다. 지금은 HTTPS URL을 복사합니다. (URL 옆 복사 아이콘 클릭)
- Clone 명령어 실행: 터미널을 열고, 저장소를 내려받고 싶은 폴더로 이동한 후 다음 명령어를 실행합니다.예시: git clone https://github.com/your-username/my-first-repo.git (your-username 부분은 실제 본인 계정명으로!)
-
git clone [복사한 HTTPS URL]
- 결과 확인: 명령어가 성공적으로 실행되면 현재 위치에 my-first-repo 라는 폴더가 생성되고, 그 안에 README.md, .gitignore, LICENSE 파일이 들어있는 것을 확인할 수 있습니다. 이제 이 폴더가 여러분의 로컬 저장소가 됩니다! cd my-first-repo 명령어로 폴더 안으로 이동해 주세요.
💡 git remote add origin은 언제 사용할까? git clone은 원격 저장소를 새롭게 로컬로 가져올 때 사용합니다. 만약 이미 로컬 PC에서 작업하던 프로젝트 폴더가 있고, 이것을 나중에 생성한 GitHub 원격 저장소와 연결하고 싶을 때는 해당 폴더로 이동하여 다음 명령어를 사용합니다: git init (로컬 폴더를 Git 저장소로 초기화) git remote add origin [원격 저장소 URL] (원격 저장소 연결. 'origin'은 관례적으로 사용하는 원격 저장소의 별칭입니다.)
✨ 가장 기본적인 Git 작업 흐름 (Local -> Remote)
로컬 저장소에서 코드를 수정하고 GitHub 원격 저장소에 반영하는 가장 기본적인 작업 흐름은 다음과 같습니다. 꼭 기억해두세요!
1. 파일 수정 또는 추가: 먼저 로컬 저장소(my-first-repo 폴더) 안에 새로운 파일을 만들거나 기존 파일을 수정합니다. 예시로, hello.py 파일을 만들고 간단한 파이썬 코드를 작성해 봅시다.
```python
# hello.py
print("Hello, GitHub!")
```
2. 변경사항 확인 (git status): 터미널에서 git status 명령어를 실행하면 현재 Git 저장소의 상태를 확인할 수 있습니다. 방금 만든 hello.py 파일이 'Untracked files'(추적되지 않는 파일) 목록에 나타날 것입니다.
```bash
git status
```
3. 변경사항 스테이징 (git add): 커밋(Commit)하고 싶은 변경사항을 선택하여 스테이징 영역(Staging Area) 에 추가하는 단계입니다. "이번 커밋에 포함할 변경사항은 이것들이야!"라고 Git에게 알려주는 과정이죠.
```bash
git add hello.py # 특정 파일 추가
# 또는
git add . # 현재 폴더 내의 모든 변경사항(추가/수정/삭제) 추가
```
다시 `git status`를 실행하면 `hello.py`가 'Changes to be committed'(커밋될 변경사항) 목록으로 이동한 것을 볼 수 있습니다.
4. 변경사항 확정 및 기록 (git commit): 스테이징 영역에 있는 변경사항들을 하나의 의미 있는 작업 단위로 묶어 로컬 저장소의 버전 기록에 확정(저장)합니다. -m 옵션 뒤에는 어떤 변경사항인지 명확히 알 수 있는 커밋 메시지를 작성해야 합니다.
```bash
git commit -m "Add hello.py script"
```
**💡 중요:** 커밋 메시지는 매우 중요합니다! 나중에 변경 이력을 추적할 때, 또는 다른 사람과 협업할 때 이 메시지를 보고 어떤 작업이었는지 파악하게 됩니다. "Fix bug", "Update README" 보다는 "Fix: User login issue with invalid password", "Docs: Add installation guide to README" 처럼 명확하고 구체적으로 작성하는 습관을 들이세요.
5. 원격 저장소에 업로드 (git push): 로컬 저장소에 기록된 커밋들을 GitHub 원격 저장소로 전송(업로드)합니다. origin은 우리가 연결한 원격 저장소의 별칭이고, main은 변경사항을 올릴 브랜치(Branch) 이름입니다. (기본 브랜치 이름은 main 또는 master일 수 있습니다.)
```bash
git push origin main
```
이 명령어를 실행하면 GitHub 계정 인증(사용자 이름 및 비밀번호 또는 PAT)을 요구할 수 있습니다. (자세한 내용은 아래 인증 섹션 참고)
성공적으로 Push가 완료되면, 이제 GitHub 웹사이트의 `my-first-repo` 저장소 페이지를 새로고침 해보세요. 방금 추가한 `hello.py` 파일과 새로운 커밋 기록이 반영된 것을 확인할 수 있습니다! 🎉
🔄 원격 저장소 변경사항 가져오기 (Remote -> Local)
다른 사람이 원격 저장소에 변경사항을 Push 했거나, 내가 GitHub 웹사이트에서 직접 파일을 수정했을 경우, 그 최신 내용을 내 로컬 저장소로 가져와야 합니다. 이때 git pull 명령어를 사용합니다.
예시:
- GitHub 웹사이트에서 README.md 수정: GitHub의 my-first-repo 저장소 페이지로 가서 README.md 파일을 클릭하고, 연필 모양(Edit) 아이콘을 눌러 내용을 수정한 후 페이지 하단의 'Commit changes' 버튼을 눌러 저장합니다.
- 로컬에서 변경사항 가져오기: 터미널의 로컬 저장소 폴더(my-first-repo)에서 다음 명령어를 실행합니다.이 명령어는 원격 저장소(origin)의 main 브랜치에서 최신 변경사항을 가져와(Fetch) 현재 로컬 브랜치와 병합(Merge)합니다.
-
Bash
git pull origin main
- 결과 확인: 로컬 PC의 README.md 파일을 열어보면 GitHub 웹사이트에서 수정한 내용이 반영되어 있을 것입니다.
🔑 인증 방식: HTTPS vs SSH
GitHub 원격 저장소에 연결하여 push 또는 pull 작업을 하려면 내가 해당 저장소에 접근할 권한이 있는지 인증해야 합니다. 주로 두 가지 방식이 사용됩니다.
- HTTPS:
- 설정이 비교적 간단합니다. 저장소 URL이 https://... 로 시작합니다.
- push 또는 pull 시 GitHub 사용자 이름과 비밀번호(또는 PAT)를 요구합니다.
- 주의: 현재 GitHub는 보안 강화를 위해 비밀번호 대신 Personal Access Token(PAT) 사용을 요구합니다.
- Personal Access Token (PAT): 특정 권한(Scope)과 만료일을 가진 임시 비밀번호 같은 것입니다.
- 발급: GitHub 웹사이트 > Settings > Developer settings > Personal access tokens > Tokens (classic) 또는 Fine-grained tokens 에서 생성할 수 있습니다. 저장소 접근(repo 스코프) 권한을 포함하여 생성하고, 생성된 토큰 문자열은 반드시 안전한 곳에 복사해 두어야 합니다. (다시 볼 수 없음!)
- 사용: Git이 비밀번호를 물어볼 때, 발급받은 PAT 문자열을 입력합니다. 운영체제의 자격 증명 관리자(Credential Manager)에 저장되어 다음번에는 자동으로 인증될 수도 있습니다. (만료되면 재발급 필요)
- SSH (Secure Shell):
- 초기 설정이 HTTPS보다 조금 더 복잡하지만, 한번 설정해두면 이후에는 비밀번호나 PAT 입력 없이 편리하게 인증할 수 있습니다.
- 작동 방식: 로컬 PC에서 공개키(Public Key)와 비밀키(Private Key) 한 쌍을 생성합니다. 공개키는 GitHub 계정에 등록하고, 비밀키는 로컬 PC에 안전하게 보관합니다. Git 작업 시 SSH 프로토콜을 통해 이 키 쌍으로 안전하게 인증합니다.
- 간략 설정 방법:
- ssh-keygen -t ed25519 -C "your_email@example.com" 명령어로 SSH 키 생성 (기본 경로: ~/.ssh/id_ed25519 (비밀키), ~/.ssh/id_ed25519.pub (공개키))
- ~/.ssh/id_ed25519.pub 파일의 내용을 복사합니다.
- GitHub 웹사이트 > Settings > SSH and GPG keys > 'New SSH key' 버튼 클릭 후, 복사한 공개키를 붙여넣고 저장합니다.
- (필요시) ssh-agent를 사용하거나 ~/.ssh/config 파일을 설정하여 키 관리를 용이하게 할 수 있습니다.
- git clone 또는 git remote add 시 HTTPS URL 대신 SSH URL (git@github.com:your-username/my-first-repo.git)을 사용합니다.
어떤 방식을 선택해야 할까? 처음에는 HTTPS와 PAT를 사용하는 것이 더 쉬울 수 있습니다. 익숙해진 후에 SSH로 전환하는 것을 고려해 보세요.
🤯 문제 해결: 흔히 겪는 오류와 대처법
1. 인증 오류 (fatal: Authentication failed)
- HTTPS 사용 시:
- 비밀번호 대신 **Personal Access Token(PAT)**를 사용하고 있는지 확인하세요.
- PAT가 만료되지 않았는지 확인하세요. 만료되었다면 재발급 받아야 합니다.
- PAT 생성 시 필요한 권한(Scope, 최소 repo 권한)이 부여되었는지 확인하세요.
- 운영체제(Windows Credential Manager, macOS Keychain)에 잘못된 자격 증명이 저장되어 있을 수 있습니다. 관련 GitHub 자격 증명을 삭제하고 다시 시도해보세요.
- SSH 사용 시:
- SSH 키가 정상적으로 생성되었고, 공개키가 GitHub 계정에 올바르게 등록되었는지 확인하세요. (.pub 파일 내용 전체 복사)
- 로컬 PC의 ~/.ssh 폴더 및 키 파일 권한이 올바른지 확인하세요. (보통 비밀키는 chmod 600 ~/.ssh/id_ed25519)
- SSH Agent가 실행 중이고 키가 등록되어 있는지 확인 (ssh-add -l).
- ~/.ssh/config 파일 설정이 올바른지 확인하세요 (만약 사용 중이라면).
- ssh -T git@github.com 명령어로 SSH 연결 자체를 테스트해볼 수 있습니다. ("Hi [username]! You've successfully authenticated...") 메시지가 나와야 합니다.
2. Push 거부 (rejected)
```
! [rejected] main -> main (fetch first)
error: failed to push some refs to 'https://github.com/your-username/my-first-repo.git'
hint: Updates were rejected because the remote contains work that you do
hint: not have locally. This is usually caused by another repository pushing
hint: to the same ref. You may want to first integrate the remote changes
hint: (e.g., 'git pull ...') before pushing again.
```
- 원인: 이 메시지는 내가 마지막으로 pull 한 이후에 누군가 (혹은 내가 다른 곳에서) 원격 저장소(origin)의 main 브랜치에 새로운 커밋을 Push 했다는 의미입니다. 즉, 내 로컬 저장소의 main 브랜치가 원격 저장소의 main 브랜치보다 뒤처져 있는 상태입니다. Git은 이런 상황에서 데이터 유실을 방지하기 위해 무작정 push하는 것을 막습니다.
- 해결 방법: 메시지의 hint가 알려주듯이, push 하기 전에 원격 저장소의 최신 변경사항을 먼저 로컬 저장소로 가져와 병합(Merge)해야 합니다.pull 과정에서 만약 나와 다른 사람이 같은 파일의 같은 부분을 수정했다면 충돌(Conflict) 이 발생할 수 있습니다. (충돌 해결은 다음 편에서 자세히 다룰 예정입니다.) 충돌이 없다면, pull이 성공적으로 완료된 후 다시 push를 시도하면 됩니다.
-
git push origin main
git pull origin main
- git pull --rebase origin main 사용: pull 시 병합 커밋을 남기지 않고 내 로컬 커밋들을 원격 저장소의 최신 커밋 뒤에 이어 붙여(Rebase) 히스토리를 깔끔하게 유지하고 싶을 때 사용할 수 있습니다. 하지만 초보자에게는 rebase 중 충돌 해결이 더 복잡할 수 있으므로, 우선은 기본 git pull (Merge 방식)에 익숙해지는 것을 권장합니다.
3. 원격 저장소 주소 오류
만약 git remote add 또는 git clone 시 원격 저장소 URL을 잘못 입력했다면, git remote -v 명령어로 현재 설정된 원격 저장소 주소를 확인할 수 있습니다. 잘못된 주소를 수정하려면 다음 명령어를 사용합니다.
git remote set-url origin [새로운_올바른_URL]
🎉 잘 하셨습니다! 이제 여러분은 로컬 컴퓨터에서 작업한 코드를 GitHub에 올리고(push), GitHub의 변경사항을 로컬로 가져오는(pull) 기본적인 작업 흐름을 이해하고 실행할 수 있게 되었습니다. HTTPS/PAT 및 SSH 인증 방식의 차이와 흔한 문제 해결 방법까지 익혔으니, GitHub 사용에 대한 자신감이 한층 더 높아졌을 거예요!
💡 꾸준한 연습이 중요합니다. 오늘 배운 clone, add, commit, push, pull 명령어들은 매일 사용하게 될 핵심 명령어들입니다. 작은 프로젝트라도 직접 만들어보면서 반복적으로 사용해보는 것이 가장 좋은 학습 방법입니다.
'Github' 카테고리의 다른 글
[Github]GitHub Issues로 작업 흐름 정복하기 🚀 (5) | 2025.04.25 |
---|---|
[Github]Pull Request(PR)로 협업 마스터하기 🚀 (8) | 2025.04.25 |
[Github]🌿브랜치(Branch)로 안전하게 개발하기 (7) | 2025.04.24 |
[Github]📝 GitHub 입문하기: 개발자의 필수 도구, 지금 바로 시작하세요! 🚀 (8) | 2025.04.24 |