Git과 협업: 초보자 가이드 (실제 비유 포함)
출처: Dev.to
🌐 이 글을 Bahasa Indonesia 로 읽으려면 여기를 클릭하세요.
📝 이 글에 대한 참고 사항
이 포스트는 버전 관리와 Git 협업에 대한 개인 학습 노트를 기반으로 작성되었습니다. 노트를 더 읽기 쉽고 유용하게 만들기 위해 AI와 함께 내용을 확장하고 블로그 형식으로 정리했습니다. 아이디어와 학습 여정, 이해는 전부 저의 것이며, AI는 글쓰기와 프레젠테이션을 도와주었습니다.
Git을 배우는 것이 두려울 필요는 없습니다. 이 글에서는 버전 관리와 협업의 핵심 개념을 누구나 이해할 수 있는 간단한 비유와 함께 풀어보겠습니다.
Git이란?
Git은 버전 관리 시스템입니다. 코드를 위한 저장 시스템이라고 생각하면 됩니다—비디오 게임의 저장 지점과 비슷하죠. 저장(커밋)할 때마다 Git은 그 순간 프로젝트의 상태를 기억합니다. 문제가 생기면 언제든지 되돌릴 수 있습니다.
Repository: 프로젝트의 창고
레포지토리(또는 “repo)는 Git이 감시하는 폴더입니다. 종류는 두 가지:
- 로컬 레포지토리: 내 컴퓨터에 존재합니다. 개인 작업 공간.
- 원격 레포지토리: 서버에 존재합니다(GitHub, GitLab, Bitbucket 등). 팀이 공유하는 “공식” 복사본.
두 레포는 원격 URL을 통해 연결되며, 로컬 변경 사항을 푸시하고 다른 사람의 변경 사항을 풀 할 수 있습니다.
git init # 폴더 추적 시작
git remote add origin <url> # 원격 레포와 연결
git push origin main # 커밋을 원격에 전송
git pull origin main # 원격 최신 내용 받아오기Commit: 프로젝트의 저장 지점
커밋은 특정 시점의 프로젝트 스냅샷입니다. 각 커밋은 다음을 포함합니다.
- 어떤 내용이 바뀌었는지 설명하는 메시지
- 고유 ID(해시)
- 타임스탬프
git add . # 모든 변경 사항 스테이징
git commit -m "Add homepage layout" # 스냅샷 저장
git log --oneline # 커밋 히스토리 보기의미 있는 커밋 메시지를 작성하세요. 미래의 당신이 현재의 당신에게 감사할 겁니다.
Checkout, Reset, Revert: 시간 여행
세 명령은 모두 커밋 히스토리와 상호작용하지만, 작동 방식이 크게 다릅니다.
git checkout — 과거를 잠시 방문
시간 여행자가 방문 허가증을 가진 것과 같습니다. 과거 커밋을 살펴볼 수 있지만, 영구적인 변화를 주지는 않습니다.
git checkout <commit> # 과거 커밋 방문
git checkout main # 현재(main)로 복귀
git checkout -b new-branch # 과거 커밋에서 새 브랜치 시작git reset — 히스토리 지우기
과거 커밋으로 돌아가 그 이후의 모든 것을 제거합니다. 특히 이미 푸시한 경우 조심해서 사용하세요.
git reset --soft HEAD~1 # 마지막 커밋 되돌리되, 변경 내용은 스테이징 유지
git reset --hard HEAD~1 # 마지막 커밋 되돌리고, 변경 내용도 삭제git revert — 안전한 되돌리기
이전 커밋을 취소하는 새로운 커밋을 만듭니다. 히스토리는 그대로 유지되므로, 공유 레포에서 가장 안전한 옵션입니다.
git revert <commit> # 커밋을 안전하게 되돌리기규칙: 이미 푸시한 경우 revert를 사용하고, 아직 푸시하지 않았다면 reset을 사용해도 괜찮습니다.
Branches: 코드의 평행 우주
브랜치는 독립적인 개발 라인입니다. main 같은 안정된 브랜치를 건드리지 않고도 기능이나 버그 수정을 진행할 수 있습니다.
git switch -c feature/dark-mode # 새 브랜치 생성 및 전환
git switch main # main 브랜치로 전환
git branch -d feature/dark-mode # 병합된 브랜치 삭제
git push origin feature/dark-mode # 브랜치를 원격에 푸시흔히 쓰이는 브랜치 명명 규칙
| 종류 | 접두사 | 예시 |
|---|---|---|
| 새 기능 | feature/ | feature/dark-mode |
| 버그 수정 | fix/ | fix/login-redirect |
| 긴급 수정 | hotfix/ | hotfix/payment-crash |
Stash: 미완성 작업을 위한 일시 정지 버튼
기능을 절반만 구현했는데 코드가 엉망이고 아직 커밋할 준비가 안 됐다고 가정해봅시다. 팀 리더가 “메인에서 급히 이 버그 좀 고쳐줄래?” 라고 요청한다면?
커밋되지 않은 상태에서는 브랜치를 바꿀 수 없습니다. 하지만 아직 커밋하고 싶지도 않은 상황이죠. 해결책은 stash입니다.
비유: 그림을 그리고 있는데 테이블을 다른 용도로 써야 할 때, 그림을 서랍에 넣어두고 나중에 꺼내서 이어 그리는 것과 같습니다.
git stash # 작업을 임시 저장
git switch fix/some-bug # 자유롭게 브랜치 전환
# ... 버그 고치고 커밋 후 다시 돌아오기 ...
git switch feature/dark-mode
git stash pop # 작업 복원여러 개의 stash 관리하기
git stash push -m "WIP: dark mode palette" # 이름 붙인 stash
git stash list # 모든 stash 확인
git stash pop # 가장 최근 stash 복원
git stash apply stash@{1} # 특정 stash 복원(목록에 남김)
git stash drop stash@{1} # 특정 stash 삭제
git stash -u # 추적되지 않은 파일도 포함Merge & Pull Requests: 전체 흐름 연결하기
기능 구현이 끝났다면 merge를 통해 main에 합칩니다.
git switch main
git merge feature/dark-modeGitHub/GitLab에서는 보통 Pull Request(PR) 형태로 진행합니다.
- 브랜치를 푸시하고 PR을 엽니다.
- 팀원이 코드를 리뷰하고 피드백을 남깁니다.
- 승인되면 PR이 머지됩니다.
Merge 옵션
| 방법 | 결과 |
|---|---|
| Merge commit | 모든 커밋을 보존하고 머지 커밋을 추가 |
| Squash and merge | 모든 커밋을 하나로 압축 |
| Rebase and merge | 커밋을 main 위에 재배치, 머지 커밋 없음 |
충돌 해결
두 브랜치가 같은 라인을 수정하면 Git이 자동으로 머지하지 못합니다. 다음과 같은 표시가 나타납니다.
>>>>>>> feature/dark-mode
// 충돌 난 코드
=======수동으로 충돌을 해결한 뒤:
git add <파일>
git commitCode Reviews: 품질 게이트
PR이 머지되기 전에 누군가가 리뷰합니다. 좋은 리뷰어는 다음을 체크합니다.
- 논리적 정확성
- 가독성 및 네이밍
- 테스트 커버리지
- 복잡도 (필요 이상으로 복잡하지 않은가?)
- 스타일 가이드 준수
코드 리뷰는 단순히 실수를 잡는 것이 아니라, 팀 내 지식 전파의 중요한 수단이기도 합니다.
Fork & Clone: 접근 권한 없이 기여하기
- Fork: 다른 사람의 레포를 자신의 GitHub 계정으로 복사합니다.
- Clone: 레포를 로컬 머신에 복사합니다.
일반적인 오픈소스 기여 흐름:
# 1. GitHub에서 Fork