저장소와 작업 폴더를 분리한다 - Git에서 Fossil로 옮길 때 달라지는 것

TL;DR

• Fossil은 버전 관리와 웹 인터페이스, 위키·티켓을 함께 제공한다. Lucio Albenga는 개인 프로젝트의 관리와 자체 호스팅을 단순하게 만들 수 있다는 이유로 Git에서 옮겼다. 이 선택은 대규모 Git 협업보다 자신의 작업 방식에 맞는 도구를 찾은 경험이다.
• Fossil에서는 저장소 파일과 작업 디렉터리가 분리된다. Git의 스테이징 영역과 같은 단계가 없고 기본 autosync 설정에서는 커밋과 원격 동기화가 연결된다. 명령 이름만 바꿔 쓰기보다 저장·작업·동기화의 경계를 먼저 이해해야 한다.
• Git 이력은 fast-export와 Fossil import로 옮길 수 있다. 가져오기 전에 브랜치 이름과 작성자 매핑을 정하고 이후 이력과 내용을 검증해야 한다. 변환 가능성과 일상적인 양방향 동기화는 다른 기능이다.
• 원문은 Git 미러를 양방향으로 설명하지만 Fossil 공식 문서는 단방향이라고 명시한다. 저장소의 비밀번호 필드를 읽으면 원문 비밀번호를 복구할 수 있다는 설명도 해시 저장 환경에는 맞지 않는다. 이런 부분은 공식 문서의 제한을 따라 구분했다.

Lucio Albenga는 개인 프로젝트의 버전 관리 도구를 Git에서 Fossil로 바꿨다. 출발점은 Git 개발에서 Rust를 필수 의존성으로 도입하려는 제안에 대한 거부감이었지만 최종 선택에는 작은 실행 파일, 단순한 작업 흐름, 내장 웹 인터페이스가 영향을 줬다. 언어와 공동체에 대한 평가는 저자의 개인적인 견해다. 그 제안이 Git 사용자의 프로젝트를 Rust로 다시 작성하라는 요구인 것은 아니다.

버전 관리와 협업 기능을 한 도구에 둔다

Fossil은 C로 구현된 버전 관리 도구이며 저장소를 조회하는 웹 인터페이스와 서버 기능을 내장한다. 위키와 티켓 같은 프로젝트 관리 기능도 함께 제공한다. 별도의 대형 협업 플랫폼을 운영하고 싶지 않은 개인이나 작은 팀에는 관리할 구성요소가 줄어드는 장점이 있다. 다만 Git 자체로 원격 저장소를 운영할 수 없는 것은 아니며 GitLab·Gitea·Forgejo는 추가적인 웹 협업 기능을 제공하는 선택지다.

Albenga는 Git의 스테이징 영역을 자신의 작업에는 불필요한 복잡성으로 본다. 변경을 별도로 스테이징한 뒤 커밋하는 방식보다 Subversion에 가까운 흐름이 더 자연스럽다는 평가다. Git의 스테이징이 모든 프로젝트에서 쓸모없다는 주장은 아니다. 부분 변경을 세밀하게 구성하는 작업과 단순한 커밋 흐름 중 무엇이 필요한지에 따라 선호가 달라질 수 있다.

작성자를 사용자 이름으로 다루는 점도 저자에게 장점이었다. 공개 이력마다 이메일 주소를 쓰는 부담을 줄일 수 있기 때문이다. 하지만 저장소 운영에서 이메일이 전혀 필요하지 않거나 Git으로 내보낼 때도 작성자 정보가 그대로 유지된다고 일반화할 수는 없다. 다른 버전 관리 시스템으로 옮길 때는 작성자·브랜치·태그의 표현 방식도 변환해야 한다.

저장소 파일과 체크아웃은 별개다

Fossil 저장소는 SQLite 기반의 파일로 보관하고 실제 파일을 편집하는 체크아웃 디렉터리는 따로 둔다. fossil init으로 저장소를 만드는 것과 fossil open으로 작업 디렉터리를 여는 단계가 구분된다. 저장소 파일은 한곳에 모으고 프로젝트별 체크아웃은 필요한 위치에 둘 수 있다. Git의 .git 디렉터리가 작업 트리 안에 있는 전형적인 사용 경험과 다른 지점이다.

원문의 개념을 보여 주는 최소 예시는 다음과 같다. 이 명령은 설명용이며 이 글을 작성하면서 사용자의 저장소를 변환하거나 서버를 실행하지는 않았다. 실제 경로와 설치 버전에 맞는 옵션은 실행 전에 도움말로 확인해야 한다.

fossil init project.fossil
mkdir project-work
cd project-work
fossil open ../project.fossil

복제할 때도 저장소를 받는 일과 작업 디렉터리를 여는 일을 구분해서 보면 이해하기 쉽다. 원문은 clone과 자동 체크아웃을 하지 않는 옵션을 소개하지만 버전에 따라 명령 형식과 기본 동작을 확인해야 한다. 원격 사용자 설정과 인증도 별도다. 저장소 파일을 복사했다는 사실만으로 원하는 원격 권한까지 자동으로 구성됐다고 가정하면 안 된다.

Git 이력을 옮길 때 정해야 할 것

공식 문서가 제시하는 기본 변환 경로는 Git의 fast-export 결과를 Fossil import에 전달하는 방식이다. Albenga는 여러 저장소를 옮기기 위해 내보낸 파일과 새 저장소 파일을 별도 디렉터리에 보관했다. 중간 산출물을 남기면 변환 옵션을 조정하거나 결과를 다시 확인하기 쉽다. 기존 Git 저장소를 즉시 지우기보다 새 저장소의 이력과 파일을 검증할 때까지 원본을 보존하는 편이 안전하다.

git fast-export --all | fossil import --git project.fossil

원문은 Git의 master를 Fossil의 trunk로 바꾸는 --rename-master trunk와 이메일을 사용자 이름으로 매핑하는 --attribute를 사용한다. 이 옵션을 다른 이름의 기본 브랜치에도 무조건 적용해서는 안 된다. 여러 작성자가 있으면 각 작성자 매핑도 살펴야 한다. 변환 완료 메시지와 저장소 파일의 생성은 시작일 뿐이며 브랜치·태그·작성자·주요 체크인의 내용이 기대대로 옮겨졌는지 확인해야 한다.

자동 동기화가 커밋의 의미를 바꾼다

Fossil의 autosync는 기본적으로 활성화돼 있다. 이 설정에서는 업데이트 시 원격 변경을 가져오고 커밋할 때도 원격 서버와 동기화가 연결된다. autosync를 끄면 원격 변경을 가져오는 pull과 작업 디렉터리에 반영하는 update, 원격으로 보내는 push를 더 명시적으로 다룬다. 커밋을 로컬 이력 기록으로만 생각하면 예상치 못하게 원격에 반영될 수 있다. 먼저 동기화 설정을 이해해야 한다.

스테이징 영역이 없다고 모든 파일을 한꺼번에 커밋해야 하는 것은 아니다. 파일을 지정해 커밋할 수 있으며 extras는 추적하지 않는 파일을, changes는 추적 중인 변경을 확인하는 데 쓰인다. status와 diff, timeline은 상태·차이·이력을 살피는 기본 도구다. Git 명령과 일대일로 대응시키기보다 어떤 정보를 보고 어느 범위의 변경을 기록하는지 확인하는 편이 낫다.

원문은 파일 추가·추적 해제와 .fossil-settings/ignore-glob을 이용한 제외 규칙도 소개한다. 삭제 명령이 파일의 실제 삭제와 같은 의미인지, 추적 해제만 표시하는지는 설정과 명령 동작을 확인해야 한다. 브랜치와 태그, 비공개 브랜치도 Git과 다른 관행을 가진다. 저자는 개인 프로젝트에서 브랜치를 많이 사용하지 않으므로 복잡한 협업 전환은 공식 문서에서 별도로 검토하도록 남긴다.

내장 서버가 있어도 공개 운영의 책임은 남는다

체크아웃에서 fossil ui를 실행하면 별도 상시 서버 없이 로컬 웹 인터페이스를 사용할 수 있다. 여러 저장소를 서버에 두고 내장 서버로 제공하는 방식도 가능하다. 원문의 서버 예시는 사용자가 적고 외부에서 접근할 수 없는 사설 네트워크를 전제로 한다. 이를 인터넷에 공개할 운영 구성으로 그대로 복제해서는 안 된다.

특히 원문에 나오는 unsafe-builtin 인증서는 편의상 제시된 선택지이지 공개 서비스의 인증서 검증을 대신하는 해법이 아니다. 외부 서비스에는 적절한 TLS와 인증·권한, 네트워크 노출 범위, 백업을 따로 검토해야 한다. 관리 계정 정보도 글이나 로그에 공개하지 않도록 보호해야 한다. 도구 하나로 서버를 띄울 수 있다는 것과 안전한 운영이 자동으로 완성된다는 것은 다르다.

양방향 미러와 비밀번호 복구 설명은 바로잡아 읽는다

원문은 Git과 Fossil의 양방향 동기화를 장점으로 들지만 인용한 Fossil 공식 GitHub 미러 문서는 단방향이라고 명시한다. Fossil에서 Git으로 내보내는 미러이며 GitHub에서 추가한 커밋이 자동으로 Fossil에 되돌아오지 않는다. Git 미러를 다시 Fossil로 가져올 수 있다는 사실과 상시 양방향 미러는 다른 기능이다. 따라서 GitHub에서 받은 PR을 같은 미러 경로로 자동 수용하는 흐름도 성립하지 않는다.

미러의 범위도 제한된다. 공식 문서는 체크인과 단순 태그를 변환하며 Fossil의 위키·티켓 등은 Git으로 옮기지 않는다고 설명한다. 브랜치·태그 이름과 중복 태그의 처리에도 차이가 있다. 기존 협업 데이터를 포함해 두 도구를 자유롭게 오갈 수 있다고 생각하면 예상하지 못한 손실이나 별도 이전 작업이 생길 수 있다.

비밀번호 설명도 주의가 필요하다. 원문은 SQLite의 사용자 테이블을 읽어 관리 비밀번호를 확인하는 예를 제시하지만 공식 문서에 따르면 비밀번호 필드는 평문이거나 해시일 수 있다. 웹 인터페이스나 사용자 명령으로 바꾼 비밀번호는 해시로 저장되므로 필드 값을 읽는 것이 원래 비밀번호의 복구를 뜻하지 않는다. 관리 권한으로 안전하게 재설정하는 절차를 검토해야 하며 저장된 인증정보를 일괄 출력하는 방법을 일반적인 운영 지침으로 삼지 않는다.

Albenga의 선택에서 일관된 기준은 자신의 프로젝트 규모에 맞는 단순함이다. Fossil은 저장소와 협업 기능을 한 도구에 모으고 체크아웃과 이력을 분리하는 방식을 제공한다. 이 장점을 얻으려면 Git의 익숙한 동작을 그대로 기대하기보다 동기화·미러·권한의 차이를 받아들여야 한다. 개인 프로젝트에 적합하다는 경험을 모든 팀의 전환 권고로 확대할 필요는 없다.

참고 자료

From Git to Fossil — Lucio Albenga, 2025년 11월 12일.

Fossil: Import And Export · GitHub 미러의 방향과 제한 · Fossil Password Management. 원문의 기술 설명 중 양방향 미러와 평문 비밀번호 복구를 일반화할 수 없는 부분을 공식 문서와 대조했다.