목차
시작 전 준비
이 글은 GitHub 계정이 있고, 컴퓨터에 Git이 설치되어 있다고 가정합니다. 명령어를 실행할 터미널과 관리할 프로젝트 폴더도 준비하세요.
GitHub는 코드를 저장하고 여러 사람이 변경 이력을 공유하는 서비스입니다. Git은 내 컴퓨터의 파일 변경을 기록하고 GitHub 저장소와 동기화하는 도구입니다.
저장소 생성과 기본 작업
GitHub에서 새 저장소를 만들 때 저장소 이름과 공개 여부를 정한 뒤 README 생성을 선택하면 프로젝트 설명 파일이 함께 만들어집니다. README에는 프로젝트 목적, 설치 방법, 실행 방법을 적어 다른 사람이 저장소를 이해하도록 합니다.
기존 저장소를 내려받고 파일을 수정한 뒤 다음 순서로 업로드합니다.
git clone https://github.com/사용자명/프로젝트명.git
cd 프로젝트명 || exit
git add .
git commit -m "기능 수정"
git push origin main
clone은 저장소를 복사하고, add는 변경 파일을 커밋 대상으로 지정합니다. commit은 변경 이력을 로컬에 기록하며, push는 로컬 커밋을 GitHub에 올립니다. pull은 원격 저장소의 변경 내용을 내 컴퓨터에 반영할 때 사용하는 명령입니다.
브랜치와 Pull Request
기능별 브랜치로 변경 내용을 분리하고, Pull Request를 통해 검토한 뒤 main에 반영하는 방식이 일반적입니다.
git switch -c feature/login
git add .
git commit -m "로그인 기능 추가"
git push -u origin feature/login
GitHub 저장소 화면에서 해당 브랜치를 기준으로 Pull Request를 생성합니다. 제목과 변경 내용을 작성하고 검토자가 확인한 뒤 문제가 없을 때 main에 머지하는 흐름입니다.
머지 충돌 해결
같은 파일의 같은 부분을 서로 다르게 수정하면 머지 충돌이 발생합니다. 이때 Git은 파일 안에 <<<<<<<, =======, >>>>>>> 표시를 남기고, GitHub의 Pull Request에는 충돌 해결이 필요하다는 안내가 나타납니다.
최신 main을 내 브랜치에 반영한 뒤 표시를 직접 정리합니다.
git switch feature/login
git pull origin main
git status
# 충돌 파일을 수정한 뒤 표시 제거
git add 충돌파일
git commit -m "머지 충돌 해결"
git push
해결 내용이 불확실하다면 팀원에게 원래 의도를 확인한 뒤 최종 변경을 결정하세요.
작업 방식 비교와 FAQ
| 비교 항목 | HTTPS | SSH |
|---|---|---|
| 인증 방식 | 개인 액세스 토큰 등 | SSH 키 |
| 시작 난이도 | 낮음 | 중간 |
| 반복 작업 편의성 | 인증 설정 필요 | 키 등록 후 편리 |
| 추천 상황 | 처음 사용하거나 간단한 환경 | 개인 PC에서 반복 작업 |
자주 묻는 질문
push가 거부되면 어떻게 하나요? 원격 저장소에 먼저 올라간 변경 때문에 거부됐다면, 현재 작업 방식에 맞춰 git pull --rebase origin main 등으로 원격 변경을 반영한 뒤 다시 push할 수 있습니다. rebase는 커밋 이력을 다시 작성할 수 있으므로 이미 공유한 커밋에는 주의하세요.
README는 꼭 필요한가요? README는 선택 사항입니다. 프로젝트 목적과 실행 절차를 설명하는 첫 문서이므로 공개 저장소에서 작성하면 다른 사람이 저장소를 이해하는 데 도움이 됩니다.
결론
GitHub 사용법을 익힐 때는 변경 내용을 commit으로 기록하고, 원격 변경은 pull로 반영한 뒤 push로 공유합니다. 협업에서는 기능별 브랜치와 Pull Request를 활용해 변경을 검토한 뒤 main에 반영할 수 있습니다.