- Git, công cụ được các lập trình viên trên toàn thế giới sử dụng, đang thúc đẩy những thay đổi mang tính cấu trúc để chuẩn bị cho 10 năm tới, với các cải tổ trọng tâm xoay quanh bảo mật, khả năng mở rộng và tính dễ dùng
- Thay đổi dễ thấy nhất là chuyển từ SHA-1 sang SHA-256; dù việc sử dụng SHA-1 dự kiến sẽ bị cấm vào năm 2030, quá trình triển khai vẫn đang chậm do hệ sinh thái còn thiếu hỗ trợ
- Việc đưa vào Reftable đang được tiến hành nhằm quản lý hiệu quả hàng triệu tham chiếu, đồng thời giải quyết các ràng buộc của hệ thống tệp và vấn đề đồng thời
- Để cải thiện việc xử lý tệp dung lượng lớn, Large-object promisors và cơ sở dữ liệu đối tượng dạng plug-in đang được phát triển, và dần được tích hợp trong các phiên bản sau Git 2.50
- Chịu ảnh hưởng từ các hệ thống quản lý phiên bản mới nổi như Jujutsu, Git đang hướng tới hỗ trợ workflow hiện đại thông qua việc đơn giản hóa UI và bổ sung các lệnh mới
Sự cần thiết phải thay đổi của Git
- Kể từ khi ra mắt năm 2005, Git đã trở thành công cụ cốt lõi được hàng triệu kho lưu trữ và vô số script phụ thuộc trong suốt 20 năm
- Tuy nhiên, những thay đổi của môi trường như lỗ hổng bảo mật của SHA-1, sự gia tăng của các kho lưu trữ lớn và sự phổ biến của pipeline CI đã bộc lộ các giới hạn về cấu trúc
- Với cuộc tấn công SHAttered của CWI và Google vào năm 2017, khả năng xảy ra va chạm của SHA-1 đã được chứng minh
- Sự gia tăng năng lực tính toán GPU khiến các tổ chức lớn đã đạt tới mức có thể tính toán va chạm hàm băm
- Git cần lựa chọn tiến hóa dần dần thay vì tái thiết kế đột phá, và đang thúc đẩy thay đổi trong khi vẫn giữ tương thích với hệ sinh thái hiện tại
Chuyển đổi sang SHA-256
- Git 2.29 (tháng 10/2020) đã bổ sung hỗ trợ SHA-256, nhưng các nền tảng lớn như GitHub vẫn chưa hỗ trợ
- Git, Dulwich, Forgejo hỗ trợ đầy đủ; GitLab, go-git và libgit2 hiện ở giai đoạn hỗ trợ thử nghiệm
- SHA-1 được dùng cho mục đích kiểm tra tính toàn vẹn đơn thuần, nhưng toàn bộ hệ sinh thái như chữ ký, CI và script đều vận hành với giả định có khả năng chống va chạm
- Theo quy định của chính phủ và doanh nghiệp, việc loại bỏ SHA-1 được yêu cầu trước năm 2030, và SHA-256 dự kiến trở thành giá trị mặc định trong Git 3.0
- Để hỗ trợ quá trình chuyển đổi của hệ sinh thái, người dùng được khuyến khích tham gia bằng cách kiểm thử công cụ và yêu cầu hỗ trợ từ các forge
Đưa Reftable vào sử dụng
- Git hiện tại dùng cấu trúc loose reference lưu từng tham chiếu thành các tệp riêng lẻ
- Với các kho có hàng chục triệu tham chiếu, cách này kém hiệu quả và gây ra vấn đề phân biệt chữ hoa chữ thường của hệ thống tệp cùng sự không nhất quán do đồng thời
- Reftable là cấu trúc bảng dựa trên định dạng nhị phân, cho phép cập nhật nguyên tử và quản lý tham chiếu hiệu quả
- Trong trường hợp kho lưu trữ của GitLab có 20 triệu tham chiếu, tệp packed-refs hiện tại cần ghi lại toàn bộ 2GB
- Trong Git 3.0, Reftable sẽ trở thành backend mặc định, và người dùng được khuyến nghị dùng lệnh Git thay vì truy cập trực tiếp vào tệp
Cải thiện xử lý tệp dung lượng lớn
- Git hiệu quả trong nén tệp văn bản, nhưng khi chỉnh sửa tệp nhị phân, việc phải tái tạo toàn bộ đối tượng gây ra sự kém hiệu quả
- Theo phân tích của GitLab, 75% dung lượng kho lưu trữ là do các tệp nhị phân từ 1MB trở lên chiếm giữ
- Tính năng Large-object promisors cho phép lưu các đối tượng lớn trên kho từ xa riêng, rồi truyền qua CDN hoặc S3 API
- Việc triển khai giao thức đã hoàn tất trong Git 2.50~2.52, và hiện đã ở giai đoạn có thể sử dụng phía client
- Cơ sở dữ liệu đối tượng dạng plug-in dự kiến đưa vào định dạng lưu trữ chuyên cho tệp nhị phân để hỗ trợ lưu trữ gia tăng
- Git 2.53 đã đưa vào giao diện cơ sở dữ liệu đối tượng hợp nhất, còn bản chứng minh khái niệm (PoC) được kỳ vọng ở 2.54
Cải thiện giao diện người dùng
- Các lệnh Git từ lâu đã bị chỉ trích là phức tạp và thiếu nhất quán, trong khi Jujutsu (JJ) viết bằng Rust đang nổi lên như một lựa chọn thay thế
- Jujutsu cung cấp tự động sắp xếp lại lịch sử, xử lý xung đột như dữ liệu và cách tiếp cận coi commit như bản nháp
- Git đang dần đưa vào một phần ưu điểm của Jujutsu mà không phá vỡ workflow hiện có
- Trong Git 2.54, dự kiến sẽ bổ sung các lệnh
git history split và git history reword
- Trong tương lai, sẽ có thêm nhiều subcommand chỉnh sửa lịch sử được bổ sung
- Steinhardt nhấn mạnh rằng Git đang học hỏi thông qua cạnh tranh, và quá trình hiện đại hóa UI cùng nâng cao tính dễ dùng đang được triển khai
1 bình luận
Bình luận trên Hacker News
Git thực sự là một phần mềm tuyệt đẹp, nhưng cũng phơi bày nguyên vẹn kiểu phức tạp lấy lập trình viên làm trung tâm
Tôi từng thử dạy Git cho những người không làm phát triển phần mềm, và họ không thể tận dụng hết sức mạnh tinh vi của các tính năng đó
Các trang như Learn Git Branching là tài nguyên học tập tuyệt vời. Sẽ rất tốt nếu kiểu UX này được tích hợp vào trải nghiệm mặc định của Git — như các giá trị mặc định trực quan, luồng học tập theo từng bước
Gần đây, dùng các agent CLI như Claude, Codex, OpenCode thì có thể dễ dàng mang lại trải nghiệm đó. Nhưng nếu chính Git cung cấp lớp trừu tượng dễ tiếp cận hơn thì mọi thứ sẽ còn dễ hơn nhiều
Tôi rất mong chờ Git 3.0, nhưng đồng thời cũng đã sẵn sàng thất vọng ngay lập tức 😅
jjđã giúp ích rất nhiều cho người dùng Git. Nó cho thấy rằng một frontend VCS trực quan hơn là hoàn toàn khả thiTôi đã thấy ở GitLab có trường hợp tệp packed-refs 2GB bị ghi lại vài giây một lần, và tôi không hiểu nổi “rốt cuộc vì sao chuyện này lại xảy ra”
Việc lưu trữ các tệp lớn ở bên ngoài trông giống như thêm một bước tiến tới mô hình tập trung, nhưng lại đi ngược với triết lý thiết kế ban đầu của Git
Việc chuyển đổi để rời khỏi SHA1 đang mất quá nhiều thời gian
Hàm băm lẽ ra ngay từ đầu nên được thiết kế theo cấu trúc mô-đun hơn
Tôi nghĩ Git cần chức năng theo dõi giấy phép phần mềm theo từng commit
Ví dụ:
Co-Authored-By: Whatever LLM,License: WTFPL