Git 명령어 정리, 초보자용 12개와 충돌 해결법

이 포스팅은 쿠팡 파트너스 활동의 일환으로, 이에 따른 일정액의 수수료를 제공받습니다.

Git 명령어 정리는 초보자에게 12개면 충분해요. init · clone · status · add · commit · log · branch · switch(checkout) · merge · pull · push · stash입니다.

이 12개의 흐름은 «작업 → 담기(add) → 기록(commit) → 올리기(push)»예요. 충돌은 두 사람이 같은 줄을 고쳤을 때 생기고, 파일 안의 <<<<<<< · ======= · >>>>>>> 표식을 고르고 지운 뒤 add·commit하면 끝나요.

공식 안내는 git-scm.com Pro Git 한국어, GitHub Docs, Atlassian Git 튜토리얼을 같이 보면 좋아요.

📋 Git 명령어 정리 — 매일 쓰는 12개 표

🗂 명령어 · 하는 일 · 옵션

Git 명령어 정리의 핵심은 표 암기가 아니라 «지금 status로 확인했는가»예요. 막히면 표를 다시 펴면 됩니다.

포맷 뒤 뭐 깔지? — 필수 프로그램 12가지다음 글

🔁 하루 작업 흐름 7단계

✅ 혼자·팀 공통

1. pull로 최신을 가져와요.
2. 브랜치를 만들어요(switch -c).
3. 코드를 수정해요.
4. status로 변경을 확인해요.
5. add로 담아요.
6. commit -m으로 기록해요.
7. push로 올려요.

Git 명령어 정리를 외울 때 이 7줄을 벽에 붙여 두면 손이 먼저 움직입니다. 커밋 메시지는 짧게, 대략 50자 안쪽을 목표로 잡아요.

💥 충돌 해결 6단계

🛠 표식을 지우는 순서

1. pull/merge에서 CONFLICT 메시지를 봐요.
2. git status로 파일을 확인해요.
3. 파일을 열어 <<<<<<< HEAD ~ >>>>>>> 사이에서 남길 내용을 고르세요.
4. 표식을 모두 삭제해요.
5. add → commit해요.
6. push해요.

저는 충돌 표식을 안 지우고 commit해 빌드가 깨진 적이 있어요. 그다음부터는 status를 습관으로 만들었어요. Git 명령어 정리에서 충돌은 «무서움»이 아니라 «표식 청소»예요.

🎙️ 말하는 순간, 기록된다커밋 메시지, 말로 먼저 적어 두세요가입 후 7일 무료 체험 · 온디바이스 음성 인식스피캣 보러가기 →

↩️ 실수 되돌리기 3가지

🧯 안전한 되돌림

reset --hard는 지우면 복구가 어렵다는 경고만 기억하세요. 초보 단계에서는 위 세 가지면 충분합니다.

커밋 메시지 몇 자? — 50자 규칙 바로 확인계산기

Git 명령어 정리에서 「되돌리기」 앞에 붙는 질문은 항상 하나예요 — 이미 push 했나? 아직 내 컴퓨터에만 있는 커밋은 amend 나 reset으로 고쳐도 아무도 모르지만, push 한 커밋을 고쳐서 다시 올리면 팀원의 기록과 갈라져 충돌이 두 배로 늘어요. push 뒤에는 고치지 말고 git revert 커밋ID로 «되돌리는 커밋»을 하나 더 쌓는 것이 정답이에요. 기록이 한 줄 늘지만, 그 한 줄이 「누가 언제 무엇을 되돌렸는지」를 팀 전체에 알려 주는 문서가 돼요.

🌐 GitHub 연결 한 줄

🔗 origin과 첫 push

원격은 git remote add origin URL로 추가해요. 첫 push -u는 업스트림을 기억해 다음부터 짧게 올리게 해 줍니다. 비밀번호 대신 GitHub 설정에서 발급하는 개인 액세스 토큰을 쓰는 안내가 일반적이에요.

개발 환경을 새로 짜면 Git도 다시 깔게 돼요. 포맷 후 필수 프로그램과 컴퓨터 포맷하는 법을 같이 보면 설치 순서가 덜 헷갈려요.

Git 명령어 정리의 마지막 조각, 원격 주소는 HTTPS와 SSH 두 가지가 있어요. HTTPS 주소(https://github.com/…)는 처음 push할 때 GitHub 계정 인증을 물어보고, 비밀번호 대신 «개인 액세스 토큰»을 넣어야 통과돼요. SSH 주소([email protected]:…)는 내 컴퓨터에 열쇠(키)를 한 번 만들어 GitHub에 등록해 두면 그 뒤로는 묻지 않아요. 초보자는 HTTPS로 시작해서 push가 한 번 되는 것을 확인한 뒤, 매일 쓰기 시작하면 SSH로 바꾸는 순서가 헤맬 일이 가장 적어요. 주소를 잘못 넣었다면 git remote set-url origin 새주소 한 줄로 고칠 수 있어요.

🧭 Git 명령어 정리로 읽는 «상태 3층»

Git 명령어 정리가 머리에 안 남는 이유는 «어디에 있는 파일인지»를 모른 채 명령만 외우기 때문이에요. Git은 파일을 세 층에 나눠 봐요 — 내가 편집하는 작업 폴더, 다음 기록에 «담아 둔» 스테이지, 그리고 이미 기록된 저장소. 12개 명령은 결국 이 세 층 사이에서 파일을 옮기는 일이에요.

🪜 명령어를 층으로 다시 배열하면

1. 작업 폴더 → 스테이지 = git add · 되돌리기는 git restore --staged 파일
2. 스테이지 → 저장소 = git commit -m "메시지" · 메시지만 고치기는 git commit --amend
3. 저장소 ↔ 원격 = git push · git pull · 처음 한 번은 git remote add origin URL
4. 층을 건너뛰지 않는 확인 = git status — 어느 층에 무엇이 있는지 색으로 보여 줘요. 빨강은 작업 폴더, 초록은 스테이지예요.
5. 기록 읽기 = git log --oneline — 커밋 한 줄씩. 최근 5개만 보려면 -5를 붙여요.

이 배열로 보면 「add를 왜 해야 하나」가 풀려요. add는 «이번 기록에 넣을 파일을 고르는 단계»라, 한 번에 여러 파일을 고쳤어도 관련 있는 것만 골라 작은 커밋을 만들 수 있어요. 나중에 어디서 문제가 생겼는지 찾을 때 이 «작은 커밋» 습관이 시간을 제일 많이 아껴 줘요.

숫자 몇 개만 알아 두면 문서 읽기가 쉬워져요. Git은 2005년 리누스 토르발스가 만들었고, 지금 쓰는 switch·restore는 2019년 8월 나온 2.23 버전부터 들어왔어요. 커밋 메시지는 첫 줄 50자 안, 본문은 한 줄 72자에서 줄바꿈하는 것이 오래된 관례고, GitHub 이용자는 2023년 1월 기준 1억 명을 넘었어요. 이 글의 12개 명령과 6단계 충돌 해결은 버전 2.23 이후 어디서나 같게 동작해요.

🖥️ GUI 도구와 터미널을 같이 쓰는 법

명령어를 외우는 것과 GUI를 쓰는 것은 경쟁 관계가 아니에요. VS Code의 소스 제어 패널이나 소스트리 같은 도구는 «지금 어느 층에 무엇이 있는지»를 그림으로 보여 주고, 터미널은 「정확히 무엇을 했는지」를 남겨 줘요. 초보자는 GUI로 상태를 보고 터미널로 명령을 치는 조합이 가장 빨리 늘어요.

🧩 도구별로 맡기면 좋은 일

1. VS Code 소스 제어 — 바뀐 줄을 빨강·초록으로 보여 주는 «diff» 확인. 커밋 전에 여기서 한 번 훑으면 실수한 파일이 같이 올라가는 일이 줄어요.
2. 충돌 편집기 — VS Code는 충돌 표식을 「현재 변경 수락 / 수신 변경 수락 / 둘 다」 버튼으로 바꿔 줘요. 표식을 손으로 지우다 한 줄 남기는 실수를 막아 줘요.
3. 소스트리·GitHub Desktop — 브랜치가 갈라지고 합쳐진 모양을 그래프로 봐요. 「내가 지금 어느 브랜치에 있나」를 잊었을 때 제일 빨라요.
4. 터미널 — 위 도구가 하는 일은 전부 명령어로 기록돼요. 무엇을 눌렀는지 모를 때는 GUI가 실행한 명령을 로그 창에서 읽어 보면 배움이 두 배예요.

주의할 점은 하나 — GUI에서 「모두 되돌리기(discard all)」 류 버튼은 터미널의 reset --hard와 같아서, 작업 폴더의 저장 안 된 변경을 한 번에 지워요. 누르기 전에 git stash로 잠시 치워 두는 습관이 안전해요.

📅 첫 주 연습 플랜 — 하루 10분

Git 명령어 정리는 읽는 것보다 손이 기억해야 끝나요. 새 폴더 하나로 아래 순서를 하루 10분씩 따라 하면, 7일째에는 충돌까지 혼자 풀 수 있어요. 진짜 프로젝트가 아니어도 돼요 — 메모장 파일 하나로 충분해요.

1. 1일 — git init으로 저장소 만들기 · 파일 하나 만들고 add → commit 두 번. git log --oneline으로 기록 2줄 확인.
2. 2일 — 파일을 고치고 git status로 빨강(작업 폴더) → add 뒤 초록(스테이지) 색 변화를 눈으로 확인. restore --staged로 다시 빨강으로.
3. 3일 — git switch -c 실험 으로 브랜치 만들기 · 그 위에서 커밋 1개 · git switch main으로 돌아와 파일이 «예전 상태»인 것 확인.
4. 4일 — main에서 같은 줄을 다르게 고쳐 커밋 → git merge 실험 으로 충돌을 일부러 만들기. 표식 세 줄을 눈에 익히고 정리 → add → commit.
5. 5일 — GitHub에 빈 저장소 만들고 remote add origin → push -u origin main. 웹에서 커밋 목록이 보이면 성공.
6. 6일 — 웹에서 파일을 직접 고쳐 저장 → 로컬에서 git pull. 반대로 로컬 커밋 → push. 두 방향을 한 번씩.
7. 7일 — 작업 중간에 git stash로 치우고 다른 브랜치 갔다 오기 → stash pop. 여기까지 되면 팀 저장소에 들어가도 무섭지 않아요.

7일이 지나면 Git 명령어 정리 12개가 «외운 것»이 아니라 «손에 남은 것»이 돼요. 그다음부터는 커밋 메시지를 짧고 정확하게 쓰는 연습만 더하면 되고, 그건 글자 수 계산기로 50자 안팎인지 확인하는 습관으로 충분해요.

마지막으로, 이 Git 명령어 정리를 어디에 붙여 둘지가 실력을 가르는 작은 차이예요. 저는 12개 표를 A4 한 장으로 인쇄해 모니터 옆에 붙였고, 3주쯤 지나자 표를 안 보게 됐어요. 그 뒤로는 새 명령을 만날 때만 한 줄씩 그 종이에 덧붙였는데, 지금은 20개 남짓이에요. 표가 더 길어지지 않는다는 것 자체가 「이 도구를 이제 안다」는 신호였어요.

🎴 사주 오행으로 짜는 5게임푸시 끝내고 쉬는 5게임무료로 5게임 · 1등 확률은 모든 조합이 동일오행담 보러가기 →

❓ 자주 묻는 질문

❓ Git 명령어 정리에서 commit과 push 차이는?

commit은 로컬 기록, push는 원격 공유예요.

❓ 브랜치는 왜 만드나요?

기능을 분리해 메인 선을 안전하게 두려는 거예요.

❓ Git 명령어 정리만으로 충돌을 피하려면?

자주 pull하고 작은 commit을 하세요.

❓ GUI(소스트리·VS Code) 써도 되나요?

돼요. 다만 표의 12개 의미를 알면 GUI가 하는 일이 보여요.

❓ 커밋 메시지는 몇 자가 좋나요?

팀 규칙이 우선이고, 혼자면 대략 50자 안쪽을 목표로 잡아요.