비개발자를 위한 GitHub 첫걸음 - 06. GitHub 웹으로 해보는 첫 실습: 문서 수정부터 Pull Request까지
핵심 요약
비개발자 입문 실습은 코드가 아니라 문서 파일로 하는 것이 가장 좋다. GitHub 웹 UI만으로도 저장소 보기, issue 만들기, 문서 수정, 새 branch에서 commit 남기기, pull request 올리기까지 기본 흐름을 충분히 경험할 수 있다.
이제 개념을 조금 알게 되었으니, 실제로 가장 작은 흐름 하나를 따라가 보면 좋습니다.
이 실습의 목적은 잘하는 것이 아니라 낯선 화면과 친해지는 것입니다.
준비물
- GitHub 계정
- 실습용 저장소 하나
- 수정 가능한 문서 파일 하나
- 예:
README.md,guide.md,faq.md
- 예:
처음부터 코드 파일로 하지 않아도 됩니다.
오히려 문서 파일이 입문자에게 훨씬 좋습니다.
실습 시나리오
여기서는 아주 작은 변경만 해보겠습니다.
- issue 하나 만들기
- 문서 한 줄 수정하기
- 새 branch에서 commit 남기기
- pull request 만들기
예시 상황은 이렇습니다.
faq.md의 안내 문구가 너무 딱딱해서, 초보자가 더 이해하기 쉬운 표현으로 한 줄 바꾸고 싶다.
1. 저장소 둘러보기
먼저 저장소 첫 화면에서 아래를 찾아보세요.
- 파일 목록
README.mdIssues탭Pull requests탭
여기서 중요한 감각은 이것입니다.
- 파일만 있는 것이 아니라
- 요청과 검토 기록도 함께 있는 공간이라는 점
즉 이 저장소는 단순 자료실이 아니라 프로젝트 작업 방입니다.
2. Issue 만들기
이제 Issues 탭으로 가서 New issue를 눌러봅니다.
예를 들어 이렇게 적을 수 있습니다.
- 제목:
FAQ 문구를 더 쉽게 바꾸기 - 본문:
- 현재 문장이 초보자에게 다소 딱딱하게 느껴짐
- 안내 톤을 더 쉽게 바꾸고 싶음
- 수정 대상은
faq.md의 첫 문단
여기서 포인트는 “무엇이 문제인지”와 “어떻게 바꾸고 싶은지”를 글로 남기는 것입니다.
작은 실습에서는 이 단계를 생략할 수도 있지만, 실무에서는 이 습관이 중요합니다.
3. 웹에서 문서 수정하기
이제 문서 파일을 열고 오른쪽 위의 연필 아이콘, 즉 Edit this file을 눌러봅니다.
그다음 아주 작은 수정 하나를 합니다.
- 문장 한 줄을 더 쉽게 바꾸기
- 자기소개 한 줄 추가하기
- 안내 문장에 예시 문구 추가하기
수정 후 화면 아래로 내려가면 commit 메시지를 적는 영역이 나옵니다.
예시:
FAQ 첫 문단 문구를 더 쉽게 수정자기소개 예시 한 줄 추가
메시지는 길 필요는 없지만, 무엇을 왜 바꿨는지 짐작 가능해야 합니다.
4. 새 branch에서 commit 남기기
이 단계가 중요합니다.
가능하면 원본 브랜치에 바로 커밋하지 말고, Create a new branch for this commit and start a pull request 같은 옵션을 선택하세요.
branch 이름은 간단해도 됩니다.
fix-faq-copyupdate-intro-linerevise-guide-text
이렇게 하면 원본을 바로 건드리지 않고, 안전한 작업 갈래에서 수정하게 됩니다.
즉 지금 하는 일은 “공식본 수정”이 아니라 “수정안 초안 만들기”입니다.
5. Pull Request 만들기
커밋을 마치면 보통 Compare & pull request 버튼이 보입니다.
이제 이 버튼을 눌러 검토 요청을 만듭니다.
예시:
- 제목:
FAQ 문구를 초보자 친화적으로 수정 - 설명:
- 첫 문단 표현을 더 쉽게 다듬음
- 초보 사용자가 바로 이해할 수 있는 표현으로 변경
- 리뷰 시 첫 문단만 확인하면 됨
여기서 핵심은 무엇을 바꿨는지보다 왜 바꿨는지까지 함께 적는 것입니다.
그래야 리뷰어가 맥락을 이해하기 쉽습니다.
6. 리뷰 체험하기
가능하다면 짝 실습이나 강사와 함께 댓글을 남겨보면 좋습니다.
예를 들면 이런 식입니다.
- “좋습니다. 훨씬 읽기 쉬워졌어요.”
- “이 표현은 조금 더 부드럽게 바꿔보면 어떨까요?”
- “정책 용어는 기존 문서와 맞춰주세요.”
이 단계에서 가져가야 할 감각은 단 하나입니다.
review는 혼나는 과정이 아니라, 더 나은 결과를 만드는 대화다.
7. Merge 보기
검토가 끝나고 승인되면 마지막으로 Merge가 일어납니다.
이제 수정안은 원본에 공식 반영됩니다.
이 순간을 보면 GitHub의 기본 구조가 손에 잡힙니다.
- 요청이 있었다.
- 따로 작업했다.
- 기록을 남겼다.
- 검토를 요청했다.
- 승인 후 공식 반영됐다.
즉 어려운 기술 행위처럼 보이던 것들이 사실은 제안-검토-반영 흐름이었다는 점이 분명해집니다.
실습 중 자주 나오는 실수
branch가 왜 필요한지 잘 모르겠어요
원본에 바로 쓰지 않고 초안 공간에서 먼저 작업한다고 생각하면 됩니다.
commit 메시지를 뭘 써야 할지 모르겠어요
내일의 나나 동료가 봐도 알 수 있게 짧게 적으면 충분합니다.
FAQ 문구 수정운영 안내 예시 추가
Pull Request와 merge가 같은 것 같아요
다릅니다.
Pull Request: 검토 요청Merge: 최종 반영
잘못 수정할까 봐 무서워요
GitHub는 변경 기록이 남기 때문에 비교와 복구가 가능합니다.
오히려 실수를 관리하기 좋은 도구입니다.
이 실습에서 꼭 가져가야 할 것
이 실습의 진짜 목표는 버튼 순서를 외우는 것이 아닙니다.
- 원본을 바로 바꾸지 않는 감각
- 변경 이유를 남기는 감각
- 수정안을 검토받는 감각
이 세 가지만 느껴도 GitHub는 훨씬 덜 낯설어집니다.