Git Gud!
You heard me. Alright, that was mean lol. Though based on the title, you probably already knew the...
개요 #
이력서에는 "Git"이라고 적어놨지만, 정작 손에 익은 건 GitHub Desktop 버튼 클릭뿐이었다. Dev.to에 올라온 이 글의 저자 FrancisTRᴅᴇᴠ가 밝힌 출발점이다. 그는 친숙한 UI와 쉬운 조작 때문에 처음부터 GitHub Desktop만 써왔고, 그래서 이력서의 저 한 줄이 계속 불편했다고 말한다.
해법은 단순했다. UI로 하던 일을 커맨드라인으로 다시 해보는 것. 저자는 UI와 터미널 양쪽을 다 이해하고 싶었다며, 자신이 실제로 자주 쓰게 된 명령어를 프로젝트 진행 순서대로 정리했다. 글 자체가 커뮤니티 피드백을 받으려는 목적도 겸하고 있다.
한 가지 짚고 갈 것: Git과 GitHub는 서로 다르다. 저자도 글 앞부분에서 이 점을 먼저 못 박는다.
Git과 게임 세이브 파일 #
저자는 각 명령어를 할로우 나이트: 실크송에 빗대 설명한다. 시각적으로 이해하는 독자를 위한 장치다. 새 게임을 시작하는 것, 기존 세이브 파일을 여는 것, 체크포인트를 남기는 것, 게임 버전을 업데이트하는 것 — Git의 주요 동작을 대략 이 네 갈래로 묶어 짚는다.
1. git init — 새 게임 시작 #
새 프로젝트를 시작할 때 가장 먼저 실행하는 명령이다. 기존 프로젝트인데 Git이 초기화되지 않은 상태라면 그때도 이 명령을 쓴다.
저자의 비유로는 실크송에서 새 게임을 켜는 단계다. 게임을 켜야 쓸 수 있는 기능이 열리는 것과 같다.
이미 Git이 초기화된 GitHub 저장소를 클론해 온 경우에는 실행할 필요가 없다. 실행해도 되지만 의미가 없다는 게 저자의 설명이다.
2. git clone url — 기존 세이브 파일 열기 #
이미 존재하는 프로젝트를 내 컴퓨터로 가져오고 싶을 때 쓴다. 저장소 페이지에서 HTTPS 링크를 복사한 뒤, VS Code 터미널에서 실행한다.
git clone https://github.com/forem/forem.git저자는 이걸 게임에서 기존 파일을 열어보는 것에 비유한다. 남의 파일을 내 기기로 가져오는 상황이라면 필요한 게 다 설치돼 있다고 가정하는 셈이고, 파일이 낡았으면 업데이트해야 한다. Git이 아예 없는 프로젝트라면 git init부터다.
클론할 때는 빈 폴더에서 실행하는 게 좋다.
3. git add filepath — 인벤토리에서 장착하기 #
프로젝트를 손보다 보면 변경 사항이 쌓인다. 커밋 전에, 브랜치로 보낼 파일을 먼저 추가해둔다.
변경한 파일이 많고 전부 한 커밋에 넣고 싶다면:
git add .특정 파일만 넣으려면 경로를 지정한다. 예를 들어 app 폴더 안의 tests.js를 수정했다면:
git add /app/tests.js알아두면 좋은 추가 명령
실수로 전체 파일을 추가했다면 되돌릴 수 있다.
git restore .특정 파일만 되돌릴 때도 마찬가지로 경로를 준다.
git restore /app/tests.js저자는 이 단계를 게임 속 부적(charm) 장착에 비유한다. 장착한 아이템이 추적 중인 파일(tracked files), 인벤토리에 모아둔 목록이 아직 추적하지 않는 파일에 해당한다. 실제로 쓰려고 꺼낸 것과, 지금까지 모으거나 손댄 것 전체의 차이다.
4. git commit -m "..." — 세이브 포인트 #
파일을 추가했으면 커밋할 준비가 끝났다. 저자는 커밋을 "체크포인트"로 본다. 게임을 이어서 하기 전에 저장해두는 것과 같다.
뭔가 완전히 잘못됐을 때는 이전 커밋으로 돌아갈 수 있다. 커밋이 세 개 있고 현재 C 위치라고 하자.
A --> B --> C (현재 위치)
B로 돌아가려면 B의 해시를 찾아 되돌린다.
# 커밋 해시 찾기
git log
# 특정 커밋 되돌리기
git revert <commit-hash>게임에서 이전 세이브 지점으로 돌아가는 것과 다르지 않다.
커밋 메시지는 무슨 작업을 했는지 꼭 채워 넣는 게 좋다. git commit -m "Update file"보다는 git commit -m "Fix a rerouting bug" 쪽이 낫다는 것이 저자의 조언이다.
5. git push origin main — 버전 맞추고 올리기 #
커밋과 변경 사항이 어느 정도 쌓였으면 GitHub 저장소로 올릴 차례다. 다만 올리기 전에 원격의 변경을 가져오는 습관이 좋다.
git fetch origin main저장소에는 변경이 있는데 로컬 개발 환경이 최신이 아니라면, fetch 다음에 이걸 실행한다.
git pull origin main저자는 이 과정을 게임 버전 관리로 설명한다. 게임이 낡았으면 최신 버전을 "fetch"해서 업데이트해야 세이브가 제대로 된다. 세이브 데이터가 현재 게임 버전과 맞지 않으면 충돌이 생길 수 있는데, 기초를 다루는 글이라 충돌 해결은 범위에서 빼뒀다.
6. 브랜치 만들고 옮겨 다니기 #
브랜치를 만들 때:
git branch nameBranch만든 브랜치로 옮겨 작업할 때:
git checkout existingBranch브랜치 생성과 전환을 한 번에 하고 싶으면 아래 명령을 쓴다. 저자는 이 방법을 @inayi의 댓글에서 알게 됐다고 밝혔다.
git checkout -b branchName7. git status — 지금 뭐가 잡혀 있나 #
이 명령은 추적 중인 파일과 그렇지 않은 파일을 주로 보여준다. 추적 중인 파일이 이번에 커밋될 대상이고, 추적되지 않는 파일은 변경됐지만 다가올 커밋에 포함되지 않은 것들이다. 어떤 파일이 바뀌었고 그중 무엇이 커밋에 들어가는지 파악하는 데 쓴다.
완벽한 목록은 아니다 #
저자는 글을 마무리하며 스스로 한계를 인정한다. 완벽하지 않고, 빠뜨린 것도 있을 거라고 말한다. git merge 같은 명령은 다루지 않았고, 단순하게 유지하려는 의도였다고 밝혔다. 어디까지나 GitHub Desktop에서 벗어나는 과정에서 자신이 자주 쓰게 된 명령어를 정리한 글이다.
그럼에도 목적은 분명하다. UI 클릭에서 벗어나 명령어를 손에 익히는 출발점으로는 충분하다. Git을 더 파고들고 싶다면 공식 문서(https://git-scm.com/docs)를 참고하라고 덧붙였다.
글 끝에는 독자 참여 요청도 있다. 알아두면 좋은 다른 명령어가 있으면 댓글로 남겨달라는 내용이다. 참고로 저자는 Doom: The Dark Ages 신규 트레일러 이야기도 곁들였다.
이 글은 위 출처를 바탕으로 한국 독자를 위해 재작성한 기사입니다. 원문의 사실과 수치에 근거하며, 별도의 견해를 포함하지 않습니다.