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