Git 용어의 어원 (Feat. 눈물 젖은 학습기)

내가 Git을 처음 배운 건 4년 전이었다. 첫 회사에 입사했을 때, 모든 문서가 깃허브 Repository(저장소)에 관리되고 있었기 때문이다. “모르면 살아남을 수 없다”는 스스로 만든 압박 속에, 전면 재택근무라는 환경까지 겹쳐 질문조차 쉽지 않았다. 결국 혼자 씨름하면서 억지로 배워야 했다.

일단 브랜치(Branch), 클론(Clone), 포크(Fork) 같은 기초 개념은 간신히 이해했다. 하지만 Pull Request(PR)라는 단어는 도저히 납득이 가지 않았다. (GitLab에서는 이걸 Merge Request(MR)라고 부르는데, 그게 훨씬 직관적이다.) “도대체 뭘 Pull한다는 거지?” 코드도, 협업도 뭔지도 모른 상태에서 Git을 파악하려니, 눈앞은 더 아득해졌다.

“지금 코딩도 한다면서, 이런 쉬운 걸 몰랐다고..?라고 생각할 수도 있지만, 나는 컴퓨터 공포증을 오랫동안 앓고 있던 선량한 문과생이었다.

공인인증서와 그에 수반된 키보드 보안 프로그램, 이상한 액티브X 창, 하루 다섯 번 꼬이는 비밀번호. 수년간 지속된 사투에 나는 소진되어 가고 있었다.

결정타는 무방비 상태로 스트리밍 사이트에서 잭 니콜슨 주연의 「인생은 아름다워」를 보다가 랜섬웨어에 감염된 사건으로, 데이터를 모조리 잃은 뒤에는 만성화된 패배감으로 움츠러들었다.

Git은 왜 Git일까?

참고로 Git이라는 이름은 리눅스 아버지 리누스 토르발스가 “멍청이, 얼간이”라는 뜻으로 일부러 지은 것이다. 입문자에게는 이 단어가 주는 어감 때문에 더 헷갈린다. 단어의 뜻을 파악하면 원리도 보일 거라 착각했던 나는 문서를 읽을수록 모르는 개념이 세 배로 증식하는 경험을 했다.

Pull Request는 왜 Pull일까?

처음에는 진짜 이해가 안 갔다. “누가 뭘 당긴다고?” Pull Request는 말 그대로 “내 브랜치에 있는 코드를 메인 브랜치로 Pull(끌어와) 주세요”라는 요청이다.

GitLab의 Merge Request(MR)가 더 직관적으로 들리는 이유는, 협업에서 실제로 일어나는 행위가 “병합(Merge)”이기 때문이다. 하지만 GitHub은 PR이라는 이름을 굳혀버린 것이다.

지금보면 사실 일상에서도 “뚜껑”이라는 말의 어원을 이해하지 않고도 사용할 수 있듯 단어에 집착할 필요가 없었다.

첫 PR의 눈물

그러던 어느 날, 팀에서 “PR 올려주세요”라는 요청이 떨어졌다. 나는 세 시간 동안 머리를 쥐어뜯으며 결국 PR을 올렸는데, 알고 보니 다른 팀 개발자 브랜치에다 올리는 기행을 저질러버렸다. 자괴감에 눈물이 주르륵 흘렀고, 내 흐느끼는 소리를 듣고 방에 들어온 엄마가 “왜 우냐” 묻던 장면은 아직도 생생하다.

Commit이라는 단어, 어디서 온 걸까?

어찌어찌 Git에 익숙해지고 나니 문서 번역과 리뷰에는 문제가 없었다. 하지만 Commit 메시지는 여전히 방치했다. Commit이라는 단어도 이해가 안 갔기 때문에 무시해버렸던 것이다.

Git에서 Commit은 변경 사항을 저장소에 남기는 행위를 말한다. 그런데 이 단어는 원래 데이터베이스 트랜잭션 용어에서 가져온 것이다. 데이터베이스에서 트랜잭션을 수행할 때는 보통 두 가지 선택지가 있다:

• Commit: 지금까지의 변경을 확정해서 영구 저장
• Rollback: 방금까지의 변경을 취소하고 이전 상태로 되돌림

즉, Commit은 “이제 이 변경을 되돌릴 수 없는 공식 기록으로 확정한다”는 선언 같은 것이다. 프로젝트 히스토리에 새로운 상태를 남기고, 그 순간부터는 누구도 그 기록을 지워버릴 수 없다.

라틴어 committere의 “맡기다, 확정하다”라는 어원적 뉘앙스와도 딱 맞아떨어지는 셈이다.

기타 용어들

Stash

개발 중간에 다른 브랜치로 급히 넘어가야 할 때, 미완성 변경사항을 잠깐 “서랍에 숨겨두는” 비유로 붙여진 이름이다.

Squash

squash = 으깨다, 압축하다. 여러 커밋을 한 덩어리로 합쳐서 히스토리를 깔끔하게 만들 때 쓴다. 말 그대로 “으깨서 하나로 만들기.”

Origin

내가 클론한 원격 저장소(remote)의 기본 이름으로, Git에서 자동으로 붙여주는 값이다. 사실 이름은 마음대로 바꿀 수 있지만, 토르발스가 “기원(origin)”이라는 표현을 기본값으로 설정하면서 문화가 굳어졌다.

Master → Main

• Master: Git 초기(2005~) 기본 브랜치 이름. ‘마스터 브랜치’라는 표현은 오래된 소프트웨어 업계 전통에서 비롯되었다.
• Main: 2020년 이후 GitHub·GitLab이 인종차별적 언어 사용 지양을 선언하면서 main으로 교체되었다.

Rebase

base = 기반. re-base = 기반을 다시 깔아주다. 내 브랜치의 기반을 다른 브랜치로 옮기는 것이다.

Cherry-pick

체리만 골라 따다 → 좋은 것만 선택하다. 특정 커밋 하나만 다른 브랜치에 골라 반영.

Git Commit Message Convention

기록을 남겨야 하는 순간이니, 사실은 메시지를 잘 작성하는 게 매우 중요하다. 그런데 나는 당시 번역/리뷰만 하던 입장이었고, 내가 올린 커밋을 누군가 세세히 리뷰하는 경우도 없었다. 그러다 보니 커밋 메시지에 진심을 담을 이유가 없었다.

나의 예전 커밋 메시지는 이랬다.

얍
ㅁㄹㅁㄴㄹㅁ
fix

이런 메시지들이 저장소에 박제되기 시작했다. 나도 모르게 쌓여버린 악습관이었다.

Git Commit Message Convention

Git 세계에는 Commit 메시지 컨벤션이라는 것이 존재한다. 흔히 쓰이는 규칙 몇 가지를 예로 들어보자.

feat: 새로운 기능 추가
fix: 버그 수정
docs: 문서 변경
style: 코드 포맷팅, 세미콜론 누락 등 기능에 영향 없는 변경
refactor: 코드 리팩토링
test: 테스트 코드 추가 및 수정
chore: 기타 자잘한 변경

예를 들어,

feat: Added Notes in dashboard
fix: Fixed bug in FAQ page toggle_event
docs: Updated installation guide in README

이런 식으로 작성하면 팀원들은 커밋 내역만 봐도 “아, 이번 변경이 어떤 성격인지” 단번에 파악할 수 있다.

습관은 쉽게 바뀌지 않는다

문제는 이걸 알면서도 혼자 하는 사이드 프로젝트에서는 여전히 원하는 만큼의 정돈된 커밋 메시지를 사용하지 않고 있다.

참고로 나는 처음부터 GUI의 열성 사용자로서, 터미널을 잘 쓰지 않았던 탓에 커맨드도 잘 외우지 못한다. 매번 창을 켜놓고 있다.

협업을 할 때도 중요하지만, 사실 혼자 하는 프로젝트일수록 나중에 과거 코드를 돌아볼 때 “내가 뭘 했더라?”를 알 수 있는 기록이 필요하다.

뒤늦게 고치는 악습관이라 쉽지는 않지만, 최근에는 주의를 기울이는 중이다.