Git을 처음 쓰는 사람에게 첫 주가 중요한 이유

Git은 초보자에게 거의 외국어처럼 느껴진다. add, commit, push를 외워도 실제 작업 중에는 무엇을 먼저 해야 할지 자주 헷갈린다.

그래서 첫 주의 목표는 어려운 브랜치 전략이 아니라, 현재 변경 사항을 보고 안전하게 기록하는 흐름을 익히는 것이다.

명령을 외우는 대신 상태를 읽는 쪽으로 방향을 잡으면, Git은 암기 과목이 아니라 관찰 도구가 된다.

Git은 현재 상태를 보는 도구이기도 하다

코드를 작성한 뒤 Git으로 보는 첫 화면은 대개 git status다. 이 한 명령만 익숙해져도 내가 무엇을 바꿨고, 아직 무엇이 기록되지 않았는지 파악하기 쉬워진다.

초보자에게 Git은 팀 협업 도구이기 전에, 내 변경을 잃지 않게 기록하는 안전장치다. 그리고 안전장치는 걸어 둔 시점이 많을수록 좋다.

status 화면을 실제로 읽어 본다

status 출력은 짧아 보이지만 세 구역으로 나뉜다. 기록될 예정인 것, 바뀌었지만 아직 담기지 않은 것, Git이 처음 보는 것이다. 이 세 구역이 눈에 들어오면 add가 무엇을 하는 명령인지 설명 없이도 이해된다.

GIT STATUS

$ git status
On branch main
Changes to be committed:
        modified:   score.py

Changes not staged for commit:
        modified:   README.md

Untracked files:
        .env
        __pycache__/

score.py만 다음 커밋에 담긴다. README.md는 수정됐지만 아직 담기지 않았고, 아래 둘은 Git이 관리한 적 없는 파일이다.

여기서 초보자가 놓치기 쉬운 것은 세 번째 구역이다. .env와 __pycache__/는 저장소에 들어가면 안 되는 파일인데, git add .를 습관처럼 치면 둘 다 함께 들어간다. 비밀값이 한 번 커밋되면 나중에 지워도 기록에는 남는다. 그래서 첫 주에 배울 명령 목록에는 .gitignore 파일을 만드는 일이 반드시 들어가야 한다.

.gitignore

.env
__pycache__/
node_modules/
*.log

여기에 적힌 것은 status의 Untracked 목록에서 사라진다. 저장소가 조용해진다.

기록까지 가는 최소 흐름

흐름 자체는 세 걸음이다. 무엇이 바뀌었는지 보고, 그중 함께 묶일 것을 담고, 한 문장으로 이름을 붙여 저장한다. 명령의 개수보다 이 순서가 몸에 붙는 것이 먼저다.

GIT

git status
git diff
git add score.py
git commit -m "평균 계산에서 빈 리스트 처리 추가"

add와 commit 사이에 diff를 한 번 끼우면, 의도하지 않은 변경이 섞여 들어가는 일이 크게 줄어든다.

커밋 메시지는 거창할 필요가 없지만 무엇을 했는지는 남아야 한다. 수정, 업데이트, 작업중 같은 단어만 있는 메시지는 사흘 뒤의 나에게 아무 정보도 주지 않는다. 무엇을 왜 바꿨는지 한 줄이면 충분하다.

커밋 시점

기능이 완성됐을 때가 아니라, 지금 상태로 돌아오고 싶을 때 커밋하십시오. 하루에 한 번보다 막히기 직전에 한 번이 훨씬 유용합니다.

첫 주에 꼭 익히면 좋은 것

status로 현재 상태 확인하기
diff로 실제 바뀐 줄 확인하기
.gitignore를 만들어 비밀값과 캐시 폴더 제외하기
commit이 저장 지점이라는 감각 익히기
메시지를 너무 거창하게 쓰지 않고 변경 내용을 짧게 적기
뭔가 이상할 때는 일단 status부터 다시 보기

원격 저장소는 언제 붙이나

로컬 커밋에 익숙해지기 전에 push부터 배우면, Git이 하는 일 두 가지가 머릿속에서 하나로 뭉친다. 기록하는 것과 다른 컴퓨터로 보내는 것은 별개의 동작인데, 처음에 git add부터 git push까지를 한 덩어리 주문처럼 외우면 중간에 뭐가 잘못됐을 때 어디를 볼지 알 수 없다.

순서는 반대가 낫다. 며칠 로컬에서만 커밋해 보고, 커밋이 눈에 익은 뒤에 원격을 붙인다. 그러면 push가 하는 일이 이미 만들어 둔 기록을 그대로 옮기는 것뿐이라는 게 자연스럽게 이해된다.

REMOTE

git remote add origin https://github.com/<id>/<repo>.git
git branch -M main
git push -u origin main

세 줄은 처음 한 번만 필요하다. 그 뒤로는 git push만 치면 된다.

여기서 실패하는 경우의 대부분은 Git 문제가 아니라 인증 문제다. 비밀번호를 물어보고 계속 거부한다면 명령을 의심하기 전에 토큰이나 SSH 키 설정을 먼저 보십시오. 에러 문장에 authentication이나 permission이라는 단어가 있으면 그쪽이다.

미뤄도 되는 것과 미루면 안 되는 것

첫 주에 rebase, cherry-pick, reset의 세 가지 모드 같은 것을 배울 필요는 없다. 혼자 만드는 프로젝트에서 브랜치 전략을 공부하는 것도 대개 이르다. 쓸 일이 없는 명령은 외워도 이틀이면 사라진다.

다만 이 조언에는 조건이 붙는다. 혼자 작업할 때만 그렇다. 첫 주부터 다른 사람과 같은 저장소를 쓴다면 브랜치는 선택이 아니라 최소 안전장치다. main에 직접 커밋하고 push하는 두 사람은 사흘 안에 서로의 작업을 덮어쓴다. 팀이 있다면 브랜치를 만들고 합치는 흐름만큼은 첫 주에 배워야 한다.

반대 방향의 함정도 있다. Git을 완전히 이해한 다음에 쓰겠다며 학습을 미루는 경우다. Git은 이해하고 쓰는 도구가 아니라 쓰면서 이해하는 도구에 가깝다. 커밋을 백 번쯤 하고 나면 그때 읽는 설명이 훨씬 잘 들어온다.

정리하면 첫 주의 기준은 이렇다. 지금 하는 작업에 필요하면 배우고, 아니면 미룬다. 그리고 그 기준을 적용할 수 있으려면 status와 diff로 현재 상태를 읽을 줄 알아야 한다. 결국 다시 상태 읽기로 돌아온다.

겁먹지 않아도 되는 이유

커밋한 내용은 웬만해서는 사라지지 않습니다. 무서운 명령은 커밋하지 않은 변경을 지우는 쪽이니, 이상한 명령을 실행하기 전에 커밋부터 해 두면 대부분의 사고는 되돌릴 수 있습니다.

초보자에게 Git은 팀 도구이기 전에, 내 변경을 잃지 않게 기록하는 안전장치다.

도구와 디버깅

더 볼 것

커밋에 비밀값이 섞여 들어가는 문제는 Git보다 프로젝트 설계 쪽 이야기입니다. 첫 프로젝트의 보안 기본에서 환경 변수 분리를 함께 보시고, 터미널 자체가 아직 어색하다면 명령줄 첫 습관을 먼저 읽는 편이 순서상 편합니다.

이 글의 포인트

Git 입문은 명령어 암기보다 상태 읽기부터 시작한다.
status의 세 구역을 구분할 수 있으면 add의 의미가 저절로 잡힌다.
.gitignore는 첫 주에 만드는 것이 나중에 지우는 것보다 싸다.
혼자면 브랜치를 미뤄도 되지만, 팀이면 첫 주에 배워야 한다.
이상할 때는 복잡한 명령보다 git status부터 보는 습관이 좋다.