이번 프리코스에서는 이전 시간에 배웠던 Git의 기본 개념에서 한 단계 더 나아가, 실제로 변경한 파일을 커밋으로 기록하고 GitHub에 올리는 전체 과정을 실습했다.
처음 Git을 배울 때는 add, commit, push 같은 명령어를 각각 외워야 하는 것처럼 느껴졌는데, 이번 강의를 통해 각각의 명령어가 따로 존재하는 것이 아니라 파일의 변경 사항을 하나의 버전으로 만들고 이를 원격 저장소까지 전달하는 과정이라는 것을 이해할 수 있었다.
또한 이미 만들어진 커밋의 내용을 확인하는 git show와 버전 사이의 차이를 비교하는 git diff도 함께 살펴봤다.
1. Git의 기본 작업 흐름
Git에서 파일은 작업 과정에 따라 여러 상태를 거친다.
이번 강의에서는 다음과 같은 흐름을 중심으로 살펴봤다.
Working Tree → Staging Area → Commit
Working Tree
Working Tree는 실제로 파일을 작성하고 수정하는 작업 공간이다.
예를 들어 Python 파일의 코드를 수정하거나 새로운 파일을 생성하면 우선 Working Tree에 변경 사항이 발생한다.
Staging Area
변경된 파일 중에서 다음 커밋에 포함할 파일을 준비하는 공간이다.
git add 파일명
특정 파일만 선택할 수도 있고,
git add .
현재 디렉터리에서 발생한 변경 사항을 한꺼번에 스테이징할 수도 있다.
Commit
Staging Area에 준비된 변경 사항을 하나의 버전으로 기록하는 과정이다.
git commit -m "커밋 메시지"
즉, 내가 이해한 Git의 기본 흐름을 간단하게 정리하면 다음과 같다.
파일 수정 → 변경 사항 확인 → 필요한 파일 선택 → 커밋 → 기록 확인
2. git status로 파일 상태 확인하기
Git을 사용할 때 중요한 명령어 중 하나가 git status였다.
git status
이 명령어를 사용하면 현재 Working Tree에서 어떤 파일에 변화가 생겼는지 확인할 수 있다.
강의에서는 기존 파일을 수정하고 새로운 파일도 생성해보면서 상태의 차이를 확인했다.
기존에 Git이 관리하던 파일을 수정하면 modified, 새롭게 생성되어 아직 Git이 추적하지 않는 파일은 untracked 상태로 표시됐다.
따라서 무조건 git add .부터 실행하는 것보다 먼저 git status로 내가 어떤 파일을 변경했는지 확인하는 습관이 중요하다는 것을 알 수 있었다.
3. git add로 커밋할 파일 선택하기
변경된 모든 파일을 항상 하나의 커밋에 넣어야 하는 것은 아니다.
강의에서는 기존 first.txt 파일을 수정하면서 동시에 새로운 beta.txt 파일을 생성한 뒤, 두 파일을 서로 다른 커밋으로 관리하는 실습을 진행했다.
특정 파일만 스테이징하려면 다음과 같이 사용했다.
git add first.txt
전체 변경 사항을 추가하려면 다음과 같이 사용할 수 있었다.
git add .
이 부분에서 Staging Area가 왜 필요한지 조금 더 이해할 수 있었다.
여러 파일을 동시에 수정했더라도 기능이나 작업 목적에 따라 필요한 변경 사항만 골라 하나의 커밋으로 만들 수 있기 때문이다.
4. 잘못 스테이징한 파일 되돌리기
실수로 커밋에 포함하면 안 되는 파일까지 git add를 했다면 다시 Staging Area에서 제외할 수도 있었다.
강의에서는 다음 명령을 사용했다.
git rm --cached 파일명
--cached 옵션을 사용하면 실제 Working Tree의 파일을 삭제하는 것이 아니라 Staging Area, 즉 인덱스에서만 제외할 수 있다는 점도 확인했다.
Git을 사용할 때 단순히 명령어 이름만 보는 것이 아니라 해당 명령이 실제 파일을 지우는 것인지, Git이 관리하는 상태만 변경하는 것인지 구분해야 한다는 점도 중요해 보였다.
5. 커밋으로 하나의 버전 만들기
Staging Area에 원하는 변경 사항을 준비했다면 커밋을 만들 수 있다.
가장 간단한 방법은 다음과 같다.
git commit -m "로그인 기능 구현"
-m 옵션을 사용하면 명령어에서 바로 커밋 메시지를 작성할 수 있다.
커밋 메시지는 단순한 메모가 아니라 해당 버전에서 무엇을 변경했는지 알려주는 기록이었다.
특히 GitHub를 포트폴리오나 협업 도구로 사용하면 다른 사람도 커밋 기록을 확인하기 때문에,
수정
1
처럼 의미를 알기 어려운 메시지보다는
로그인 기능 구현
카카오톡 로그인 기능 구현 완료
처럼 어떤 작업을 했는지 알 수 있도록 작성하는 것이 좋다는 점도 배웠다.
6. 의미 있는 단위로 커밋하기
이번 강의에서 단순히 커밋 명령어를 사용하는 방법뿐 아니라 언제 커밋하면 좋은지에 대한 설명도 있었다.
예를 들어 다음과 같은 작업을 각각 의미 있는 커밋으로 관리할 수 있다.
- 새로운 기능 추가
- 버그 수정
- 리팩토링
- 인터페이스 변경
- 코드 스타일이나 문서 수정
프로젝트를 처음부터 끝까지 개발한 뒤 한 번만 커밋하면 중간 과정을 확인하기 어렵다.
반대로 의미 있는 작업 단위로 커밋을 남기면 나중에 변경 이력을 추적하거나 특정 시점의 코드를 확인하기가 쉬워진다.
결국 커밋은 단순히 코드를 저장하는 행위라기보다 개발 과정을 작은 버전으로 기록하는 작업이라고 이해할 수 있었다.
7. git log로 커밋 기록 확인하기
만들어진 커밋은 git log를 이용해 확인했다.
git log
커밋 기록에서는 커밋을 구분하는 해시값과 함께 작성자, 작성 시간, 커밋 메시지 등을 확인할 수 있었다.
또한 다음과 같이 --graph 옵션을 사용할 수도 있었다.
git log --graph
커밋이 어떤 흐름으로 이어져 왔는지 조금 더 시각적으로 확인할 수 있었다.
커밋을 만들기만 하는 것이 아니라 기록을 다시 확인하고 추적할 수 있다는 것이 버전 관리의 중요한 부분이라는 생각이 들었다.
8. 커밋 메시지 편집기를 VS Code로 변경하기
git commit만 실행하면 별도의 편집기가 열려 커밋 메시지를 작성할 수도 있었다.
강의에서는 Vim을 이용해 메시지를 작성하는 방법을 먼저 살펴본 뒤, Git의 기본 편집기를 VS Code로 변경하는 과정도 진행했다.
git config --global core.editor "code --wait"
여기서 --wait 옵션이 중요했다.
VS Code가 커밋 메시지 작성을 끝내기도 전에 Git이 다음 작업으로 넘어가지 않고, VS Code를 닫을 때까지 기다리도록 하는 역할을 했다.
실습 중 처음에는 이 옵션이 없어 커밋이 정상적으로 진행되지 않았고, --wait를 추가한 뒤 정상적으로 커밋이 완료되는 것도 확인했다.
이번 실습을 통해 오류가 발생했을 때 단순히 명령어를 다시 실행하기보다 설정과 옵션이 어떤 역할을 하는지 확인하는 과정도 필요하다는 것을 볼 수 있었다.
9. Git과 GitHub의 차이
로컬에서 커밋을 만드는 방법을 배운 뒤에는 GitHub와 연결하는 과정으로 넘어갔다.
여기서 먼저 구분해야 할 것은 Git과 GitHub는 같은 것이 아니라는 점이었다.
Git은 파일의 변경 이력을 관리하는 분산형 버전 관리 프로그램이고, GitHub는 Git 저장소를 온라인에서 관리하고 공유할 수 있도록 제공하는 서비스다.
즉 지금까지 만든 커밋은 내 컴퓨터의 로컬 저장소에만 존재했고, 이를 GitHub에 올리면 온라인에서도 관리할 수 있게 된다.
10. GitHub 원격 저장소 연결하기
GitHub에서 새로운 Repository를 만든 뒤 로컬 Git 저장소와 연결했다.
원격 저장소를 등록할 때는 다음과 같은 형태의 명령어를 사용했다.
git remote add origin 원격저장소주소
여기서 origin은 원격 저장소 주소를 매번 길게 입력하지 않도록 붙여 사용하는 이름이라고 이해할 수 있었다.
등록된 원격 저장소는 다음 명령어로 확인했다.
git remote -v
이를 통해 fetch와 push에 사용되는 원격 저장소 주소를 확인할 수 있었다.
11. git push로 GitHub에 커밋 올리기
로컬에서 만든 커밋을 GitHub로 전달하는 작업이 push다.
최초 연결 과정에서는 다음과 같이 upstream을 설정했다.
git push -u origin main
이 과정을 통해 로컬의 main 브랜치와 원격 저장소의 브랜치가 연결되고, 로컬에서 만든 커밋이 GitHub Repository에 반영되는 것을 확인했다.
이후의 기본적인 작업 흐름은 다음과 같이 정리할 수 있었다.
git status
git add 파일명
git commit -m "작업 내용"
git push
이제 단순히 내 컴퓨터에 버전을 만드는 것을 넘어 온라인 저장소에도 개발 기록을 남길 수 있게 된 것이다.
12. GitHub 인증과 토큰
강의에서는 GitHub 원격 저장소에 접근하기 위한 인증 과정으로 Personal Access Token도 다뤘다.
토큰을 만들면서 유효기간과 Repository 관련 권한을 설정했고, 생성된 토큰은 최초 생성 시 확인할 수 있기 때문에 별도로 관리해야 한다는 점도 살펴봤다.
특히 토큰은 계정과 저장소 접근 권한에 관련된 중요한 정보이므로 소스 코드나 공개 Repository에 그대로 올리지 않도록 주의해야 한다.
13. git show로 특정 커밋 살펴보기
커밋이 여러 개 쌓이기 시작하면 과거 특정 시점에서 어떤 작업을 했는지 확인할 필요가 있다.
이때 사용한 명령어가 git show였다.
git show 커밋해시
특정 커밋에서 어떤 변경이 발생했는지 확인할 수 있다.
특정 커밋에서 특정 파일의 내용만 보고 싶다면 다음과 같이 확인할 수도 있었다.
git show 커밋해시:파일경로
커밋의 해시값이 각각의 버전을 구분하는 식별자 역할을 하기 때문에 원하는 시점의 내용을 찾아볼 수 있었다.
14. git diff로 변경 사항 비교하기
git show가 특정 커밋을 살펴보는 명령이라면 git diff는 서로 다른 상태 사이에서 무엇이 변경됐는지 비교하는 명령어였다.
현재 Working Tree에서 아직 스테이징하지 않은 변경 사항을 확인할 때는 다음과 같이 사용했다.
git diff
이미 Staging Area에 올라간 변경 사항을 확인할 때는 다음과 같이 사용했다.
git diff --staged
특정 커밋과 현재 상태를 비교할 수도 있었다.
git diff 커밋해시
실습에서는 로그인 기능과 관련된 문장을 추가하면서 어떤 줄이 삭제되고 어떤 줄이 새롭게 추가됐는지 확인했다.
이 기능을 이용하면 커밋하기 전에 내가 의도한 코드만 변경됐는지 검토할 수 있고, 이후에는 코드 리뷰나 오류 원인을 확인하는 데에도 활용할 수 있다는 점을 배웠다.
15. 이번 프리코스를 통해 정리한 Git 흐름
이번 시간까지 배운 내용을 연결해보면 Git의 작업 흐름이 조금 더 명확해졌다.
1. 파일을 작성하거나 수정한다.
↓
2. git status로 변경된 파일을 확인한다.
↓
3. git diff로 실제 변경 내용을 확인한다.
↓
4. git add로 커밋할 파일을 Staging Area에 올린다.
↓
5. 필요하다면 git diff --staged로 다시 확인한다.
↓
6. git commit으로 하나의 버전을 만든다.
↓
7. git log와 git show로 기록을 확인한다.
↓
8. git push로 GitHub 원격 저장소에 반영한다.
각 명령어만 따로 보면 외워야 할 것이 많아 보이지만, 실제 개발 과정에 맞춰 연결해보면 결국 확인 → 선택 → 기록 → 검토 → 공유의 흐름이라고 이해할 수 있었다.
마무리
이번 프리코스에서는 Git을 단순히 명령어를 사용하는 도구가 아니라 개발 과정의 변화를 기록하는 버전 관리 도구라는 관점에서 조금 더 구체적으로 이해할 수 있었다.
특히 Working Tree에서 발생한 모든 변경 사항을 무조건 커밋하는 것이 아니라 Staging Area를 이용해 필요한 변경 사항을 선택하고, 의미 있는 작업 단위로 커밋을 나누는 이유를 알 수 있었다.
또한 로컬에서 만든 커밋을 GitHub 원격 저장소에 push하면서 Git과 GitHub가 어떤 관계인지도 연결해서 이해할 수 있었다.
마지막으로 git show와 git diff를 이용하면 단순히 과거 기록을 저장하는 것에서 끝나는 것이 아니라, 어떤 시점에 무엇이 바뀌었는지 다시 확인하고 비교할 수 있다는 점도 배웠다.
앞으로는 Git 명령어 자체를 외우는 것보다 실제 프로젝트에서 status → add → commit → push 흐름을 반복해서 사용하면서 익숙해지는 것이 중요할 것 같다. 특히 커밋하기 전에 git diff를 확인하고, 나중에 봐도 작업 내용을 이해할 수 있도록 커밋 메시지를 작성하는 습관을 연습해봐야겠다.
'AI 오케스트레이션 프리코스' 카테고리의 다른 글
| SK네트웍스 Family 엔코아 AI 오케스트레이션 프리코스 9｜AI 주도 개발과 Cursor·Claude Code 활용 (0) | 2026.09.18 |
|---|---|
| SK네트웍스 Family 엔코아 AI 오케스트레이션 프리코스 8｜GitHub 협업과 브랜치 활용 (0) | 2026.09.14 |
| SK네트웍스 Family 엔코아 AI 오케스트레이션 프리코스 6｜Git 기초·초기 설정·브랜치·파일 상태 (0) | 2026.08.18 |
| SK네트웍스 Family 엔코아 AI 오케스트레이션 프리코스 5｜파이썬 내장 함수·클래스·상속·모듈 (0) | 2026.08.07 |
| SK네트웍스 Family 엔코아 AI 오케스트레이션 프리코스 4｜파이썬 반복문·함수·리스트 컴프리헨션·람다 (0) | 2026.08.03 |
댓글