개발자라면 필수로 알아야 할 버전 관리 시스템, Git!
Mac 터미널 환경에서 Git을 설치하고 초기 설정하는 방법부터, GitHub 연동을 통한 협업, 브랜치 전략, 충돌 해결까지 Git의 핵심 사용법을 완벽하게 마스터할 수 있도록 도와드리겠습니다.
TL;DR
Mac 터미널에 Git을 설치하고, 기본 명령어(init, add, commit)로 로컬 프로젝트를 관리합니다. GitHub와 연동하여 원격 저장소에 코드를 공유하고, 브랜치를 활용해 효율적으로 협업하며, .gitignore 설정과 충돌 해결로 깔끔하게 프로젝트를 유지하는 방법을 배웁니다.
배경: 버전 관리 시스템 Git의 중요성
개발 프로젝트는 시간이 지남에 따라 수많은 코드 변경이 발생합니다. 이런 변경 사항들을 체계적으로 관리하고, 여러 명이 함께 작업할 때 발생하는 혼란을 방지하기 위해 '버전 관리 시스템(Version Control System, VCS)'이 필수적입니다. Git은 현재 전 세계 개발자들이 가장 널리 사용하는 분산형 버전 관리 시스템으로, 다음과 같은 장점 덕분에 개발의 필수 도구로 자리 잡았습니다.
- 변경 이력 추적: 모든 코드 변경 사항을 기록하고 언제든 과거 시점으로 돌아갈 수 있습니다.
- 협업 용이: 여러 개발자가 동시에 같은 프로젝트를 작업해도 충돌을 최소화하고 효율적으로 병합할 수 있습니다.
- 안정성: 작업 중 문제가 발생해도 이전 버전으로 쉽게 복구할 수 있어 안정적인 개발 환경을 제공합니다.
- 분산형: 각 개발자가 독립적인 코드 저장소를 가질 수 있어, 중앙 서버에 문제가 생겨도 작업이 중단되지 않습니다.
사전 준비
이 가이드를 따라가기 전에 몇 가지 준비물이 필요합니다.
- Mac 운영체제: macOS가 설치된 컴퓨터.
- 터미널(Terminal) 접근: macOS에 내장된 터미널 앱 (Finder > 응용 프로그램 > 유틸리티 > 터미널).
- GitHub 계정: (선택 사항이지만 협업을 위해 강력히 권장) GitHub 웹사이트에서 무료로 생성할 수 있습니다.
Mac에 Git 설치 및 초기 설정
Git은 Mac에 기본적으로 설치되어 있는 경우가 많지만, 최신 버전으로 업데이트하거나 설치해야 할 수 있습니다. Homebrew를 이용하면 가장 쉽고 빠르게 설치할 수 있습니다.
1. Homebrew 설치 (설치되어 있지 않다면)
Homebrew는 Mac용 패키지 관리자로, 다양한 개발 도구를 쉽게 설치할 수 있게 해줍니다. 이미 설치되어 있다면 이 단계는 건너뛰세요.
/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"2. Git 설치
Homebrew를 통해 Git을 설치합니다.
bash brew install git3. Git 버전 확인
설치가 완료되면 Git 버전 정보를 확인하여 정상적으로 설치되었는지 확인합니다.
bash git --version
# 예시 출력: git version 2.37.14. Git 사용자 정보 설정
Git을 사용하기 전에 커밋(Commit)에 기록될 사용자 이름과 이메일 주소를 설정해야 합니다. 이 정보는 각 커밋에 포함되어 누가 변경했는지 식별하는 데 사용됩니다.
bash git config --global user.name "Your Name"
bash git config --global user.email "your_email@example.com"--global 옵션은 이 설정을 모든 Git 프로젝트에 적용하라는 의미입니다. 특정 프로젝트에만 다른 정보를 사용하고 싶다면 해당 프로젝트 디렉토리에서 --global 없이 설정할 수 있습니다.
기본 Git 명령어 (init, add, commit, status)
이제 Git이 설치되었으니, 프로젝트를 초기화하고 변경 사항을 기록하는 기본 명령어들을 살펴보겠습니다.
1. git init: Git 저장소 초기화
새로운 프로젝트 폴더를 Git 저장소로 만들 때 사용합니다. 이 명령어를 실행하면 .git이라는 숨김 폴더가 생성되어 Git 관련 모든 정보가 저장됩니다.
bash mkdir my-first-git-project
bash cd my-first-git-project
bash git init
# 예시 출력: Initialized empty Git repository in /Users/username/my-first-git-project/.git/2. git add: 변경 사항 스테이징
작업 디렉토리에서 수정한 파일들을 Git 저장소에 기록하기 전에, '스테이징 영역(Staging Area)'에 추가하는 명령어입니다. 스테이징 영역은 다음 커밋에 포함될 변경 사항들을 모아두는 곳입니다.
bash # 새 파일 생성 (예시)
bash echo "Hello, Git!" > hello.txt
bash # 모든 변경 사항을 스테이징 영역에 추가
bash git add .
bash # 특정 파일만 추가
bash git add hello.txt3. git commit: 스테이징된 변경 사항 저장
스테이징 영역에 있는 파일들의 변경 사항을 로컬 저장소에 영구적으로 기록하는 명령어입니다. 각 커밋은 프로젝트의 '스냅샷'으로, 고유한 ID(해시값)를 가집니다.
bash git commit -m "Initial commit: Add hello.txt"
# -m 옵션 뒤에 커밋 메시지를 간략하게 작성합니다.
# 예시 출력: [master (root-commit) 7a5b3c2] Initial commit: Add hello.txt
# 1 file changed, 1 insertion(+)
# create mode 100644 hello.txt4. git status: 저장소 상태 확인
현재 작업 디렉토리와 스테이징 영역, 그리고 마지막 커밋 사이의 상태를 보여주는 명령어입니다. 어떤 파일이 수정되었고, 스테이징되었는지 등을 알 수 있습니다.
bash git status
# 예시 출력 (모든 파일이 커밋된 상태):
# On branch master
# nothing to commit, working tree clean파일을 수정하고 git status를 다시 실행하면 Changes not staged for commit과 같이 변경 사항이 나타납니다.
원격 저장소 (GitHub) 연동 및 push/pull
로컬에서만 Git을 사용하는 것은 한계가 있습니다. GitHub와 같은 원격 저장소를 이용하면 코드를 백업하고, 다른 사람들과 공유하며 협업할 수 있습니다.
1. GitHub에 새 저장소 생성
GitHub 웹사이트에 로그인하여 'New repository'를 클릭하고, 저장소 이름 등을 설정하여 빈 저장소를 생성합니다. 이때 README.md나 .gitignore 파일은 추가하지 않고 'Public' 또는 'Private'을 선택하여 생성합니다.
2. 로컬 저장소와 원격 저장소 연결
GitHub 저장소를 생성하면 '…or push an existing repository from the command line' 섹션에 다음과 같은 명령어가 표시됩니다.
bash git remote add origin https://github.com/your-username/your-repository-name.git
# origin은 원격 저장소의 별칭이며, 일반적으로 사용되는 이름입니다.3. git push: 로컬 변경 사항 원격으로 전송
로컬 저장소의 커밋들을 원격 저장소로 업로드합니다.
bash git push -u origin master
# -u 옵션은 로컬 master 브랜치를 원격 origin의 master 브랜치에 연결합니다.
# 이후부터는 git push만으로도 작동합니다.4. git pull: 원격 저장소 변경 사항 로컬로 가져오기
원격 저장소에 있는 최신 변경 사항들을 로컬 저장소로 다운로드하여 업데이트합니다. 주로 협업 환경에서 다른 사람이 올린 코드를 가져올 때 사용합니다.
bash git pull origin master브랜치(Branch) 활용 및 병합(Merge) 전략
브랜치는 Git의 핵심 기능 중 하나로, 독립적인 작업 공간을 만들어 메인 코드베이스에 영향을 주지 않고 새로운 기능 개발이나 버그 수정을 할 수 있게 합니다.
1. git branch: 브랜치 목록 확인
현재 저장소에 존재하는 브랜치들을 확인하고, 현재 작업 중인 브랜치(*로 표시)를 알 수 있습니다.
bash git branch
# 예시 출력:
# * master2. git branch <new-branch-name>: 새 브랜치 생성
현재 브랜치를 기반으로 새로운 브랜치를 생성합니다.
bash git branch feature/add-login3. git checkout <branch-name>: 브랜치 전환
다른 브랜치로 작업 공간을 전환합니다.
bash git checkout feature/add-login
# 예시 출력: Switched to branch 'feature/add-login'새 브랜치를 생성함과 동시에 전환하려면 -b 옵션을 사용합니다.
bash git checkout -b feature/add-new-feature4. git merge <branch-to-merge>: 브랜치 병합
다른 브랜치의 변경 사항을 현재 브랜치로 가져와 합칩니다. 예를 들어, feature/add-login 브랜치에서 작업이 완료되면 master 브랜치로 돌아와 병합합니다.
bash git checkout master
bash git merge feature/add-login
# 예시 출력: Updating d8a7c6f..e9f0d1a
# Fast-forward
# new-file.txt | 1 +
# 1 file changed, 1 insertion(+)Gitignore 파일 관리 및 충돌 해결
1. .gitignore 파일 관리
모든 파일을 Git으로 관리할 필요는 없습니다. 빌드 파일, 로그 파일, 개인 설정 파일 등은 버전 관리에서 제외하는 것이 좋습니다. .gitignore 파일을 생성하여 Git이 무시할 파일이나 디렉토리를 지정할 수 있습니다.
프로젝트 루트 디렉토리에 .gitignore 파일을 생성하고 내용을 작성합니다.
bash # .gitignore 예시
# 운영체제 관련 파일
.DS_Store
# IDE 및 에디터 관련 파일
.idea/
.vscode/
# 빌드 아티팩트
/build/
/dist/
# Node.js 패키지 및 임시 파일
node_modules/
npm-debug.log
# 개인 설정 파일
*.envgit status 명령어로 확인하면 .gitignore에 등록된 파일들은 Untracked files 목록에 나타나지 않습니다.
2. 충돌 해결 (Merge Conflict)
두 개 이상의 브랜치에서 같은 파일의 같은 부분을 동시에 수정하고 병합하려 할 때 '병합 충돌(Merge Conflict)'이 발생합니다. Git은 자동으로 해결할 수 없는 부분을 표시해주며, 개발자가 수동으로 해결해야 합니다.
충돌이 발생하면 git status 명령어로 어떤 파일에서 충돌이 났는지 확인할 수 있습니다. 충돌 파일에는 다음과 같은 마커가 추가됩니다.
<<<<<<< HEAD
console.log("This is from the current branch (master).");
=======
console.log("This is from the feature branch.");
>>>>>>> feature/new-feature<<<<<<< HEAD: 현재 브랜치(여기서는master)의 내용=======: 두 브랜치 내용의 구분선>>>>>>> feature/new-feature: 병합하려는 브랜치의 내용
개발자는 이 마커들을 보고 원하는 내용으로 파일을 직접 수정한 후, 마커를 제거합니다. 수정이 완료되면 git add로 변경 사항을 스테이징하고 git commit으로 병합을 완료합니다.
bash # 충돌 해결 후 파일 수정
bash # ...
bash git add conflicted-file.js
bash git commit -m "Fix merge conflict in conflicted-file.js"검증
Git 작업이 잘 진행되었는지 확인하는 몇 가지 방법입니다.
git log: 커밋 이력을 확인하여 모든 변경 사항이 정확히 기록되었는지 확인합니다.bash git log- GitHub/원격 저장소 확인:
git push후에 GitHub 웹사이트에 접속하여 최신 코드가 반영되었는지 확인합니다. - 브랜치 확인:
git branch명령어로 현재 브랜치와 다른 브랜치들이 잘 관리되고 있는지 확인합니다.
흔히 발생하는 에러와 해결책
1. fatal: remote origin already exists.
원인: 이미 origin이라는 이름의 원격 저장소가 설정되어 있는 경우입니다.
해결:
- 기존
origin을 제거하고 다시 추가합니다.bash git remote remove origin bash git remote add origin - 다른 이름으로 원격 저장소를 추가합니다.
bash git remote add upstream
2. Authentication failed for 'https://github.com/...'
원인: GitHub 인증 정보(사용자 이름, 비밀번호 또는 Personal Access Token)가 올바르지 않거나 만료되었을 때 발생합니다.
해결:
- 최근 GitHub는 비밀번호 대신 Personal Access Token(PAT) 사용을 권장합니다. GitHub 설정에서 새로운 PAT를 생성하고, 이를 비밀번호 대신 사용합니다.
- macOS 키체인 접근을 확인하여 저장된 Git 자격 증명이 올바른지 확인합니다.
3. error: failed to push some refs to 'https://github.com/...' (non-fast-forward)
원인: 원격 저장소에 로컬 저장소보다 최신 변경 사항이 있는데, git pull 없이 git push를 시도할 때 발생합니다.
해결: git pull을 먼저 실행하여 원격 저장소의 변경 사항을 로컬로 가져온 후, 다시 git push를 시도합니다. 이 과정에서 병합 충돌이 발생할 수 있으니 해결해야 합니다.
bash git pull origin master
bash # (충돌 발생 시 해결)
bash git push origin master4. fatal: not a git repository (or any of the parent directories): .git
원인: 현재 디렉토리가 Git 저장소가 아니거나, 상위 디렉토리에도 .git 폴더가 없을 때 발생합니다.
해결: Git 명령어를 실행하려는 디렉토리에서 git init 명령어로 새 Git 저장소를 초기화하거나, 이미 Git 저장소인 프로젝트의 루트 디렉토리로 이동하여 명령어를 실행합니다.
응용
1. Git GUI 도구 활용
터미널 명령어가 익숙하지 않거나 시각적인 관리를 선호한다면, Sourcetree, GitKraken, VS Code의 Git 통합 기능과 같은 GUI(Graphic User Interface) 도구를 활용할 수 있습니다. 이 도구들은 Git 명령어의 복잡성을 줄여주고, 커밋 이력, 브랜치 구조, 충돌 해결 등을 시각적으로 보여주어 편리합니다.
2. Git Flow 또는 GitHub Flow 도입
팀 프로젝트에서는 일관된 브랜치 관리 전략이 중요합니다. Git Flow는 복잡한 기능 개발과 릴리즈 관리에 적합하며, GitHub Flow는 지속적인 배포(Continuous Deployment)에 유리한 간단한 워크플로우를 제공합니다. 프로젝트의 규모와 팀의 특성에 맞춰 적절한 워크플로우를 도입하면 더욱 효율적인 협업이 가능합니다.
FAQ
Q1: Git과 GitHub의 차이는 무엇인가요?
A1: Git은 분산형 버전 관리 시스템 자체이며, 코드 변경 이력을 추적하고 관리하는 '도구'입니다. 반면 GitHub는 Git 저장소를 호스팅하고 공유할 수 있는 '플랫폼'입니다. GitHub는 Git 저장소 위에 협업, 코드 리뷰, 이슈 트래킹 등의 기능을 제공하여 팀 프로젝트를 쉽게 관리할 수 있도록 돕습니다. 마치 MS Word(Git)와 Google Drive(GitHub)의 관계와 비슷합니다.
Q2: 다른 운영체제(Windows, Linux)에서도 Git 사용법이 동일한가요?
A2: 네, Git의 핵심 명령어와 개념은 운영체제에 관계없이 동일합니다. 설치 방법은 운영체제마다 약간의 차이가 있지만(예: Windows에서는 Git Bash 설치), 터미널/명령 프롬프트에서 사용하는 명령어들은 거의 동일합니다. 따라서 이 가이드에서 배운 내용들은 다른 OS에서도 유용하게 활용할 수 있습니다.
Q3: Git GUI 도구를 사용하는 것이 더 좋은가요, 아니면 터미널 명령어를 쓰는 것이 더 좋은가요?
A3: 둘 다 장단점이 있습니다. GUI 도구는 시각적으로 Git 흐름을 파악하고 간단한 작업을 처리하는 데 매우 편리합니다. 하지만 터미널 명령어를 익히는 것은 Git의 내부 동작 원리를 이해하고, 복잡하거나 특수한 상황에 대응하는 데 필수적입니다. 숙련된 개발자들은 보통 두 가지를 상황에 맞춰 병행하여 사용합니다. 처음에는 터미널로 기본을 다지고, 이후 필요에 따라 GUI 도구를 활용하는 것을 추천합니다.