[GIT] Git 시작하기와 로컬 워크플로우 완벽 가이드

현대 소프트웨어 개발 환경에서 버전 관리 시스템(Version Control System, VCS)은 선택이 아닌 필수입니다. 수많은 개발자가 협업하고, 방대한 양의 코드가 매일 변경되는 상황에서 안정적으로 소스 코드를 관리하는 것은 프로젝트의 성공과 직결됩니다. 이 중에서도 Git은 전 세계적으로 가장 널리 사용되는 분산형 버전 관리 시스템입니다.

이 포스팅에서는 Git이 무엇인지 그 핵심 개념을 정확히 이해하고, 운영체제별 설치 방법과 초기 환경 설정까지 상세하게 살펴보겠습니다.

1. 버전 관리 시스템과 Git의 필요성

소프트웨어 프로젝트를 진행하다 보면 동일한 파일에 여러 번 수정을 가하게 됩니다. 단순히 파일명을 `project_v1`, `project_v2_final`, `project_v3_진짜최종` 등으로 변경하여 관리한다면, 나중에는 어떤 파일에 어떤 변경이 있었는지 추적하기가 매우 어려워집니다. 특히 여러 명의 개발자가 동시에 같은 파일을 수정한다면 충돌이 발생하고, 누군가의 작업 내용이 덮어쓰여 날아가는 치명적인 문제가 발생할 수 있습니다.

이러한 문제를 해결하기 위해 도입된 것이 버전 관리 시스템입니다. 특정 시점의 파일 상태를 기록(Commit)하여 언제든지 과거의 상태로 되돌아갈 수 있도록 지원하며, 누가 언제 어떤 코드를 추가하고 삭제했는지 명확한 이력을 제공합니다. Git은 리누스 토르발스(Linus Torvalds)가 리눅스 커널 개발을 위해 창시한 시스템으로, 기존의 중앙집중식 시스템(SVN 등)과 차별화되는 강력한 기능들을 제공합니다.

중앙집중식 vs 분산식 버전 관리

과거에 주로 사용되었던 중앙집중식 버전 관리 시스템은 단일 서버에 원본을 저장하고, 클라이언트는 필요한 파일만 받아와 작업하는 방식이었습니다. 서버에 장애가 발생하면 전체 개발팀의 작업이 마비되는 치명적인 단점이 있었습니다.

반면 Git은 분산 버전 관리 시스템(DVCS)입니다. 개발자는 원격 서버의 저장소 전체를 자신의 로컬 컴퓨터로 복제(Clone)합니다. 즉, 모든 개발자의 로컬 환경 자체가 백업 서버 역할을 수행합니다. 인터넷에 연결되지 않은 오프라인 상태에서도 히스토리 조회, 커밋, 브랜치 생성 등의 작업을 원활하게 진행할 수 있으며, 서버에 의존하지 않으므로 작업 속도 또한 압도적으로 빠릅니다.

Git의 데이터 저장 방식: 스냅샷(Snapshot)
Git은 파일의 변경점(Delta)만을 저장하는 다른 시스템들과 달리, 데이터를 미니 파일 시스템의 스냅샷 형태로 다룹니다. 파일을 커밋할 때마다 그 순간의 전체 파일 상태를 기록하며, 변경되지 않은 파일은 새로 저장하지 않고 이전 파일에 대한 링크만을 유지합니다. 이러한 방식은 버전 간 이동을 극도로 빠르게 만들어 줍니다.

2. 운영체제별 Git 설치 방법

Git을 사용하기 위해서는 로컬 컴퓨터에 Git을 설치해야 합니다. 운영체제(Windows, macOS, Linux)에 따라 설치 과정에 차이가 있습니다. 공식 웹사이트에서 제공하는 설치 프로그램을 사용하거나, 각 운영체제의 패키지 매니저를 활용할 수 있습니다.

Windows에서 Git 설치하기

Windows 환경에서는 주로 'Git for Windows' 패키지를 설치합니다. 이 패키지에는 Git 명령어 도구뿐만 아니라, 리눅스 스타일의 명령어(ls, grep 등)를 사용할 수 있게 해주는 Git Bash가 포함되어 있어 매우 유용합니다.

1. Git 공식 홈페이지(https://git-scm.com/download/win)에 접속합니다.
2. 자신의 시스템(32-bit 또는 64-bit)에 맞는 설치 파일을 다운로드합니다. 보통은 64-bit 버전을 선택합니다.
3. 다운로드한 `.exe` 파일을 실행합니다.
4. 설치 마법사의 지시에 따라 진행합니다. 여러 옵션이 나타나지만, 기본적으로 제공되는 권장 설정(기본 에디터: Vim, 기본 브랜치 이름: master 등)을 그대로 유지하며 'Next'를 눌러 설치를 완료해도 무방합니다.

설치가 완료되면 시작 메뉴에서 'Git Bash'를 검색하여 실행한 후, 다음 명령어를 입력하여 정상적으로 설치되었는지 버전을 확인합니다.

$ git --version
git version 2.41.0.windows.1

macOS에서 Git 설치하기

macOS는 터미널에서 Git 명령어를 처음 실행할 때 Apple에서 제공하는 'Command Line Tools' 설치 프롬프트가 나타나 쉽게 설치할 수 있습니다. 가장 권장되는 방식은 패키지 매니저인 Homebrew를 이용하는 것입니다.

# Homebrew가 설치되어 있다는 가정하에 아래 명령어를 터미널에 입력합니다.
$ brew install git

# 설치 후 버전 확인
$ git --version
git version 2.41.0

3. Git 초기 환경 설정 (Global Configuration)

Git을 설치한 직후에는 사용자의 정보를 설정해야 합니다. Git은 커밋을 생성할 때마다 해당 커밋을 작성한 사람의 이름과 이메일 주소를 기록합니다. 이 정보는 협업 시 코드의 작성자를 식별하는 중요한 단서가 되므로 반드시 초기에 설정해 두어야 합니다.

사용자 이름 및 이메일 등록

git config 명령어를 사용하여 설정을 진행합니다. `--global` 옵션을 추가하면 현재 컴퓨터의 모든 Git 저장소에 동일한 설정이 적용됩니다. 특정 프로젝트(저장소)에서만 다른 정보를 사용하고 싶다면, 해당 디렉토리로 이동한 후 `--global` 옵션을 제외하고 명령어를 실행하면 됩니다.

# 전역 사용자 이름 설정
$ git config --global user.name "Hong Gil Dong"

# 전역 사용자 이메일 설정 (GitHub 계정 이메일과 일치시키는 것을 권장)
$ git config --global user.email "hong@example.com"

설정 확인 및 기타 환경변수

위에서 설정한 정보가 올바르게 저장되었는지 확인하려면 --list 옵션을 사용합니다. 또한, 특정 항목만 지정하여 현재 설정된 값을 확인할 수도 있습니다.

# 전체 설정 내역 확인
$ git config --list
user.name=Hong Gil Dong
user.email=hong@example.com
core.repositoryformatversion=0
...

# 특정 설정 항목 확인
$ git config user.name
Hong Gil Dong

추가적으로, 텍스트 편집기나 운영체제 간의 줄바꿈(CRLF) 차이로 인해 발생할 수 있는 문제를 사전에 방지하기 위한 설정도 존재합니다. Windows의 경우 캐리지 리턴(CR)과 라인 피드(LF)를 모두 사용하는 반면, Unix 계열(macOS, Linux)은 LF만 사용합니다. 이 차이로 인해 불필요한 변경 내역이 발생하는 것을 막으려면 core.autocrlf 속성을 설정하는 것이 좋습니다.

# Windows 환경에서의 줄바꿈 자동 변환 설정
$ git config --global core.autocrlf true

# macOS, Linux 환경에서의 줄바꿈 자동 변환 설정
$ git config --global core.autocrlf input

1. Git의 세 가지 공간 (Three Trees)

Git 로컬 저장소는 크게 세 가지 가상 공간으로 나뉘어 관리됩니다. 파일이 현재 어느 공간에 위치해 있느냐에 따라 상태가 다르게 정의됩니다.

1. 워킹 디렉토리 (Working Directory): 우리가 실제로 코드를 작성하고 수정하는 작업 공간입니다. 폴더 내에 눈에 보이는 파일들이 바로 워킹 디렉토리에 속해 있습니다. 이 공간에서 파일이 수정되면 Git은 해당 파일을 Modified 상태로 인식합니다.
2. 스테이징 영역 (Staging Area / Index): 워킹 디렉토리에서 수정한 파일 중, 다음 버전에 포함시킬(커밋할) 파일들만 따로 모아두는 임시 준비 공간입니다. 마치 택배 상자에 물건을 담기 전에 모아두는 카트와 같습니다. 이 공간에 올라간 파일은 Staged 상태가 됩니다.
3. Git 디렉토리 (Repository): .git 폴더 안에 존재하는 실제 데이터베이스로, 프로젝트의 메타데이터와 파일들의 객체 데이터가 저장되는 곳입니다. 스테이징 영역에 있는 파일들을 영구적인 스냅샷으로 확정 지어 저장하면 비로소 새로운 버전(Commit)이 생성되며, 파일들은 Committed 상태로 변경됩니다.

왜 스테이징 영역이 필요할까?
만약 10개의 파일을 수정했는데, 5개는 UI 수정 관련이고 나머지 5개는 데이터베이스 관련 수정이라고 가정해 보겠습니다. 스테이징 영역이 없다면 10개의 변경 사항이 하나의 커밋에 섞이게 되어 나중에 코드를 리뷰하거나 되돌릴 때 매우 복잡해집니다. 스테이징 영역을 활용하면, 연관된 작업 단위로만 파일들을 선별하여 논리적인 커밋을 만들 수 있습니다.

2. 새 저장소 생성: git init

새로운 프로젝트 폴더를 만들고 이 폴더를 Git이 관리하도록 하려면 git init 명령어를 사용해야 합니다. 기존에 진행 중이던 프로젝트 디렉토리나 완전히 비어있는 새 디렉토리 모두에 적용할 수 있습니다.

# 프로젝트 폴더 생성 및 이동
$ mkdir my_project
$ cd my_project

# Git 저장소 초기화
$ git init
Initialized empty Git repository in /path/to/my_project/.git/

위 명령어를 실행하면 숨김 폴더인 .git 디렉토리가 생성됩니다. 이때부터 Git은 이 디렉토리 내부의 모든 파일 변경 사항을 감시(Track)할 준비를 마칩니다.

3. 상태 확인: git status

파일을 추가하거나 수정했을 때, 해당 파일들이 현재 어떤 상태에 있는지(수정만 되었는지, 스테이징 영역에 올라갔는지) 확인하려면 git status 명령어를 사용합니다. 이는 Git을 다룰 때 가장 빈번하게 사용하는 명령어 중 하나입니다.

# README.md 파일을 새로 생성합니다.
$ echo "My Awesome Project" > README.md

# 현재 상태 확인
$ git status
On branch master
No commits yet
Untracked files:
  (use "git add ..." to include in what will be committed)
        README.md

nothing added to commit but untracked files present (use "git add" to track)

새로 만든 README.md 파일이 Untracked files에 목록으로 나타납니다. 즉, 파일이 워킹 디렉토리에는 존재하지만 아직 Git이 추적 관리하지 않는다는 의미입니다.

4. 스테이징 영역으로 이동: git add

워킹 디렉토리에 있는 변경된 파일을 다음 커밋에 포함시키기 위해 스테이징 영역으로 넘기려면 git add 명령어를 사용합니다.

# 특정 파일만 스테이징 영역에 추가
$ git add README.md

# 다시 상태 확인
$ git status
On branch master
No commits yet
Changes to be committed:
  (use "git rm --cached ..." to unstage)
        new file:   README.md

이제 파일이 Changes to be committed 아래로 이동했습니다. 이는 정상적으로 스테이징 영역(Index)에 등록되었음을 뜻합니다. 프로젝트 내에서 변경된 모든 파일을 한 번에 추가하려면 git add . (현재 디렉토리 이하 모든 변경사항 추가) 명령어를 사용할 수 있습니다.

5. 버전 스냅샷 생성: git commit

스테이징 영역에 올려둔 파일들을 하나의 확정된 버전으로 저장소에 기록하는 과정이 바로 커밋(Commit)입니다. 커밋 시에는 반드시 어떤 변경 사항을 담고 있는지 설명하는 메시지를 함께 남겨야 합니다.

# 커밋 메시지와 함께 커밋 생성 (-m 옵션)
$ git commit -m "docs: 프로젝트 README 파일 추가"
[master (root-commit) a1b2c3d] docs: 프로젝트 README 파일 추가
 1 file changed, 1 insertion(+)
 create mode 100644 README.md

# 커밋 후 상태 확인
$ git status
On branch master
nothing to commit, working tree clean

성공적으로 커밋이 완료되면, 해시값(a1b2c3d)이 부여된 고유한 스냅샷이 Git 디렉토리에 영구적으로 보존됩니다. 마지막에 git status를 입력했을 때 나타나는 "nothing to commit, working tree clean" 문구는 워킹 디렉토리에 변경된 파일이 더 이상 남아있지 않음을 의미합니다.