GitHub 초보자에서 마스터까지: 종합 가이드

GitHub 으로 돈을 벌고 싶다면 가장 직접적인 방법은 복잡하지 않습니다. 라이선스 허용 범위 내에서 가치 있는 오픈소스 프로젝트를 찾고, 배포, 한국어 문서화, 사후 지원을 서비스화하여 중고나라 같은 플랫폼에서 납품하는 것입니다.

하지만 진짜 돈이 되는 것은 정보 필터링과 구현 능력입니다. AI 를 하려면 FDE(풀스택 개발자)로 전환하거나, 스스로 OPC(1인 기업)가 되려면 코드, 문서, 버전, 협업은 결국 GitHub 에 정착하게 됩니다.

창작이나 1인 미디어를 하는 경우에도 GitHub 에는 수많은 주제 선정 도구, 자동화 프로젝트, 콘텐츠 제작 프로세스가 있습니다. 파일이 늘어나고 AI 가 수정을 가하면 Git 으로 버전을 관리하지 않으면 곧 통제 불능 상태가 됩니다. 따라서 프로그래머뿐만 아니라 프로젝트 매니저와 콘텐츠 크리에이터도 배워야 합니다. 이것이 영감을 관리 가능하고, 재사용 가능하며, 납품 가능한 프로젝트로 전환할 수 있는지를 결정하기 때문입니다.

저는 이 글을 다듬는 데 보름 이상을 투자했습니다. Git, GitHub, 커밋, 브랜치, PR, 그리고 흔한 오류들을 0부터 1까지 연습했습니다. 앞으로의 라이브 방송도 이와 동일한 프로세스를 따를 예정입니다. 공식 방송 전에 이 튜토리얼을 먼저 오픈소스로 공개합니다. 북마크에 추가하거나 처음부터 따라 해 보세요.

1. Git 과 GitHub: 각각 무엇을 관리할까?

Git 은 컴퓨터에 설치하는 버전 관리 도구입니다. 오프라인 상태에서도 커밋, 기록 조회, 브랜치 생성 및 병합이 가능합니다. GitHub 는 원격 저장소이자 협업 플랫폼으로, Git 이 푸시한 커밋을 받아 Issues, Pull Requests, Actions, 코드 리뷰, 권한 관리를 제공합니다.

Git 에서 가장 혼동하기 쉬운 점은 동일한 수정 사항이 네 가지 다른 위치에 존재할 수 있다는 것입니다. 아래 인포그래픽은 작업 디렉토리, 스테이징 영역, 로컬 저장소, 원격 저장소를 네 개의 계층으로 나누어 설명합니다.

저장을 누르면 내용이 하드 드라이브에만 기록됩니다. git add 는 선택을 담당하고, git commit 은 로컬에 버전을 남기며, git push 는 이 커밋들을 GitHub 로 보냅니다.

따라서 커밋하기 전에 diff 를 확인하고 실행하거나 테스트해 보세요. 푸시가 성공한 후에는 웹 페이지로 돌아가 다시 한번 확인하세요. 이렇게 하면 문제가 발생했을 때 어느 계층에서 멈췄는지 즉시 알 수 있습니다.

2. 시작하기 전에: 네 가지만 준비하세요

Git, GitHub 계정, 편집기, 연습용 프로젝트가 필요합니다. 편집기는 VS Code 면 충분하고, 프로젝트는 웹 페이지나 Markdown 문서면 됩니다.

먼저 터미널에서 Git 을 확인합니다.

1git --version

이번 실습은 macOS 와 Git 2.49.0 을 사용합니다. Windows 사용자는 Git Bash 나 VS Code 내장 터미널을 사용하면 되며, 아래 Git 명령어는 동일합니다.

다음으로, 커밋 작성자를 설정합니다.

1git config --global user.name "Your Name"
2git config --global user.email "Your Email"

이 정보는 커밋 기록에 기록되는 작성자 정보이며, GitHub 로그인과는 관련이 없습니다. 현재 연습 프로젝트에만 설정하려면 --global 대신 --local 을 사용하세요.

GitHub 로그인은 별개의 문제입니다. 명령줄에서는 주로 세 가지 방법을 사용합니다.

• GitHub CLI: gh auth login 으로 브라우저를 통해 인증
• HTTPS: Personal Access Token 또는 자격 증명 관리자 사용
• SSH: 공개 키를 GitHub 에 추가하고 나중에 키로 인증

초보자는 GitHub CLI 또는 HTTPS 를 선택하세요. HTTPS 사용 시 터미널에서 Password 를 요구하면 Token 을 입력하세요. 일반 계정 비밀번호는 더 이상 사용할 수 없습니다. Token 을 명령어, 원격 URL, README, 채팅, 스크린샷에 절대 작성하지 마세요.

3. init 부터 하지 마세요: 터미널의 실제 위치를 확인하세요

이번 실습은 간단한 웹 페이지로 시작합니다. 브라우저에서 열 수 있지만 아직 Git 히스토리는 없습니다.

프로젝트에는 세 개의 파일이 있습니다.

1index.html
2style.css
3.gitignore

VS Code 에서 "폴더 열기"를 선택하고, HTML 파일 하나만 클릭하지 마세요. 그런 다음 내장 터미널에서 다음을 실행합니다.

1pwd
2ls

pwd 는 현재 디렉토리를 보여주고, ls 는 파일을 나열합니다. index.html 과 style.css 가 보일 때까지 계속 진행하지 마세요.

이 확인 작업은 바보 같아 보이지만, 가장 골치 아픈 사고를 방지합니다. 누군가가 바탕화면, 문서 폴더, 또는 사용자 홈 디렉토리에서 git init 을 실행하고 git add . 로 수천 개의 관련 없는 파일을 스테이징 영역에 넣는 상황을 막을 수 있습니다. Git 이 고장 난 것이 아니라 디렉토리가 잘못된 것입니다.

4. git init 은 무엇을 할까?

이제 저장소를 초기화합니다.

1git init -b main
2git status --short

git init -b main 은 현재 폴더에 .git 디렉토리를 생성하고 초기 브랜치 이름을 main 으로 지정합니다. .git 은 커밋, 브랜치, 스테이징 영역, 원격 주소 등의 정보가 저장되는 숨김 디렉토리입니다. 프로젝트 파일은 그대로 있으며, Git 은 이 순간부터 파일을 관찰하기 시작합니다.

스크린샷의 ?? 는 추적되지 않은 파일을 나타냅니다. 파일은 존재하지만 Git 이 아직 기록할지 결정하지 않은 상태입니다.

저장소 루트 디렉토리를 확인하려면 다음을 실행할 수 있습니다.

1git rev-parse --show-toplevel

출력은 현재 프로젝트 폴더여야 합니다. fatal: not a git repository 라고 나오면 먼저 디렉토리를 확인하고 git init 이 실행되었는지 확인하세요.

5. 첫 번째 커밋: 신뢰할 수 있는 시작점을 유지하세요

프로젝트를 아직 수정하지 않았는데 왜 먼저 커밋할까요? 이후의 모든 변경 사항에는 비교할 수 있는 시작점이 필요하기 때문입니다. 먼저 브라우저에서 웹 페이지를 열어 제목, 카드, 등록 영역이 표시되는지 확인하고, 창을 좁혀 모바일 너비에서 가로 스크롤이 생기는지 확인하세요.

그런 다음 .gitignore 를 살펴보세요. 이번에 사용한 내용은 다음과 같습니다.

1.env
2.env.*
3*.log
4node_modules/
5dist/
6build/

.gitignore 는 키, 로그, 종속성, 빌드 산출물을 차단하는 데 사용됩니다. 주로 아직 추적되지 않은 파일에 적용됩니다. 키가 이미 커밋된 상태에서 나중에 .gitignore 에 추가해도 해당 히스토리는 여전히 존재합니다. 실제 처리는 키를 취소하거나 순환시키는 작업도 포함됩니다.

첫 번째 커밋을 위해 파일을 선택하기 시작합니다.

1git add index.html style.css .gitignore
2git status --short
3git diff --cached --stat

상태의 A 는 Added 를 의미하며, 파일이 스테이징 영역에 들어갔음을 나타냅니다. git diff --cached --stat 는 커밋을 준비 중인 파일 수와 대략적인 변경 줄 수를 알려줍니다. 구체적인 내용을 보려면 다음을 실행하세요.

1git diff --cached

확인 후 커밋합니다.

1git commit -m "chore: 캠퍼스 AI 채용 페이지 초기화"
2git log --oneline
3git status

커밋은 작성자, 시간, 설명, 부모 커밋이 있는 프로젝트 스냅샷으로 이해할 수 있습니다. ffdf4ff 는 이 커밋 해시의 짧은 버전이며, 현재 저장소에서 이 값을 사용하면 정확히 해당 버전을 찾을 수 있습니다.

feat, fix, docs, style, chore 는 일반적인 커밋 유형이며, 필수 Git 문법은 아닙니다. 접두사보다 더 중요한 것은 그 뒤에 오는 한국어(또는 영어) 설명입니다. 무엇을 했는지, 어떤 대상을 수정했는지, 왜 수정했는지입니다.

6. 두 번째 커밋: AI 수정 사항을 검토용 초안으로 취급하세요

다음으로, 페이지에 "등록 방법 보기" 버튼을 추가합니다. AI 프로그래밍 도구를 사용할 때는 프롬프트에 경계를 명시합니다.

1index.html 만 수정하고, 소개 텍스트 아래에 "등록 방법 보기" 링크를 추가하세요.
2페이지 내 #apply 로 연결됩니다. style.css 는 수정하지 말고, Git 커밋도 실행하지 마세요.
3완료되면 어떤 파일을 수정했는지 알려주세요.

수동 수정도 간단합니다.

1<a class="cta" href="#apply">등록 방법 보기</a>

AI 가 완료했다고 하지만, 아직 커밋하지 마세요. 다음을 실행하세요.

1git status --short
2git diff -- index.html
3git diff --check

git diff 는 아직 스테이징되지 않은 작업 디렉토리의 변경 사항을 보여줍니다. 초록색 + 는 추가된 줄, 빨간색 - 는 삭제된 줄입니다. git diff --check 는 출력이 없으면 후행 공백과 같은 명백한 서식 문제가 발견되지 않았음을 의미합니다. 버튼이 클릭 가능한지까지 확인해 주지는 않습니다.

브라우저로 돌아가 새로고침하고, 버튼을 클릭한 다음 창을 좁혀보세요. 페이지가 등록 영역으로 스크롤되어야 하며, 좁은 화면에서도 버튼과 카드가 정상적으로 보여야 합니다.

테스트를 통과한 후에만 커밋하세요.

1git add index.html
2git diff --cached
3git commit -m "feat: 지원 방법 빠른 확인을 위한 등록 항목 추가"
4git log --oneline -2

이제 저장소에는 시작 페이지와 등록 버튼이라는 두 개의 명확한 버전이 있습니다. 나중에 버튼에 문제가 생기면 어떤 커밋에서 추가되었는지 직접 찾을 수 있습니다.

참고로, 두 가지 diff 를 구분하세요.

1git diff             # 작업 디렉토리와 스테이징 영역의 차이
2git diff --cached    # 스테이징 영역과 가장 최근 커밋의 차이

git diff 에 출력이 없으면 파일이 저장되지 않았거나, 이미 스테이징되었거나 커밋되었을 수 있습니다. git status, git diff --cached, git log 를 순서대로 확인하는 것이 git add . 를 반복해서 입력하는 것보다 더 안정적입니다.

7. 브랜치: 불확실한 변경 사항을 위한 테스트 장소를 남겨두세요

버튼은 한 줄만 추가하므로 위험이 적습니다. 전체 테마를 보라색에서 주황색으로 변경하는 것은 예뻐 보일 수도 있고 촌스러워 보일 수도 있습니다. 이런 종류의 수정은 브랜치에 적합합니다.

1git switch -c experiment/warm-theme
2git branch --show-current

브랜치는 개념적으로 특정 커밋을 가리키는 이름입니다. 새 브랜치를 처음 생성하면 main 과 동일한 커밋을 가리키므로 파일은 완전히 동일합니다. 실험 브랜치에서 새 커밋이 생성될 때만 두 라인이 갈라집니다.

다이어그램에서 파란색 main 은 여전히 두 번째 커밋을 가리키는 반면, 주황색 experiment 는 이미 세 번째 커밋을 가리킵니다. 프로젝트가 두 세트의 파일을 복제한 것은 아닙니다. 두 브랜치 이름의 포인터만 변경된 것입니다.

style.css 에서 색상 변수를 수정하고, 페이지를 새로고침하여 확인한 후 커밋합니다.

1git diff -- style.css
2git diff --check
3git add style.css
4git commit -m "style: 실험 브랜치에서 따뜻한 테마 시도"
5git log --oneline --graph --decorate --all

HEAD 는 현재 위치를 나타냅니다. 스크린샷에서 HEAD 는 experiment/warm-theme 를 가리키고, main 은 버튼 커밋에 그대로 있습니다.

따뜻한 테마를 유지하기로 결정하고, main 으로 전환하여 병합합니다.

1git switch main
2git merge experiment/warm-theme

실험 기간 동안 main 에 새 커밋이 없었기 때문에 Fast-forward 가 발생합니다. Git 은 main 포인터를 따뜻한 테마 커밋으로 직접 이동시키며, 변경 사항이 성공적으로 병합되었습니다.

병합된 브랜치는 안전하게 삭제할 수 있습니다.

1git branch -d experiment/warm-theme

소문자 -d 는 브랜치가 병합되었는지 확인합니다. 대문자 -D 는 강제 삭제하며, 병합되지 않은 브랜치의 커밋은 참조를 잃을 수 있으므로 일상적인 정리 명령어로 사용하지 마세요.

8. 충돌은 신비롭지 않습니다. Git 이 당신을 위해 선택하지 못할 뿐입니다.

충돌을 확인하기 위해 저장소를 복제했습니다. main 은 메인 제목을 "캠퍼스 창의성을 더 많은 사람들이 볼 수 있도록"으로 변경했고, feature 브랜치는 같은 줄을 "아이디어를 실제로 사용 가능한 작업물로 전환"으로 변경했습니다. Git 이 병합 중에 멈췄습니다.

충돌 마커는 세 부분으로 나뉩니다.

1<<<<<<< HEAD
2현재 브랜치의 내용
3=======
4병합될 브랜치의 내용
5>>>>>>> feature/rewrite-heading

처리 방법은 파일을 편집하여 최종적으로 원하는 텍스트를 남기고, 세 개의 마커 세트를 삭제한 후 테스트하고, 다음을 실행하는 것입니다.

1git add index.html
2git commit

그 당시 처리하고 싶지 않다면 병합을 중단할 수 있습니다.

1git merge --abort

충돌은 두 사람 또는 두 Agent 가 같은 위치에 대해 다른 답변을 제공했고 Git 이 스스로 선택할 수 없음을 의미합니다.

9. 로컬 저장소를 GitHub 로 보내기

프로젝트에 이미 로컬 히스토리가 있습니다. 이제 GitHub 로 가서 저장소를 생성합니다. 오른쪽 상단의 + 를 클릭하고 "New repository"를 선택한 후 저장소 이름을 입력합니다. 예를 들어:

1campus-ai-demo

첫 번째 실습에서는 Private 으로 설정하는 것이 좋습니다. 로컬에 이미 README, .gitignore, 커밋 히스토리가 있으므로 새 GitHub 저장소는 비워 둡니다. 웹에서 README, 라이선스, .gitignore 를 초기화하지 마세요. 그렇지 않으면 로컬과 원격이 각각 초기 히스토리를 가지게 되어 첫 번째 푸시 시 양쪽의 관계를 먼저 처리해야 합니다. GitHub 공식 문서인 "Adding locally hosted code"에서도 이를 명시적으로 언급하고 있습니다.

HTTPS 주소를 복사합니다.

1https://github.com/YourUsername/campus-ai-demo.git

프로젝트 터미널로 돌아갑니다.

1git remote add origin https://github.com/YourUsername/campus-ai-demo.git
2git remote -v
3git push -u origin main

origin 은 원격 주소의 별칭입니다. 다른 이름도 사용할 수 있지만, 커뮤니티에서는 주 원격 저장소를 origin 이라고 부르는 것이 관례입니다. -u 는 로컬 main 과 origin/main 간의 추적 관계를 설정하며, 이후 작업은 일반적으로 git push 만 실행하면 됩니다.

아래 터미널 다이어그램은 로컬 베어 저장소를 사용하여 push 와 clone 을 실행했기 때문에 기존 GitHub 계정을 변경하지 않았습니다. GitHub 로 전환할 때는 origin URL 만 바꾸면 되며, Git 이 커밋을 전달하고 추적 관계를 설정하는 로직은 동일합니다.

실제 푸시가 완료된 후 GitHub 웹 페이지로 돌아가 새로고침하여 파일, README, 기본 브랜치, 커밋 히스토리가 모두 표시되는지 확인하세요. 터미널의 성공 메시지는 한 가지 증거이고, 웹 확인은 또 다른 증거입니다.

10. GitHub 저장소 처음 읽기: 페이지에 있는 것들을 읽는 방법

아래는 GitHub 공식 문서 저장소의 실제 페이지이며, 2026년 8월 15일에 캡처했습니다.

저장소를 열 때는 다음 위치를 먼저 살펴보세요.

• Code: 파일, 디렉토리, 브랜치, 커밋
• Issues: 버그, 요구 사항, 작업, 토론
• Pull requests: 검토 또는 병합을 기다리는 변경 사항
• Actions: 자동화된 테스트, 빌드, 배포
• Security: 보안 정책 및 취약점 관련 기능
• Insights: 기여도, 트래픽, 저장소 활동
• README: 프로젝트 소개 및 사용 진입점
• LICENSE: 사용, 수정, 배포가 어떻게 허용되는지

낯선 프로젝트를 읽을 때는 먼저 Stars 만 쳐다보지 마세요. 먼저 다섯 가지 질문에 답하세요. 어떤 문제를 해결하는지, 어떻게 실행하는지, 어떤 종속성이 있는지, 최근에 유지 관리되고 있는지, 라이선스가 무엇을 허용하는지. Stars 는 관심도를 반영할 뿐, 보안, 호환성, 권한을 확인해 주지는 않습니다.

11. clone, fetch, pull, push: 네 가지 방향을 혼동하지 마세요

처음으로 원격 저장소를 컴퓨터로 가져오는 경우:

1git clone https://github.com/OWNER/REPO.git

Clone 은 파일, 커밋 히스토리, 원격 구성을 가져오며, 일반적으로 원격 저장소 이름을 자동으로 origin 으로 지정합니다. ZIP 을 다운로드하면 해당 시점의 파일 스냅샷만 얻을 수 있으며, 전체 히스토리가 없고 원격 관계도 설정되지 않습니다.

이후 일반적으로 사용되는 세 가지 작업은 다음과 같습니다.

1git fetch origin   # 원격 정보 다운로드, 현재 작업 파일 변경 안 함
2git pull           # fetch 후 현재 브랜치에 통합
3git push           # 로컬 커밋을 원격으로 보내기

원격에서 무슨 일이 있었는지 먼저 확인하려면 다음을 실행할 수 있습니다.

1git fetch origin
2git status -sb
3git log --oneline HEAD..origin/main

로컬에 차이가 없음을 확인하고 Fast-forward 업데이트만 허용하려는 경우:

1git pull --ff-only

pull 은 먼저 fetch 를 수행한 다음 설정에 따라 merge 또는 rebase 를 수행합니다. 팀은 첫 번째 협업 전에 통합 방법을 합의해야 하며, 차이가 발생했을 때 force push 에 의존하여 문제를 덮지 마세요.

12. 개인 저장소에서 GitHub 협업으로

Pull Request 는 병합 제안이자 협업이 이루어지는 곳입니다. 토론, 코드 리뷰, 자동화된 검사 모두 동일한 변경 사항 세트를 중심으로 이루어지며, 확인 후에만 main 에 병합됩니다.

Issue 가 "이벤트 시간 설명 추가"라고 가정하면 로컬 작업은 다음과 같이 수행할 수 있습니다.

1git switch -c feat/event-time
2# 페이지 수정 및 테스트
3git add index.html
4git commit -m "feat: 이벤트 시간 설명 추가"
5git push -u origin feat/event-time

푸시 후 GitHub 는 일반적으로 Pull Request 생성을 제안합니다. PR 은 설명, 커밋, 파일 차이, 댓글, 리뷰, 자동화된 검사를 표시하는 병합 제안입니다. 생성되었다고 해서 자동으로 main 에 들어가는 것은 아닙니다.

사람들이 리뷰하고 싶어 하는 PR 은 최소한 세 가지를 설명해야 합니다. 무엇을 변경했는지, 왜 변경했는지, 어떻게 확인할 수 있는지입니다. 변경 사항이 집중될수록 리뷰어가 문제를 찾기 쉽습니다.

같은 팀에서 저장소에 쓰기 권한이 있다면 브랜치에서 직접 PR 을 보낼 수 있습니다. 낯선 오픈소스 프로젝트에 기여할 때는 일반적으로 먼저 자신의 계정으로 Fork 한 다음, 자신의 Fork 를 Clone 합니다.

1git clone https://github.com/YourUsername/ProjectName.git
2cd ProjectName
3git remote add upstream https://github.com/OriginalAuthor/ProjectName.git
4git remote -v

여기에는 일반적으로 두 개의 원격 저장소가 있습니다.

1origin    자신의 Fork
2upstream  원작자의 저장소

원본 프로젝트를 동기화합니다.

1git fetch upstream
2git switch main
3git merge --ff-only upstream/main
4git push origin main

그런 다음 새 브랜치에서 수정을 완료하고, 자신의 Fork 에 푸시한 후 upstream 에 PR 을 보냅니다. Fork, clone, branch 는 각각 다른 것을 해결합니다. Fork 는 GitHub 상의 저장소 공간 세트, clone 은 저장소를 로컬로 가져오는 것, branch 는 저장소 내의 개발 라인입니다.

13. README 와 LICENSE 는 다른 사람들이 사용해도 되는지 결정합니다

README 는 최소한 다음 질문에 답해야 합니다.

1. 프로젝트가 무엇인지
2. 어떤 문제를 해결하는지
3. 설치 또는 실행 방법
4. 현재 어느 정도 완료되었는지
5. 주요 파일의 위치
6. 작성자, 자료, 인용 출처

코드가 실행 가능하지만 README 가 모호하면 3개월 후에 자신도 다시 사용하지 못할 수 있습니다. 최소한의 README 는 예쁠 필요가 없습니다. 프로젝트, 실행 방법, 상태만 명확히 작성하면 됩니다.

공개 저장소라고 해서 자동으로 오픈소스 라이선스를 얻는 것은 아닙니다. GitHub 의 공식 라이선스 설명은 명확히 밝히고 있습니다. 라이선스가 없으면 기본 저작권 규칙이 여전히 적용되며, 저자는 복사, 배포, 2차 저작물 생성 권리를 보유합니다. 공개는 다른 사람이 볼 수 있고 GitHub 서비스 약관에 따라 Fork 할 수 있다는 것을 의미합니다. 코드를 자신의 공개 또는 상업용 프로젝트에 가져가려면 저장소의 LICENSE 도 확인해야 합니다.

MIT, Apache-2.0, GPL 등은 각각 다른 의무가 있습니다. 상업적 사용, 재배포, 혼합 라이선스를 접할 때는 전체 파일을 읽고 필요한 경우 전문가와 상담하세요. AI 에게 "상업적 용도로 사용해도 되나요?"라고 묻지 마세요.

14. 실수 후: 변경 사항이 어느 계층에 있는지 확인하세요

후회 약은 상태에 따라 선택해야 합니다.

잘못된 파일을 스테이징했지만 파일 내용은 유지하려는 경우:

1git restore --staged filename

가장 최근 커밋 메시지를 잘못 작성했고 아직 푸시하지 않은 경우:

1git commit --amend -m "새 커밋 메시지"

공유 브랜치의 커밋을 취소해야 하는 경우:

1git revert commit_hash

revert 는 새로운 역방향 커밋을 생성하며, 이전 히스토리는 계속 볼 수 있습니다. 이미 푸시되었고 여러 사람이 사용하는 브랜치에 적합합니다.

git restore filename 은 커밋되지 않은 수정 사항을 폐기합니다. git reset --hard 는 커밋, 스테이징 영역, 작업 디렉토리를 모두 지정된 위치로 되돌립니다. git push --force 는 원격 커밋을 덮어쓸 수 있습니다. 이 세 가지 유형의 작업은 실행 전에 대상을 확인하고 백업을 수행해야 하며, 초보 단계에서 일반적인 복구 버튼처럼 취급하지 마세요.

15. 가장 흔한 여덟 가지 오류: 이 순서대로 확인하세요

1. fatal: not a git repository

1pwd
2ls
3git status

일반적으로 디렉토리가 잘못되었거나 현재 프로젝트가 아직 git init 되지 않았습니다.

2. Author identity unknown

1git config --local user.name "Your Name"
2git config --local user.email "Your Email"

3. nothing to commit

파일이 저장되었는지, 다른 복사본을 수정했는지, 변경 사항이 이미 커밋되었는지 확인하세요.

1git status
2git log --oneline -3

4. remote origin already exists

1git remote -v
2git remote set-url origin 올바른GitHub주소

5. src refspec main does not match any

저장소에 커밋이 없거나 현재 브랜치 이름이 main 이 아닐 수 있습니다.

1git log --oneline
2git branch --show-current

6. Authentication failed or 403

원격 URL, 저장소 소유권, 계정 권한, 인증 방법을 확인하세요. 문제 해결을 위해 Token 을 다른 사람에게 보내지 마세요.

7. rejected non-fast-forward

로컬에 없는 커밋이 원격에 있습니다. 먼저 fetch 하고 차이를 확인하세요. 바로 force push 하지 마세요.

1git fetch origin
2git status -sb
3git log --oneline --graph --decorate --all -10

8. Merge Conflict

git status 를 실행하여 UU 파일을 찾고, 최종 내용을 수동으로 결정한 후 테스트하고, add 및 commit 을 실행합니다. 지금 당장 처리하지 않으려면 git merge --abort 를 실행하세요.

학생이나 동료가 "Git이 고장 났어요"라고 말할 때, 다음 다섯 가지 출력 결과를 요청하세요:

1pwd
2git status
3git branch --show-current
4git log --oneline -5
5git remote -v

그런 다음 운영 체제, 방금 실행한 전체 명령어, 그리고 전체 오류 메시지를 추가하세요. 대부분의 문제는 디렉토리, 상태, 식별자, 원격 주소, 권한 중 하나의 계층으로 빠르게 분류됩니다.

16. AI 시대에 Git은 수용 시스템에 가깝습니다

AI가 명령어를 대신 입력해 줄 수는 있지만, 어떤 수정 사항이 비즈니스 의도에 부합하는지 자동으로 알 수는 없습니다. 프롬프트가 20개의 파일을 변경했는데, diff를 확인하지 않고, 프로젝트를 실행하지 않으며, 키를 점검하지 않는다면, Git은 이 엉망진창을 충실히 기록할 뿐입니다.

더 안정적인 방법은 작업을 좁히고 사람을 수용 위치에 두는 것입니다. 범위, 차이점, 테스트, 키 점검이 모두 통과된 후에야 사람이 이러한 수정 사항이 커밋이 될 수 있는지 결정합니다.

AI가 Git을 작동하도록 할 때는 경계도 함께 설정하세요:

1먼저 git status와 git diff를 확인하고, 현재 변경 사항만 요약하세요.
2커밋되지 않은 내용을 폐기하지 말고, reset --hard, clean, force push를 실행하지 마세요.
3수정을 완료한 후 검증 결과를 제공하고, 자동으로 커밋하거나 푸시하지 마세요.

명령어를 외울 수 있는지 여부는 더 이상 중요하지 않습니다. 상태를 읽고, AI가 무엇을 옮겼는지 알고, 검증이 충분한지 판단하며, 위험한 작업이 나타나면 중단을 요청할 수 있어야 합니다.

17. 전체 프로세스를 다시 실행하세요

1# 1. 위치 확인
2pwd
3ls
4
5# 2. 초기화
6git init -b main
7git status
8
9# 3. 첫 번째 커밋
10git add index.html style.css .gitignore
11git diff --cached
12git commit -m "chore: Initialize project"
13
14# 4. 수정, 확인, 테스트, 다시 커밋
15git status --short
16git diff
17git diff --check
18git add index.html
19git commit -m "feat: Add registration entry"
20
21# 5. 브랜치 실험
22git switch -c experiment/warm-theme
23git add style.css
24git commit -m "style: Experiment with warm theme"
25git switch main
26git merge experiment/warm-theme
27
28# 6. GitHub에 연결
29git remote add origin https://github.com/YourUsername/RepoName.git
30git remote -v
31git push -u origin main
32
33# 7. 최종 확인
34git status
35git log --oneline --graph --decorate --all
36git remote -v
37git diff --check
38git ls-files

각 명령어가 어떤 계층을 변경했는지 설명할 수 있고, 잘못된 디렉토리, 스테이징 오류, 병합 충돌을 독립적으로 처리할 수 있다면, GitHub는 더 이상 코드를 저장하는 웹사이트가 아닙니다. 개인 프로젝트를 검토, 감사, 협업 가능한 저장소로 전환할 수 있는 능력을 갖춘 것입니다.

다음 단계는 명령어를 계속 수집할 필요가 없습니다. 실제 작은 프로젝트를 찾아 7일 연속으로 진행하세요: 매일 하나의 작은 수정만 완료하고, diff를 확인하고, 테스트하고, 커밋한 다음 GitHub에 푸시합니다. 커밋 기록은 이 모든 과정을 천천히 작업 습관으로 만들어 줄 것입니다.

저는 Miles입니다. 대기업에서 FDE로 전향한 AI 알고리즘 전문가입니다. 알고리즘 연구개발, 최적화 배포, 기업 교육을 해왔습니다. 저를 팔로우하세요 @miles_mazy 함께 성장하고, 함께 돈을 벌어요.