✍ 간단한 GitHub 사용법
GitHub를 사용하다 보면,
“내가 수정한 파일은 어떤 과정을 거쳐 GitHub에 올라가는 걸까?”
라는 궁금증이 생길 때가 있습니다.
저도 처음에는 단순히 파일을 업로드하고 다운로드하는 정도로만 생각했는데,
실제로는 Git이 파일의 상태를 관리하고,
그 상태를 바탕으로 add → commit → push 과정을 거쳐 변경 사항을 기록하고 업로드합니다.
이번 글에서는 Git의 동작 원리 중에서도
status, staging, upload 개념을 중심으로 정리해보려고 합니다.
참고로 이 글은 Mac 환경을 기준으로 작성했습니다.
Git Staging
스테이징(Staging)이란?
스테이징(Staging)이란,
작업한 변경 사항 중 커밋할 내용을 임시로 올려두는 과정을 말합니다.
즉, 작업 디렉터리에서 수정한 파일 전체가 바로 커밋되는 것이 아니라,
먼저 staging area에 올린 뒤 그 내용만 커밋하게 됩니다.
Git에서 파일 상태는 어떻게 나뉠까요?
Git 저장소를 만들고 파일을 관리하기 시작하면,
파일은 여러 상태를 가지게 됩니다.
대표적으로는 다음과 같이 이해하시면 됩니다.
-
Untracked
아직 Git이 관리하지 않는 파일입니다.
예를 들어, 새로 만든 파일이 여기에 해당합니다. -
Tracked
Git이 이미 관리하고 있는 파일입니다.
한 번이라도 스테이징되거나 커밋된 파일은 보통 tracked 상태로 관리됩니다.
그리고 tracked 상태의 파일은 다시 다음과 같이 나뉩니다.
-
Unmodified
마지막 커밋 이후 변경되지 않은 상태 -
Modified
파일은 수정했지만 아직 스테이징하지 않은 상태 -
Staged
수정한 파일 중 커밋할 내용을 스테이징 영역에 올려둔 상태
즉, untracked와 tracked는 서로 구분되는 개념이고,
tracked 안에서 다시 unmodified, modified, staged 상태로 나뉜다고 이해하시면 됩니다.
Git Upload
파일을 수정한 뒤 GitHub까지 올리는 기본 흐름은 보통 다음과 같습니다.
git add → git commit → git push
그림과 함께 보면 각 명령어의 역할을 조금 더 쉽게 이해할 수 있습니다.
-
git add
작업 디렉터리에서 변경한 파일을 staging area에 올리는 명령어입니다.
쉽게 말해, “이 파일을 다음 커밋에 포함하겠습니다”라고 표시하는 과정입니다. -
git commit
staging area에 올라간 변경 사항을 하나의 기록으로 남기는 명령어입니다.
이 기록은 아직 내 컴퓨터의 로컬 저장소(local repository) 에만 저장됩니다. -
git push
로컬 저장소에 기록한 커밋을 원격 저장소(remote repository) 로 업로드하는 명령어입니다.
이때부터 GitHub 같은 원격 저장소에서 변경 사항을 확인할 수 있습니다.
즉, commit까지는 내 로컬에서 일어나는 작업이고,
push를 해야 비로소 GitHub에 반영됩니다.
pull, checkout, merge 같은 명령어는 다음 글에서 따로 정리해보겠습니다.
Git 명령어
그렇다면 add, commit, push는 어떻게 사용할까요?
1. git add
git add [파일 경로]특정 파일만 스테이징하고 싶을 때 사용하는 명령어입니다.
예를 들어 전체 파일이 아니라 일부 파일만 선택해서 커밋하고 싶다면
git add . 대신 파일 경로를 직접 지정하는 것이 좋습니다.
2. git commit
git commit -m "Commit Message"commit이란?
commit은 스테이징된 변경 사항을 하나의 기록으로 저장하는 작업입니다.
여기서 -m 옵션은 커밋 메시지를 명령어와 함께 바로 입력하는 기능입니다.
이 옵션이 없으면 기본 편집기가 열리고, 그 안에서 메시지를 작성해야 합니다.
즉, -m은 커밋 메시지를 더 간편하게 작성하기 위한 옵션이라고 생각하시면 됩니다.
3. git push
git push -u origin [브랜치 이름]이 명령어는 로컬 저장소의 커밋을 원격 저장소로 업로드할 때 사용합니다.
예전에는 기본 브랜치 이름으로 master를 많이 사용했지만,
최근에는 main을 기본 브랜치로 사용하는 경우가 많습니다.
브랜치(branch)는 하나의 프로젝트 안에서 작업 흐름을 나누는 기능입니다.
이 부분도 다음 글에서 조금 더 자세히 다뤄보겠습니다.
실습
이전 글에서는 GitHub에 프로젝트를 빠르게 업로드하는 방법을 정리했다면,
이번에는 그 과정을 조금 더 자세하게 살펴보겠습니다.
1. Spring Boot 프로젝트 파일 열기
먼저 이전에 연결해두었던 Spring Boot 프로젝트를 열어보겠습니다.
예를 들어 Spring Boot 프로젝트를 처음 설정할 때
properties 파일을 yml 파일로 바꾸는 작업을 자주 하곤 합니다.
이 상황에서 파일 이름을 바꾸거나 내용을 수정했다고 가정해보겠습니다.
2. 파일이 수정되면 Git은 상태를 변경합니다
이름을 바꾸거나 내용을 수정하면,
IntelliJ 기준으로 해당 파일 색상이 달라지는 것을 볼 수 있습니다.
이는 해당 파일에 변경 사항이 생겼다는 뜻이고,
이제 그 파일은 git add를 통해 스테이징할 수 있습니다.
그리고 git commit으로 이 변경 사항에 대한 설명을 기록할 수 있습니다.
3. 파일별로 나누어 커밋하기
만약 작업한 내용을 세세하게 나누어 커밋하고 싶다면
git add .을 사용하는 대신,
git add [파일 경로]를 통해 원하는 파일만 선택해서 스테이징하는 것이 좋습니다.
예를 들어 아래처럼 entity와 controller 파일을 새로 만들었다고 해보겠습니다.
이때 두 파일의 작업 성격이 다르다면
각각 다른 커밋 메시지로 관리하고 싶을 수 있습니다.
그런데 git add .으로 모든 파일을 한 번에 스테이징하면
그 변경 사항들이 하나의 커밋으로 묶이기 쉽습니다.
반대로 내가 원하는 파일만 골라서 커밋하고 싶다면,
아래처럼 파일 단위로 스테이징한 뒤 커밋하면 됩니다.
이렇게 하면 작업 의미에 맞게 커밋을 나누어 관리할 수 있습니다.
4. 마지막으로 push 하기
위와 같은 방식으로 커밋을 모두 완료했다면,
이제 git push를 통해 로컬 저장소의 내용을 GitHub 저장소로 올릴 수 있습니다.
저는 main 브랜치를 사용했기 때문에
origin 뒤에 main이라는 브랜치 이름이 들어갔습니다.
업로드가 완료된 뒤 저장소의 커밋 목록을 확인해 보면,
내가 나누어 저장한 커밋들이 잘 반영된 것을 확인할 수 있습니다.
📌 정리
이번 글에서는 이전 글에서 자세히 다루지 않았던
git add, git commit, git push의 개념과 흐름을 정리해보았습니다.
중요한 점은 다음과 같습니다.
git add는 변경 사항을 스테이징 영역에 올리는 과정git commit은 스테이징된 내용을 로컬 저장소에 기록하는 과정git push는 로컬 커밋을 원격 저장소에 업로드하는 과정
이 흐름만 잘 이해해도 Git을 훨씬 덜 헷갈리게 사용할 수 있습니다.
다음 글에서는 프로젝트 방향에 맞게 브랜치를 나누는 방법과
브랜치를 이동하는 checkout,
원격 저장소의 내용을 가져오는 pull에 대해 정리해보겠습니다.
