먼저 문제부터 이해하기
GitHub를 배우기 전에 가장 먼저 알아야 할 것은 명령어가 아닙니다. GitHub가 어떤 문제를 해결하는지 이해하는 것입니다.
많은 사람이 파일을 관리할 때 이런 식으로 이름을 붙입니다.
보고서.docx보고서_수정.docx보고서_최종.docx보고서_최종_진짜.docx보고서_최종_진짜_마지막.docx
처음에는 괜찮아 보입니다. 하지만 시간이 지나면 문제가 생깁니다.
어떤 파일이 정말 최신인지 헷갈립니다. 중간에 어떤 내용을 고쳤는지도 기억하기 어렵습니다. 실수로 중요한 문장을 지웠을 때 이전 상태로 되돌리기도 어렵습니다. 다른 사람과 함께 작업한다면 문제는 더 커집니다. 서로 다른 파일을 수정한 뒤 하나로 합쳐야 하기 때문입니다.
Git과 GitHub는 바로 이런 문제를 해결하기 위해 사용합니다. 핵심은 단순합니다.
파일의 변경 이력을 남기고, 필요할 때 비교하고, 되돌리고, 함께 작업할 수 있게 해준다.
개발자는 코드 파일을 다루지만, 원리는 문서 수정과 같습니다. 어떤 파일이든 시간이 지나며 계속 바뀝니다. 중요한 것은 "지금 파일이 무엇인가"뿐 아니라 "어떻게 여기까지 왔는가"입니다.
Git과 GitHub는 다르다
초보자가 가장 많이 헷갈리는 부분이 Git과 GitHub의 차이입니다.
간단히 말하면 다음과 같습니다.
Git: 내 컴퓨터에서 파일 변경 이력을 관리하는 도구
GitHub: Git으로 관리한 이력을 온라인에 올리고, 공유하고, 협업하는 플랫폼
비유하면 Git은 개인 작업 노트입니다. 내가 언제 무엇을 바꿨는지 차곡차곡 기록합니다. 인터넷이 없어도 내 컴퓨터에서 사용할 수 있습니다.
GitHub는 그 작업 노트를 올려두는 온라인 작업 공간입니다. 다른 사람에게 보여줄 수 있고, 함께 수정할 수 있고, 작업 내용을 검토할 수 있습니다.
예를 들어 혼자 자기소개 페이지를 만든다고 해봅시다. 내 컴퓨터에서 index.html 파일을 수정하고, 변경 내용을 Git으로 기록합니다. 이것만으로도 "어제 상태로 돌아가기", "어떤 줄을 바꿨는지 확인하기"가 가능합니다.
그런데 이 프로젝트를 다른 컴퓨터에서도 보고 싶거나, 친구에게 보여주고 싶거나, 팀원과 함께 수정하고 싶다면 온라인 공간이 필요합니다. 이때 GitHub를 사용합니다.
즉, GitHub를 잘 쓰려면 Git의 기본 개념을 알아야 합니다. 하지만 처음부터 모든 명령어를 외울 필요는 없습니다. 지금은 "Git은 기록 도구, GitHub는 공유와 협업 공간"이라고 이해하면 충분합니다.
버전 관리는 무엇을 해결할까
버전 관리는 파일의 변화를 기록하는 방식입니다. 단순히 최신 파일 하나만 보관하는 것이 아니라, 중요한 순간마다 상태를 저장합니다.
문서 수정 예시로 생각해보겠습니다.
처음에는 다음 문장이 있었습니다.
우리 서비스는 사용자가 일정을 쉽게 관리하도록 돕습니다.
이후 설명을 더 자세히 바꿨습니다.
우리 서비스는 개인과 팀이 일정을 쉽게 정리하고 공유하도록 돕습니다.
며칠 뒤 다시 보니 예전 문장이 더 간결해서 좋다고 느꼈습니다. 일반 파일 관리 방식이라면 예전 문장을 기억해야 합니다. 또는 이전 파일을 따로 저장해두었어야 합니다.
하지만 Git을 사용했다면 각 변경 시점이 기록되어 있습니다. 그래서 다음 일을 할 수 있습니다.
이전 문장과 현재 문장을 비교한다.
언제 누가 바꿨는지 확인한다.
필요하면 예전 상태로 되돌린다.
특정 변경만 골라 살펴본다.
이것이 버전 관리의 힘입니다. 파일을 많이 복사해서 보관하는 방식이 아니라, 변경의 흐름을 관리합니다.
개발에서는 이 흐름이 특히 중요합니다. 기능을 추가하다가 문제가 생길 수 있습니다. 디자인을 고쳤는데 화면이 깨질 수 있습니다. 팀원이 동시에 같은 파일을 수정할 수도 있습니다. 버전 관리가 있으면 이런 상황을 추적하고 정리할 수 있습니다.
GitHub의 핵심 용어를 비유로 이해하기
GitHub를 배우다 보면 낯선 단어가 계속 나옵니다. 처음부터 어렵게 생각할 필요는 없습니다. 실제 작업 흐름과 연결해서 보면 이해하기 쉽습니다.
저장소: 프로젝트 보관함
저장소(Repository)는 프로젝트를 담는 공간입니다. 코드, 문서, 이미지, 설정 파일 등이 함께 들어갑니다.
비유하면 하나의 프로젝트 전용 폴더입니다. 다만 일반 폴더와 달리 변경 이력까지 함께 관리됩니다.
예를 들어 my-portfolio라는 저장소를 만들면 그 안에 포트폴리오 사이트 파일과 수정 기록이 함께 쌓입니다.
커밋: 의미 있는 저장 지점
커밋(Commit)은 변경 내용을 기록하는 단위입니다.
일반 문서 프로그램의 "저장"과 비슷하지만 더 똑똑합니다. 커밋에는 보통 "무엇을 바꿨는지" 설명하는 메시지를 함께 남깁니다.
예를 들면 다음과 같습니다.
자기소개 문구 추가프로필 이미지 변경연락처 섹션 수정
커밋은 나중에 과거를 찾는 기준이 됩니다. 그래서 아무 때나 무작정 저장하기보다, 의미 있는 작업 단위로 남기는 것이 좋습니다.
브랜치: 안전한 실험 공간
브랜치(Branch)는 기존 작업 흐름에서 갈라져 나온 별도 작업 공간입니다.
비유하면 원본 문서를 그대로 둔 채 복사본에서 실험하는 것입니다. 새 디자인을 적용해보거나, 기능을 추가해보거나, 문장을 크게 바꿔볼 수 있습니다.
실험이 성공하면 원래 작업에 합칩니다. 실패하면 버리면 됩니다. 그래서 브랜치는 안전하게 시도할 수 있는 공간입니다.
예를 들어 포트폴리오 사이트에 새로운 소개 섹션을 추가하고 싶다면 add-about-section 같은 브랜치를 만들 수 있습니다. 작업이 마음에 들면 기본 브랜치에 합치고, 마음에 들지 않으면 그대로 삭제하면 됩니다.
푸시: 내 기록을 GitHub에 올리기
푸시(Push)는 내 컴퓨터에 있는 커밋을 GitHub로 올리는 작업입니다.
내 컴퓨터에서만 작업하면 다른 사람은 그 내용을 볼 수 없습니다. GitHub에도 반영되지 않습니다. 푸시를 해야 온라인 저장소에 변경 이력이 올라갑니다.
비유하면 내 노트북에 적어둔 작업 기록을 팀 공용 게시판에 올리는 것과 같습니다.
풀: GitHub의 변경을 내 컴퓨터로 가져오기
풀(Pull)은 GitHub에 있는 최신 변경 내용을 내 컴퓨터로 가져오는 작업입니다.
팀원이 GitHub에 새 커밋을 올렸다면 내 컴퓨터는 아직 예전 상태일 수 있습니다. 이때 풀을 해서 최신 상태로 맞춥니다.
비유하면 팀 공용 게시판에 올라온 최신 자료를 내 책상으로 가져오는 것입니다.
풀 리퀘스트: 변경 내용을 합치기 전에 검토 요청하기
풀 리퀘스트(Pull Request)는 내가 만든 변경 내용을 다른 작업 흐름에 합치기 전에 검토를 요청하는 과정입니다.
혼자 작업할 때도 유용하지만, 팀 작업에서 특히 중요합니다. 바로 합치지 않고 "이렇게 바꿨는데 확인해 주세요"라고 요청하는 단계이기 때문입니다.
풀 리퀘스트에서는 다음을 할 수 있습니다.
어떤 파일이 바뀌었는지 확인한다.
코드나 문서에 의견을 남긴다.
문제가 없으면 변경 내용을 합친다.
자동 테스트를 실행해 오류를 확인한다.
비유하면 최종 문서에 반영하기 전에 수정안을 올리고 검토받는 과정입니다.
GitHub는 어디에 쓰일까
GitHub는 개발자만 쓰는 도구처럼 보이지만, 실제로는 다양한 목적에 사용할 수 있습니다. 특히 개발을 배우는 사람에게는 학습 기록과 포트폴리오를 함께 쌓는 공간이 됩니다.
개인 백업
내 컴퓨터는 언제든 문제가 생길 수 있습니다. 파일을 실수로 삭제할 수도 있고, 노트북을 바꿀 수도 있습니다.
GitHub에 프로젝트를 올려두면 온라인 백업이 됩니다. 새 컴퓨터에서도 저장소를 가져와 이어서 작업할 수 있습니다.
단, 비밀번호나 API 키 같은 민감한 정보는 절대 올리면 안 됩니다. GitHub는 공유를 전제로 한 공간이므로 공개 저장소에 비밀 정보가 올라가면 위험합니다.
포트폴리오
개발을 배우는 사람에게 GitHub는 이력서보다 더 구체적인 증거가 될 수 있습니다.
"HTML과 CSS를 공부했습니다"라고 말하는 것보다, 직접 만든 웹페이지 저장소를 보여주는 편이 더 설득력 있습니다. 커밋 기록을 보면 꾸준히 학습했는지도 알 수 있습니다.
처음에는 거창한 프로젝트가 아니어도 됩니다. 계산기, 할 일 목록, 자기소개 페이지, 작은 자동화 스크립트처럼 단순한 프로젝트도 좋습니다. 중요한 것은 완성하고 기록하는 습관입니다.
팀 협업
팀 프로젝트에서는 누가 어떤 파일을 고쳤는지 관리해야 합니다. 여러 사람이 동시에 작업하면 변경 내용이 겹칠 수 있습니다.
GitHub를 사용하면 각자 브랜치에서 작업하고, 풀 리퀘스트로 검토한 뒤 합칠 수 있습니다. 이 과정 덕분에 실수를 줄이고, 작업 내용을 투명하게 공유할 수 있습니다.
예를 들어 한 사람은 로그인 화면을 만들고, 다른 사람은 상품 목록 페이지를 만들 수 있습니다. 각자 브랜치에서 작업한 뒤 GitHub에서 변경 내용을 확인하고 합칩니다.
오픈소스 기여
오픈소스는 누구나 볼 수 있고, 경우에 따라 누구나 개선에 참여할 수 있는 프로젝트입니다.
GitHub에는 수많은 오픈소스 프로젝트가 있습니다. 처음부터 큰 기능을 개발할 필요는 없습니다. 문서의 오타를 고치거나, 설명을 보완하거나, 작은 버그를 수정하는 것도 기여입니다.
오픈소스 기여의 기본 흐름도 GitHub와 연결됩니다. 저장소를 복사하고, 브랜치에서 수정하고, 풀 리퀘스트를 보내 검토를 받습니다. 이 책의 뒤쪽에서 이 과정을 차근차근 다룹니다.
처음 배울 때의 올바른 순서
GitHub를 처음 배울 때 모든 개념을 한 번에 이해하려고 하면 어렵습니다. 다음 순서로 익히면 훨씬 쉽습니다.
저장소를 만든다.
파일을 추가하거나 수정한다.
커밋으로 변경 이력을 남긴다.
GitHub에 푸시한다.
필요할 때 풀로 최신 내용을 가져온다.
브랜치에서 실험한다.
풀 리퀘스트로 검토하고 합친다.
이 흐름이 GitHub 학습의 뼈대입니다. 이후에 배우는 충돌 해결, 오픈소스 기여, 자동화, 배포도 결국 이 기본 흐름 위에 쌓입니다.
처음에는 명령어가 낯설 수 있습니다. 하지만 명령어는 목적을 실행하는 도구일 뿐입니다. "왜 이 명령을 쓰는지"를 알면 외우는 양이 줄어듭니다.
예를 들어 push라는 단어를 보았을 때 "온라인에 올리는 것"이라고 이해하면 됩니다. pull은 "온라인의 최신 내용을 가져오는 것"입니다. branch는 "실험 공간"입니다. 이렇게 목적과 연결해서 익히면 훨씬 오래 기억됩니다.
이 장에서 기억할 것
GitHub 학습의 시작점은 명령어 암기가 아닙니다. 변경 이력을 관리하고 협업 문제를 해결하는 전체 그림을 이해하는 것입니다.
핵심만 정리하면 다음과 같습니다.
Git은 내 컴퓨터에서 변경 이력을 관리하는 도구다.
GitHub는 Git 기록을 온라인에서 공유하고 협업하는 플랫폼이다.
버전 관리는
최종_진짜_마지막같은 파일 이름 혼란을 줄여준다.커밋은 의미 있는 저장 지점이다.
브랜치는 안전한 실험 공간이다.
푸시는 내 변경을 GitHub에 올리는 것이다.
풀은 GitHub의 변경을 내 컴퓨터로 가져오는 것이다.
풀 리퀘스트는 변경 내용을 합치기 전에 검토받는 과정이다.
앞으로의 장에서는 이 개념들을 실제로 손으로 따라 하며 익힙니다. 지금은 완벽히 외우지 않아도 됩니다. "Git은 기록, GitHub는 공유와 협업"이라는 큰 그림만 잡고 다음 단계로 넘어가면 됩니다.
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.