Git — 개념, 작동 원리 및 명령어

Git이란?

Git은 파일의 변경 사항을 추적하고 여러 개발자가 동시에 동일한 프로젝트에서 작업할 수 있게 하는 분산 버전 관리 시스템(VCS)입니다. 중앙 집중식 시스템과 달리 Git에서는 각 개발자가 변경 기록 전체를 포함한 리포지토리의 완전한 복사본을 가지므로 시스템이 데이터 손실에 강하고 중앙 서버에 지속적으로 연결할 필요가 없습니다.

Git의 역사는 2005년 BitKeeper가 Linux 커널 개발자를 위한 무료 라이선스를 철회한 후 리누스 토르발스가 새로운 VCS를 만들면서 시작되었습니다. 목표는 속도, 아키텍처의 단순성, 브랜치를 통한 비선형 개발 지원, 완전한 분산이었습니다. 3개월 만에 토르발스는 Git의 코어를 작성했고, 1년 안에 프로젝트는 하마노 준의 지도 아래 자체 관리되게 되었습니다.

Stack Overflow 설문조사(2024)에 따르면 Git은 전문 개발자의 93.9%가 사용하여 업계에서 지배적인 버전 관리 시스템이 되었습니다. 가장 가까운 경쟁자인 Subversion(SVN)은 중앙 집중식 프로세스를 가진 대기업 환경에서 주로 5.2%의 프로젝트에서만 사용됩니다.

Git 작동 방식: 리포지토리 및 커밋

Git 리포지토리는 Git이 모든 파일의 변경 사항을 추적하는 디렉토리입니다. 디렉토리 안에는 모든 시스템 객체(커밋, 트리, 블롭, 참조)를 저장하는 숨겨진 폴더 .git이 있습니다. 개발자가 커밋을 생성할 때 Git은 파일을 완전히 복사하지 않고 스냅샷을 만들어 그 참조를 저장합니다.

각 커밋에는 고유한 SHA-1 해시(40자), 이전 커밋에 대한 참조(parent), 작성자, 날짜, 커밋 메시지, 커밋 시점의 파일 상태를 설명하는 트리에 대한 참조가 포함됩니다. 커밋의 체인은 각 커밋이 하나 이상의 부모를 가리키는 방향성 비순환 그래프를 형성합니다.

# 리포지토리 초기화
git init my-project
cd my-project

# 커밋 생성
echo "안녕하세요, Git" > README.md
git add README.md
git commit -m "Initial commit"

# 기록 보기
git log --oneline --graph --all

Git은 세 가지 주요 영역을 사용합니다: working directory(디스크의 파일), staging area(준비된 파일이 가는 인덱스), repository(커밋 기록). git add 명령어는 작업 디렉토리에서 스테이징으로 변경 사항을 이동하고, git commit은 스테이징의 내용을 리포지토리에 기록합니다. 이 분리를 통해 개발자는 각 편집을 개별적으로 커밋하지 않고 변경 사항 집합에서 의미 있는 커밋을 구성할 수 있습니다.

Git 기본 명령어

Git 기본 명령어는 개발자의 일상 작업의 90%를覆盖합니다. git clone 명령어는 원격 리포지토리의 로컬 복사본을 만들고, git pull은 서버에서 변경 사항을 가져와 현재 브랜치에 병합하며, git push는 로컬 커밋을 서버로 보냅니다. 이 세 명령어는 Git 작업의 주요 사이클을 형성합니다.

상태를 보려면 git status를 사용합니다. 수정된 파일, 스테이징에 추가된 파일, 추적되지 않는 파일을 보여줍니다. git diff는 스테이징에 추가하기 전 파일의 구체적인 변경 사항을 표시합니다. 아래는 가장 자주 사용되는 명령어 표입니다:

변경 사항을 취소하기 위해 Git은 여러 옵션을 제공합니다. git reset은 브랜치 포인터를 지정된 커밋으로 이동하고 스테이징 또는 작업 디렉토리를 재설정할 수 있습니다. git revert는 지정된 커밋의 변경 사항을 되돌리는 새 커밋을 만듭니다. 기록이 다시 쓰이지 않으므로 공유 브랜치에 안전한 취소 방법입니다.

Git 브랜치: main, feature, release

Git의 브랜치는 특정 커밋을 가리키는 가벼운 이동 가능 포인터입니다. 새 브랜치를 만들어도 파일이 복사되지 않고 새 포인터만 생성되므로 브랜치 생성이 거의 즉시 이루어집니다. main 브랜치(이전에는 master)는 안정적인 릴리스 가능 코드를 포함하는 프로젝트의 메인 브랜치입니다.

표준 관행은 Git Flow 또는 GitHub Flow를 사용하는 것입니다. Git Flow는 main(릴리스 코드), develop(통합 브랜치), feature/*(새 기능), release/*(릴리스 준비), hotfix/*(긴급 수정) 브랜치를 사용합니다. GitHub Flow는 더 간단합니다: main과 기능 브랜치만 있으며, 모든 변경 사항은 Pull Request를 통해 전달됩니다.

# 브랜치 생성 및 전환
git branch feature-auth
git checkout feature-auth
# 또는 하나의 명령어로:
git checkout -b feature-auth

# 브랜치 목록
git branch --list
git branch -a  # 모든 브랜치 (원격 포함)

# 브랜치 삭제
git branch -d feature-auth

Git 브랜치의 중요한 기능은 cherry-pick입니다. git cherry-pick <hash> 명령어를 사용하여 개별 커밋을 한 브랜치에서 다른 브랜치로 이동할 수 있습니다. 전체 브랜치를 병합하지 않고 기능 브랜치에서 릴리스로 버그 수정을 전송해야 할 때 유용합니다. Git은 또한 커밋을 스쿼시, 재정렬 및 편집하기 위한 리베이스 및 대화형 리베이스(git rebase -i)를 지원합니다.

Merge와 Rebase

Merge(병합)는 두 개의 부모가 있는 특별한 병합 커밋을 만듭니다. 이 커밋은 두 브랜치의 통합 사실을 기록하고 전체 기록을 보존하므로 병합이 언제 어디서 발생했는지 확인할 수 있습니다. Merge는 기록을 생성된 그대로 보존하여 감사를 단순화하지만 커밋 그래프를 더 복잡하게 만듭니다.

Rebase(리베이스)는 병합 커밋을 만드는 대신 현재 브랜치의 커밋을 대상 브랜치의 끝으로 이동합니다. 기록이 선형이 되어 개발이 순차적으로 진행된 것처럼 보이게 합니다. 그러나 리베이스는 기록을 다시 쓰고 커밋의 SHA-1 해시를 변경하므로 다른 개발자가 접근할 수 있는 공유 브랜치에서 위험합니다.

권장 사항: 기록이 다른 개발자에게 보이는 공개 브랜치(feature → develop)에서는 merge를 사용하고, Pull Request를 만들기 전에 main의 최신 변경 사항을 기능 브랜치에 적용해야 하는 로컬 작업에서는 rebase를 사용하세요. 규칙은 간단합니다: 커밋이 이미 서버에 푸시되었다면 리베이스하지 마세요.

충돌 해결

병합 충돌은 Git이 단일 파일의 변경 사항을 자동으로 병합할 수 없을 때 발생합니다. Git은 파일의 충돌 부분을 특수 마커로 표시합니다: <<<<<<<(우리의 변경), =======(구분선), >>>>>>>(상대방의 변경). 개발자는 파일을 수동으로 편집하여 원하는 옵션을 선택하거나 둘을 결합한 후 커밋으로 병합을 완료합니다.

원격 리포지토리 작업

원격 리포지토리(remote)는 서버에 있는 Git 리포지토리의 복사본입니다. GitHub, GitLab, Bitbucket은 원격 리포지토리 호스팅을 위한 가장 인기 있는 플랫폼입니다. 코드 보기, 액세스 관리, 코드 리뷰 및 CI/CD 시스템 통합을 위한 웹 인터페이스를 제공합니다.

Git에서는 하나의 프로젝트에 여러 원격 리포지토리를 구성할 수 있습니다. 기본적으로 주요 원격은 origin이라고 합니다. git remote add 명령어는 새 원격을 추가하고, git fetch는 병합 없이 변경 사항을 가져오며, git pull은 git fetch + git merge의 줄임말입니다. Pull Request를 통해 코드 작업을 하기 위해 개발자는 리포지토리의 포크를 만들고, 클론한 후 기능 브랜치에서 작업하고, 원본 리포지토리에 병합 요청을 보냅니다.

# 원격 리포지토리 추가
git remote add origin https://github.com/user/repo.git

# 원격 리포지토리 보기
git remote -v

# 서버에 브랜치 푸시
git push -u origin feature-auth

# 원격 브랜치에서 변경 사항 가져오기
git pull origin main

원격 리포지토리는 릴리스 버전 표시를 위한 태깅을 지원합니다. 태그는 가벼운(커밋에 대한 단순 포인터) 또는 주석이 달린(메타데이터: 작성자, 날짜, 메시지 포함) 것일 수 있습니다. 주석이 달린 태그는 전체 버전 정보를 전달하고 저작자 확인을 위해 GPG 키로 서명할 수 있으므로 릴리스 버전에 권장됩니다.

병렬 작업을 위한 Git Worktree

Git Worktree를 사용하면 디렉토리 간에 전환하지 않고 여러 브랜치로 동시에 작업할 수 있습니다. git worktree add ../feature-auth feature-auth 명령어는 새 작업 디렉토리 feature-auth를 만들어 메인 디렉토리에서 브랜치를 전환하지 않고 코드를 작성할 수 있게 합니다. Worktree는 메인 디렉토리가 장기 개발로 사용 중일 때 릴리스 브랜치에서 빠른 수정을 하는 데 유용합니다.

의존성을 위한 Git Submodules

Git Submodules은 하나의 Git 리포지토리를 다른 리포지토리 안에 포함시키는 메커니즘입니다. 서브모듈은 외부 리포지토리의 고정 커밋에 대한 참조를 저장하여 빌드 재현성을 보장합니다. git submodule add https://github.com/example/lib.git 명령어는 외부 라이브러리를 서브모듈로 추가합니다. 서브모듈이 있는 프로젝트를 클론할 때는 모든 의존성을 다운로드하기 위해 git submodule update --init --recursive를 실행해야 합니다.