Git
"Git - the stupid content tracker"
— 리누스 토발즈가 Git 최초 릴리스 당시 매뉴얼 문서 헤더에 직접 적어둔 자조적이고 유구한 슬로건.
버전 관리라는 신세계를 열어주어, 현대 모든 개발 환경에서 '코드_최종_진짜최종_최종의최종.zip'을 역사적 유물로 만들어버린 구세주. 하지만 머지 컨플릭트(Merge Conflict)가 터지는 순간 동료와의 우정도 함께 공중분해시키는 우정 파괴자
1. 개요
Git은 2005년 리눅스 커널의 창시자인 리누스 토발즈(Linus Torvalds)가 개발한 분산 버전 관리 시스템(VCS)이다. 이전의 SVN이나 CVS 같은 중앙집중식 시스템의 느린 속도와 네트워크 의존성을 비웃듯, 모든 개발자가 프로젝트의 전체 히스토리를 로컬에 복사해 두고 독립적으로 작업할 수 있는 혁명적인 속도와 유연성을 선사했다.
현대 소프트웨어 개발 업계에서는 워드프로세서의 저장 버튼만큼이나 숨 쉬듯 쓰이는 표준 도구이다. 비개발자 직군에서 파일 이름 뒤에 '최종', '진짜최종', '진짜진짜최종'을 붙여가며 괴로워할 때, 개발자들은 멋들어지게 git commit과 git checkout을 때리며 과거의 시점으로 타임머신을 타는 쾌감을 누린다.(...)
2. 핵심 개념 및 주요 명령어
2.1. 로컬 저장소 삼형제: Working Directory, Staging Area, Repository
자바나 파이썬 코드를 짤 때 Git은 단순히 파일을 저장하는 것이 아니라 세 단계를 거쳐 관리한다.
- Working Directory (작업 디렉토리): 내가 현재 실제로 코드를 수정하고 있는 생생한 코딩 현장.
- Staging Area (준비 영역): 저장(커밋)을 하기 전에 올릴 파일들만 골라 담는 쇼핑 카트.
git add명령어로 카트에 물건을 담는다. - Repository (저장소): 카트에 담긴 최종 상태를 영구적인 역사로 기록하는 박물관.
git commit을 하는 순간 새로운 버전의 스냅샷이 박제된다.
이 3단계 구조 덕분에 수정한 파일이 많아도 내가 원하는 변경사항만 쏙쏙 골라 깔끔하게 저장할 수 있어 편리하지만, 초보 개발자들에게는 "왜 코드를 고쳤는데 바로 커밋이 안 되냐"며 머리를 쥐어뜯게 만드는 주범이기도 하다.
2.2. 브랜치(Branch)와 머지(Merge)의 갈림길
Git의 진정한 마법은 평행우주를 만드는 브랜치(Branch) 기능이다. 기존의 안정적인 소스코드(Main)에서 가지를 쳐서 나만의 실험실 브랜치(Feature)를 만든 뒤 마음껏 코드를 망쳐가며(?) 개발할 수 있다. 작업이 끝나면 다시 줄기 브랜치로 코드를 합치는 머지(Merge)를 진행한다.
문제는 서로 다른 우주에서 같은 파일의 같은 줄을 동시에 수정했을 때 발생한다. Git은 스스로 판단을 포기하고 'Merge Conflict (머지 충돌)' 에러를 뿜어내는데, 이때 코드 에디터 화면에 <<<<<<< HEAD와 >>>>>>> branch-name이 도배되는 광경은 개발자의 심장박동수를 분당 150회로 올려주는 직효약이다.1
3. 관련 밈 및 드립
3.1. git push --force (강제 푸시)
원격 서버(GitHub 등)에 등록된 공용 커밋 내역과 내 로컬의 내역이 꼬였을 때, 모든 경고를 무시하고 "내가 맞으니까 그냥 덮어씌워라!"며 강제로 밀어버리는 최강의 명령어(-f)이다.
만약 여러 명이 함께 작업하는 메인 브랜치에 이 짓을 저지르면, 동료들이 작업 중이던 코드가 흔적도 없이 날아가고 깃 히스토리가 엉망진창이 되는 대참사가 벌어진다. 개발자 커뮤니티에서는 동료의 코드를 지워버리고 유유히 퇴근하는 빌런 짤방의 필수 요소로 사용되며, 이 명령어를 메인 브랜치에 치는 순간 인사고과 평가나 사직서 제출서와 동의어가 된다.(...)
3.2. 커밋 메시지 'fix', 'asdf', '제발되게해주세요'
원칙적으로 커밋 메시지는 '해당 버전에서 무엇이 변경되었는지' 명확하게 설명해야 한다. 그러나 야근과 피로에 지친 개발자들은 커밋이 반복될수록 멘탈이 나가기 시작하며, 메시지의 퀄리티가 수직으로 하락한다.
- 1단계:
[Feat] Add user login function - 2단계:
Fix login bug - 3단계:
Fix logic error... again - 4단계:
fix 222 - 5단계:
asdf - 6단계:
제발 마지막으로 한번만 더 수정2
결국 프로젝트 히스토리창이 초등학생 낙서장처럼 변해버리고, 훗날 버그를 추적해야 하는 미래의 나와 동료들은 과거의 나에게 살인 충동을 느끼게 된다.
4. 여담
- 리누스 토발즈의 2주 기적: 리누스 토발즈는 원래 리눅스 커널 개발에 쓰던 상용 VCS 'BitKeeper'사가 무료 지원을 중단하자, 빡쳐서 단 2주 만에 C언어로 Git의 프로토타입을 설계하여 구현을 끝마쳤다. 천재가 빡치면 세상의 표준이 어떻게 바뀌는지 보여주는 대표적 사례다.
- 악명 높은 직관성 결여: Git의 명령어 체계는 직관성이 떨어지기로 악명 높다.
checkout하나가 브랜치를 바꾸는 데도 쓰이고, 변경사항을 되돌리는 데도 쓰이는 식이다. 오죽하면 Git 명령어를 조롱하며 아무 말이나 던지는 랜덤 명령어 생성 사이트도 존재할 정도다. - 최고의 해결책, 무한 클론: Git 상태가 돌이킬 수 없을 정도로 꼬였을 때는, 어설프게 고치려고 명령어 삽질을 하느라 시간 낭비하기보다 그냥 작업 중이던 폴더를 통째로 지우고 원격 리포지토리에서
git clone을 새로 받아오는 것이 정신 건강과 시간 절약에 매우 이롭다.