깃 워크 플로우

 

단순히 명령어를 나열하는 것을 넘어, 프로젝트의 변경사항을 추적하고, 협업하는 것

 

정의

 

1. 워킹 디렉토리 (Working Directory):
   • 물질적 비유: 사용자님의 컴퓨터 책상 위, 현재 펼쳐놓고 작업 중인 실제 프로젝트 파일들이 놓인 공간입니다. 코드를 수정하고, 파일을 생성하거나 삭제하는 모든 활동이 여기서 일어납니다.
   • 실체: 프로젝트 폴더 그 자체입니다. my-project/ 같은 곳이죠.
2. 스테이징 에어리어 (Staging Area, 또는 Index):
   • 물질적 비유: 책상 위에서 작업한 결과물 중, 다음번 공식 기록(커밋)에 포함시킬 것들만 골라 올려두는 '발표 준비대'와 같습니다. 모든 변경사항을 한꺼번에 기록하는 것이 아니라, 의미 있는 단위로 선별하는 중간 단계입니다.
   • 실체: .git 디렉토리 내의 index 파일에 이 정보가 기록됩니다. 어떤 파일의 어떤 내용이 다음 커밋에 포함될지 명시하는 목록과 같습니다.
3. 로컬 저장소 (Local Repository):
   • 물질적 비유: 사용자님 개인 서재의 '프로젝트 역사 기록 보관함'입니다. 스테이징 에어리어에서 준비된 변경사항들이 버전별로 차곡차곡 스냅샷 형태로 저장되는 곳입니다. 모든 버전 히스토리와 브랜치 정보 등이 이곳에 안전하게 보관됩니다.
   • 실체: 프로젝트 루트 폴더 내의 숨겨진 .git 디렉토리입니다. 이 안에는 객체 데이터베이스(실제 파일 변경 내용들), 참조(브랜치, 태그 포인터), 설정 파일 등이 들어있습니다.
4. 원격 저장소 (Remote Repository):
   • 물질적 비유: 여러 사람이 함께 사용하는 '중앙 도서관의 프로젝트 서고'와 같습니다. 내 로컬 저장소의 내용을 다른 사람들과 공유하거나, 다른 사람의 작업을 가져올 때 사용합니다. 주로 GitHub, GitLab, Bitbucket 같은 서비스에 위치합니다.
   • 실체:네트워크 어딘가에 있는 또 다른 Git 저장소입니다.

 

---

기본 명령어

완전히 새로운 프로젝트 시작 git init

mkdir my-awesome-project  # 프로젝트 폴더 생성
cd my-awesome-project     # 폴더로 이동
git init                  # 현재 디렉토리를 Git 저장소로 초기화

 

기존 프로젝트 참여 git clone

git clone https://github.com/some-user/their-awesome-project.git

 

---

변경 상태 확인 git status

 

커밋할 변경사항 선별 : 스테이징 구역으로 이동 git add

git add main.py          # main.py 파일의 변경사항만 스테이징
git add utils.py         # utils.py 파일을 새로 추적하고 스테이징
# 또는
git add .                # 현재 디렉토리의 모든 변경사항(수정, 새 파일)을 스테이징

 

로컬 저장소에 기록 git commit

git commit -m "Add feature X and utility functions"

 

---

새 브랜치 생성 git branch 브랜치이름

git branch feature/new-login  # 'feature/new-login'이라는 이름의 브랜치 생성

 

브랜치 전환 git switch 브랜치명

git checkout feature/new-login
# 또는 (더 최신, 명확한 명령어)
git switch feature/new-login

 

워킹 디렉토리의 파일들이 feature/new-login 브랜치의 마지막 커밋 상태로 업데이트됩니다

 

주 브랜치로 복귀 및 병합 준비 (main으로 돌아와서 합침)

git switch main  # main 브랜치로 전환

 

브랜치 병합 git merge 병합할브랜치명

git merge feature/new-login

 

• Fast-forward merge: main 브랜치가 feature/new-login 브랜치가 분기한 이후로 아무런 추가 커밋이 없었다면, main 브랜치 포인터는 단순히 feature/new-login 브랜치가 가리키는 최신 커밋으로 "빨리 감기"처럼 이동합니다. 히스토리가 단순하게 직선으로 이어집니다.
• 3-way merge (Merge commit): main 브랜치에도 그동안 다른 변경사항이 있었다면 (다른 커밋이 존재), Git은 두 브랜치의 변경사항을 합친 새로운 **머지 커밋(merge commit)**을 생성합니다. 이 머지 커밋은 두 개의 부모 커밋(하나는 main의 최신 커밋, 다른 하나는 feature/new-login의 최신 커밋)을 가집니다. main 브랜치 포인터는 이 새로운 머지 커밋을 가리키게 됩니다. 히스토리에 가지가 합쳐지는 모양이 나타납니다.
• 충돌 (Conflict): 만약 main 브랜치와 feature/new-login 브랜치에서 같은 파일의 같은 부분을 다르게 수정했다면, Git은 자동으로 병합할 수 없어 충돌이 발생합니다.
• 물질적 변화: 충돌이 발생한 파일에는 <<<<<<<, =======, >>>>>>> 같은 마커가 표시됩니다.
• 사용자는 이 파일을 직접 열어 충돌 부분을 수정한 후, 다시 git add [충돌난_파일] -> git commit (이때 -m 옵션 없이 실행하면 Git이 기본 머지 커밋 메시지를 제안)을 통해 병합을 완료해야 합니다.

 

브랜치 삭제 git branch -d 브랜치 이름

git branch -d feature/new-login  # 병합된 브랜치 삭제
# 강제 삭제 (병합되지 않은 변경사항이 있어도 삭제): git branch -D feature/wip-branch

 

---

원격 저장소에 로컬 변경사항 업로드 git push 별칭 브랜치명

git push origin main  # 로컬 main 브랜치의 내용을 origin 원격 저장소의 main 브랜치로 푸시
git push origin feature/new-login # 로컬 feature/new-login 브랜치를 origin에 같은 이름으로 푸시 (원격에 해당 브랜치가 없다면 새로 생성)

 

• 주의: 만약 로컬에서 푸시하려는 브랜치의 원격 버전이 내가 모르는 사이에 다른 사람에 의해 업데이트되었다면 (즉, 원격 브랜치에 내가 가지지 않은 커밋이 있다면), 푸시가 거부될 수 있습니다 (non-fast-forward). 이 경우 먼저 git pull을 통해 원격 변경사항을 가져와 병합한 후 다시 푸시해야 합니다.

 

원격 저장소의 변경사항 가져오기 git fetch 별칭

git fetch origin

 

최신 변경사항을 내 로컬 저장소로 가져오고 싶지만, 아직 내 워킹 디렉토리나 현재 브랜치에 바로 병합하고 싶지는 않을 때 사용

 

원격 저장소 변경사항 가져와서 병합하기 git pull 별칭 브랜치명

git pull origin main  # origin 원격 저장소의 main 브랜치 내용을 가져와 현재 로컬 브랜치에 병합

 

---

GitHub/GitLab 등 플랫폼에서의 협업 흐름

1. 주 저장소(upstream 또는 origin)를 자신의 계정으로 Fork합니다. (플랫폼 기능)
2. Fork한 개인 저장소를 로컬로 clone합니다.
3. 새로운 기능이나 수정을 위해 로컬에서 브랜치를 생성하고 작업합니다 (feature/my-fix).
4. 작업한 브랜치를 자신의 Fork된 원격 저장소로 push합니다 (git push origin feature/my-fix).
5. GitHub/GitLab 웹사이트에서, Fork한 저장소의 feature/my-fix 브랜치에서 원본 주 저장소의 main 브랜치로 Pull Request (PR) 또는 **Merge Request (MR)**를 생성합니다.
6. 프로젝트 관리자 또는 다른 팀원들이 PR/MR을 보고 코드 리뷰를 진행하고, 의견을 주고받습니다.
7. 리뷰에서 수정 요청이 있으면, 로컬 feature/my-fix 브랜치에서 추가 커밋을 하고 다시 push하면 PR/MR에 자동으로 반영됩니다.
8. 모든 검토가 끝나고 승인되면, 프로젝트 관리자가 웹사이트에서 PR/MR을 Merge합니다. 이때 실제 병합 작업은 플랫폼 서버에서 이루어집니다.
9. 이후 로컬 main 브랜치를 원본 주 저장소의 main과 동기화하기 위해 git pull upstream main (원본 주 저장소를 upstream으로 등록해뒀다면) 등을 실행합니다.

 

---

기타 유용한 도구들 (물질적 관점)

• .gitignore 파일:
  • 프로젝트 루트에 이 파일을 만들고, 버전 관리에서 제외하고 싶은 파일이나 디렉토리 패턴(예: *.log, build/, .env)을 적어두면, git add . 실행 시 Git이 이 패턴에 해당하는 파일들을 "못 본 척" 무시합니다. 즉, 스테이징 에어리어에 올라가지 않습니다.
• git log --graph --oneline --decorate --all:
  • 커밋 히스토리를 브랜치 구조와 함께 한 줄로 깔끔하게 시각화하여 보여줍니다. 브랜치 포인터들이 어떻게 각 커밋들을 가리키고, 어떻게 갈라지고 합쳐졌는지 한눈에 파악할 수 있습니다.
• git diff:
  • git diff: 워킹 디렉토리와 스테이징 에어리어 간의 변경 내용 비교.
  • git diff --staged (또는 git diff --cached): 스테이징 에어리어와 마지막 커밋 간의 변경 내용 비교.
  • git diff [브랜치1] [브랜치2]: 두 브랜치 간의 최종 결과물 차이 비교.
  • 파일 내용의 어떤 줄이 추가/삭제/변경되었는지 보여줍니다.
• git stash:
  • 상황: 현재 브랜치에서 작업을 하던 중, 아직 커밋하기는 애매한데 다른 브랜치로 급하게 전환해야 할 때.
  • 명령어: git stash save "임시 작업 내용"
  • 물질적 변화: 워킹 디렉토리와 스테이징 에어리어의 변경사항들을 특별한 "스태시(stash)"라는 임시 저장 공간에 저장하고, 워킹 디렉토리를 마지막 커밋 상태로 깨끗하게 되돌립니다. .git 내부에 이 임시 변경사항이 스택처럼 쌓입니다.
  • 나중에 git stash pop 또는 git stash apply로 저장했던 변경사항을 다시 불러올 수 있습니다.

 

 

---

✨ git switch vs git checkout: 무엇이 다를까요? ✨

git switch는 git checkout이 가진 여러 기능 중 브랜치 전환과 관련된 작업을 보다 명확하고 안전하게 수행하기 위해 Git 2.23 버전부터 도입된 명령어입니다.

 

1. git checkout의 과거와 현재: 만능 도구의 명과 암

git checkout은 Git의 역사와 함께 해온 매우 강력하고 다재다능한 명령어입니다. 하지만 그만큼 다양한 역할을 수행했습니다.

 

• 주요 기능들:
  • 브랜치 전환: git checkout <이동할_브랜치명> : HEAD 포인터가 지정된 브랜치를 가리키도록 변경되고, 워킹 디렉토리와 인덱스(스테이징 에어리어)가 해당 브랜치의 최신 커밋 상태로 업데이트됩니다.
  • 파일 복원 (워킹 디렉토리): git checkout -- <파일경로> : 워킹 디렉토리의 특정 파일을 마지막 커밋(또는 스테이징된) 상태로 되돌립니다.
  • 파일 복원 (스테이징 에어리어에서): 과거에는 git reset HEAD <파일경로> 후 git checkout -- <파일경로> 조합을 사용하거나, 다른 복잡한 방식이 필요했습니다.
  • 특정 커밋으로 이동 (Detached HEAD 상태): git checkout <커밋_해시> 또는 git checkout <태그명> : HEAD가 특정 커밋을 직접 가리키게 되어 "Detached HEAD" 상태가 됩니다. 워킹 디렉토리와 인덱스는 해당 커밋 상태로 바뀝니다. 이 상태에서의 커밋은 어떤 브랜치에도 속하지 않게 됩니다.
  • 브랜치 생성과 동시에 전환: git checkout -b <새_브랜치명> [시작점_커밋/브랜치] : 새로운 브랜치를 생성하고 즉시 그 브랜치로 HEAD를 이동시킵니다.
• 문제점: 하나의 명령어가 너무 많은 맥락에서 다르게 동작하여, 특히 초보 사용자에게 혼란을 주거나 의도치 않은 실수를 유발할 가능성이 있었습니다. 예를 들어 브랜치 이름과 파일 이름이 같은 경우, Git은 사용자의 의도를 명확히 파악하기 어려울 수 있습니다. (물론 --를 사용해 파일을 명시적으로 지정하면 해결되지만요.)

 

2. git switch의 등장: 명확성을 위한 분리

이러한 혼란을 줄이고자 Git 개발팀은 git checkout의 기능 중 일부를 분리하여 더 직관적인 새 명령어를 만들었습니다. 그중 하나가 바로 git switch입니다.

 

• • 주요 목적: 오직 **브랜치와 관련된 작업(생성, 전환)**에만 집중합니다.
  • 주요 기능들:
    • 브랜치 전환: git switch <이동할_브랜치명>
      • 물질적 변화: git checkout <브랜치명>과 동일하게 HEAD 이동, 워킹 디렉토리/인덱스 업데이트.
      • 안전장치: 만약 전환하려는 브랜치가 존재하지 않으면, 파일 이름으로 착각하여 파일을 복원하려는 시도를 하지 않고 명확히 오류를 표시합니다.
    • 브랜치 생성과 동시에 전환: git switch -c <새_브랜치명> 또는 git switch --create <새_브랜치명> [시작점_커밋/브랜치]
      • git checkout -b와 동일한 기능입니다. 옵션 이름(-c, --create)이 더 명시적입니다.
    • 이전 브랜치로 빠르게 전환: git switch -
      • git checkout - 와 동일하게, 바로 이전에 작업하던 브랜치로 돌아갑니다.
    • Detached HEAD 상태로 전환 (명시적): git switch --detach <커밋_해시_또는_태그명>
      • git checkout <커밋_해시>와 유사하지만, --detach 옵션을 통해 사용자의 의도를 명확히 합니다.
    • 강제 전환 (로컬 변경사항 무시): git switch -f <브랜치명> 또는 git switch --force <브랜치명> (주의해서 사용!)
      • 이 기능은 git checkout -f 와 유사하게, 커밋되지 않은 로컬 변경사항이 있더라도 강제로 브랜치를 전환하고 변경사항을 덮어쓸 수 있습니다. (데이터 유실 위험)

 

3. git restore의 등장: 파일 복원의 명확화

git switch와 함께 등장한 또 다른 중요한 명령어는 git restore입니다. 이 명령어는 git checkout이 담당하던 "파일 복원" 기능을 가져왔습니다.

 

• • 주요 목적: 워킹 디렉토리의 변경사항을 되돌리거나, 스테이징 에어리어에서 파일을 내리는(unstage) 작업에 집중합니다.
  • 주요 기능들:
    • 워킹 디렉토리 파일 변경사항 되돌리기: git restore <파일경로>
      • git checkout -- <파일경로>와 유사하게, 워킹 디렉토리의 파일을 마지막 커밋 또는 스테이징된 상태로 되돌립니다.
    • 스테이징된 파일 내리기 (Unstage): git restore --staged <파일경로>
      • git reset HEAD <파일경로>와 동일한 효과입니다. 스테이징 에어리어에서 파일을 내리고, 변경사항은 워킹 디렉토리에 남겨둡니다.

 

4. 핵심 차이점 요약

대표사진 삭제

사진 설명을 입력하세요.

5. 권장 사용법

• • 브랜치를 만들거나 전환할 때는 git switch를 사용하십시오.
  • 파일의 변경사항을 되돌리거나 스테이징을 취소할 때는 git restore를 사용하십시오.
  • git checkout은 여전히 모든 기능을 수행할 수 있지만, 새로운 명령어들을 사용함으로써 명령어의 의도를 더 명확히 하고 실수를 줄일 수 있습니다. 마치 잘 만들어진 전문 공구가 여러 작업을 어설프게 하는 만능 공구보다 특정 작업에 더 효율적이고 안전한 것과 같습니다.