Git과 GitHub

1. 개요 및 정의

1.1. 한 줄 요약 (비유)

Git은 '타임머신(저장 포인트)'이고, GitHub는 '타임머신 보관소(클라우드)'다.

• Git
  • 게임의 세이브 파일을 만드는 도구다. 과거의 특정 시점으로 언제든 되돌아갈 수 있게 해준다.
• GitHub
  • 내 컴퓨터에만 있는 세이브 파일을 친구들과 공유할 수 있는 클라우드 드라이브이자, 개발자들의 SNS다.

1.2. 공식 정의

• Git (깃)
  • 리눅스 커널의 창시자 리누스 토발즈가 개발한 분산 버전 관리 시스템이다.
  • 소스 코드의 이력을 관리하고 변경 사항을 추적한다.
• GitHub (깃허브)
  • Git 저장소를 호스팅해주는 웹 기반 호스팅 서비스다.
  • Git의 기본적인 기능 외에 협업을 위한 기능(Pull Request, Code Review, Issue Tracking)과 DevOps 기능(GitHub Actions)을 제공한다.

2. 버전 관리 시스템 종류

• 버전 관리 시스템은 데이터를 저장하고 관리하는 아키텍처에 따라 크게 3세대로 구분된다.
  • 각 방식은 명확한 장단점과 탄생 배경을 가진다.

2.1. 1세대: 로컬 버전 관리 (Local VCS)

• 대표 도구: RCS (Revision Control System)
• 동작 원리:
  • 내 컴퓨터의 로컬 디스크에 있는 간단한 데이터베이스를 사용한다.
  • 파일의 변경 사항(Patch Set)만을 관리하며, 이를 적용하여 특정 시점의 파일을 재구성한다.
• 한계: 내 컴퓨터가 고장 나면 모든 히스토리가 날아간다. 협업이 불가능하다.

2.2. 2세대: 중앙 집중식 버전 관리 (Centralized VCS, CVCS)

• 대표 도구: SVN (Subversion), CVS, Perforce
• 동작 원리:
  • 파일을 저장하는 단 하나의 중앙 서버가 존재한다.
  • 클라이언트(사용자)는 중앙 서버에서 파일의 특정 버전을 내려받아(Checkout) 작업하고 다시 올린다.
  • 파일 잠금(Locking) 모델을 주로 사용하여, A가 파일을 수정 중이면 B는 수정하지 못하게 막는 방식이 많았다.
• 구조적 특징:
  • 관리자가 누가 무엇을 하는지 꼼꼼하게 관리할 수 있다.
  • 치명적 단점 (SPOF):
    • 중앙 서버가 다운되면 그동안 아무도 작업을 커밋하거나 이력을 조회할 수 없다.
    • 서버 디스크가 깨지면 모든 역사가 사라진다.

2.3. 3세대: 분산 버전 관리 (Distributed VCS, DVCS)

• 대표 도구: Git, Mercurial, Bazaar
• 동작 원리:
  • 단순히 파일의 마지막 스냅샷을 가져오는 것이 아니라, 저장소 전체를 클라이언트로 복제한다.
  • 서버에 있는 모든 히스토리가 내 컴퓨터에도 똑같이 저장된다.
• 구조적 특징:
  • 완벽한 백업:
    • 서버가 죽어도 클라이언트 중 아무거나 골라서 서버를 복원할 수 있다.
  • 오프라인 작업:
    • 네트워크가 없어도 로컬에서 커밋, 히스토리 조회, 브랜치 생성이 가능하다.
    • 나중에 인터넷이 연결될 때 푸시하면 된다.

3. Git 내부 구조

3.1 개요

• 단순한 파일 저장소가 아니라 Key-Value DB처럼 동작한다.
  • 여기서 Key는 데이터의 해시값(SHA-1)이고, Value는 데이터 그 자체다.

3.2 Working Directory (작업 디렉터리)

• 상태:
  • Untracked (Git이 모르는 파일) 또는 Modified (수정된 파일).
• 특징:
  • 개발자가 코드를 작성하고 수정하는 실제 파일 시스템 공간이다.
  • 이곳의 변화는 아직 Git 버전에 기록되지 않은 상태다.
• 주요 명령어:
  • git status: 현재 작업 공간의 상태를 확인한다.

3.3 Staging Area (스테이징 영역 / Index)

• 상태:
  • Staged (커밋 대기 중).
• 특징:
  • .git/index 파일에 메타데이터로 존재한다.
  • 작업 디렉터리의 변경 사항 중 '버전으로 남길 것들만 골라내는' 필터 역할을 한다.
• 주요 명령어:
  • git add <파일>: Working Directory → Staging Area로 이동.

3.4 Local Repository (로컬 저장소)

• 상태:
  • Committed (버전 확정).
• 특징:
  • 내 컴퓨터의 .git 폴더 내부에 스냅샷이 영구 저장된 상태다.
  • 네트워크가 없어도 이력을 조회하거나 이전 버전으로 되돌릴 수 있다.
• HEAD 포인터:
  • 현재 내가 보고 있는 로컬 저장소의 버전을 가리킨다.
• 주요 명령어:
  • git commit: Staging Area → Local Repository로 저장.

3.5 Remote Repository (원격 저장소)

• 상태:
  • Pushed (서버 업로드 완료).
• 특징:
  • GitHub, GitLab 등 인터넷상의 서버에 위치한다.
  • 내 로컬 저장소의 거울(Mirror)과 같다.
  • 다른 개발자는 이 원격 저장소를 통해 나의 코드를 받아간다.
• 주요 명령어:
  • git push: Local Repository → Remote Repository로 업로드.
  • git fetch: Remote Repository → Local Repository (데이터만 가져옴, 병합 X).
  • git pull: Remote Repository → Working Directory (데이터 가져와서 병합까지 완료).

4. Git 파일 상태

4.1 대분류: 추적 여부

1. Untracked (추적되지 않음)
   • 파일을 새로 생성했지만, 아직 git add를 한 번도 하지 않은 상태다.
   • Git은 이 파일이 변경되든 삭제되든 전혀 신경 쓰지 않는다.
   • 보안상 중요한 파일(비밀번호 등)이나 빌드 부산물은 이 상태로 두거나 .gitignore에 등록해야 한다.
2. Tracked (추적됨)
   • 이미 스냅샷(커밋)에 포함되어 있거나, Staging Area에 있는 파일이다.
   • Git이 이 파일의 변경 사항을 계속 감시한다.

4.2 소분류: Tracked 파일의 3가지 상태

• Tracked 파일은 다음과 같이 세부 상태가 나뉜다.
• Unmodified (수정되지 않음 / Committed)
  • 마지막 커밋 이후 파일 내용이 전혀 변하지 않은 상태다.
  • git checkout을 막 했을 때의 초기 상태와 같다.
• Modified (수정됨)
  • 파일이 추적 중이지만, 내용이 수정되었고 아직 Staging Area에 올라가지 않은 상태다.
  • git add를 하지 않으면 커밋에 포함되지 않는다.
• Staged (커밋 예정)
  • 수정된 파일(Modified)을 곧 커밋하겠다고 표시(git add)한 상태다.
  • 이 상태의 파일들만 다음 git commit 시 스냅샷으로 저장된다.

5. GitHub 란?

5.1 정의

• 단순한 저장소를 넘어, 소스 코드 열람, 버그 추적, 코드 리뷰, 기능 배포 자동화 등 소프트웨어 개발 생명주기 전반을 지원하는 DevOps 플랫폼이다.

5.2 Pull Request (PR)

• Git 자체에는 merge 명령어만 있지, Pull Request라는 명령어는 없다.
  • PR은 GitHub가 만든 개념이다.
• 동작 원리
  • "내가 코드를 수정했으니(Push), 당신의 원본 저장소에 내 코드를 가져가 달라고(Pull) 요청(Request) 합니다."라는 뜻이다.
• 기술적 의의
  • 코드를 합치기 전에 코드 리뷰를 강제할 수 있는 시스템적 절차를 만들었다.
  • 이 과정에서 토론하고, 자동 테스트를 돌려 안정성을 검증한다.

5.3 오픈소스 생태계: Fork와 Star

• Fork (포크)
  • 다른 사람의 저장소를 내 계정으로 통째로 복제해 오는 기능이다.
  • 원작자에게 권한이 없어도 마음대로 코드를 뜯어고칠 수 있게 하여 오픈소스 기여의 장벽을 낮췄다.
• Star (스타)
  • SNS의 '좋아요'와 같다.
  • 개발자 사이에서 프로젝트의 인기와 신뢰도를 나타내는 척도로 사용된다.

5.4 GitHub Actions (CI/CD 자동화)

• 과거에는 Jenkins 같은 별도 서버가 필요했으나, GitHub는 저장소 내에서 바로 빌드, 테스트, 배포를 수행하는 가상 컴퓨터(Runner)를 제공한다.
  • 동작 방식:
    • 사용자가 .github/workflows 폴더에 YAML 파일을 넣으면, GitHub 서버가 특정 이벤트(Push, PR 등) 발생 시 자동으로 스크립트를 실행한다.