깃허브?
깃허브(GitHub)는 코드를 로컬에서 버전별로 관리할 수 있도록 하는 도구인 깃(Git)을 기반으로 협업 및 코드 공유가 이루어지는 플랫폼이다.
깃허브를 왜 사용해야 할까?
- 코드 백업 및 접근성 → 코드를 로컬이 아닌 원격 저장소에 보관하여 언제든 꺼내서 사용할 수 있다.
- 버전 관리 → 변경된 부분을 비교하고, 이전 버전으로 쉽게 되돌릴 수 있다.
- 협업 최적화 → 여러 사람이 같은 파일을 수정해도 변경 내역을 추적하고, 쉽게 병합할 수 있다.
- 브랜치 관리 → 각자 독립적인 브랜치에서 작업 후 안전하게 병합하며, 다양한 버전을 유지할 수 있다.
- CI/CD 자동화 → GitHub Actions를 활용해 코드 업로드만으로 빌드, 테스트, 배포를 자동화할 수 있다.
깃의 작업 영역
(1) Working Directory (작업 디렉터리)은 실제로 개발자가 코드를 수정하는 공간이다.
(2) git add를 하면 Staging Area (스테이징 영역)으로 넘어가 커밋을 하기 전에 변경된 파일을 모아둔다.
(3) git commit을 하면 Local Repository (로컬 저장소)으로 넘어가 내 컴퓨터에 Git 히스토리를 저장한다.
(4) git push를 하면 Remote Repository (원격 저장소)으로 넘어가 GitHub와 같은 서버에 저장된다.
작업한 내용이 즉시 로컬 저장소에 반영되지 않고, 변경 사항을 커밋 단위로 나누어 관리할 수 있도록 스테이징 영역이 존재한다. 이를 통해 어떤 변경을 어떤 커밋에 포함할지 선택하여 기록할 수 있다.
git add file1.txt # file1.txt만 스테이징
git commit -m "file1.txt 수정 사항 커밋"깃의 파일 상태
Git에서 파일은 영역을 넘나들며 상태가 변화한다.
현재 파일이 어떤 상태인지 git status 명령어를 사용하여 확인할 수 있다.
1️⃣ Untracked (Git이 추적하지 않는 상태)
새로운 파일이 생성되었지만, 아직 Git이 관리하고 있지 않은 상태이다.
이 상태의 파일은 Git의 버전 관리 대상이 아니며, 커밋에 포함되지 않는다.
test.py가 Untracked 상태이며, 아직 Git이 관리하지 않는 파일이다.
2️⃣ Unmodified (Git이 추적하지만, 변경되지 않은 상태)
여기서 git add를 실행하면 Tracked 상태가 되고 아직 변경되지 않은(Unmodified) 상태가 된다.
이제부터 Git은 파일의 변경 사항을 감지할 수 있으며, 스테이징 영역에 추가된다.
3️⃣ Modified (파일이 수정되었지만, 아직 스테이징되지 않은 상태)
Tracked 상태의 파일이 수정되면 Modified 상태가 된다.
Git은 파일이 변경된 사실을 감지하지만, 아직 스테이징 영역에 추가되지 않았다.
4️⃣ Staged (수정된 파일을 커밋할 준비가 된 상태)
git add를 실행하면 변경 사항이 스테이징 영역으로 이동하여 Staged 상태가 된다.
5️⃣ Committed (로컬 저장소에 기록됨)
git commit을 실행하면 변경 사항이 로컬 저장소에 저장된다.
커밋 후, 파일 상태는 다시 Unmodified 상태로 돌아간다.
6️⃣ Pushed (원격 저장소에 업로드됨)
git push를 실행하면 원격 저장소에 반영된다.
이를 통해 GitHub 같은 원격 저장소에서 다른 개발자와 변경 사항을 공유할 수 있다. 로컬 저장소와 원격 저장소는 동기화된 상태이다.
정리하면,
새로운 파일을 추가하면 Git이 추적하지 않는 Untracked 상태이며, git add를 실행하면 Tracked 상태로 변경된다. Tracked 상태는 Unmodified, Modified, Staged 세 가지로 나뉘며, 파일을 수정하면 Modified 상태가 되고, 다시 git add를 실행하면 Staged 상태가 되어 로컬 저장소에 커밋할 수 있는 상태가 된다.
Untracked → Tracked(Unmodified, Modified, Staged) → Committed마주할 수 있는 에러 상황과 해결책
- 실수로 git add한 파일을 커밋 전에 되돌리기
파일을 수정하고 git add를 실행했지만, 아직 커밋할 준비가 되지 않았다.
git reset을 활용하여 파일 상태를 Staged → Modified 상태로 되돌려서 불필요한 커밋을 방지할 수 있다.
- 다른 브랜치로 이동하려는데, 변경 사항이 남아 있어서 이동이 불가능한 경우
작업 중이던 브랜치를 변경하려고 했는데, Modified 상태의 파일이 있어서 브랜치 변경이 불가능하다.
git stash를 사용하여 변경 사항을 안전하게 저장하고 브랜치를 이동한다.
git stash pop을 사용하여 변경 사항을 다시 복원하며, stash가 자동으로 제거된다.
📌 git stash의 상세 기능 (list, show, apply, drop, pop)
여러 버전의 stash를 저장하고, 원하는 stash를 꺼내 적용하거나 삭제할 수 있다.
(1) git stash list
leeyena@192 test_folder % git stash list
stash@{0}: WIP on develop: dced3c4 commit message
stash@{1}: WIP on main: 83b7265 commit(2) git stash show
leeyena@192 test_folder % git stash show stash@{1}
test.py | 1 +
1 file changed, 1 insertion(+)
leeyena@192 test_folder % git stash show -p stash@{1}
diff --git a/test.py b/test.py
index 2cad118..be602c2 100644
--- a/test.py
+++ b/test.py
@@ -1,4 +1,5 @@
print("test1")
print("test1")
print("test1")
+print("test1")
print("test1")
\ No newline at end of file(3) git stash apply stash@{번호} → 특정 stash를 적용하지만, 삭제하지 않음
(4) git stash drop stash@{번호} → 특정 stash를 삭제함
(5) git stash pop → 가장 최근 stash (stash@{0})만 적용한 후 삭제함 (특정 stash 적용 불가)
마무리
내 작업 폴더에서 원격 저장소까지 코드가 이동하는 과정을 정리하며, Git이 파일 상태에 따라 어떻게 동작하는지 정리해보았다.
마치 if state == "modified"일 때 특정 작업을 수행하는 것처럼, Git은 각 상태에 맞는 처리를 하도록 설계되어 있다.
다양한 에러 상황에서 파일이 현재 어떤 상태에 있는지 추적하며 작업하면 문제를 더 쉽게 받아들이고 효과적으로 해결할 수 있다.
