Git 2.56 sắp ra mắt và triển vọng về Git 3.0

Hệ thống quản lý mã nguồn Git đang chuẩn bị bước vào một giai đoạn chuyển mình quan trọng. Bản phát hành Git 2.56 dự kiến ra mắt vào cuối tháng 9/2026 với hơn 700 commit không phải merge, mang đến nhiều cải tiến đáng giá nhưng chưa thay đổi căn bản trải nghiệm của người dùng. Điều đáng bàn hơn nằm ở bản phát hành kế tiếp, có thể sẽ là Git 3.0 mà cộng đồng đã chờ đợi từ lâu.

Những điểm mới trong Git 2.56

Một trong những tính năng đáng chú ý nhất của Git 2.56 là lệnh git history drop, bổ sung vào bộ công cụ git history vẫn còn ở trạng thái thử nghiệm:

$ git history drop commit-id

Lệnh này cho phép loại bỏ một commit cụ thể khỏi lịch sử của nhánh hiện tại bằng cách phát lại toàn bộ các commit được thêm sau đó. Đây là cách đơn giản hơn để xóa một commit gây lỗi. Tuy nhiên, công cụ này vẫn từ chối hoạt động nếu lịch sử chứa các merge commit, khiến nó chưa dùng được cho nhiều kho mã nguồn thực tế.

Bên cạnh đó, lệnh git status giờ đây sẽ gợi ý dùng git pull để cập nhật một nhánh đang chậm hơn nhánh mà nó theo dõi. Lệnh git refs cũng có thêm nhiều subcommand mới như create, delete, update và rename — những lệnh này, khá bất ngờ với Git, làm đúng như tên gọi của chúng.

Một số tinh chỉnh nhỏ nhưng hữu ích:

• Tùy chọn --delete-merged mới của git branch sẽ xóa các nhánh cục bộ đã được hợp nhất vào nhánh theo dõi từ xa.
• Việc xóa nhánh bằng git branch -d sẽ thất bại kèm thông báo hữu ích nếu nhánh đó đang được dùng cho quá trình bisect.
• Các nỗ lực khóa file cấu hình sẽ được thử lại khi gặp lỗi, tránh phiền toái khi nhiều lệnh cùng sửa file một lúc.
• git add có tùy chọn --resolved mới, chỉ thêm các file đã giải quyết xong xung đột merge và sẽ dừng lại nếu phát hiện dấu hiệu xung đột còn sót.

Nhìn chung, 2.56 là một bản phát hành vững chắc, nhưng cũng cho thấy dấu hiệu của một dự án đang dành nhiều công sức quan trọng cho tương lai.

Sau 2.56 sẽ là gì?

Đầu tháng 9, người bảo trì Git là Junio Hamano đã hỏi cộng đồng rằng bản phát hành tiếp theo nên là gì. Liệu có nên tung ra Git 3.0 mà cộng đồng đã hướng tới từ lâu, khép lại năm bằng một dấu ấn đáng nhớ? Hay vẫn cần thêm một hoặc vài bản 2.x nữa trước khi 3.0 có thể ra đời?

Đây là câu hỏi quan trọng, bởi Git 3.0 sẽ chứa nhiều thay đổi phá vỡ tương thích khiến người dùng phải cân nhắc kỹ trước khi nâng cấp. Đáng kể nhất là việc chuyển sang dùng hàm băm SHA-256 mặc định thay cho SHA-1 mà Git đã dùng từ thuở ban đầu.

SHA-1 từ lâu đã bị đánh giá là yếu, điều này đáng lo với những ứng dụng như Git. Hàm băm được dùng để định danh mọi đối tượng (file, cây thư mục, commit) trong kho Git và để xác minh chuỗi commit dẫn tới bất kỳ thời điểm nào. Nếu SHA-1 bị phá vỡ, kẻ xấu có thể sửa đổi lịch sử kho mã nguồn theo cách khó hoặc không thể phát hiện.

Git đã tích hợp các biện pháp phòng vệ trước những cuộc tấn công SHA-1 đã biết, và ít ai tỏ ra lo ngại nghiêm trọng về nguy cơ bị xâm phạm hiện nay. Dẫu vậy, việc chuyển sang hàm băm an toàn hơn vẫn rất hợp lý.

Hỗ trợ SHA-256 ở dạng không thử nghiệm đã có trong Git từ phiên bản 2.42 năm 2023, nhưng một số phần keo kết nối với các kho cũ vẫn mất nhiều thời gian hơn.

Trở ngại lớn nhất khiến các nhà phát triển Git chưa mặc định dùng SHA-256 là mức hỗ trợ ở các nền tảng lưu trữ lớn. GitLab đã hỗ trợ từ năm 2024, Forgejo cũng vậy. Nhưng chú voi còn thiếu trong phòng này là GitHub — việc phát hành một phiên bản Git tạo ra các kho không tương thích với GitHub là triển vọng đáng lo.

Những rào cản kỹ thuật cần vượt qua

Vẫn chưa rõ khi nào GitHub có thể bổ sung hỗ trợ này, nhưng đáng chú ý là brian m. carlson, nhân viên GitHub và là nhà phát triển chủ chốt đứng sau quá trình chuyển đổi SHA-256, đã phản hồi câu hỏi của Hamano rằng tin tức về chủ đề này sắp có, và việc bản phát hành tới là 3.0 có thể là lựa chọn tốt nhất.

Carlson cũng đã đề xuất thêm một thay đổi trước khi 3.0 ra mắt. Git tuy luôn quản lý các số thập lục phân (cụ thể là object ID) dưới dạng chuỗi chữ thường, nhưng vẫn chấp nhận ID chữ hoa. Điều này dẫn tới tình huống hai ID trông khác nhau (ví dụ f00f00 và F00F00) thực ra lại là một. Có vẻ như các lỗi và lỗ hổng bảo mật đã nảy sinh từ sự nhập nhằng này, nên carlson muốn thay đổi hành vi của Git để chỉ chấp nhận ID chữ thường.

Một thay đổi quan trọng khác đang chờ Git 3.0 là việc chuyển sang cơ chế "reftable". Một reference (thường gọi là "ref") trong Git là liên kết giữa một tên và một đối tượng trong kho — nhánh, tag và remote đều là ref. Git hiện lưu mỗi ref thành một file dưới .git/refs/. Nếu kho có nhánh tên foo, sẽ có file .git/refs/heads/foo chứa ID của commit ở đầu nhánh đó.

Cơ chế này hoạt động được, nhưng ngày càng kém hiệu quả khi số lượng ref tăng lên. Theo tài liệu reftable của dự án, kho Android chứa hơn 800.000 ref. Ở quy mô đó, việc tra cứu ref hoặc xác định xem có ref nào trỏ tới một commit cụ thể hay không có thể là thao tác rất tốn kém.

Git 2.45 đã thêm reftable như một cách lưu trữ ref hiệu quả hơn — một file nhị phân được tối ưu cả về dung lượng lẫn tốc độ truy cập. Kể từ đó, có thể tạo kho dùng reftable thay vì cơ chế dựa trên file cũ, nhưng đây chưa bao giờ là mặc định.

Việc chuyển sang reftable về lý thuyết không gây hậu quả rõ rệt nào cho người dùng Git (ngoài hiệu năng tốt hơn), nhưng có thể là vấn đề với người dùng các phần mềm khác truy cập kho Git. Trong email của mình, carlson đã đề cập libgit2 như một mối lo tiềm tàng.

Các thư viện và ngôn ngữ liên quan đã sẵn sàng

Hóa ra libgit2 sẽ không phải là trở ngại. Patrick Steinhardt cho biết ông đã thêm hỗ trợ reftable vào libgit2, và hỗ trợ SHA-256 đã được bật mặc định từ tháng 8. Vậy nên libgit2 có vẻ đã sẵn sàng cho quá trình chuyển đổi Git 3.0.

Cuối cùng, như carlson đã đề cập, còn có câu hỏi về Rust. Dự án đã thêm một số hỗ trợ thử nghiệm cho mã viết bằng Rust, nhưng vẫn ngần ngại biến Rust thành bắt buộc để build Git. Điều này cũng được kỳ vọng sẽ thay đổi trong bản 3.0; sau đó, bất kỳ nền tảng nào không có trình biên dịch Rust hoạt động sẽ không thể nâng cấp.

Sau khi liệt kê các mối lo này, carlson cho rằng chúng có lẽ không nên cản trở việc phát hành 3.0:

Tôi nghĩ bất kỳ ai chưa tiến xa đến mức cực kỳ trong việc hỗ trợ SHA-256 (và reftable, với phần mềm làm việc với kho cục bộ) thì có lẽ không đáng để cân nhắc. JGit và Gitoxide đều đã được thông báo rằng SHA-256 sẽ có trong Git 3.0 ít nhất một năm trước.

Điều này dẫn tới kết luận của ông rằng nhiều khả năng việc đặt tên bản phát hành tiếp theo là 3.0 sẽ là lựa chọn tốt nhất.

Điều gì thực sự sẽ xảy ra?

Hiện vẫn chưa có thông báo chính thức, mọi thứ đang chờ quyết định của Hamano. Như ông nói: "đây không phải là một cuộc thi về độ phổ biến, cũng chẳng phải một nền dân chủ". Tuy nhiên, gần hai tuần kể từ khi câu hỏi được đăng, chưa có phản đối mạnh mẽ nào với việc bước vào kỷ nguyên 3.x và bỏ lại phía sau một số quyết định thiết kế ban đầu của Git — dù đương nhiên, các kho dùng SHA-1 và không có reftable vẫn sẽ được hỗ trợ đầy đủ.

Nếu Git 3.0 không ra mắt trong năm 2026, gần như chắc chắn nó sẽ xuất hiện ngay sau đó. Với cộng đồng lập trình viên Việt Nam đang ngày càng tham gia sâu vào các dự án mã nguồn mở toàn cầu, việc theo dõi những thay đổi này là điều cần thiết để chuẩn bị cho quá trình nâng cấp hạ tầng phát triển trong thời gian tới.