# Git 20주년 회고 – 여전히 이상하고, 여전히 멋진 도구

> Clean Markdown view of GeekNews topic #20217. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=20217](https://news.hada.io/topic?id=20217)
- GeekNews Markdown: [https://news.hada.io/topic/20217.md](https://news.hada.io/topic/20217.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2025-04-09T08:33:21+09:00
- Updated: 2025-04-09T08:33:21+09:00
- Original source: [blog.gitbutler.com](https://blog.gitbutler.com/20-years-of-git/)
- Points: 25
- Comments: 6

## Summary

Git은 20년 전 Linus Torvalds가 Linux 커널 커뮤니티의 비효율적인 버전 관리 문제를 해결하기 위해 만든 도구로, 단순한 디렉토리 콘텐츠 추적에서 시작해 전 세계적으로 널리 사용되는 버전 관리 시스템으로 성장했습니다. 초기에는 저수준 명령어로 작동하는 백엔드 도구였으나, git log, rebase, commit 등의 명령어가 발전하며 소프트웨어 개발 방식을 혁신했습니다. GitHub 공동 창립자인 작성자는 Git을 코드뿐 아니라 디지털 광고 콘텐츠 배포 같은 창의적 용도로 활용한 사례를 공유하며, Git의 유연성을 강조합니다. Git은 콘텐츠 배포와 코드 관리 등 다양한 분야에서 활용되며, 앞으로도 강력한 **콘텐츠 추적 및 분산 시스템**으로서 다양한 방식으로 활용될 가능성이 큽니다.

## Topic Body

- Git은 20년 전 Linus Torvalds가 첫 커밋을 하며 시작된 버전 관리 시스템임  
- 원래는 단순한 개인 프로젝트였지만, 이후 전 세계적으로 가장 널리 사용되는 버전 관리 시스템으로 성장함  
- 작성자는 GitHub 공동 창립자이며, Git 관련 책과 커뮤니티를 구축하면서 Git의 발전에 깊게 관여해왔음  
- 초기에는 단순한 디렉토리 콘텐츠 관리 도구였지만, 지금은 소프트웨어 개발 방식을 바꾼 핵심 도구가 되었음  
  
### Git의 철학과 필요성  
  
- Git은 Linux 커널 커뮤니티에서 기존 버전 관리 도구의 한계에 불만을 가지며 탄생함  
- 기존의 협업 방식은 메일링 리스트와 tarball, patch 파일을 통한 분산적이고 지역 기반의 협업이었음  
- 당시의 SCM 도구들은 느리고 중앙 집중적이며 비효율적이었기 때문에 tarball/patch 기반의 방식이 더 나았음  
- Bitkeeper라는 도구가 대안이었지만 라이선스 문제로 인해 Git 개발이 시작됨  
- Git은 처음부터 "버전 관리 시스템"이 아닌, 패치와 tarball을 더 잘 다루기 위한 데이터 구조로 설계되었음  
  
### Git의 첫 커밋  
  
- 첫 커밋은 매우 기본적인 디렉토리 콘텐츠 추적 도구였음  
- 당시 도구들은 `git commit` 같은 명령어가 아니라 `write-tree`, `commit-tree` 등 낮은 수준의 데이터베이스 툴이었음  
- Git은 처음부터 다음과 같은 기능을 가졌음:  
  - 작업 디렉토리를 캐시에 저장하고(`update-cache`), 트리로 객체화(`write-tree`)하여 데이터베이스에 기록  
  - 변경사항을 커밋 형태로 저장(`commit-tree`)하여 히스토리 생성  
  - `cat-file`, `read-tree`, `show-diff`로 데이터베이스 객체를 읽고 비교  
- Linus는 Git을 단지 백엔드 "배관 도구(plumbing)"로 보고, UI는 외부에서 만들기를 원했음  
  
### Git을 이용한 콘텐츠 배포 사례  
  
- 작성자는 2005년 Reactrix라는 스타트업에서 디지털 광고 콘텐츠 배포용으로 Git을 사용함  
- 수백 대의 디지털 디스플레이가 각각 다른 광고 조합을 가져야 했고, Git의 콘텐츠 주소화 기능이 이를 효율적으로 해결했음  
- Git을 코드 관리가 아닌 콘텐츠 배포 도구로 사용한 창의적인 사례였음  
- 초기 Git 프로젝트의 주요 기여자였던 Nick Hengeveld가 SSL, 병렬 HTTP 전송 등 기능을 추가함  
- 이 경험이 Git 관련 문서, 웹사이트, 책을 만들게 된 계기가 되었고 GitHub까지 이어짐  
  
### Git 명령어와 사용자 도구의 진화  
  
- 초창기 Git 명령어는 모두 저수준의 스크립트 기반 툴이었으며, 지금과는 많이 달랐음  
- `git log`, `git rebase`, `git commit` 등의 명령어도 처음에는 단순한 셸 스크립트였고, 이후 점점 발전하여 현재의 포맷으로 자리잡음  
  
#### `git log`의 초기 버전  
  
- `git log`는 `git-rev-list --pretty HEAD | less` 형태의 간단한 스크립트였음  
- `rev-list`는 현재도 존재하는 커밋 ID 출력용 도구임  
  
#### `git rebase`의 등장  
  
- `rebase`라는 개념은 2005년 Linus와 Junio Hamano의 이메일 대화에서 탄생  
- Junio의 작업 방식이 기존 HEAD를 버리고 새로운 HEAD를 기반으로 작업을 이어가는 방식이었고, 이를 "rebase"라고 표현함  
- 이는 현재 우리가 알고 있는 `git rebase` 명령어로 발전  
  
### Octocat의 기원  
  
- GitHub의 상징인 Octocat은 Git에서의 "octopus merge" 전략에서 아이디어를 얻음  
- 여러 브랜치를 동시에 병합하는 전략을 "octopus"라고 불렀으며, GitHub 초기 시절 이 단어에서 영감을 받아 Octocat 캐릭터가 탄생함  
  
### Git의 미래와 현재  
  
- 작성자는 여전히 Git을 원래 목적대로 "stupid content tracker"로 활용하고 있음  
- GitButler 프로젝트는 Git을 이용해 프로젝트의 히스토리를 추적하고 기록하는 방식으로 활용 중  
- Git은 여전히 강력한 콘텐츠 추적 및 분산 시스템이며, 앞으로도 다양한 방식으로 활용될 가능성이 있음  
  
* 생일 축하합니다, Git. 여전히 이상하고, 여전히 멋진 도구

## Comments



### Comment 37093

- Author: aobamisaki
- Created: 2025-04-13T11:10:16+09:00
- Points: 1

Git의 20세 생일을 축하드립니다.

### Comment 37011

- Author: bobross0
- Created: 2025-04-10T17:21:33+09:00
- Points: 1

오메데토

### Comment 36971

- Author: girr311
- Created: 2025-04-10T00:26:15+09:00
- Points: 2

생일 축하해. 아저씨 말 잘듣고 오래오래 건강해야한다.

### Comment 36962

- Author: kaistj
- Created: 2025-04-09T18:36:51+09:00
- Points: 1

생일 축하합니다 ^^

### Comment 36954

- Author: crawler
- Created: 2025-04-09T14:13:14+09:00
- Points: 1

이상하게 뽕차는 게시물이군요 이거

### Comment 36917

- Author: neo
- Created: 2025-04-09T08:33:21+09:00
- Points: 1

###### [Hacker News 의견](https://news.ycombinator.com/item?id=43613305) 
- Git의 기원에 대한 이야기는 Linus가 예언자처럼 묘사되는 경향이 있음
  - 블로그 글은 Linus의 인간적인 면을 강조하며 초기의 시행착오를 언급함
  - Mercurial도 중요한 역할을 했지만 종종 간과됨
  - Mercurial은 처음부터 UI를 가지고 있었고, Subversion과 유사한 UI로 사용자 친화적이었음
  - Git의 데이터 구조는 대용량 파일에 적합하지 않음
  - Git이 필연적이라고 생각하지 않으며, 새로운 대안이 나오길 기대함

- 2002년경 프로젝트의 각 부분에 고유한 해시 코드를 태그하는 아이디어를 가졌음
  - 소프트웨어 기업에 제안했지만 관심을 받지 못했음

- Git을 ClearCase의 대안으로 사용하기 시작했음
  - 2007년경부터 Git을 사용하기 시작했으며, ClearCase의 불편함을 해결하기 위해 스크립트를 작성함
  - 2008년에는 Git에 패치를 기여하기 시작했으며, 오픈 소스 기여에 대해 많은 것을 배웠음
  - Git의 복잡한 CLI에도 불구하고 사용에 어려움을 겪지 않았음
  - 다음 직장에서는 Chromium의 포크를 기반으로 작업했으며, Git을 사용하여 병합 충돌을 해결하는 데 능숙해졌음
  - GitHub가 Git의 주요 코드 리뷰 도구가 된 것에 실망했지만, Mercurial보다 Git이 더 나은 선택이라고 생각함

- Git이 20년밖에 되지 않았다는 사실이 놀라움
  - GitHub는 20년 미만이라는 것이 놀랍지 않지만, Git이 2005년 이전에 존재하지 않았다는 것은 충격적임
  - 다른 소스 제어 옵션을 사용해본 적이 없으며, 앞으로도 사용할지 궁금함

- 역사적 맥락을 알게 되어 흥미로웠음
  - ClearCase도 "rebase"라는 용어를 사용했으며, 1999년부터 사용된 것을 확인할 수 있음
  - ClearCase의 rebase는 시간이 오래 걸렸지만, Git의 즉각적인 rebase는 놀라웠음

- 효율적인 tarball 히스토리 데이터베이스 도구를 만들고자 했으며, 버전 관리 시스템을 만들 의도는 아니었음

- 커밋을 ssh 키로 서명할 수 있다는 사실을 알게 되었음
  - OpenBSD에서의 문제를 해결하기 위해 ssh로 서명하는 방법을 사용함
  - CVS에서 Git으로 작업 항목을 옮긴 지 20년이 지난 것 같지 않음

- 유용한 기사에 감사하며, Git 내부 구조에 대한 소개를 포함한 저장소를 추천함

- 메일링 리스트 협업에 대한 블로그 글을 작성하고 싶다는 의견이 흥미로움

- 여러 소스 제어 시스템 중 Git의 사용성이 가장 나쁘지만 가장 좋아하는 시스템임