Nhìn lại 20 năm của Git – vẫn kỳ lạ và vẫn tuyệt vời

 (blog.gitbutler.com)
25 điểm bởi GN⁺ 2025-04-09 | 6 bình luận | Chia sẻ qua WhatsApp
  • Git là hệ thống quản lý phiên bản bắt đầu từ 20 năm trước khi Linus Torvalds thực hiện commit đầu tiên
  • Ban đầu chỉ là một dự án cá nhân đơn giản, nhưng sau đó đã phát triển thành hệ thống quản lý phiên bản được sử dụng rộng rãi nhất trên toàn thế giới
  • Tác giả là đồng sáng lập GitHub, và đã tham gia sâu vào sự phát triển của Git thông qua việc xây dựng sách và cộng đồng liên quan đến Git
  • Thuở ban đầu, đây chỉ là một công cụ quản lý nội dung thư mục đơn giản, nhưng giờ đã trở thành công cụ cốt lõi làm thay đổi cách phát triển phần mềm

Triết lý và sự cần thiết của Git

  • Git ra đời từ sự bất mãn của cộng đồng Linux kernel với những giới hạn của các công cụ quản lý phiên bản trước đó
  • Cách cộng tác trước đây là phân tán và mang tính cục bộ, thông qua mailing list, tarball và file patch
  • Các công cụ SCM thời đó chậm, tập trung hóa và kém hiệu quả, nên cách làm dựa trên tarball/patch lại tốt hơn
  • Một công cụ tên là Bitkeeper từng là phương án thay thế, nhưng do vấn đề giấy phép nên việc phát triển Git đã bắt đầu
  • Ngay từ đầu, Git không được thiết kế như một "hệ thống quản lý phiên bản" mà là một cấu trúc dữ liệu để xử lý patch và tarball tốt hơn

Commit đầu tiên của Git

  • Commit đầu tiên là một công cụ rất cơ bản để theo dõi nội dung thư mục
  • Khi đó các công cụ không phải là những lệnh như git commit, mà là các công cụ cơ sở dữ liệu cấp thấp như write-tree, commit-tree
  • Ngay từ đầu Git đã có các khả năng sau:
    • Lưu thư mục làm việc vào cache (update-cache), chuyển thành đối tượng cây (write-tree) rồi ghi vào cơ sở dữ liệu
    • Lưu thay đổi dưới dạng commit (commit-tree) để tạo lịch sử
    • Đọc và so sánh các đối tượng trong cơ sở dữ liệu bằng cat-file, read-tree, show-diff
  • Linus xem Git chỉ là phần backend, tức các "công cụ đường ống (plumbing)", và muốn phần UI được xây dựng từ bên ngoài
Quảng cáo

Ví dụ phân phối nội dung bằng Git

  • Tác giả đã sử dụng Git vào năm 2005 tại startup tên Reactrix để phân phối nội dung quảng cáo số
  • Hàng trăm màn hình hiển thị số cần những tổ hợp quảng cáo khác nhau, và khả năng định địa chỉ nội dung của Git đã giải quyết việc này một cách hiệu quả
  • Đây là một ví dụ sáng tạo về việc dùng Git không phải để quản lý mã nguồn mà là như một công cụ phân phối nội dung
  • Nick Hengeveld, một trong những người đóng góp chính cho dự án Git thời kỳ đầu, đã bổ sung các tính năng như SSL và truyền HTTP song song
  • Trải nghiệm này đã trở thành động lực để tạo ra tài liệu, website và sách về Git, rồi tiếp nối đến GitHub

Sự tiến hóa của lệnh Git và công cụ cho người dùng

  • Các lệnh Git thời kỳ đầu đều là công cụ cấp thấp dựa trên script, rất khác so với hiện nay
  • Những lệnh như git log, git rebase, git commit ban đầu cũng chỉ là các shell script đơn giản, rồi dần phát triển thành định dạng hiện tại

Phiên bản đầu tiên của git log

  • git log là một script đơn giản có dạng git-rev-list --pretty HEAD | less
  • rev-list là công cụ để in ra ID commit và vẫn còn tồn tại cho đến hiện nay
Quảng cáo

Sự xuất hiện của git rebase

  • Khái niệm rebase ra đời trong cuộc trao đổi email năm 2005 giữa Linus và Junio Hamano
  • Cách làm việc của Junio là bỏ HEAD hiện tại và tiếp tục công việc dựa trên HEAD mới, và cách đó được gọi là "rebase"
  • Điều này sau đó đã phát triển thành lệnh git rebase như chúng ta biết ngày nay

Nguồn gốc của Octocat

  • Octocat, biểu tượng của GitHub, lấy ý tưởng từ chiến lược "octopus merge" trong Git
  • Chiến lược gộp nhiều nhánh cùng lúc được gọi là "octopus", và trong những ngày đầu của GitHub, từ này đã truyền cảm hứng để tạo ra nhân vật Octocat

Hiện tại và tương lai của Git

  • Tác giả vẫn đang sử dụng Git đúng theo mục đích ban đầu của nó như một "stupid content tracker"
  • Dự án GitButler đang tận dụng Git theo cách theo dõi và ghi lại lịch sử của dự án
  • Git vẫn là một hệ thống phân tán và theo dõi nội dung mạnh mẽ, và trong tương lai vẫn có thể được sử dụng theo nhiều cách khác nhau
  • Chúc mừng sinh nhật, Git. Vẫn kỳ lạ và vẫn tuyệt vời

Bài viết liên quan

6 bình luận

 
aobamisaki 2025-04-13

Chúc mừng sinh nhật lần thứ 20 của Git.
 
bobross0 2025-04-10

Chúc mừng
 
girr311 2025-04-10

Chúc mừng sinh nhật. Hãy ngoan ngoãn nghe lời các bậc tiền bối và luôn khỏe mạnh thật lâu nhé.
 
kaistj 2025-04-09

Chúc mừng sinh nhật ^^
 
crawler 2025-04-09

Đúng là một bài đăng khiến người ta thấy phấn khích một cách kỳ lạ.
 
GN⁺ 2025-04-09
Ý kiến Hacker News

  • Câu chuyện về nguồn gốc của Git thường có xu hướng mô tả Linus như một nhà tiên tri

    • Bài blog nhấn mạnh khía cạnh rất con người của Linus và đề cập đến những lần thử-sai ban đầu
    • Mercurial cũng đóng vai trò quan trọng nhưng thường bị bỏ qua
    • Mercurial có UI ngay từ đầu và thân thiện với người dùng nhờ UI tương tự Subversion
    • Cấu trúc dữ liệu của Git không phù hợp với các tệp dung lượng lớn
    • Tôi không nghĩ Git là điều tất yếu, và hy vọng sẽ có những lựa chọn thay thế mới xuất hiện

  • Khoảng năm 2002, tôi đã có ý tưởng gắn mã hash duy nhất cho từng phần của dự án

    • Tôi đã đề xuất với một công ty phần mềm nhưng không nhận được sự quan tâm

  • Tôi bắt đầu dùng Git như một giải pháp thay thế cho ClearCase

    • Tôi bắt đầu dùng Git từ khoảng năm 2007 và viết script để giải quyết sự bất tiện của ClearCase
    • Năm 2008, tôi bắt đầu đóng góp patch cho Git và học được rất nhiều về việc đóng góp cho mã nguồn mở
    • Dù CLI của Git phức tạp, tôi không gặp nhiều khó khăn khi sử dụng
    • Ở công việc tiếp theo, tôi làm việc dựa trên một bản fork của Chromium và trở nên thành thạo trong việc dùng Git để giải quyết xung đột merge
    • Tôi thất vọng khi GitHub trở thành công cụ review mã chính của Git, nhưng vẫn cho rằng Git là lựa chọn tốt hơn Mercurial

  • Thật đáng ngạc nhiên khi Git mới chỉ 20 năm tuổi

    • Việc GitHub chưa đến 20 năm tuổi thì không quá bất ngờ, nhưng việc Git không tồn tại trước năm 2005 thì thật gây sốc
    • Tôi chưa từng dùng lựa chọn quản lý mã nguồn nào khác và tự hỏi liệu sau này mình có dùng hay không

  • Thật thú vị khi biết được bối cảnh lịch sử

    • ClearCase cũng dùng thuật ngữ "rebase", và có thể xác nhận nó đã được dùng từ năm 1999
    • Rebase của ClearCase mất rất nhiều thời gian, nên rebase gần như tức thì của Git thật đáng kinh ngạc

  • Mục tiêu là tạo ra một công cụ cơ sở dữ liệu lịch sử tarball hiệu quả, chứ không có ý định làm ra một hệ thống quản lý phiên bản

  • Tôi mới biết rằng có thể ký commit bằng ssh key

    • Tôi đã dùng cách ký bằng ssh để giải quyết một vấn đề trên OpenBSD
    • Có cảm giác như chưa hề trôi qua 20 năm kể từ khi chuyển các hạng mục công việc từ CVS sang Git

  • Cảm ơn vì bài viết hữu ích, và xin giới thiệu một kho lưu trữ có phần nhập môn về cấu trúc nội bộ của Git

  • Ý tưởng muốn viết một bài blog về cộng tác qua mailing list nghe rất thú vị

  • Trong số nhiều hệ thống quản lý mã nguồn, Git có tính khả dụng tệ nhất nhưng lại là hệ thống tôi yêu thích nhất