개발자들 사이에서 "깃허브 없이는 개발 못 한다"라는 말이 나올 정도로 GitHub는 현대 소프트웨어 개발의 심장과도 같습니다. 단순히 코드를 저장하는 곳을 넘어, 전 세계 개발자들과 소통하고 협업하는 거대한 플랫폼이죠.

하지만 초보자에게 git push, git pull, merge conflict 같은 용어들은 외계어처럼 느껴질 수 있습니다. 협업 중에 코드를 잘못 건드려 팀원들의 작업을 망칠까 봐 겁이 나기도 하죠. 오늘 이 글에서는 협업을 위해 반드시 알아야 할 깃허브의 핵심 원리와 필수 명령어들을 실무 중심으로 정리해 드립니다.

Git과 GitHub의 차이점 이해하기

먼저 깃(Git)과 깃허브(GitHub)의 차이를 명확히 알아야 합니다. Git은 내 컴퓨터에서 코드의 변경 이력을 관리하는 '도구(Software)'입니다. 게임으로 치면 '세이브 파일 관리 시스템'이라고 볼 수 있죠.

GitHub는 이 Git으로 관리하는 프로젝트들을 온라인에 올려두는 '저장소(Cloud Service)'입니다. 내 세이브 파일을 클라우드에 올려서 친구들과 공유하고 함께 플레이하는 공간이라고 생각하면 쉽습니다.

로컬 저장소 만들기: git init와 git clone

새로운 프로젝트를 시작할 때 Git에게 "이제부터 이 폴더를 관리해 줘"라고 명령하는 것이 git init입니다. 이 명령어를 입력하면 눈에 보이지 않는 .git 폴더가 생성되며 이력 관리가 시작됩니다.

반대로 이미 깃허브에 올라와 있는 다른 사람의 프로젝트를 내 컴퓨터로 그대로 복제해 오고 싶을 때는 git clone [저장소 주소]를 사용합니다. 협업의 시작은 대개 이 클론 작업부터 이루어집니다.

변경 사항 기록하기: git add와 git commit

코드를 수정했다면 이제 '세이브'를 해야 합니다. 이때 과정이 두 단계로 나뉩니다. 먼저 git add [파일명]을 통해 세이브할 파일들을 장바구니에 담습니다. (이를 Staging Area라고 합니다.)

그다음 git commit -m "수정 메시지"를 입력하여 실제로 기록을 남깁니다. 커밋 메시지는 나중에 내가 무엇을 고쳤는지 알 수 있도록 "로그인 기능 버그 수정"처럼 명확하게 적는 습관이 중요합니다.

서버로 전송하고 가져오기: git push와 git pull

내 컴퓨터(로컬)에서 커밋한 내용을 온라인 저장소(GitHub)에 반영하는 명령어가 git push입니다. 비로소 다른 팀원들이 내가 작업한 내용을 볼 수 있게 되는 순간입니다.

반대로 팀원이 업데이트한 최신 코드를 내 컴퓨터로 가져올 때는 git pull을 사용합니다. 작업을 시작하기 전에는 항상 git pull을 먼저 해서 최신 상태를 유지하는 것이 충돌을 방지하는 지름길입니다.

독립적인 작업 공간: git branch의 활용

협업의 핵심은 '브랜치(Branch)'입니다. 메인 코드 줄기(Main)에서 가지를 뻗어 나와 나만의 작업 공간을 만드는 것입니다. git branch [이름]으로 생성하고 git checkout [이름]으로 이동합니다.

새로운 기능을 만들거나 실험적인 코드를 짤 때 브랜치를 사용하면, 설령 코드가 망가지더라도 메인 코드에는 아무런 영향을 주지 않습니다. 작업이 완료되면 검토를 거쳐 메인 줄기에 합치게 됩니다.

작업 합치기와 충돌 해결: git merge

브랜치에서 작업이 끝났다면 다시 메인 줄기로 합쳐야 합니다. 이때 사용하는 것이 git merge입니다. 하지만 같은 파일의 같은 줄을 두 사람이 동시에 고쳤다면 '충돌(Conflict)'이 발생합니다.

충돌은 오류가 아니라 Git이 "어느 쪽 코드가 맞는지 내가 모르겠으니 직접 골라줘"라고 요청하는 것입니다. 코드를 직접 확인하고 수정한 뒤 다시 커밋하면 해결됩니다. 충돌을 두려워하지 마세요. 성장의 기회입니다.

협업의 꽃: Pull Request (PR)

실무 협업에서는 merge를 직접 하기보다 'Pull Request(PR)' 과정을 거칩니다. "내가 이만큼 수정했는데 메인에 합쳐도 될까?"라고 팀원들에게 요청을 보내는 것입니다.

팀원들은 내가 짠 코드를 보고 의견을 남기거나 수정 제안을 할 수 있습니다(Code Review). 이 과정을 통해 코드의 품질이 높아지고 팀 전체가 진행 상황을 공유하게 됩니다. 깃허브를 사용하는 가장 강력한 이유이기도 합니다.

상태 확인과 이력 조회: git status와 git log

작업을 하다가 "내가 지금 어떤 파일을 수정했지?" 궁금할 때는 git status를 입력하세요. 현재 장바구니에 담긴 파일과 수정된 파일 목록을 한눈에 보여줍니다.

지금까지 어떤 커밋들이 있었는지 히스토리를 보고 싶다면 git log를 사용합니다. 누가, 언제, 어떤 메시지로 코드를 고쳤는지 상세히 확인할 수 있어 문제 발생 시 원인을 추적하기 매우 좋습니다.

자주 발생하는 실수와 대처법

실수로 파일을 잘못 삭제했거나 이전 커밋으로 되돌리고 싶을 때는 git restore나 git reset을 사용합니다. 하지만 reset은 신중해야 합니다. 이미 push한 커밋을 삭제하면 팀원들의 저장소가 꼬일 수 있기 때문입니다.

만약 커밋 메시지에 오타를 냈다면 git commit --amend로 바로 수정할 수 있습니다. 당황하지 말고 명령어를 하나씩 찾아보며 해결해 나가는 것이 중요합니다.

마치며: 깃허브는 개발자의 이력서

깃허브 사용법을 익히는 것은 단순히 협업 툴을 배우는 것이 아닙니다. 여러분이 어떤 고민을 하며 코드를 짰는지, 어떻게 팀원과 소통했는지를 보여주는 가장 확실한 증거가 됩니다.

오늘 배운 명령어들을 직접 터미널에 입력해 보며 작은 프로젝트부터 시작해 보세요. 잔디 심기(매일 커밋하기)를 꾸준히 하다 보면 어느새 훌륭한 협업 능력을 갖춘 개발자로 성장해 있을 것입니다.