Git 기본 개념

읽는 시간: 약 15분 · 버전: v0.5 (2026-09-21) · GitHub 가이드 4편
3편 기본 실습을 한 번 해 본 뒤에 읽으세요. 손으로 해 본 것에 이름을 붙이는 문서입니다.

실습에서 여러분은 이미 Git을 썼습니다. 이 문서는 그때 화면 뒤에서 무슨 일이 일어났는지 설명합니다. 외울 것은 없습니다.

1. 네 가지 구성 요소

• Git과 GitHub는 다릅니다. Git은 내 PC 안에 있고 인터넷 없이도 돌아갑니다. GitHub는 그 기록을 올려 두는 곳입니다.
• Git은 누가 파일을 고쳤는지 가리지 않습니다. AI가 고치든 내가 고치든, Git이 관리하는 파일의 변경은 GitHub Desktop의 Changes에 나타납니다. 그래서 어떤 AI 도구를 쓰든 기록하는 방법은 같습니다.

2. 저장, 커밋, 푸시의 차이

"저장했는데 왜 GitHub에 없어요?"가 가장 흔한 질문입니다. 장소가 세 군데이기 때문입니다.

Git은 파일이 바뀌는 모든 순간을 알아서 기록하지 않습니다. 내가 커밋한 시점만 이력에 남습니다. 커밋과 커밋 사이에 AI가 열 번을 고쳤어도 이력에는 마지막 결과만 남습니다.

버튼에 나오는 origin(오리진)은 "이 폴더와 연결된 GitHub 쪽 저장소"를 부르는 별명입니다.

3. 커밋에 담기는 것

보고서 파일 이름에 붙이던 v1, v2, v3 에 해당하는 것이 Git에서는 커밋(commit)입니다. 영어로 revision(리비전, '고친 판'이라는 뜻)이라고도 부릅니다. 같은 말입니다.

담기지 않는 것도 있습니다.

• 제외하도록 설정된 파일. 비밀번호를 담는 .env, 업무 데이터가 들어가는 data 폴더, 문서 원본 같은 것은 기본 틀에서 Git이 무시하도록 설정해 둡니다. 이런 파일은 Changes에 나타나지 않고, 커밋에도 GitHub에도 올라가지 않습니다. 그래서 Git은 폴더 전체의 백업이 아닙니다.
• 체크를 끈 변경. GitHub Desktop의 Changes에서 체크를 끈 파일은 그 커밋에 들어가지 않습니다.

고유 번호(a1b2c3d)는 외울 필요가 없습니다. 도움을 요청할 때 "이 커밋이요" 하고 가리키는 용도입니다.

커밋 시점

• AI에게 시킨 일 하나가 끝났고, 세 가지 확인(예상 못 한 파일, 동작, 민감한 자료)을 마쳤을 때
• 큰 변경을 시키기 직전 (문제가 생기면 취소하기 쉽습니다)
• 하루 작업을 마칠 때 (그리고 푸시)

4. 되돌리기 두 가지: Discard와 Revert

• 되돌릴 커밋이 여러 개라면 최신 것부터 차례로 합니다.
• 그 뒤에 다른 변경이 쌓여 있으면 충돌이 나거나 결과가 예상과 다를 수 있습니다. 그럴 때는 멈추고 도움을 요청합니다. 충돌이 무엇이고 어떻게 대처하는지는 7편에 있습니다.
• "지난주 상태로 통째로 돌아가고 싶다"처럼 여러 커밋을 한꺼번에 되감아야 하는 일은 직접 하지 말고 팀장에게 요청합니다.

5. 브랜치, PR, 병합, 배포

브랜치(branch) 는 같은 저장소 안에서 따로 자라는 이력의 줄기입니다. 어느 한 시점에서 갈라져 나와 따로 자라고, 병합으로 다시 합쳐집니다. 그림과 자세한 설명은 7편에 있습니다.

work 와 main 은 Git의 명령어나 예약어가 아니라 브랜치에 붙인 이름표입니다. main 은 GitHub의 기본 이름이고, work 는 우리 TF가 정했습니다. 인터넷 글이나 AI의 설명에 develop, feature/..., master 가 나와도 같은 개념의 다른 이름표입니다.

PR에서 서버까지는 서로 다른 세 단계입니다.

GitHub의 기능과 우리 TF의 규칙

규칙 중 일부는 팀장이 GitHub 설정으로 걸어 둡니다(예: main 에 직접 푸시하지 못하게 하기). 다만 이런 보호는 GitHub 쪽 저장소에 거는 규칙이라서, 내 PC에서 main 을 열어 놓고 파일을 고치거나 커밋하는 것까지 막아 주지는 않습니다. 그래서 작업을 시작할 때 브랜치를 직접 확인합니다.

또 하나, 비공개 저장소는 "초대받아 권한이 있는 계정만 볼 수 있다"는 뜻입니다. "회사 네트워크 안에서만 열린다"는 뜻이 아닙니다.

6. 첫 PR 이후의 작업

같은 work 를 계속 씁니다. PR마다 브랜치를 새로 만들지 않습니다.

• 병합은 GitHub 쪽 main 에서 일어나는 일입니다. 내 work 는 그대로이고, 병합 뒤에 내가 따로 맞춰야 할 것은 없습니다. 평소처럼 공통 순서(저장소 확인 → 브랜치 선택 → Fetch origin → Pull origin이 나타나면 Pull)로 시작하면 됩니다.
• main 은 직접 고치지 않는 것이 우리 TF의 원칙입니다. main 은 PR 병합으로만 바뀌므로 main 에 있는 내용은 모두 work 에서 간 것이고, work 를 main 에 맞추는 작업이 필요 없습니다.
• Pull origin은 GitHub 쪽 work 에 내 PC에 없는 커밋이 있을 때만 나타납니다(예: 팀장이 도와주려고 work 에 수정을 넣어 준 경우). 나타나지 않으면 받을 것이 없는 것입니다.
• PR이 열려 있는 동안 work 에 푸시하면 그 변경도 그 PR에 들어갑니다. 수정 요청 반영은 괜찮지만, 관련 없는 새 작업은 병합된 뒤에 시작합니다.
• 두 번째 PR에 이미 반영된 예전 커밋이 다시 보이면 멈추고 팀장에게 알립니다. 저장소의 병합 설정을 점검해야 하는 상황입니다.

7. 역할 분담

커밋 버튼을 누가 누르든, 커밋 직전의 확인은 여러분이 합니다. 그것이 여러분이 하는 검토입니다. 코드를 전부 이해할 필요는 없지만, 업무 결과가 맞는지는 업무를 아는 여러분이 가장 잘 판단합니다. 그래서 AI에게 커밋을 맡길 때도 "작업이 끝나면 멈추고, 내가 확인한 뒤에 커밋해 달라고 하면 그때 커밋한다"가 규칙입니다. 교육 기간에 직접 해 보는 이유는 AI가 무엇을 대신하는지 알아야 문제가 생겼을 때 어디를 볼지 알 수 있기 때문입니다.

AI를 Git 해설자로 쓰는 것은 권장합니다.

지금 이 폴더에서 마지막 커밋 이후에 바뀐 내용을 쉬운 말로 설명해 줘. 아무것도 수정하지는 마.

오류 메시지를 AI에게 붙여 넣어 뜻을 물어봐도 됩니다. 다만 AI가 제안한 명령을 직접 실행하게 하지는 말고, 설명만 듣습니다.

8. 도구별 용도 (우리 TF의 기준)

같은 폴더의 같은 Git 기록을 보는 것이라 두 프로그램을 함께 써도 상태는 하나입니다. 어느 쪽에서 커밋했든 GitHub Desktop의 History에 나타납니다. 헷갈릴 때는 GitHub Desktop을 기준으로 봅니다. 용어가 하나 다릅니다. ChatGPT 앱의 Revert 는 "커밋하지 않은 변경을 버린다"는 뜻으로 GitHub Desktop의 Discard Changes 에 해당합니다.

9. 다루지 않는 용어

rebase · stash · cherry-pick · fork · tag · SSH key · HEAD · reset · .gitignore 작성

검색하다 만나도 우리 방식에서는 쓸 일이 없거나 팀장이 처리합니다. 충돌(conflict) 이라는 말이 화면에 나오면 7편의 네 단계(멈춤 → 캡처 → Abort merge → 팀장에게 알림)를 따릅니다.

10. 확인 문제

이어서 읽기

• 다음 편: 5편. GitHub 이용 규칙 — 작업 흐름과 지켜야 할 규칙
• 함께 보기: 6편. 한 장 요약 — 인쇄용 A4 한 장
• 함께 보기: 7편. 브랜치 분기와 충돌 대처 — 브랜치의 원리, 충돌 안내가 떴을 때
• 전체 목록: 가이드 전체 구성