혼자서 처음으로 코드를 짜기 시작했을 때, 누구나 한 번쯤 이런 상황을 겪습니다. “잘 되던 코드가 갑자기 안 돼. 뭘 고쳤더라?” 그 순간 머릿속이 하얘지죠. Git 명령어를 알았더라면 이런 공포가 없었을 겁니다.
이 글은 Git을 처음 쓰는 분들이 실제로 프로젝트를 혼자 시작할 때 가장 많이 쓰는 명령어들만 골라서 설명합니다. 이론 말고, 바로 써먹을 수 있는 것들로요.
저장소 시작하기: git init과 git add
💡 git init으로 Git을 시작하고, git add로 저장할 파일을 선택합니다. 이 두 명령어가 버전 관리의 시작입니다.
프로젝트 폴더에서 터미널을 열고 처음 입력하는 명령어가 바로 git init입니다. 이걸 치면 폴더 안에 .git이라는 숨김 폴더가 생겨요. 여기에 모든 변경 이력이 저장됩니다.
근데 말이에요, git init을 한다고 해서 파일이 자동으로 Git에 저장되는 건 아닙니다. “어떤 파일을 저장할 거야?”를 Git에게 알려주는 과정이 따로 필요해요. 그게 바로 git add입니다.
- git init — 현재 폴더를 Git 저장소로 초기화
- git add 파일명 — 특정 파일을 저장 대상으로 지정
- git add . — 현재 폴더의 모든 파일을 저장 대상으로 지정
제가 처음 git add .를 배웠을 때, 점(.)이 “현재 폴더 전체”를 의미한다는 걸 몰라서 왜 이게 되나 한참 헷갈렸어요. (이건 진짜 초보 시절 얘기예요.) 이제는 너무 당연한 거지만요.
혹시 “git add를 했는데 아무것도 안 일어나는 것 같아요”라고 느끼시는 분? 맞아요. git add는 눈에 보이는 변화가 없어요. 그냥 “내가 이 파일들을 저장할 준비가 됐어”라고 목록에 올려두는 것뿐입니다. 실제 저장은 다음 단계에서 이루어집니다.
변경 사항 저장하기: git commit
💡 git commit은 add로 선택한 파일들을 실제로 저장하는 명령어입니다. 메시지를 꼭 남겨야 나중에 무슨 작업이었는지 알 수 있습니다.
잠깐, 이건 꼭 알아야 해요. git commit은 단순히 저장하는 게 아닙니다. 하나의 의미 있는 작업 단위를 기록하는 것입니다. 나중에 “3일 전에 뭘 바꿨더라?”를 확인할 때 이 기록이 생명줄이 됩니다.
기본 문법은 이렇습니다.
- git commit -m “메시지 내용”
메시지는 짧고 명확하게 쓰는 게 좋습니다. “수정함”, “고침” 같은 말은 의미가 없어요. 대신 “로그인 버튼 클릭 시 오류 수정”, “메인 페이지 레이아웃 변경” 이런 식으로 써두면 나중에 한눈에 파악됩니다.
주변에서 개발을 막 배우기 시작한 20대 초반 분이 “커밋 메시지가 귀찮아서 그냥 ‘1’, ‘2’, ‘3’으로 남겼더니 나중에 뭐가 뭔지 몰라서 전부 다시 짰다”고 했어요. 웃프지만 이게 현실입니다. 처음부터 습관 들이는 게 훨씬 이득이에요.
변경 사항 확인하기: git status와 git diff
💡 git status로 어떤 파일이 변경됐는지 확인하고, git diff로 구체적으로 무엇이 바뀌었는지 볼 수 있습니다.
아 그리고, 이 두 명령어는 거의 매일 쓰게 될 거예요. 특히 “내가 지금 뭘 바꿨더라?” 싶을 때 바로 쓰는 명령어입니다.
- git status — 현재 저장소 상태 확인 (어떤 파일이 수정됐는지, add됐는지)
- git diff — add 전 파일의 구체적인 변경 내용 확인
- git diff –staged — add 이후 commit 전 변경 내용 확인
git status를 치면 빨간색과 초록색 글씨가 나옵니다. 빨간색은 “아직 add 안 한 파일”, 초록색은 “add 해서 commit 준비된 파일”이에요. 처음엔 헷갈릴 수 있는데, 색깔 기억해두면 금방 익숙해집니다.
git diff는 실제로 줄 단위로 뭐가 바뀌었는지 보여줍니다. 추가된 줄은 + 표시, 삭제된 줄은 – 표시로 나와요. 솔직히 처음 보면 뭔지 모르겠는데, 두세 번 써보면 바로 읽힙니다.
브랜치 생성과 전환, 그리고 히스토리 확인
💡 브랜치는 메인 코드를 건드리지 않고 새로운 작업을 시도할 수 있는 복사본 같은 개념입니다.
여기서 반전인데, 브랜치는 처음엔 “이게 왜 필요하지?” 싶지만 한 번 쓰고 나면 없으면 못 삽니다.
예를 들어 “새로운 기능을 추가해봐야 하는데, 원본은 건드리기 싫어”라는 상황에서 브랜치를 만들면 됩니다. 원본은 그대로 두고 새 브랜치에서 마음껏 실험할 수 있어요.
- git branch 브랜치명 — 새 브랜치 생성
- git checkout 브랜치명 — 해당 브랜치로 이동
- git checkout -b 브랜치명 — 생성과 이동을 동시에
- git log — 커밋 히스토리 전체 확인
- git log –oneline — 한 줄씩 간결하게 확인
git log –oneline은 특히 자주 쓰게 될 거예요. 커밋 내역을 한 줄씩 깔끔하게 보여주거든요. 히스토리가 길어졌을 때 한눈에 파악하기 좋습니다.
gitGraph commit id: "초기 프로젝트 생성" commit id: "메인 페이지 레이아웃 작성" branch feature/login checkout feature/login commit id: "로그인 폼 추가" commit id: "로그인 유효성 검사" checkout main commit id: "README 업데이트" merge feature/login id: "로그인 기능 병합"
이게 실제 브랜치 흐름을 시각화한 거예요. main 브랜치를 건드리지 않고 feature/login 브랜치에서 작업한 뒤 나중에 합치는 방식입니다. 혼자 작업해도 이렇게 관리하면 나중에 어떤 기능을 언제 추가했는지 한눈에 보입니다.
Git 명령어 처음 배울 때 가장 헷갈리는 게 init → add → commit의 흐름인데, 이 세 가지만 확실히 잡으면 나머지는 자연스럽게 따라옵니다. 이거 저만 어렵게 느꼈던 건 아닐 거예요. 분명 공감하실 분들 계실 겁니다.
답글 남기기