SQLite가 Git 대신 Fossil을 사용하는 이유를 설명한다. Git의 상황 인식 부족, 체크인 후속 관계 파악의 어려움, 불필요하게 복잡한 정신 모델, 과거 브랜치 이름 미보존, 더 큰 관리 부담, 미흡한 사용자 경험 등을 사례와 함께 짚고, Git 사용자들이 SQLite 소스 코드를 이용하는 방법(공식 GitHub 미러, 웹 다운로드, Fossil 사용법, 소스 무결성 검증)을 안내한다.
Why SQLite Does Not Use Git
===============
작다. 빠르다. 신뢰할 수 있다.
셋 다 고르세요.
SQLite가 Git을 사용하지 않는 이유
목차
2. SQLite가 Git을 사용하지 않는 몇 가지 이유
2.2. Git에서는 체크인의 후속(자손) 찾기가 어렵다
3. Git 사용자를 위한 SQLite 소스 코드 접근 가이드
SQLite는 Git 버전 관리 시스템을 사용하지 않습니다. SQLite는 대신 Fossil을 사용합니다. Fossil은 SQLite를 지원하기 위해 특별히 설계되고 작성된 버전 관리 시스템입니다.
사람들은 종종 왜 SQLite가 다른 모두처럼 Git을 사용하지 않는지 궁금해합니다. 이 글은 그 질문에 답하려고 합니다. 또한 섹션 3에서는 Git 사용자가 SQLite 소스 코드를 쉽게 액세스하는 방법에 대한 힌트를 제공합니다.
이 글은 Fossil과 Git의 비교 문서가 아닙니다. 두 시스템의 비교 중 하나는 https://fossil-scm.org/fossil/doc/trunk/www/fossil-v-git.wiki를 참고하세요. 다른 서드파티 비교도 있으니 검색 엔진으로 찾아보시기 바랍니다.
이 글은 여러분이 프로젝트를 Git에서 다른 것으로 바꾸라고 주장하는 것도 아닙니다. 원하는 버전 관리 시스템을 사용하시면 됩니다. Git에 완전히 만족한다면 계속 Git을 쓰면 됩니다. 하지만 Git이 잘 맞지 않거나 개선의 여지가 있는지, 더 나은 것이 있는지 궁금하다면 아래의 관점을 이해해 보세요. 그 통찰을 바탕으로 다른 더 나은 버전 관리 시스템을 찾거나 만들거나, Git 자체를 개선하는 데 활용할 수 있습니다.
이 글은 명확성을 높이고 우려와 의문을 다루며 오류를 고치기 위해 여러 차례 개정되었습니다. 이 문서의 전체 편집 이력은 https://sqlite.org/docsrc/finfo/pages/whynotgit.in에서 볼 수 있습니다. (사용 팁: 그래프의 임의 두 노드를 클릭하면 diff를 볼 수 있습니다. 참고로, 이와 유사한 기능을 제공하는 Git 웹 인터페이스가 있나요?)
SQLite에서 최근 무슨 일이 있었는지 보고 싶다면 타임라인에 방문합니다. 그러면 단일 화면에서 모든 브랜치의 최신 변경사항 요약을 볼 수 있습니다. 몇 번의 클릭으로 원하는 만큼 상세하게 파고들 수 있습니다. 휴대전화로도 가능합니다.
GitHub와 GitLab에는 이에 상응하는 것이 없습니다. 제가 찾은 것 중 가장 가까운 것은 network인데, 렌더링이 느리고(캐시되지 않았다면), 제공하는 세부 정보가 훨씬 부족하며, 모바일에서는 거의 작동하지 않습니다. GitHub의 commits 보기는 더 많은 세부 정보를 제공하고 렌더링이 빠르며 모바일에서도 잘 작동하지만, 한 번에 하나의 브랜치만 보여줍니다. 그래서 최신 변경사항을 모두 봤는지 쉽게 알 수 없습니다. 게다가 설령 GitHub/GitLab이 더 나은 인터페이스를 제공하더라도 그것들은 서드파티 서비스입니다. Git의 핵심 일부가 아닙니다. 따라서 그것들을 쓰면 프로젝트에 또 다른 의존성이 추가됩니다.
Git 사용자들은 흔히 Git용 서드파티 그래픽 뷰어를 설치하며, 그중 상당수는 프로젝트의 최근 활동을 더 잘 보여준다고 들었습니다. 좋습니다. 하지만 그런 것들도 여전히 별도 설치하고 관리해야 하는 서드파티 애플리케이션입니다. 많은 도구가 특정 플랫폼 전용입니다. (예를 들어, 꽤 괜찮은 GitUp은 Mac에서만 작동합니다.) 모두 먼저 로컬 저장소를 동기화한 다음, 데스크톱에서 그래픽 인터페이스를 띄워야 합니다. 그런데도 보통 제가 보고 싶은 것을 보려면 클릭을 여러 번 해야만 합니다. 사무실 밖에서 휴대전화로 프로젝트 상태를 확인하는 건 사실상 불가능합니다.
Git은 과거로 거슬러 올라가 보는 것은 쉽게 해주지만, 미래를 보는 것은 어렵습니다. 과거의 어떤 체크인(check-in)을 기준으로 이전에 무엇이 있었는지는 볼 수 있지만, 그 다음에 무엇이 이어졌는지는 파악하기가 까다롭습니다.
반면, Fossil은 시간의 흐름을 앞으로 따라가며 보여주는 유용한 표시를 제공합니다. 몇 가지 예시는 다음과 같습니다:
Git에서 체크인의 자손을 찾는 것이 불가능한 것은 아닙니다. 다만 어렵습니다. 예를 들어, 유닉스에서 체크인의 자손을 찾기 위한 명령 시퀀스를 보여주는 Stack Overflow 페이지가 있습니다:
git rev-list --all --parents | grep ".{40}.." | awk '{print $1}'
하지만 이것은 같은 것이 아닙니다. 위 명령은 분기 구조를 보여주지 않은 채 자손 목록만을 제공합니다. 분기 구조는 무슨 일이 일어났는지를 이해하는 데 중요합니다. 그리고 이 명령은 로컬에 저장소를 클론해 둔 경우에만 동작합니다. GitHub나 GitLab 같은 웹 인터페이스에서는 체크인의 자손을 찾을 수 없습니다.
여기서 핵심은 가끔 체크인의 자손을 찾을 수 있느냐가 아닙니다. Fossil에서는 자손 정보가 쉽게 얻어지기 때문에 Fossil이 제공하는 웹 페이지 전반에 그 정보가 스며들어 있습니다. 한 가지 예: 모든 Fossil 체크인 정보 페이지(예시)는 해당 체크인의 직전과 직후 체크인을 보여주는 작은 "컨텍스트" 그래프를 표시합니다. 이는 사용자가 더 나은 상황 인식을 유지하도록 돕고, 예를 들어 일련의 다음 체크인으로 앞으로 클릭해 이동하는 기능 같은 유용한 능력을 제공합니다. 또 다른 예: Fossil은 특정 체크인 주변의 컨텍스트를 쉽게 보여줍니다(예시). 이것 역시 상황 인식을 높이고 코드에서 무슨 일이 벌어지는지를 더 깊이 이해하는 데 도움이 됩니다. Fossil 문서에는 추가 예시만 모아둔 전체 페이지가 있습니다.
위의 모든 것은 이론적으로는 Git에서도 가능합니다. 적절한 확장과 도구, 그리고 올바른 명령을 사용하면요. 하지만 쉽지 않아서 좀처럼 실행되지 않습니다. 그 결과, 개발자들은 코드에서 벌어지는 일에 대한 인식이 떨어지게 됩니다.
Git의 복잡성은 개발 중인 소프트웨어로부터 주의를 분산시킵니다. Git 사용자는 다음 사항을 모두 염두에 두어야 합니다:
Git에는 이들 위치 사이에서 콘텐츠를 이동하거나 비교하는 각종 명령(및/또는 명령 옵션)이 있습니다.
반면 Fossil 사용자는 자신의 작업 디렉터리와 작업 중인 체크인만 생각하면 됩니다. 산만함이 60% 줄어듭니다. 모든 개발자의 뇌 사이클은 유한합니다. Fossil은 작동시키는 데 필요한 뇌 사이클이 더 적기에, 개발 중인 소프트웨어에 더 많은 지적 자원을 집중할 수 있게 해줍니다.
Git과 Fossil을 모두 사용하는 한 사용자는 HN에서 이렇게 말합니다:
Fossil은 모든 것이 ... 단일 명령으로 서버에 동기화되었다는 마음의 평화를 줍니다.... git에서는 이런 마음의 평화를 결코 얻지 못합니다.
Git은 체크인 시퀀스의 전체 DAG를 보존합니다. 하지만 브랜치 태그는 로컬 정보이므로 동기화되지 않으며 브랜치가 닫히면 보존되지 않습니다. 이 때문에 과거 브랜치 검토가 번거롭습니다.
예를 들어, 고객이 이렇게 물었다고 해봅시다. "2년 전의 'prefer-coroutine-sort-subquery' 브랜치는 어떻게 됐나요?" 그러면 버전 관리 시스템의 이력을 다음과 같이 조회해 답하려고 할 것입니다:
Fossil 보기는 해당 브랜치가 결국 트렁크로 병합되었음을 분명히 보여줍니다. 브랜치가 어디서 시작되었는지, 트렁크의 변경사항이 두 차례 브랜치로 병합된 것도 보여줍니다. GitHub에는 이런 정보가 전혀 나오지 않습니다. 사실, GitHub 표시만으로는 무슨 일이 있었는지 파악하는 데 거의 쓸모가 없습니다.
많은 독자들이 과거 개발 활동을 더 잘 보여줄 수 있는 다양한 Git용 서드파티 GUI를 추천했습니다. 일부는 원래 Git이나 GitHub보다 더 잘 작동할 수 있습니다. 그러나 Git은 과거 브랜치 이름을 동기화에서 보존하지 않기 때문에 그들 모두 한계를 가질 수밖에 없습니다. 게다가 설령 다른 도구들이 더 낫더라도, 원하는 정보를 얻으려면 서드파티 도구를 써야 한다는 사실 자체가 핵심 시스템의 완성도를 드러냅니다.
Git은 복잡한 소프트웨어입니다. 개발자 워크스테이션에 Git을 설치하거나 업그레이드하려면 어떤 형태로든 인스톨러가 필요합니다. Git 서버를 세우는 일도 만만치 않아, 대부분의 개발자는 GitHub나 GitLab 같은 서드파티 서비스를 사용하고, 그 결과 추가 의존성을 도입합니다.
반면 Fossil은 단일 독립 실행형 바이너리이며, 이를 $PATH에 두는 것만으로 설치가 끝납니다. 그 하나의 바이너리에 코어 Git의 모든 기능뿐 아니라 GitHub 및/또는 GitLab의 기능까지 들어 있습니다. 위키, 버그 추적, 채팅, 포럼이 있는 커뮤니티 서버를 운영하고, 사용자용 패키지 다운로드를 제공하며, 로그인 관리 등등을 별도의 소프트웨어 없이 모두 처리합니다. Fossil 커뮤니티 서버를 세우는 데는 몇 분이면 충분합니다. 그리고 Fossil은 효율적입니다. Fossil 서버는 월 $5 VPS나 라즈베리 파이에서도 잘 동작하지만, GitLab 등은 더 강력한 하드웨어가 필요합니다.
관리 부담이 줄어들면, 프로그래머들은 버전 관리 시스템을 만지작거리는 시간이 줄고(이 경우엔 SQLite) 소프트웨어 작업에 더 많은 시간을 쓸 수 있습니다.
다음 https://xkcd.com/1597/ 만화는 과장이긴 하지만, 꽤나 뼈를 때립니다:
솔직해집시다. Git이 최적의 사용자 경험을 제공하지 못한다는 데 이견을 제기하는 사람은 많지 않습니다. 내부 구현의 많은 부분이 사용자 인터페이스에 그대로 드러납니다. 인터페이스가 너무 나빠서 가짜 git man 페이지를 만들어주는 패러디 사이트까지 있을 정도입니다.
소프트웨어를 설계하는 일은 어렵습니다. 많은 집중이 필요합니다. 훌륭한 버전 관리 시스템은 개발자에게 좌절이 아니라 도움을 줘야 합니다. 지난 10여 년 동안 Git도 이 점에서 나아지긴 했지만, 아직 갈 길이 멉니다.
열렬한 Git 사용자라 해도 SQLite에 쉽게 접근할 수 있습니다. 이 섹션은 그 방법에 대한 힌트를 제공합니다.
2019-03-20 기준으로, GitHub에 SQLite 소스의 공식 Git 미러가 생겼습니다.
이 미러는 SQLite의 정본 Fossil 저장소를 점진적으로 내보낸 것입니다. 크론 잡이 매시간 GitHub 저장소를 업데이트합니다. 이는 단방향, 읽기 전용 코드 미러입니다. GitHub를 통한 풀 리퀘스트나 변경사항은 받지 않습니다. GitHub 저장소는 Fossil 저장소의 콘텐츠를 단순 복제할 뿐입니다. 모든 변경 입력은 Fossil을 통해서만 이루어집니다.
Git 미러에서 체크인과 파일을 식별하는 해시는 Fossil의 해시와 다릅니다. 그 이유는 많지만, 가장 큰 이유는 Fossil은 SHA3-256을, Git은 SHA1을 사용하기 때문입니다. 내보내기 과정에서 각 체크인의 원래 Fossil 해시는 체크인 코멘트의 바닥글로 추가됩니다. 혼동을 피하기 위해, SQLite 체크인을 지칭할 때는 Git 해시가 아니라 항상 원래의 Fossil 해시를 사용하세요.
SQLite Fossil 저장소에는 SQLite의 임의의 과거 버전을 Tarball, ZIP 아카이브 또는 SQLite 아카이브로 다운로드할 수 있는 링크가 있습니다. 이 다운로드의 URL은 단순하여 자동화 도구에 쉽게 포함시킬 수 있습니다. 형식은 다음과 같습니다:
다운로드할 버전을 설명하는 내용으로 _VERSION_만 바꾸면 됩니다. _VERSION_은 특정 체크인의 암호학적 해시 이름 접두어나, 브랜치 이름(이 경우 해당 브랜치의 최신 버전이 내려받아집니다), 혹은 "version-3.23.1"처럼 특정 체크인에 대한 태그가 될 수 있습니다:
최신 릴리스를 받으려면 _VERSION_에 "release"를 사용하세요:
최신 트렁크 체크인을 받으려면 _VERSION_에 "trunk"를 사용하세요:
기타 등등. ZIP 아카이브나 SQLite 아카이브를 원한다면 "/tarball/" 요소를 각각 "/zip/" 또는 "/sqlar/"로 바꾸고, 다운로드 파일 이름의 확장자도 ".zip" 또는 ".sqlar"로 바꾸면 됩니다.
Fossil은 설치와 사용이 쉽습니다. 다음은 유닉스 기준 단계입니다. (Windows도 비슷합니다.)
이제 "./configure; make"를 입력할 준비가 되었습니다(Windows에서 MSVC를 사용할 경우 "nmake /f Makefile.msc").
체크아웃을 다른 버전으로 바꾸려면 "update" 명령을 사용하세요:
fossil update VERSION
SQLite의 최신 트렁크 버전을 받으려면 _VERSION_에 "trunk"를 사용하세요. 혹은 암호학적 해시 이름의 접두어나, 브랜치 또는 태그 이름을 사용할 수 있습니다. _VERSION_에 사용할 수 있는 이름에 대한 더 많은 제안은 https://fossil-scm.org/fossil/doc/trunk/www/checkin_names.wiki를 참고하세요.
~/sqlite 체크아웃 안에서 "fossil ui" 명령을 사용하면 웹사이트의 로컬 사본이 나타납니다.
Fossil에 대한 추가 문서는 https://fossil-scm.org/fossil/doc/trunk/www/permutedindex.html에서 볼 수 있습니다.
탐색과 실험을 두려워하지 마세요. 로그인 권한이 없으면 여러분이 만든 변경사항을 푸시할 수 없으므로, 프로젝트를 망가뜨릴 수 없습니다.
여러분이 가진 SQLite 소스 코드가 진짜이며 어떤 방식으로도(아마도 공격자에 의해) 수정되지 않았음을 검증해야 한다면, 몇 가지 간단한 커맨드라인 도구로 할 수 있습니다. SQLite 소스 트리의 루트에는 "manifest"라는 파일이 있습니다. 이 manifest 파일에는 소스 트리의 다른 모든 파일 이름과 그 파일의 SHA1 또는 SHA3-256 해시가 들어 있습니다(오래된 파일에는 SHA1, 새 파일에는 SHA3-256을 사용). 이 해시를 추출해 소스 코드 파일과 대조하는 스크립트를 작성할 수 있습니다. 체크인의 해시 이름은 "manifest" 파일 자체의 SHA3-256 해시이며, 마지막 줄이 "# Remove this line..."으로 시작한다면 그 마지막 줄을 생략한 상태의 해시입니다.
Fossil과 Git을 다루는 다른 페이지는 다음과 같습니다:
이 페이지는 2025-09-04 08:56:53 UTC에 마지막으로 수정되었습니다
