기본 실습: 커밋, 푸시, 되돌리기, PR

소요: 6070분 (실습 13은 45분, 실습 4는 첫 PR이 병합된 뒤 15~20분) · 버전: v0.5 초안 (2026-09-21) · GitHub 가이드 3편
앞 문서: 2편. 계정과 프로그램 준비

연습장 저장소 tf-sandbox 에서 실제 작업 흐름을 처음부터 끝까지 해 봅니다. 연습장은 실제 프로젝트와 분리된 공간이라 부담 없이 시도해도 됩니다. 실수했다면 더 진행하기 전에 알려 주세요. 복구 방법을 함께 확인합니다.

이 실습에서는 커밋과 푸시를 전부 직접 합니다. 실무에서는 확인을 마친 뒤 AI(Codex)에게 커밋을 시켜도 되지만(5편 참고), 직접 해 봐야 AI가 무엇을 대신해 주는지, 문제가 생겼을 때 어디를 봐야 하는지 알 수 있습니다. 그래서 실습의 지시문에는 매번 "커밋은 하지 마"가 붙어 있습니다.

실습 전 규칙 두 가지 (우리 TF 규칙)

1. 올리지 않는 자료: 비밀유지계약(NDA) 자료, 개인정보, 입찰·견적 정보, 비밀번호·API 키, 업무 문서 원본. 연습에는 지어낸 내용만 씁니다.
2. 실수했다면 지우지 말고 알리기: 올리면 안 되는 것을 올렸거나 작업이 꼬였다면, 아무것도 지우지 말고 팀장에게 바로 알립니다. 알린 실수는 문제가 되지 않습니다.

GitHub Desktop 화면 구성

GitHub Desktop에서 볼 곳은 다섯 군데입니다. 실습 중에 번호로 부르겠습니다.

브랜치 이름은 두 가지가 있습니다.

이 문서에서는 연습장 기준으로 work-… 라고 씁니다. 내 작업본 이름을 모르면 팀장에게 물어보세요.

작업 시작 공통 순서

모든 실습과 앞으로의 모든 작업은 이 순서로 시작합니다.

1. ① Current Repository 가 작업할 저장소인지 확인합니다.
2. ② Current Branch 가 내 작업본(work-…, 실제 프로젝트에서는 work)인지 확인합니다. 아니면 눌러서 바꿉니다.
3. ⑤ Fetch origin 을 누릅니다. GitHub 쪽에 새 소식이 있는지 확인만 하는 버튼입니다.
4. ⑤ 버튼이 Pull origin 으로 바뀌면 누릅니다. 바뀌지 않으면 받을 것이 없는 것이니 그대로 진행합니다. 정상입니다.
5. 작업을 시작합니다.

②에 main 이라고 적혀 있으면 작업본으로 바꾼 뒤 시작하세요. main 을 보호하는 규칙은 GitHub 쪽 저장소에 걸려 있는 것이라, 내 PC에서 main 을 열어 놓고 파일을 고치거나 커밋하는 것까지 막아 주지는 않습니다. 그래서 시작할 때 직접 확인합니다.

실습 1. 첫 커밋과 푸시

1-1. 공통 순서로 시작

위의 공통 순서 1~4를 합니다. ② 목록에 내 작업본이 안 보이면 ⑤ Fetch origin 을 누른 뒤 다시 봅니다.

1-2. AI에게 작업 지시

ChatGPT 앱에서 C:\tf\tf-sandbox 프로젝트의 Codex 채팅을 열고, 아래 문장에서 대괄호 부분만 바꿔 입력합니다.

members 폴더 안에 [내 작업본 이름에서 work- 를 뺀 이름].md 파일을 새로 만들어 줘. (예: ga-gildong.md)
내용은 다음과 같이 써 줘.
- 제목: [부서 이름] [내 이름]
- 맡은 업무: [한 줄]
- TF에서 만들고 싶은 도구: [한 줄]
다른 파일은 건드리지 마. 커밋이나 푸시는 하지 마.

1-3. 커밋 전 세 가지 확인

GitHub Desktop으로 돌아옵니다. ③ 에 방금 만든 파일이 나타나 있습니다. 파일 이름을 누르면 오른쪽에 내용이 보입니다. 초록색 줄은 추가된 내용, 빨간색 줄은 지워진 내용입니다.

커밋하기 전에 매번 세 가지를 확인합니다. 코드를 전부 이해할 필요는 없지만, 결과를 확인하는 것은 여러분의 책임입니다.

③ 에서 체크된 파일만 커밋에 담깁니다. 체크를 끈 파일의 변경은 커밋에 들어가지 않고 내 PC에 그대로 남습니다. 평소에는 전부 체크된 상태로 두면 됩니다.

1-4. 커밋과 푸시

1. ④ 의 Summary 칸에 한 줄 메모를 씁니다. 예: 총무팀 홍길동 소개 파일 추가
2. 파란색 Commit to work-… 버튼을 누릅니다. 버튼에 적힌 브랜치 이름이 내 작업본인지 한 번 더 봅니다.
3. ⑤ 버튼이 Push origin 으로 바뀝니다. 누릅니다.

1-5. GitHub 반영 확인

1. GitHub Desktop 메뉴 Repository → View on GitHub 를 누르면 브라우저가 열립니다.
2. 파일 목록 위의 브랜치 선택 버튼(처음에는 main 이라고 적혀 있습니다)을 눌러 내 작업본을 고릅니다.
3. members 폴더에 내 파일이 보이면 된 것입니다.

실습 2. 되돌리기

되돌리는 방법은 커밋하기 전과 커밋한 뒤가 다릅니다. 둘 다 해 봅니다.

2-1. 커밋 전: 변경 버리기 (Discard)

1. Codex에게 시킵니다: members/[내 파일].md 파일의 내용을 전부 지워 줘. 커밋은 하지 마.
2. GitHub Desktop ③ 에서 파일을 누르면 내용이 온통 빨간색입니다.
3. ③ 의 그 파일 이름에서 마우스 오른쪽 버튼 → Discard Changes… 를 누르고, 확인 창에서 파일 이름이 맞는지 본 뒤 확정합니다.
4. 파일이 마지막 커밋 상태로 돌아왔습니다.

Discard는 "선택한 파일에서, 아직 커밋하지 않은 변경을 버리는" 동작입니다. 그 파일에 필요한 수정이 함께 들어 있었다면 그것도 같이 사라집니다. 그래서 누르기 전에 어느 파일인지, 그 안에 살릴 내용은 없는지 확인합니다. 헷갈리면 버리지 말고 도움을 요청하세요.

2-2. 커밋 후: 커밋의 변경 취소 (Revert)

1. Codex에게 시킵니다: members/[내 파일].md 파일 맨 아래에 "이 줄은 실수입니다"라고 추가해 줘. 커밋은 하지 마.
2. 세 가지를 확인한 뒤, 메모를 되돌리기 연습용 실수 로 쓰고 커밋, 푸시합니다.
3. GitHub Desktop 왼쪽의 History 탭을 누릅니다. 지금까지의 커밋이 최신순으로 쌓여 있습니다.
4. 방금 만든 커밋에서 마우스 오른쪽 버튼 → Revert Changes in Commit 을 누릅니다.
5. 목록 맨 위에 Revert "되돌리기 연습용 실수" 라는 커밋이 새로 생깁니다. ⑤ Push origin 을 누릅니다.

Revert는 "선택한 커밋이 만든 변경을 취소하는 새 커밋"을 만드는 동작입니다. 실수한 커밋은 이력에 그대로 남고, "취소했다"는 기록이 한 줄 추가됩니다. 돈을 잘못 보냈다가 돌려받아도 통장에 '출금'과 '입금' 두 줄이 모두 남는 것과 같습니다.

주의할 점이 있습니다. Revert는 폴더 전체를 그 시점으로 되감는 기능이 아닙니다. 고른 커밋 하나가 바꾼 부분만 원래대로 돌려놓습니다.

• 되돌릴 커밋이 여러 개라면 최신 것부터 차례로 합니다.
• 그 뒤에 다른 변경이 많이 쌓였다면 충돌(conflict) 이라는 안내가 나오거나 결과가 예상과 다를 수 있습니다. 그럴 때는 멈추고 7편의 네 단계(멈춤 → 캡처 → 취소 버튼 → 팀장에게 알림)를 따릅니다.

실습 3. 첫 PR 작성

PR(Pull Request)은 "내 작업본을 완성본(main)에 반영해 주세요"라는 요청입니다.

3-1. PR 작성

1. 푸시까지 끝난 상태(③ 이 비어 있는 상태)에서, GitHub Desktop 가운데에 보이는 Preview Pull Request 버튼을 누릅니다. 바뀐 내용을 미리 보여 주는 창이 열립니다. 버튼이 안 보이면 메뉴 Branch → Create Pull Request 를 눌러도 됩니다.
2. 창 위쪽의 base 가 main 인지 확인하고 Create Pull Request 를 누릅니다. 브라우저가 열립니다.
3. 브라우저 화면에서도 방향을 확인합니다. base: main ← compare: work-… 여야 합니다.
4. 제목을 씁니다. 예: 총무팀 홍길동 소개 추가
5. 본문에 아래 세 가지를 한두 줄씩 적습니다. 질문이 미리 적혀 있으면 그 밑에 답하면 됩니다.
   • 무엇을 바꿨나요?
   • 어떻게 확인했나요? (위의 세 가지 확인)
   • 걱정되는 점이나 물어보고 싶은 점
6. 초록색 Create pull request 버튼을 누릅니다.
7. PR 주소를 팀장에게 메신저로 알립니다.

3-2. PR 이후의 세 단계

팀장이 수정을 요청하면 PR 화면에 댓글이 달립니다. PR을 새로 만들지 말고, 같은 작업본에서 고쳐 커밋·푸시하면 그 PR이 갱신됩니다.

3-3. PR 검토 중 유의 사항

• 같은 작업본에 푸시하면 그 변경도 열려 있는 PR에 들어갑니다. 수정 요청을 반영하는 푸시는 괜찮습니다.
• 그 PR과 관련 없는 새 작업은 PR이 병합된 뒤에 시작합니다. 검토 중에 다른 작업을 푸시하면 팀장이 검토하던 내용이 달라집니다.
• 기다리는 동안 급히 다른 작업을 해야 한다면 먼저 팀장에게 알려 주세요.

3-4. 누르지 않는 버튼 (우리 TF 규칙)

실습 4. 병합 후 추가 작업과 두 번째 PR

첫 PR이 끝났다고 작업본을 새로 만들지 않습니다. 같은 작업본을 계속 씁니다. 팀장에게서 "병합했습니다"라는 연락을 받았거나 PR 화면에 보라색 Merged 표시가 보이면 시작하세요.

4-1. 시작: 공통 순서

공통 순서 1~4를 합니다. 저장소 확인 → 내 작업본 선택 → Fetch origin → 버튼이 Pull origin 으로 바뀌면 Pull.

여기서 알아 둘 것이 있습니다.

• 병합은 GitHub 쪽의 main 에서 일어난 일입니다. 내 작업본은 그대로이고, 병합 뒤에 내 PC에서 따로 맞출 것은 없습니다.
• main 은 직접 고치지 않는 것이 우리 TF의 원칙입니다(팀장 포함). main 은 PR이 병합될 때만 바뀌므로, 실제 프로젝트에서 main 에 있는 내용은 모두 내 작업본에서 간 것입니다. 그래서 작업본을 main 에 맞추는 단계가 없습니다.
• Pull origin 이 나타나지 않아도 정상입니다. Pull은 "GitHub에 있는 같은 이름의 작업본"에 내 PC에 없는 커밋이 있을 때만 나타납니다. 예를 들어 팀장이 도와주려고 내 작업본에 수정을 넣어 준 경우입니다. 그럴 때는 팀장이 메신저로 알려 줍니다.

4-2. 추가 수정

1. Codex에게 시킵니다: members/[내 파일].md 파일에 "- 이번 주에 해 보고 싶은 것: [한 줄]" 항목을 추가해 줘. 커밋은 하지 마.
2. 세 가지를 확인합니다. (예상 못 한 파일, 동작, 민감한 자료)
3. 커밋 메모를 쓰고 커밋, 푸시합니다.

4-3. 두 번째 PR

1. 실습 3과 같은 방법으로 PR을 만듭니다.
2. 브라우저의 PR 화면에서 Commits 탭과 Files changed 탭을 열어, 이번에 추가한 커밋과 변경만 보이는지 확인합니다.
3. 첫 PR에서 이미 반영된 커밋이 다시 보이거나 충돌 안내가 나오면, 더 진행하지 말고 팀장에게 알려 주세요. 여러분의 실수가 아니라 저장소의 병합 설정을 점검해야 하는 상황입니다.
4. PR 주소를 팀장에게 알립니다.

이것이 앞으로 반복할 흐름입니다. 공통 순서로 시작 → 작업 → 세 가지 확인 → 커밋·푸시 → 쓸 만해지면 PR → 병합 뒤 같은 작업본에서 계속.

실습 완료 확인

• GitHub 웹사이트에서 내 작업본의 members 폴더에 내 파일이 보입니다
• History 탭에 커밋이 3개 이상 있습니다 (추가, 실수, 되돌리기)
• 첫 PR을 올리고 팀장에게 알렸습니다
• (병합 뒤) 같은 작업본에서 추가 수정을 하고 두 번째 PR을 올렸습니다

자주 발생하는 문제

도움 요청에 붙이는 캡처와 오류 메시지에 비밀번호, 개인정보, 업무 자료가 보이지 않는지 확인하고 올립니다.

이어서 읽기

• 다음 편: 4편. Git 기본 개념 — 실습한 내용의 원리
• 함께 보기: 5편. GitHub 이용 규칙 — 실제 프로젝트를 시작하기 전에
• 함께 보기: 6편. 한 장 요약 — 인쇄해 모니터 옆에 둡니다
• 함께 보기: 7편. 브랜치 분기와 충돌 대처 — 충돌 안내가 떴을 때
• 전체 목록: 가이드 전체 구성