Git을 활용한 코드 버전 관리 완벽 가이드

개발자라면 반드시 알아야 할 Git의 핵심 개념과 실무 활용법을 다룹니다. 초급 개발자도 쉽게 이해할 수 있도록 스토리텔링 방식으로 Git의 기초부터 협업 전략까지 설명합니다.

---

목차

1. Git_초기화와_기본_개념
2. 브랜치_전략과_활용
3. 머지와_충돌_해결
4. 원격_저장소와_협업
5. 커밋_되돌리기와_이력_관리
6. 스태시로_임시_저장하기
7. 풀_리퀘스트와_코드_리뷰
8. Git_로그와_이력_탐색

---

1. Git 초기화와 기본 개념

신입 개발자 김개발 씨의 첫 출근 날입니다. 컴퓨터를 세팅하던 중 선배가 다가와 말합니다.

"먼저 Git부터 설치하세요. 우리 회사에서는 모든 코드를 Git으로 관리하거든요." Git이라는 단어를 들어본 적은 있지만, 정확히 무엇인지 몰랐던 김개발 씨는 고개를 갸웃거립니다.

Git은 코드의 변경 이력을 추적하고 관리하는 버전 관리 시스템입니다. 마치 문서 작업을 할 때 "최종본", "진짜최종", "진짜진짜최종" 파일을 만들어 본 경험이 있다면, Git은 이 문제를 깔끔하게 해결해줍니다.

하나의 파일에서 모든 변경 이력을 추적할 수 있기 때문입니다.

다음 코드를 살펴봅시다.

# Git 저장소 초기화
git init

# 현재 상태 확인
git status

# 파일을 스테이징 영역에 추가
git add index.js

# 변경사항 커밋 (저장)
git commit -m "첫 번째 커밋: 프로젝트 초기 설정"

# 커밋 이력 확인
git log --oneline

김개발 씨는 입사 첫날부터 Git이라는 단어를 수없이 들었습니다. 회의에서도, 코드 리뷰에서도, 심지어 점심시간 대화에서도 Git은 빠지지 않았습니다.

대체 Git이 무엇이길래 모든 개발자가 당연하게 사용하는 걸까요? 선배 개발자 박시니어 씨가 친절하게 설명해줍니다.

"Git을 이해하려면 먼저 버전 관리가 왜 필요한지 알아야 해요." 학창 시절 과제를 떠올려 봅시다. 보고서를 작성하면서 "보고서_최종.docx", "보고서_진짜최종.docx", "보고서_이게진짜최종.docx" 같은 파일을 만들어 본 적이 있을 겁니다.

수정할 때마다 새 파일을 만들었고, 나중에는 어떤 게 진짜 최종본인지 헷갈렸던 경험이 있을 것입니다. Git은 바로 이 문제를 해결합니다.

마치 타임머신처럼 파일의 모든 변경 이력을 기록해두고, 원할 때 언제든 과거 시점으로 돌아갈 수 있게 해줍니다. 파일을 여러 개 만들 필요 없이, 하나의 파일에서 모든 역사를 관리할 수 있는 것입니다.

Git을 사용하려면 먼저 **저장소(Repository)**를 만들어야 합니다. 저장소란 Git이 변경 이력을 저장하는 특별한 폴더라고 생각하면 됩니다.

git init 명령어를 실행하면 현재 폴더가 Git 저장소로 변환됩니다. 저장소를 만들었다면 이제 파일의 변경사항을 저장할 차례입니다.

Git에서는 이를 **커밋(Commit)**이라고 부릅니다. 커밋은 마치 게임의 세이브 포인트와 같습니다.

특정 시점의 상태를 저장해두면, 나중에 문제가 생겼을 때 그 시점으로 돌아갈 수 있습니다. 하지만 커밋하기 전에 한 단계가 더 있습니다.

바로 **스테이징(Staging)**입니다. 스테이징은 커밋할 파일을 미리 선택하는 과정입니다.

마치 이사할 때 박스에 물건을 담는 것처럼, 이번 커밋에 포함할 파일들을 먼저 담아두는 것입니다. git add 명령어로 파일을 스테이징하고, git commit 명령어로 실제 저장합니다.

커밋할 때는 반드시 메시지를 함께 작성해야 합니다. 이 메시지는 나중에 "이 시점에서 무엇을 했는지" 기억할 수 있게 해주는 메모와 같습니다.

git status는 현재 상태를 보여주는 명령어입니다. 어떤 파일이 수정되었는지, 어떤 파일이 스테이징되었는지 한눈에 확인할 수 있습니다.

초보자에게 가장 유용한 명령어 중 하나입니다. 김개발 씨가 박시니어 씨의 설명을 듣고 직접 실습해봅니다.

git init을 실행하니 ".git"이라는 숨김 폴더가 생겼습니다. 이 폴더 안에 모든 변경 이력이 저장됩니다.

첫 번째 커밋을 성공적으로 마친 김개발 씨의 얼굴에 미소가 번집니다.

실전 팁

💡 - 커밋 메시지는 "무엇을 왜 변경했는지" 명확하게 작성하세요

• git status를 자주 사용하여 현재 상태를 파악하는 습관을 들이세요

---

2. 브랜치 전략과 활용

김개발 씨가 새로운 기능을 개발하라는 지시를 받았습니다. 열심히 코드를 작성하던 중, 갑자기 긴급 버그 수정 요청이 들어왔습니다.

새 기능 개발을 잠시 멈추고 버그를 수정해야 하는데, 지금까지 작성한 코드는 어떻게 해야 할까요? 바로 이럴 때 브랜치가 빛을 발합니다.

**브랜치(Branch)**는 독립적인 작업 공간을 만드는 Git의 핵심 기능입니다. 마치 평행 우주처럼, 원본 코드에 영향을 주지 않으면서 새로운 시도를 할 수 있습니다.

기능 개발, 버그 수정, 실험적 작업을 각각 분리하여 안전하게 진행할 수 있습니다.

다음 코드를 살펴봅시다.

# 현재 브랜치 목록 확인
git branch

# 새로운 브랜치 생성
git branch feature/login

# 브랜치 이동
git checkout feature/login

# 브랜치 생성과 이동을 한 번에
git checkout -b feature/signup

# 브랜치에서 작업 후 커밋
git add .
git commit -m "로그인 기능 구현"

# 메인 브랜치로 돌아가기
git checkout main

어느 날 김개발 씨에게 긴급 상황이 발생했습니다. 로그인 기능을 열심히 개발하던 중, 운영 서버에서 심각한 버그가 발견된 것입니다.

당장 버그를 수정해야 하는데, 아직 완성되지 않은 로그인 코드가 문제였습니다. 박시니어 씨가 다가와 말합니다.

"걱정 마세요. 브랜치를 사용하면 됩니다." 브랜치를 이해하려면 나무를 떠올려 보세요.

나무의 줄기에서 여러 가지가 뻗어 나가듯이, Git에서도 메인 코드에서 여러 갈래의 작업 공간을 만들 수 있습니다. 각 가지는 서로 독립적이어서, 한쪽에서 무슨 일이 일어나도 다른 쪽에는 영향을 주지 않습니다.

Git 저장소를 처음 만들면 main(또는 master) 브랜치가 기본으로 생성됩니다. 이 브랜치는 보통 실제 서비스에 배포되는 안정적인 코드를 담고 있습니다.

따라서 main 브랜치에서 직접 작업하는 것은 위험할 수 있습니다. 새로운 기능을 개발할 때는 feature 브랜치를 만듭니다.

예를 들어 로그인 기능을 개발한다면 "feature/login"이라는 브랜치를 생성합니다. 이 브랜치에서 아무리 실험적인 코드를 작성해도, main 브랜치의 코드는 안전하게 보호됩니다.

git branch 명령어로 새 브랜치를 만들고, git checkout으로 그 브랜치로 이동합니다. 요즘은 git checkout -b를 사용하여 생성과 이동을 한 번에 처리하는 것이 일반적입니다.

김개발 씨의 상황으로 돌아가 봅시다. 로그인 기능 개발 중이었으니, 현재 feature/login 브랜치에 있을 것입니다.

긴급 버그를 수정하려면 먼저 main 브랜치로 돌아가서, 새로운 버그 수정용 브랜치(예: hotfix/urgent-bug)를 만들면 됩니다. 버그를 수정한 후에는 다시 feature/login 브랜치로 돌아와 로그인 기능 개발을 이어갈 수 있습니다.

마치 시간을 멈춰두고 다른 일을 처리한 것처럼, 각 작업이 서로 방해받지 않습니다. 실무에서 브랜치 이름은 보통 규칙을 따릅니다.

새 기능은 "feature/기능명", 버그 수정은 "bugfix/버그명" 또는 "hotfix/버그명", 릴리스 준비는 "release/버전" 형식을 많이 사용합니다. 팀마다 규칙이 다를 수 있으니, 입사하면 팀의 브랜치 네이밍 컨벤션을 먼저 확인하세요.

브랜치를 사용하면 여러 명이 동시에 다른 기능을 개발할 수 있습니다. A 개발자는 결제 기능을, B 개발자는 검색 기능을 각자의 브랜치에서 개발합니다.

서로의 작업에 영향을 주지 않으면서도, 나중에 하나로 합칠 수 있습니다.

실전 팁

💡 - 브랜치 이름은 작업 내용을 명확히 나타내도록 작성하세요

• 하나의 브랜치에서는 하나의 작업만 진행하는 것이 좋습니다

---

3. 머지와 충돌 해결

김개발 씨가 드디어 로그인 기능 개발을 완료했습니다. 이제 이 코드를 main 브랜치에 합쳐야 합니다.

그런데 합치려고 하니 빨간 글씨로 "CONFLICT"라는 무시무시한 단어가 나타났습니다. 충돌이 발생한 것입니다.

김개발 씨의 손에 땀이 나기 시작합니다.

**머지(Merge)**는 서로 다른 브랜치의 변경사항을 하나로 합치는 과정입니다. 대부분의 경우 Git이 자동으로 처리하지만, 같은 부분을 다르게 수정한 경우 **충돌(Conflict)**이 발생합니다.

충돌은 무섭지 않습니다. 개발자가 직접 어떤 코드를 선택할지 결정하면 됩니다.

다음 코드를 살펴봅시다.

# main 브랜치로 이동
git checkout main

# feature 브랜치를 main에 머지
git merge feature/login

# 충돌 발생 시 파일 확인
git status

# 충돌 파일 내용 (수동으로 해결 필요)
<<<<<<< HEAD
console.log("main 브랜치의 코드");
=======
console.log("feature 브랜치의 코드");
>>>>>>> feature/login

# 충돌 해결 후 커밋
git add .
git commit -m "Merge feature/login: 로그인 기능 통합"

김개발 씨가 feature/login 브랜치에서 열심히 일하는 동안, 다른 팀원들도 각자의 브랜치에서 작업을 하고 있었습니다. 이제 모든 작업을 main 브랜치에 합쳐야 할 시간입니다.

**머지(Merge)**는 두 브랜치의 변경사항을 하나로 합치는 작업입니다. 마치 두 개의 강이 만나 하나의 큰 강이 되는 것처럼, 서로 다른 곳에서 진행된 작업이 하나로 합쳐집니다.

대부분의 경우 Git은 머지를 자동으로 처리합니다. 예를 들어 A 파일은 김개발 씨가, B 파일은 박시니어 씨가 수정했다면, Git은 두 변경사항을 자연스럽게 합칩니다.

문제는 두 사람이 같은 파일의 같은 부분을 수정했을 때 발생합니다. **충돌(Conflict)**은 Git이 자동으로 판단할 수 없는 상황입니다.

"김개발 씨는 이렇게 바꿨고, 박시니어 씨는 저렇게 바꿨는데, 어떤 게 맞아요?"라고 Git이 묻는 것입니다. 이때는 개발자가 직접 결정해야 합니다.

충돌이 발생하면 Git은 파일에 특별한 표시를 남깁니다. <<<<<<< HEAD와 ======= 사이에는 현재 브랜치(main)의 코드가, **=======**와 >>>>>>> feature/login 사이에는 머지하려는 브랜치의 코드가 표시됩니다.

충돌을 해결하려면 이 표시들을 지우고, 최종적으로 남길 코드만 남기면 됩니다. 때로는 한쪽 코드만 선택하고, 때로는 양쪽을 조합한 새로운 코드를 작성하기도 합니다.

처음 충돌을 마주하면 당황스럽지만, 사실 충돌은 팀 협업에서 자연스러운 현상입니다. 여러 사람이 동시에 작업하다 보면 같은 부분을 건드릴 수밖에 없기 때문입니다.

중요한 것은 침착하게 양쪽 코드를 비교하고, 올바른 결정을 내리는 것입니다. 충돌 해결 후에는 git add로 해결된 파일을 스테이징하고, git commit으로 머지를 완료합니다.

커밋 메시지에는 어떤 브랜치를 머지했는지, 어떤 충돌을 어떻게 해결했는지 기록해두면 나중에 도움이 됩니다. 충돌을 최소화하려면 자주 머지하는 것이 좋습니다.

오랫동안 따로 작업하다가 한 번에 합치면 충돌이 많아질 수 있습니다. 작은 단위로 자주 합치면 충돌도 적고, 해결하기도 쉽습니다.

박시니어 씨가 조언합니다. "충돌이 무서워서 머지를 미루면 안 돼요.

작게 자주 머지하는 게 훨씬 안전합니다."

실전 팁

💡 - 충돌 해결 전에 양쪽 코드를 모두 이해하고 결정하세요

• 복잡한 충돌은 해당 코드를 작성한 팀원과 함께 해결하세요

---

4. 원격 저장소와 협업

김개발 씨가 집에서도 작업을 하고 싶어졌습니다. 회사 컴퓨터에 있는 코드를 어떻게 집으로 가져올 수 있을까요?

USB에 담아갈 수도 있겠지만, 매번 그러기엔 너무 번거롭습니다. 이때 필요한 것이 바로 원격 저장소입니다.

**원격 저장소(Remote Repository)**는 인터넷에 있는 Git 저장소입니다. GitHub, GitLab, Bitbucket 같은 서비스가 대표적입니다.

원격 저장소를 사용하면 어디서든 코드에 접근할 수 있고, 팀원들과 코드를 공유할 수 있습니다.

다음 코드를 살펴봅시다.

# 원격 저장소 연결
git remote add origin https://github.com/username/project.git

# 원격 저장소 확인
git remote -v

# 로컬 변경사항을 원격에 업로드
git push -u origin main

# 원격 저장소의 변경사항 가져오기
git pull origin main

# 원격 저장소 복제하기
git clone https://github.com/username/project.git

# 원격 브랜치 목록 확인
git branch -r

지금까지 김개발 씨는 자신의 컴퓨터에서만 Git을 사용했습니다. 이것을 로컬 저장소라고 합니다.

하지만 혼자만 가지고 있으면 다른 사람과 협업하기 어렵고, 컴퓨터가 고장나면 모든 것을 잃을 수 있습니다. 원격 저장소는 이 문제를 해결합니다.

마치 구글 드라이브에 파일을 저장하면 어디서든 접근할 수 있는 것처럼, 원격 저장소에 코드를 저장하면 어느 컴퓨터에서든 접근할 수 있습니다. 가장 유명한 원격 저장소 서비스는 GitHub입니다.

전 세계 개발자들이 GitHub를 통해 코드를 공유하고 협업합니다. 유명한 오픈소스 프로젝트 대부분이 GitHub에 있으니, 개발자라면 반드시 익혀야 할 서비스입니다.

원격 저장소를 사용하려면 먼저 로컬 저장소와 연결해야 합니다. git remote add 명령어로 원격 저장소의 주소를 등록합니다.

관례적으로 첫 번째 원격 저장소는 origin이라는 이름을 붙입니다. 로컬에서 작업한 내용을 원격에 올릴 때는 git push를 사용합니다.

"밀어 올린다"는 의미입니다. 반대로 원격의 변경사항을 로컬로 가져올 때는 git pull을 사용합니다.

"당겨온다"는 의미입니다. 처음 프로젝트에 참여할 때는 git clone을 사용합니다.

원격 저장소의 전체 내용을 복제해오는 것입니다. 클론하면 저장소의 모든 파일과 히스토리가 로컬에 복사됩니다.

실무에서의 일반적인 흐름을 살펴봅시다. 아침에 출근하면 git pull로 팀원들이 작업한 내용을 받아옵니다.

하루 종일 작업한 후에는 git push로 자신의 작업을 원격에 올립니다. 다른 팀원들도 같은 과정을 반복하며 코드를 공유합니다.

주의할 점이 있습니다. push하기 전에는 반드시 pull을 먼저 해야 합니다.

다른 사람이 먼저 push한 내용이 있다면, 그것을 먼저 받아와야 합니다. 그렇지 않으면 Git이 push를 거부합니다.

김개발 씨가 이제 집에서도 작업할 수 있게 되었습니다. 회사에서 push하고, 집에서 pull하면 됩니다.

마치 클라우드에 파일을 저장하는 것처럼 자연스럽게 작업을 이어갈 수 있습니다.

실전 팁

💡 - push 전에 항상 pull을 먼저 실행하는 습관을 들이세요

• .gitignore 파일을 사용하여 민감한 정보(비밀번호, API 키 등)는 원격에 올리지 마세요

---

5. 커밋 되돌리기와 이력 관리

김개발 씨가 실수로 잘못된 코드를 커밋해버렸습니다. 더 심각한 건, 이미 원격 저장소에 push까지 해버린 상황입니다.

식은땀이 흐릅니다. "어떡하지?

시간을 되돌릴 수 있다면..." 다행히 Git에는 시간을 되돌리는 기능이 있습니다.

Git은 다양한 방법으로 과거 상태로 되돌릴 수 있습니다. git reset은 커밋을 취소하고, git revert는 변경사항을 되돌리는 새 커밋을 만듭니다.

상황에 따라 적절한 방법을 선택해야 합니다.

다음 코드를 살펴봅시다.

# 최근 커밋 취소 (변경사항은 유지)
git reset --soft HEAD~1

# 최근 커밋 취소 (변경사항도 스테이징에서 제거)
git reset --mixed HEAD~1

# 최근 커밋 취소 (변경사항 완전 삭제 - 주의!)
git reset --hard HEAD~1

# 특정 커밋의 변경사항을 되돌리는 새 커밋 생성
git revert abc123

# 스테이징 취소 (add 취소)
git reset HEAD filename.js

# 파일의 변경사항 되돌리기
git checkout -- filename.js

개발을 하다 보면 실수는 피할 수 없습니다. 잘못된 코드를 커밋하거나, 불필요한 파일을 추가하거나, 심지어 비밀번호가 담긴 파일을 실수로 올리기도 합니다.

중요한 건 이런 실수를 어떻게 복구하느냐입니다. Git에서 과거로 되돌아가는 방법은 크게 두 가지가 있습니다.

reset과 revert입니다. 비슷해 보이지만 완전히 다른 방식으로 동작합니다.

git reset은 커밋을 완전히 취소합니다. 마치 그 커밋이 처음부터 없었던 것처럼 이력에서 제거됩니다.

세 가지 옵션이 있는데, --soft는 커밋만 취소하고 변경사항은 스테이징 영역에 남깁니다. --mixed는 스테이징도 취소하지만 파일 변경은 유지합니다.

--hard는 모든 것을 취소합니다. 주의할 점은 --hard 옵션입니다.

이것을 사용하면 변경사항이 완전히 사라집니다. 복구할 방법이 거의 없으니 신중하게 사용해야 합니다.

박시니어 씨도 "hard reset은 정말 필요할 때만 쓰세요"라고 강조합니다. git revert는 다른 방식으로 접근합니다.

특정 커밋의 변경사항을 되돌리는 새로운 커밋을 만듭니다. 원래 커밋은 이력에 그대로 남아있고, "이 커밋을 되돌렸다"는 새 커밋이 추가됩니다.

이미 원격 저장소에 push한 경우에는 revert를 사용해야 합니다. reset으로 이력을 바꾸면 다른 팀원들과 이력이 꼬일 수 있기 때문입니다.

revert는 이력을 추가하는 것이므로 안전합니다. 커밋 전에 실수를 발견했다면 더 간단합니다.

git reset HEAD 파일명으로 스테이징을 취소할 수 있고, git checkout -- 파일명으로 파일의 변경사항 자체를 되돌릴 수 있습니다. 실무에서는 이런 상황이 자주 발생합니다.

기능 개발 중에 방향이 바뀌어서 처음부터 다시 해야 하는 경우, 테스트 코드를 실수로 커밋한 경우 등 다양합니다. 당황하지 말고 상황에 맞는 명령어를 선택하면 됩니다.

김개발 씨도 처음에는 revert와 reset의 차이가 헷갈렸습니다. 하지만 한 가지만 기억하면 됩니다.

"push 했으면 revert, 안 했으면 reset." 이 규칙을 따르면 대부분의 상황을 안전하게 처리할 수 있습니다.

실전 팁

💡 - push 전에는 reset, push 후에는 revert를 사용하세요

• hard reset 전에는 현재 상태를 별도로 백업해두는 것이 안전합니다

---

6. 스태시로 임시 저장하기

김개발 씨가 열심히 기능을 개발하던 중, 팀장님이 급하게 다른 브랜치의 코드를 확인해달라고 요청했습니다. 브랜치를 바꾸려 하니 Git이 경고를 보냅니다.

현재 작업 중인 변경사항이 있어서 브랜치를 바꿀 수 없다는 것입니다. 아직 커밋하기엔 작업이 완료되지 않았는데, 어떻게 해야 할까요?

git stash는 현재 작업 중인 변경사항을 임시로 저장해두는 기능입니다. 마치 책상 위의 서류를 서랍에 잠시 넣어두는 것처럼, 작업 내용을 안전하게 보관했다가 나중에 다시 꺼낼 수 있습니다.

커밋하기 애매한 중간 상태의 작업을 처리할 때 유용합니다.

다음 코드를 살펴봅시다.

# 현재 변경사항 임시 저장
git stash

# 메시지와 함께 저장
git stash save "로그인 기능 개발 중"

# 저장된 stash 목록 확인
git stash list

# 가장 최근 stash 복원
git stash pop

# 특정 stash 복원 (삭제하지 않음)
git stash apply stash@{0}

# stash 삭제
git stash drop stash@{0}

# 모든 stash 삭제
git stash clear

개발하다 보면 갑자기 다른 일을 처리해야 하는 경우가 많습니다. 긴급 버그 수정, 코드 리뷰, 다른 브랜치 확인 등 예상치 못한 요청이 수시로 들어옵니다.

이때 현재 작업을 어떻게 처리할지가 문제입니다. 커밋을 하자니 아직 작업이 완료되지 않았습니다.

"작업중..." 같은 커밋을 남기는 건 이력을 지저분하게 만듭니다. 그렇다고 변경사항을 버리자니 다시 작업해야 합니다.

바로 이런 상황에서 stash가 빛을 발합니다. git stash는 현재 작업 중인 모든 변경사항을 임시 저장소에 보관합니다.

마치 메모장에 적어둔 내용을 책상 서랍에 넣어두는 것과 같습니다. 서랍에 넣어두면 책상은 깨끗해지고, 필요할 때 다시 꺼내면 됩니다.

stash를 실행하면 작업 디렉토리가 깨끗해집니다. 마지막 커밋 상태로 돌아가는 것입니다.

이제 마음 놓고 브랜치를 바꾸거나 다른 작업을 할 수 있습니다. 급한 일을 처리한 후에는 git stash pop으로 저장해둔 변경사항을 복원합니다.

pop과 apply의 차이를 알아둘 필요가 있습니다. pop은 복원하면서 stash에서 삭제합니다.

apply는 복원하지만 stash에는 그대로 남겨둡니다. 여러 브랜치에 같은 변경사항을 적용해야 할 때 apply가 유용합니다.

stash는 여러 개를 저장할 수 있습니다. git stash list로 저장된 목록을 확인할 수 있습니다.

각 stash는 stash@{0}, stash@{1} 같은 형식으로 번호가 붙습니다. 숫자가 작을수록 최근에 저장한 것입니다.

저장할 때 메시지를 함께 남기면 나중에 어떤 작업이었는지 구분하기 쉽습니다. git stash save "메시지" 형식으로 사용합니다.

여러 개의 stash가 쌓이면 메시지 없이는 구분하기 어렵습니다. 김개발 씨가 이제 당황하지 않습니다.

팀장님의 갑작스러운 요청에도 git stash로 현재 작업을 저장하고, 다른 브랜치를 확인한 후, 다시 돌아와서 git stash pop으로 작업을 이어갑니다. 마치 게임에서 세이브하고 다른 퀘스트를 하다가 돌아오는 것과 같습니다.

주의할 점은 stash를 너무 많이 쌓아두지 않는 것입니다. 시간이 지나면 어떤 작업이었는지 기억하기 어렵습니다.

가능하면 빨리 복원해서 정리하거나, 정말 필요 없는 것은 삭제하는 것이 좋습니다.

실전 팁

💡 - stash에 메시지를 함께 저장하면 나중에 구분하기 쉽습니다

• stash를 너무 많이 쌓아두지 말고 빨리 정리하세요

---

7. 풀 리퀘스트와 코드 리뷰

김개발 씨가 로그인 기능 개발을 완료하고 push했습니다. 이제 main 브랜치에 합쳐야 하는데, 박시니어 씨가 말합니다.

"바로 머지하지 말고, 풀 리퀘스트를 열어주세요. 코드 리뷰를 받아야 합니다." 풀 리퀘스트란 무엇이고, 왜 코드 리뷰가 필요한 걸까요?

**풀 리퀘스트(Pull Request, PR)**는 코드 변경사항을 리뷰받고 머지를 요청하는 과정입니다. GitHub, GitLab 같은 플랫폼에서 제공하는 기능으로, 팀원들이 코드를 검토하고 의견을 나눌 수 있습니다.

코드 품질을 높이고 버그를 사전에 잡는 중요한 협업 프로세스입니다.

다음 코드를 살펴봅시다.

# 기능 브랜치에서 작업 완료 후 push
git push origin feature/login

# GitHub에서 Pull Request 생성
# 1. GitHub 저장소 페이지 방문
# 2. "Compare & pull request" 버튼 클릭
# 3. 제목과 설명 작성
# 4. 리뷰어 지정
# 5. "Create pull request" 클릭

# 리뷰 피드백 반영 후 추가 커밋
git add .
git commit -m "리뷰 피드백 반영: 에러 처리 추가"
git push origin feature/login

# PR이 승인되면 GitHub에서 Merge 버튼 클릭

혼자 개발할 때는 코드를 작성하고 바로 main 브랜치에 머지하면 됩니다. 하지만 팀으로 일할 때는 다릅니다.

여러 사람이 같은 코드베이스에서 작업하므로, 한 사람의 실수가 전체 프로젝트에 영향을 줄 수 있습니다. 풀 리퀘스트는 이런 문제를 방지하기 위한 과정입니다.

"내가 이런 변경을 했는데, 검토하고 합쳐도 될지 확인해주세요"라고 요청하는 것입니다. 다른 팀원들이 코드를 검토하고, 문제가 없다고 판단되면 머지를 승인합니다.

코드 리뷰는 단순히 버그를 찾는 것만이 아닙니다. 더 좋은 코드를 작성하는 방법을 배우는 기회이기도 합니다.

선배 개발자가 "이 부분은 이렇게 하면 더 효율적이에요"라고 알려주면, 그것이 곧 성장의 밑거름이 됩니다. 풀 리퀘스트를 생성할 때는 제목과 설명을 명확하게 작성해야 합니다.

어떤 기능을 구현했는지, 왜 이렇게 구현했는지, 테스트는 어떻게 했는지 등을 설명합니다. 리뷰어가 코드를 이해하기 쉬워지고, 리뷰 시간도 단축됩니다.

리뷰어가 피드백을 남기면, 그에 맞게 코드를 수정합니다. 수정한 내용을 커밋하고 push하면 풀 리퀘스트에 자동으로 반영됩니다.

이 과정을 여러 번 반복할 수도 있습니다. 모든 리뷰어가 승인하면 드디어 머지할 수 있습니다.

보통 GitHub 페이지에서 "Merge" 버튼을 클릭하면 됩니다. 머지 후에는 기능 브랜치를 삭제하는 것이 일반적입니다.

실무에서는 풀 리퀘스트 없이 main 브랜치에 직접 push하는 것을 막아두는 경우가 많습니다. 이를 브랜치 보호 규칙이라고 합니다.

반드시 리뷰를 거쳐야만 머지할 수 있도록 강제하는 것입니다. 김개발 씨도 처음에는 코드 리뷰가 부담스러웠습니다.

자신의 코드가 평가받는 느낌이었기 때문입니다. 하지만 시간이 지나면서 리뷰가 자신을 성장시키는 최고의 방법이라는 것을 깨달았습니다.

이제는 리뷰를 받는 것도, 하는 것도 익숙해졌습니다.

실전 팁

💡 - PR 설명에 스크린샷이나 테스트 결과를 첨부하면 리뷰가 수월해집니다

• 작은 단위로 자주 PR을 보내는 것이 리뷰하기 쉽습니다

---

8. Git 로그와 이력 탐색

서비스에 버그가 발생했습니다. 며칠 전까지는 정상이었는데, 최근에 뭔가 바뀌면서 문제가 생긴 것 같습니다.

언제, 누가, 어떤 코드를 변경했는지 알 수 있다면 버그의 원인을 빠르게 찾을 수 있을 것입니다. Git의 로그(Log) 기능이 바로 이런 상황에서 도움이 됩니다.

git log는 커밋 이력을 보여주는 명령어입니다. 누가, 언제, 어떤 변경을 했는지 전체 히스토리를 확인할 수 있습니다.

다양한 옵션을 활용하면 원하는 정보만 필터링해서 볼 수 있습니다.

다음 코드를 살펴봅시다.

# 전체 커밋 이력 확인
git log

# 한 줄로 간결하게 보기
git log --oneline

# 최근 5개 커밋만 보기
git log -5

# 그래프로 브랜치 이력 보기
git log --oneline --graph --all

# 특정 파일의 변경 이력
git log -- src/login.js

# 특정 기간의 커밋만 보기
git log --since="2024-01-01" --until="2024-01-31"

# 특정 작성자의 커밋만 보기
git log --author="김개발"

# 변경 내용까지 함께 보기
git log -p

버그가 발생하면 가장 먼저 해야 할 일은 "언제부터 이 버그가 있었는가"를 파악하는 것입니다. 그 시점의 커밋을 찾으면 어떤 변경이 버그를 유발했는지 알 수 있습니다.

이것이 바로 git log가 필요한 이유입니다. git log를 그냥 실행하면 모든 커밋 이력이 시간 역순으로 표시됩니다.

각 커밋의 해시값, 작성자, 날짜, 메시지를 볼 수 있습니다. 하지만 프로젝트가 오래되면 커밋이 수천 개가 넘기 때문에, 이렇게 보면 필요한 정보를 찾기 어렵습니다.

--oneline 옵션을 사용하면 각 커밋을 한 줄로 압축해서 보여줍니다. 해시값의 앞 7자리와 커밋 메시지만 표시되어 훨씬 깔끔합니다.

빠르게 이력을 훑어볼 때 유용합니다. -n 옵션으로 개수를 제한할 수 있습니다.

git log -5라고 하면 최근 5개의 커밋만 보여줍니다. 방금 무슨 작업을 했는지 확인할 때 자주 사용합니다.

브랜치가 여러 개일 때는 --graph 옵션이 유용합니다. 브랜치가 어디서 갈라지고 어디서 합쳐졌는지를 시각적으로 보여줍니다.

--all 옵션을 함께 쓰면 모든 브랜치의 이력을 볼 수 있습니다. 특정 파일의 변경 이력만 보고 싶다면 파일 경로를 지정합니다.

git log -- 파일경로 형식입니다. 버그가 특정 파일과 관련된 것 같을 때, 그 파일의 변경 이력만 집중적으로 살펴볼 수 있습니다.

--since와 --until 옵션으로 기간을 지정할 수 있습니다. "지난주에 뭔가 바뀐 것 같은데"라는 막연한 기억이 있다면, 해당 기간의 커밋만 필터링해서 볼 수 있습니다.

--author 옵션은 특정 사람의 커밋만 보여줍니다. 내가 작업한 내용을 정리할 때나, 특정 팀원이 수정한 부분을 확인할 때 유용합니다.

-p 옵션은 각 커밋에서 실제로 어떤 코드가 변경되었는지까지 보여줍니다. 변경된 줄이 빨간색(삭제)과 녹색(추가)으로 표시됩니다.

코드 레벨에서 변화를 추적할 때 사용합니다. 김개발 씨가 이 옵션들을 조합해서 버그의 원인을 찾아냈습니다.

지난 화요일에 로그인 관련 파일이 수정되었고, 그 커밋에서 조건문이 잘못 변경된 것이 원인이었습니다. 문제가 되는 커밋을 찾으면 해결은 어렵지 않습니다.

실전 팁

💡 - git log --oneline --graph를 별칭(alias)으로 등록해두면 편리합니다

• 커밋 메시지를 잘 작성해두면 로그에서 원하는 커밋을 찾기 쉽습니다

---

이상으로 학습을 마칩니다. 위 내용을 직접 코드로 작성해보면서 익혀보세요!