▲

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

 (blog.gitbutler.com)
25P by GN⁺ 11일전 | ★ favorite | 댓글 6개
  • 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. 여전히 이상하고, 여전히 멋진 도구
▲
aobamisaki 7일전  [-]

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

답변달기
▲
girr311 10일전  [-]

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

답변달기
▲
kaistj 10일전  [-]

생일 축하합니다 ^^

답변달기
▲
crawler 10일전  [-]

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

답변달기
▲
GN⁺ 11일전  [-]
Hacker News 의견

  • 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의 사용성이 가장 나쁘지만 가장 좋아하는 시스템임

답변달기