Git 자주 쓰는 명령어 정리, 헷갈릴 때 먼저 보는 다섯 가지

Git은 자주 쓰는 명령어만 익혀도 절반은 끝납니다. 그런데 막상 터미널 앞에 서면 status부터 헷갈리고, checkout이랑 switch도 뒤섞이기 쉽죠. 저도 처음엔 그랬고, 직접 돌려보니 pull 방식 하나만 안 맞아도 바로 막히더라고요.

간단합니다.

그때는 몰랐는데, 자주 쓰는 명령어는 따로 있습니다. 오늘은 제가 실제로 써 보면서 정리한 흐름으로, 실수 줄이는 쪽에 맞춰 풀어볼게요.

이런 문제 있으신가요?

저장소를 건드렸는데 지금 뭐가 바뀌었는지 모르겠고, 커밋은 했는지 안 했는지도 헷갈릴 때가 있잖아요. 음, 그럴 땐 무작정 명령어를 외우는 것보다 흐름부터 잡는 게 훨씬 낫습니다.

제가 직접 테스트해보니, 서로 다른 시작점에서 만든 두 저장소를 git pull origin main 하자 바로 이런 메시지가 떴어요.

fatal: Need to specify how to reconcile divergent branches.

진짜 그랬어요. 그래서 바로 손대기보다, pull 방식을 먼저 정해 주는 게 맞다는 걸 다시 느꼈습니다. 스택오버플로우 답변에 따르면 이런 경우에는 git config pull.rebase true 같은 식으로 기준을 분명히 잡아 두는 편이 덜 헷갈립니다.
참고 링크: https://stackoverflow.com/questions/62653114/how-can-i-deal-with-this-git-warning-pulling-without-specifying-how-to-reconci

💡

핵심은 간단해요.
상태 확인, 변경 등록, 저장, 브랜치 이동, 파일 되돌리기.
이 다섯 개만 먼저 익혀도 Git이 훨씬 덜 무섭습니다.

원인 분석: 왜 이런 일이 생길까

공식 문서를 확인하면 git add는 새로 바뀐 내용을 올려 두는 역할이고, git commit은 그 상태를 저장하는 역할이에요.
반대로 git reset은 HEAD나 올려 둔 내용을 기준 상태로 맞추는 명령이라서, 손이 빠른 만큼 조심도 필요합니다.

또 하나. git checkout은 예전부터 오래 쓰였지만, 요즘은 git switch와 git restore로 역할이 나뉘어 있어요.
브랜치 바꾸는 일은 switch, 파일 되돌리는 일은 restore.
이렇게 갈라 놓으니 실수가 줄어들더라고요.

공식 설치 페이지에는 최신 버전이 2.55.0으로 표시돼 있고, 공식 문서도 그 기준으로 확인할 수 있어요. 버전이 바뀌면 세부 동작이 조금씩 달라질 수 있으니, 문서 버전 확인은 은근 중요합니다.

실전에서 바로 쓰는 팁

아래 다섯 개만 먼저 손에 익히면 됩니다. 복잡한 명령어보다 자주 쓰는 명령어가 먼저예요.

• git status
  지금 뭐가 바뀌었는지 봅니다. 제일 먼저 치면 돼요.
• git add 파일이름
  커밋할 내용을 올립니다. 한 번에 다 올릴 때는 git add .도 자주 써요.
• git commit -m "메시지"
  변경 내용을 저장합니다. 메시지는 짧고 분명하게 쓰는 게 좋아요.
• git switch 브랜치이름
  브랜치를 바꿉니다. 예전 checkout보다 의도가 더 또렷해요.
• git restore 파일이름
  파일을 이전 상태로 되돌립니다. 아차, 싶을 때 많이 씁니다.

아래처럼 외우면 편해요.

확인 → 올리기 → 저장 → 이동 → 되돌리기

공식 문서를 확인하면 git restore는 작업 트리 파일을 복원하고, --staged를 붙이면 올려 둔 내용도 다룰 수 있어요.
문서 링크: https://git-scm.com/docs/git-restore

브랜치 이동은 뭐가 더 나을까

저는 지금 새로 배우는 분이면 git switch를 먼저 권합니다.
이유는 단순해요. 덜 헷갈리거든요.
그리고 파일 되돌리기는 git restore, 기록 되돌리기는 git reset으로 나누면 머리가 훨씬 편합니다.

꼭 피해야 할 주의사항

git reset은 편하지만 세게 쓰면 되돌리기 까다로울 수 있어요.
특히 --hard는 작업 내용을 날릴 수 있으니, 습관처럼 치면 안 됩니다. 그러면 안 되죠.

또 git pull이 막혔다고 바로 강제 옵션부터 붙이는 것도 위험합니다.
먼저 내 브랜치와 원격 브랜치 상태를 확인하고, merge로 갈지 rebase로 갈지 정하는 게 안전해요.
공식 문서를 보면 git status로 상태를 보고, git reset으로 기준을 조절하고, git restore로 파일 단위 복원을 하는 흐름이 훨씬 안정적입니다.

돌이켜보면, Git은 어려운 도구라기보다 순서를 자꾸 잊게 만드는 도구에 가깝습니다.
순서만 잡히면 생각보다 단순해요.

마무리

오늘은 Git 자주 쓰는 명령어 정리를 해봤습니다.
핵심은 딱 다섯 가지예요. status, add, commit, switch, restore. 여기에 reset만 조심해서 붙이면 실수 확 줄어듭니다.
한 번에 다 외우지 말고, 오늘은 두 개만 손에 익혀 보세요. 내일 또 하나. 그게 제일 오래 갑니다.

끝까지 읽어주셔서 고맙습니다. 궁금한 점은 댓글로 알려주세요.
이 글이 조금이라도 도움이 됐다면 다음 글도 기대해 주세요.

자주 묻는 질문

Q. git switch와 git checkout은 뭐가 다른가요?
A. 둘 다 브랜치를 바꾸는 데 쓰이지만, git switch가 더 단순하고 의도가 분명합니다. 새로 익히기엔 switch가 더 편해요.

Q. git add는 꼭 해야 하나요?
A. 네, 보통은 필요합니다. 커밋할 내용을 먼저 올려 두는 단계라고 보면 됩니다.

Q. git restore는 언제 쓰면 되나요?
A. 작업한 파일을 이전 상태로 되돌리고 싶을 때 씁니다. 실수로 고친 내용을 취소할 때 유용해요.

Q. git reset은 무서운 명령어인가요?
A. 무서운 편입니다. 특히 --hard는 내용이 사라질 수 있어서, 꼭 필요한 경우에만 써야 해요.

Q. 처음 배우는 사람은 무엇부터 익히면 좋을까요?
A. git status부터입니다. 그다음 add, commit, switch, restore 순서로 가면 흐름이 잘 잡혀요.

#깃 #깃명령어 #깃정리 #개발팁 #터미널

2026년 신입 개발자라면, Git 자주 쓰는 명령어 정리 — 이것만 외우면 반은 한다

요즘 면접 보면 Git 사용 경험을 거의 필수로 물어보는 시대죠. 근데 막상 처음 배우는 사람 입장에서 명령어가 너무 많아서 막막한 거예요. 저도 첫 주에 checkout이랑 revert 헷갈려서 한참 헤맸습니다. 오늘은 자주 쓰는 명령어만 콕콕 짚어서 정리해 봤어요.

Git 자주 쓰는 명령어 정리에 대해 자주 묻는 질문 5가지

IT 커뮤니티와 GitHub Discussions를 보면 비슷한 질문이 정말 많이 올라옵니다. 흔한 것들만 추려봤어요. 진짜 자주 물어요, 이거.

Q. rebase랑 merge, 뭘 써야 하나요? 둘 다 결과는 비슷합니다. 다만 rebase는 커밋 이력을 깔끔하게 정리할 수 있어요. 공식 Git 문서(https://git-scm.com/docs/git-rebase)에서도 "history를 재작성하는 도구"라고 명시돼 있습니다. 개인적으로는 팀 정책에 맞춰 쓰는 게 제일 안전해요.

Q. reset이랑 revert는 다른 건가요? 맞아요, 엄연히 다릅니다. reset은 커밋 자체를 지우는 거고, revert는 되돌리기용 신규 커밋을 만드는 거예요. 이미 푸시한 커밋은 revert만 써야 안전합니다. Stack Overflow 답변들도 이 차이를 정확히 짚어주죠.

Q. stash는 언제 쓰나요? 작업 중인데 급하게 다른 브랜치로 옮겨야 할 때, 임시로 변경사항을 저장해두는 기능이에요. 간단히 말하면 "옮겨놓기통" 같은 거예요.

Q. clone이랑 pull 차이가 뭔가요? clone은 처음 받을 때, pull은 이미 받은 저장소를 최신 상태로 동기화할 때 씁니다. 되게 자주 헷갈리는 부분이잖아요.

Q. GitHub에 push가 안 돼요. 권한 문제일 가능성이 큽니다. PAT(Personal Access Token)나 SSH 키 설정을 먼저 확인해 보세요. GitHub 이슈 트래커에도 같은 증상이 자주 보고됩니다.

💡

처음부터 모든 옵션 외울 필요 없어요. 기본 흐름만 익히고, 필요할 때마다 한 개씩 더 배워가면 됩니다. 어차피 그렇게 늘더라고요.

실제 사례: 이런 분들은 이렇게 했습니다

옛날에 제가 처음 Git 쓸 때 얘기 하나만 해볼게요. 브랜치 이름 잘못 적었는데 그냥 -D로 강제 삭제해버린 적 있었어요. 처음엔 멀쩡한 줄 알았는데, 일주일 뒤 그 브랜치의 커밋이 통째로 사라진 거예요. 진짜 그랬어요.

그때는 몰랐는데. git reflog라는 명령어가 있었더라고요. 치면 HEAD가 가리켰던 모든 기록이 쭉 나옵니다. 거기서 커밋 해시 잡고 cherry-pick으로 살려냈어요. 살짝 무서웠지만, 결국 복구는 됐습니다.

GitHub 이슈 트래커에도 비슷한 사례가 여러 건 보고돼 있어요. "강제 리셋 후 복구"라는 주제로 종종 보이거든요. 2024년 한 해 동안만 관련 이슈가 수십 건은 올라왔던 걸로 기억합니다.

또 다른 케이스로, 협업 중 충돌(conflict)이 계속 나는 분들이 있어요. 이럴 땐 일단 git status로 상태부터 봅니다. 어떤 파일이 충돌났는지, staged 되어 있는지, 한눈에 다 나와요. 그다음 충돌 마커(<<<<<<<)를 직접 수정하는 게 가장 확실하답니다. 참고로, GUI 툴로 해결해도 무방합니다.

단계별 솔루션 따라하기

자, 이제 실제로 자주 쓰는 명령어 셋트로 넘어갈게요. 처음엔 이 정도만 외우셔도 충분합니다. 표로 한 번에 봤어요.

공식 릴리스 노트에 따르면, Git 2.43(2024년 5월)부터는 git rebase --update-refs 옵션이 도입됐다고 합니다. reference 업데이트를 자동으로 해주는 기능이에요. 써보면 꽤 편리하답니다.

추천 워크플로우는 단순합니다. add → commit → push. 딱 이거예요. 처음엔 이 세 명령어만 자유자재로 쓸 수 있어도, 협업에 들어갈 수 있어요. 그때는 몰랐는데, 사실 입문 단계에선 그것만으로도 충분했습니다.

체크리스트: 이것만 확인하세요

마지막으로, 막상 쓰다 보면 깜빡하는 항목만 추렸어요. 한번씩 훑어주시면 좋아요. 돌이켜보면, 저는 이 리스트 중 반도 안 챙기고 시작했더라고요.

• [ ] 작업 시작 전 항상 git status
• [ ] 커밋 메시지는 한 줄 요약 + 상세 설명 2줄
• [ ] 푸시 직전 git diff --staged로 변경 내역 확인
• [ ] 다른 사람 작업 가져올 땐 git pull 먼저
• [ ] 새 기능은 브랜치 따로 파서 진행
• [ ] merge 끝나면 불필요한 브랜치는 정리
• [ ] .gitignore에 환경변수·빌드 산출물 등록
• [ ] 충돌 떴을 때 무작정 --force 금지
• [ ] 패스워드는 PAT, 키 인증은 SSH로

아홉 개쯤 되네요. 근데 다 중요합니다.

자주 묻는 질문 더 보기

Q. Git을 CLI로만 익혀야 할까요? 꼭 그렇진 않아요. VS Code나 JetBrains IDE에도 Git UI가 내장돼 있습니다. 다만 도구 쓰다 문제 생기면 결국 터미널로 돌아오게 돼요. 인 셈이에요.

Q. 커밋 메시지 관례가 있나요? 있어요. Conventional Commits(https://www.conventionalcommits.org/ko)라는 규약이 널리 쓰입니다. feat:, fix:, docs: 같은 prefix를 붙이는 방식이죠.

Q. Git GUI 툴 추천해주세요. 소스트리(SourceTree)가 입문자에겐 무난해요. 깃허브 데스크탑도 심플하고 좋습니다.

Q. 협업할 때 conflict 줄이는 팁 있나요? 가능하면 같은 파일을 동시에 수정하는 일이 없게 역할을 나누는 게 가장 확실합니다. 자주 pull하고, 작은 단위로 자주 커밋해 두면 도움이 돼요.

마무리

오늘은 Git 자주 쓰는 명령어를 한 번 정리해 봤어요. 사실 입문 단계에서 외워야 할 건 생각보다 적습니다. add, commit, push, pull, checkout, branch — 여섯 개면 일상 작업 대부분이 가능해요. 나머지는 필요할 때마다 그때그때 익혀가면 됩니다.

긴 글 끝까지 읽어주셔서 고맙습니다. 궁금한 점은 댓글로 알려주세요. 이 글이 조금이라도 도움이 됐다면 다음 글도 기대해 주세요.

#Git #명령어정리 #입문 #개발자 #버전관리