코드를 처음 작성했을 때 기억나시나요? 열심히 만든 파일을 실수로 덮어쓰고, 어떤 버전이 최신인지 몰라서 파일명에 “최최최종_진짜최종_이게맞음.zip”을 붙여본 경험, 한 번쯤 있으실 겁니다.
진짜예요. 저도 그랬으니까요. 처음 개발 공부를 시작했을 때 Git이라는 단어를 들으면 괜히 겁부터 났습니다. 명령어가 외계어처럼 보였고, GitHub는 “개발자들만 쓰는 뭔가 어려운 것”이라는 인식이 있었어요. 그런데 막상 써보니 달랐습니다.
Git과 GitHub를 제대로 익히면 버전 관리 걱정은 사라지고, 팀 협업이 눈에 띄게 편해집니다. 이 가이드는 그 첫걸음을 도와드리기 위한 글입니다. 설치부터 협업 워크플로까지, 단계별로 정리해 두었으니 필요한 섹션부터 읽으셔도 됩니다.
목차
Git 기초: 설치 및 환경 설정
💡 Git은 컴퓨터에 설치하는 버전 관리 도구입니다. 설치가 반이에요.
Git을 처음 접하는 분들이 가장 많이 막히는 부분이 바로 환경 설정입니다. 운영체제마다 설치 방법이 조금 다르고, 처음 보는 터미널 화면에 당황하는 경우가 많습니다. 솔직히 이 부분은 저도 처음엔 좀 헷갈렸어요.
Windows, macOS, Linux 각각 설치 방법이 다르고, 설치 후 사용자 이름과 이메일을 등록하는 초기 설정도 빠뜨리면 나중에 문제가 생깁니다. 처음 한 번만 제대로 해두면 그 이후는 훨씬 수월합니다.
그런데 말이에요, 설치보다 더 중요한 게 있습니다. 바로 Git이 실제로 어떤 방식으로 파일을 추적하는지를 개념적으로 이해하는 것입니다. 이 개념이 잡혀야 이후 명령어가 왜 그렇게 생겼는지 납득이 됩니다. 단순 암기가 아닌 이해로 접근하면 훨씬 오래 기억할 수 있어요.
Git 명령어 기초와 버전 관리
💡 init, add, commit 세 개만 익혀도 혼자 쓰는 버전 관리는 바로 시작할 수 있습니다.
Git을 배운다는 건 결국 명령어를 익히는 일입니다. 근데 전부 외울 필요는 없어요. 실제로 자주 쓰는 명령어는 생각보다 많지 않습니다. 제가 지난달에 직접 정리해 봤는데, 일상적인 개인 프로젝트에서는 10개 미만의 명령어로 대부분 해결됩니다.
핵심은 세 단계입니다. 작업 디렉토리 → 스테이징 영역 → 로컬 저장소. 이 흐름을 이해하면 git add와 git commit이 왜 분리되어 있는지 자연스럽게 납득이 됩니다. 처음엔 “왜 두 번이나 해야 돼?” 싶었는데, 써보니 이 구조가 꽤 유용합니다.
아 그리고, 브랜치 개념도 여기서 함께 다룹니다. 브랜치는 실험적인 작업을 메인 코드와 분리해서 진행할 수 있게 해주는 기능인데요. 망해도 괜찮은 브랜치를 하나 만들어놓고 마음껏 수정하고, 잘 되면 합치는 방식입니다. 이게 Git의 가장 큰 장점 중 하나예요.
Git과 GitHub의 핵심 개념 비교
💡 Git은 도구, GitHub는 그 도구를 쓰는 온라인 플랫폼입니다. 둘은 다릅니다.
이 부분에서 많은 분들이 혼동하십니다. Git과 GitHub는 이름이 비슷하지만 본질적으로 다릅니다.
간단히 말하면, Git 없이 GitHub를 쓰기는 어렵습니다. 반대로 Git만으로도 혼자 쓰는 버전 관리는 충분히 가능하고요. 두 개를 함께 쓸 때 진가가 발휘됩니다. 팀 프로젝트라면 특히요.
혹시 이 차이가 아직 헷갈리신다면, 아래 섹션들을 순서대로 읽으시면 자연스럽게 정리될 겁니다.
GitHub 초기 설정 및 저장소 생성
💡 저장소 하나 만드는 것만으로도 포트폴리오의 시작이 됩니다.
GitHub 계정을 만들고 나서 처음 저장소(Repository)를 생성할 때, 막막하게 느껴지는 분들이 많습니다. Public으로 해야 하나 Private으로 해야 하나, README는 뭐고 .gitignore는 왜 선택하라는 건지. 옵션이 많으면 오히려 시작이 어렵죠.
잠깐, 이건 꼭 알아야 해요. GitHub의 저장소는 크게 두 종류입니다. Public(공개)과 Private(비공개). 개인 학습용이나 포트폴리오 목적이라면 Public이 유리합니다. 채용 담당자나 협업 파트너가 바로 볼 수 있거든요. 반면 회사 업무나 개인 프로젝트라면 Private으로 관리하세요.
로컬 Git 저장소와 GitHub 원격 저장소를 연결하는 과정도 여기서 다룹니다. git remote add origin 명령어가 바로 그 연결 다리 역할을 합니다. 이 과정을 한 번 직접 해보면 생각보다 간단하다는 걸 느끼실 거예요.
자세히 읽어보기: GitHub 초기 설정 및 저장소 생성
협업 워크플로와 풀리퀘스트 사용법
💡 풀리퀘스트(PR)는 “내 코드 검토해주세요”라고 팀원에게 공식 요청하는 방법입니다.
이 부분이 Git과 GitHub를 배우는 진짜 이유라고 해도 과언이 아닙니다. 혼자 쓰는 버전 관리에서 팀 협업으로 넘어가는 순간이거든요.
제 주변의 한 개발자 지인은 처음 팀 프로젝트에 투입됐을 때 PR 개념을 몰라서 실수를 한 적이 있다고 했습니다. 직접 main 브랜치에 코드를 push해서 팀 전체 작업이 꼬여버린 거예요. 이후로 그 분은 브랜치 전략과 PR 프로세스를 정말 꼼꼼히 익혔다고 합니다. (이건 진짜 흔한 실수예요)
협업 워크플로의 핵심은 간단합니다.
- 메인 브랜치는 항상 안정된 코드만 유지
- 새 기능이나 수정은 별도 브랜치에서 작업
- 작업 완료 후 PR을 통해 코드 리뷰 요청
- 팀원 승인 후 메인 브랜치에 병합(Merge)
이 흐름을 익히면 오픈소스 프로젝트에 기여하는 것도 어렵지 않습니다. GitHub에서 가장 많이 쓰이는 협업 방식이기도 하고요.
flowchart LR
A[로컬 브랜치 생성] --> B[코드 작성 및 커밋]
B --> C[GitHub에 Push]
C --> D[풀리퀘스트 생성]
D --> E[팀원 코드 리뷰]
E --> F{승인 여부}
F -->|승인| G[main 브랜치에 Merge]
F -->|수정 요청| B
G --> H[브랜치 삭제]
자주 묻는 질문 (FAQ)
Git과 GitHub의 차이점은 무엇인가요?
Git은 컴퓨터에 설치하는 버전 관리 소프트웨어입니다. 인터넷 없이도 로컬에서 코드 히스토리를 추적하고 브랜치를 관리할 수 있습니다. 반면 GitHub는 Git 저장소를 온라인에 올려두고 다른 사람들과 공유하거나 협업할 수 있게 해주는 웹 플랫폼입니다. 쉽게 말하면, Git이 도구라면 GitHub는 그 도구로 작업한 결과물을 보관하고 공유하는 공간입니다. Git 없이 GitHub만 쓸 수는 없지만, GitHub 없이 Git만 쓰는 것은 가능합니다.
로컬 저장소와 원격 저장소는 어떻게 다릅니까?
로컬 저장소는 내 컴퓨터에 존재하는 Git 저장소입니다. 인터넷 연결 없이 작업하고, 커밋하고, 브랜치를 관리할 수 있습니다. 원격 저장소는 GitHub 같은 온라인 플랫폼에 올라가 있는 저장소입니다. 팀원들과 코드를 공유하거나 백업 용도로 사용합니다. 로컬에서 작업한 내용을 git push로 원격에 올리고, 원격의 최신 내용을 git pull로 내려받는 방식으로 두 저장소를 동기화합니다.
브랜치가 충돌할 경우 어떻게 해결하나요?
브랜치 충돌(Merge Conflict)은 두 브랜치에서 같은 파일의 같은 부분을 서로 다르게 수정했을 때 발생합니다. 겁먹을 필요 없어요. Git은 충돌이 발생한 위치를 파일 안에 명확하게 표시해줍니다. <<<<<<<, =======, >>>>>>> 기호로 구분된 부분이 바로 충돌 구간입니다. 두 버전 중 어느 것을 유지할지, 혹은 두 내용을 합칠지 직접 편집한 뒤 저장하고, 다시 git add와 git commit을 실행하면 됩니다. VS Code 같은 에디터는 충돌 해결 UI를 제공하기 때문에 훨씬 편하게 처리할 수 있습니다.
마무리하며
Git과 GitHub는 처음 접하면 낯설고 복잡해 보이지만, 핵심 개념 몇 가지만 잡히면 생각보다 빠르게 익숙해집니다. 설치와 환경 설정부터 시작해서 명령어, 저장소 생성, 협업 워크플로까지 단계별로 차근차근 따라오시면 됩니다.
위에 정리된 각 서브 포스트는 하나하나 독립적으로 읽을 수 있도록 구성되어 있습니다. 막히는 부분이 생기면 해당 글로 돌아와서 다시 확인하시면 됩니다. 처음부터 전부 외우려 하지 않아도 됩니다. 써보면서 익히는 게 훨씬 빠르거든요.
오늘 배운 내용이 실제 프로젝트에서 도움이 되길 바랍니다.
답글 남기기