Git의 기본 개념을 이해했다면, 이제 실제로 Git을 어떻게 사용하는지 기본적인 명령어들을 익힐 차례입니다. 이 명령어들은 Git을 사용한 버전 관리의 가장 기초적이면서도 핵심적인 작업들을 수행하게 해줍니다.
Git 설치 및 초기 설정 (git config)
가장 먼저, 여러분의 컴퓨터에 Git을 설치해야 합니다. Git 공식 웹사이트에서 자신의 운영체제에 맞는 설치 파일을 다운로드하여 설치할 수 있습니다.
설치가 완료되었다면, Git을 사용하기 전에 최초 설정을 수행해야 합니다. 이 설정은 여러분이 커밋할 때마다 사용될 사용자 정보(이름과 이메일 주소)를 지정하는 과정입니다. 예를 들어, Git을 컴퓨터에 처음 설치했다면, 앞으로 이 컴퓨터에서 만드는 모든 Git 프로젝트의 커밋에 자신의 이름과 이메일이 정확히 기록되도록 사용자 정보를 설정해야 합니다. 이는 특히 팀 프로젝트에서 누가 어떤 변경사항을 만들었는지 명확히 하거나, 나중에 GitHub 같은 플랫폼에 코드를 푸시했을 때 기여자를 올바르게 식별하는 데 매우 중요합니다. 다음 명령어를 터미널이나 Git Bash와 같은 커맨드 라인 인터페이스에 입력하여 설정합니다
# 사용자 이름 설정
git config --global user.name "Hong Gildong"
# 사용자 이메일 설정
git config --global user.email "gildong.hong@example.com"이렇게 설정된 내용은 --list 옵션으로 확인할 수 있습니다.
# 설정된 내용 확인
git config --list--global 옵션은 해당 설정을 현재 컴퓨터의 모든 Git 저장소에 적용하겠다는 의미입니다. 특정 프로젝트에만 다른 이름이나 이메일을 사용하고 싶다면, 해당 프로젝트 디렉토리에서 --global 옵션을 빼고 명령어를 실행하면 됩니다.
새로운 저장소 만들기 (git init)
기존에 진행하던 프로젝트를 Git으로 관리하고 싶거나, 새로운 프로젝트를 Git으로 시작하고 싶을 때 git init 명령어를 사용합니다. 예를 들어, 개인적으로 만들고 있던 ‘my-recipe-app’이라는 프로젝트 폴더가 있는데, 이제부터 이 프로젝트의 변경 과정을 Git으로 체계적으로 관리하고 싶다면, ‘my-recipe-app’ 폴더 안에서 git init을 실행합니다. 또는, 새로운 웹사이트 개발 프로젝트를 시작하려고 ‘new-website’라는 빈 폴더를 만들고, 이 폴더를 Git 저장소로 만들어 처음부터 버전 관리를 시작하고 싶을 때도 이 명령어를 사용합니다.
# 'my-existing-project' 폴더로 이동했다고 가정
cd my-existing-project
# 현재 디렉토리를 Git 저장소로 초기화
git init새로운 프로젝트라면 먼저 디렉토리를 만들고 이동한 후 초기화합니다.
mkdir my-fresh-project
cd my-fresh-project
git init이 명령어를 실행하면 해당 디렉토리에 .git이라는 숨겨진 하위 디렉토리가 생성되며, 이 디렉토리 안에 저장소 관리에 필요한 모든 파일(메타데이터 및 객체 데이터베이스)이 들어갑니다. 이로써 해당 디렉토리는 Git 저장소로 변환됩니다.
기존 저장소 복제하기 (git clone)
이미 다른 곳(예: GitHub와 같은 원격 서버)에 존재하는 Git 저장소를 내 로컬 컴퓨터로 가져오고 싶을 때는 git clone 명령어를 사용합니다. 예를 들어, 팀원이 GitHub에 올려둔 ‘team-project’ 저장소의 코드를 내 컴퓨터로 가져와서 함께 개발에 참여하고 싶을 때, 해당 저장소의 URL을 사용하여 git clone을 실행합니다. 또한, 오픈 소스 라이브러리인 ‘awesome-library’의 코드를 분석하거나 직접 수정해보고 싶을 때도 GitHub에서 해당 라이브러리의 저장소 주소를 복사해 내 로컬 환경에 복제할 수 있습니다.
# GitHub에 있는 'some-organization'의 'example-repository' 저장소를 현재 디렉토리에 복제
git clone https://github.com/some-organization/example-repository.git
# 복제하면서 로컬에 생성될 디렉토리 이름을 'my-local-copy'로 지정
git clone https://github.com/some-organization/example-repository.git my-local-copy이 명령어는 원격 저장소의 전체 복사본을 지정된 로컬 디렉토리에 생성하며, 저장소의 모든 파일과 전체 커밋 히스토리를 다운로드합니다. 복제된 로컬 저장소는 자동으로 원본 원격 저장소(origin이라는 이름으로)와 연결되어 향후 변경 사항을 주고받을 수 있게 됩니다.
변경 사항 추적 및 스테이징 (git add)
프로젝트에서 파일을 수정하거나 새로운 파일을 추가한 후, 이러한 변경 사항을 Git 저장소에 기록(커밋)하기 위해서는 먼저 스테이징 영역(Staging Area) 에 해당 변경 사항을 추가해야 합니다. git add 명령어가 바로 이 역할을 합니다. 예를 들어, 오늘 ‘main.py’ 파일에 새로운 함수를 추가하고, ‘README.md’ 파일에 사용법 설명을 업데이트했다면, 이 두 파일의 변경사항을 다음 커밋에 포함시키기 위해 git add main.py README.md 와 같이 사용합니다. 여러 파일을 수정했지만 이번 커밋에는 오직 ‘user_auth.py’ 파일의 로그인 기능 개선사항만 반영하고 싶다면, git add user_auth.py를 사용하여 해당 파일만 선택적으로 스테이징할 수 있습니다.
# 'main.py' 파일의 변경사항만 스테이징
git add main.py
# 'styles/main.css' 파일의 변경사항을 스테이징
git add styles/main.css
# 'README.md' 파일과 'src/utils.js' 두 파일의 변경사항을 동시에 스테이징
git add README.md src/utils.js
# 현재 디렉토리 및 하위 디렉토리의 모든 변경 사항 (새 파일, 수정된 파일)을 스테이징 (주의해서 사용)
git add .git add . 명령어는 모든 변경사항을 한 번에 스테이징하여 편리하지만, 의도치 않은 파일까지 포함될 수 있으므로, 작업 후 git status 명령어로 어떤 파일들이 스테이징되는지 확인하는 습관을 들이는 것이 좋습니다. git add를 통해 스테이징 영역에 추가된 변경 사항만이 다음 커밋의 대상이 됩니다.
변경 사항 커밋하기 (git commit)
스테이징 영역에 준비된 변경 사항들을 로컬 저장소에 영구적으로 기록하는 명령어는 git commit 입니다. 커밋은 프로젝트의 의미 있는 변경 단위이며, 각 커밋에는 해당 변경 사항을 설명하는 커밋 메시지를 함께 기록해야 합니다. 예를 들어, user_auth.py 파일에 로그인 기능을 추가하고 git add user_auth.py로 스테이징했다면, 이제 이 변경사항을 “로그인 기능 추가”라는 명확한 메시지와 함께 저장소에 기록하기 위해 git commit -m "Add user login feature“를 사용합니다. 만약 여러 파일에 걸쳐 복잡한 버그를 수정했고, 각 파일의 변경 내용과 수정 이유를 자세히 설명하는 커밋 메시지를 남기고 싶다면, -m 옵션 없이 git commit을 실행하여 텍스트 편집기에서 여러 줄의 상세한 메시지를 작성할 수 있습니다.
# "-m" 옵션을 사용하여 한 줄 커밋 메시지와 함께 커밋
git commit -m "Implement user registration endpoint"
# "-m" 옵션 없이 실행하면 텍스트 편집기가 열려 더 자세한 메시지 작성 가능
git commit편집기에서 커밋 메시지를 작성할 때는 보통 첫 줄에 변경 요약(제목)을, 한 줄 비우고 그 아래에 상세 설명을 적는 것이 좋은 관례입니다.
커밋 메시지는 변경의 이유와 내용을 명확하게 작성하는 것이 매우 중요하며, 이는 나중에 변경 이력을 추적하거나 다른 협업자와 소통하는 데 큰 도움이 됩니다.
저장소 상태 확인 (git status)
작업 중인 Git 저장소의 현재 상태를 확인하는 데 가장 자주 사용되는 명령어 중 하나는 git status 입니다. 예를 들어, 코딩 작업을 한참 하다가 현재 어떤 파일들이 수정되었고, 어떤 파일들이 다음 커밋 대상(스테이징된 파일)인지, 혹시 Git이 아직 관리하지 않는 새로운 파일은 없는지 전체적으로 확인하고 싶을 때 git status를 사용합니다. 또한, 커밋을 하기 직전에 내가 의도한 파일들만 스테이징 영역에 올라가 있는지 최종적으로 점검하고 싶을 때도 git status를 통해 ‘Changes to be committed:’ 섹션을 주의 깊게 확인합니다.
git status이 명령어는 어떤 파일이 수정되었는지(modified), 어떤 파일이 스테이징 영역에 있는지(staged), 아직 Git이 추적하지 않는 파일(untracked files)은 무엇인지 등을 보여주어 현재 워킹 디렉토리와 스테이징 영역의 상태를 명확히 파악하고 다음 작업을 결정하는 데 도움을 줍니다.
커밋 이력 조회 (git log)
프로젝트의 커밋 이력을 시간 순서대로 (최신 커밋이 가장 위에) 보여주는 명령어는 git log 입니다. 이를 통해 각 커밋에 대한 정보, 즉 커밋 해시(고유 식별자), 작성자, 커밋 날짜, 그리고 커밋 메시지 등을 확인할 수 있습니다. 예를 들어, 프로젝트가 어떻게 변경되어 왔는지 전체적인 흐름을 파악하고 싶거나, 특정 기능이 언제 추가되었는지 과거 커밋 메시지를 찾아보고 싶을 때 git log를 사용합니다. 지난주에 특정 버그를 수정했던 커밋을 찾아야 하는데 정확한 날짜나 커밋 ID가 기억나지 않는다면, git log --grep="버그 수정 내용 키워드" 와 같이 메시지 내용을 검색하여 해당 커밋을 찾을 수도 있습니다. 동료가 작업한 최근 변경사항들을 확인하고 싶을 때는 git log --author="동료이름"을 사용할 수 있습니다.
# 기본적인 커밋 이력 조회 (가장 최근 커밋부터 순서대로)
git log
# 각 커밋을 한 줄로 간결하게 요약해서 보기
git log --oneline
# 최근 5개의 커밋만 보기
git log -5
# 특정 파일('server.js')의 변경 이력만 보기
git log server.js
# 특정 작성자("Gildong Hong")의 커밋만 보기
git log --author="Gildong Hong"
# 커밋 메시지에서 "Refactor"라는 단어를 포함하는 커밋만 검색
git log --grep="Refactor"
# 브랜치와 병합 이력을 그래프 형태로 함께 보기 (가독성 향상)
git log --graph --oneline --decorate --allgit log는 매우 다양한 옵션을 제공하므로, 필요에 따라 옵션을 조합하여 원하는 정보를 효과적으로 얻을 수 있습니다.
변경 내용 비교 (git diff)
파일의 변경된 내용을 구체적으로 확인하고 싶을 때 사용하는 명령어는 git diff 입니다. 이 명령어는 다양한 시점 간의 차이를 보여줄 수 있습니다. 예를 들어, 방금 ‘config.js’ 파일을 수정했는데, 스테이징하기 전에 정확히 어떤 부분을 변경했는지 마지막 커밋 상태와 비교해보고 싶을 때 git diff config.js를 사용합니다. 여러 파일을 스테이징(git add .)한 후 커밋하기 전에, 스테이징 영역에 있는 변경사항들이 내가 의도한 대로 정확히 반영되었는지 최종적으로 확인하고 싶다면 git diff --staged를 사용합니다.
# 워킹 디렉토리의 변경 사항 중 아직 스테이징되지 않은 모든 내용 확인 (최신 커밋과 비교)
git diff
# 특정 파일('index.html')의 워킹 디렉토리 변경 사항 확인
git diff index.html
# 스테이징 영역에 있는 변경 사항 중 아직 커밋되지 않은 모든 내용 확인 (최신 커밋과 비교)
git diff --staged
# 또는 git diff --cached (동일한 기능)
# 특정 파일('app.py')의 스테이징된 변경 사항 확인
git diff --staged app.py
# 현재 브랜치의 최신 커밋(HEAD)과 워킹 디렉토리의 모든 변경 사항 비교
git diff HEADgit diff를 통해 변경된 부분을 라인 단위로 정확히 파악하고 (+는 추가된 줄, -는 삭제된 줄), 커밋 전에 불필요한 변경이 포함되지 않았는지 등을 꼼꼼히 검토할 수 있습니다.
.gitignore 파일 설정
프로젝트 내에는 버전 관리할 필요가 없거나, 해서는 안 되는 파일들이 있을 수 있습니다. 예를 들어, Node.js 프로젝트에서 npm install을 실행하면 생기는 거대한 node_modules 디렉토리, 컴파일된 바이너리 파일, 민감한 정보가 담긴 credentials.ini 파일, 또는 개발 중 자동으로 생성되는 로그 파일(.log)이나 운영체제/IDE가 만드는 설정 파일(.DS_Store, .idea/) 등이 그러한 예입니다. 이러한 파일들을 Git이 의도적으로 무시하도록 설정하는 데 사용되는 것이 .gitignore 파일입니다.
.gitignore 파일은 일반 텍스트 파일이며, 저장소의 최상위 디렉토리에 위치시키는 것이 일반적입니다. 이 파일 안에 무시하고자 하는 파일이나 디렉토리의 패턴을 한 줄에 하나씩 나열하면 됩니다. 예를 들어, 모든 .log 확장자 파일을 무시하고 싶다면 *.log라고 적고, ‘build/’ 디렉토리 전체를 무시하고 싶다면 build/라고 적습니다.
.gitignore파일 예시
# 주석은 '#'으로 시작합니다.
# 모든 .log 확장자 파일 무시
*.log
npm-debug.log*
# 특정 이름의 디렉토리 전체 무시
temp/
node_modules/
vendor/
build/
dist/
# Python 관련 파일 및 디렉토리
*.pyc
__pycache__/
.env
venv/
env/
# IDE 및 OS 특정 파일
.idea/
.vscode/
*.DS_Store
Thumbs.db이렇게 .gitignore에 설정된 패턴에 해당하는 파일이나 디렉토리는 git status 등에서 ‘Untracked files’로 나타나지 않으며 (만약 이미 Git이 추적하고 있던 파일이라면 git rm --cached <file> 명령으로 추적을 중단해야 합니다), git add . 명령 시에도 자동으로 추가되지 않아 저장소를 깔끔하고 효율적으로 유지하는 데 큰 도움이 됩니다.
마무리
이러한 기본 명령어들과 그 사용 예시들을 통해 Git의 기본적인 작업 흐름을 이해하고 꾸준히 연습한다면, 프로젝트의 변경 사항을 효과적으로 관리하고 협업하는 데 큰 도움이 될 것입니다.