Những điểm mới đáng chú ý trong Git 2.56

Dự án mã nguồn mở Git vừa phát hành Git 2.56. Dưới đây là góc nhìn của GitHub về một số tính năng và thay đổi thú vị nhất được giới thiệu kể từ lần cập nhật trước.

28 tháng 9, 2026

8 phút

• Chia sẻ:

Dự án mã nguồn mở Git vừa phát hành Git 2.56.0 với các tính năng và bản sửa lỗi từ hơn 104 cộng tác viên, trong đó có 39 người mới. Lần cuối chúng ta cập nhật về những thay đổi mới nhất trong Git là khi phiên bản 2.55 được phát hành.

Để chào mừng bản phát hành mới nhất này, dưới đây là góc nhìn của GitHub về một số tính năng và thay đổi thú vị nhất được giới thiệu kể từ lần cập nhật trước.

Staging các xung đột đã giải quyết mà không cần stage mọi thứ khác

Việc giải quyết xung đột khi merge có hai phần riêng biệt. Đầu tiên, bạn chỉnh sửa cây làm việc (working tree) cho đến khi mỗi đường dẫn bị xung đột chứa kết quả bạn muốn. Sau đó, bạn stage các đường dẫn đó để báo cho Git biết rằng xung đột đã được giải quyết.

Giả sử một xung đột merge xảy ra trong recipe.txt, trong khi notes.txt chứa một chỉnh sửa cục bộ không liên quan.

Bước thứ hai nghe có vẻ đơn giản, nhưng các lệnh hiện có khiến bạn dễ dàng stage nhiều hơn dự định. `git add -u` cập nhật mọi đường dẫn đã theo dõi (tracked path) bị sửa đổi. Trong quá trình merge, điều đó có thể bao gồm các thay đổi cục bộ không liên quan đến xung đột. Nó cũng có thể stage một tệp vẫn còn chứa các dấu hiệu xung đột nếu bạn vô tình bỏ sót.

Git 2.56 cung cấp một quy trình làm việc an toàn hơn:

$ git add --resolved
fatal: the following paths still have conflict markers:
        recipe.txt

$ # Edit recipe.txt and remove the conflict markers.
$ git add --resolved
$ git status --short
 M notes.txt
M  recipe.txt

Chế độ `git add --resolved` mới được thiết kế đặc biệt cho bước này. Nó chỉ xem xét các đường dẫn hiện chưa được merge trong index. Trước khi stage bất cứ thứ gì, nó quét các tệp thông thường chưa được merge để tìm các dấu hiệu xung đột còn sót lại. Nếu tìm thấy, nó sẽ báo cáo các đường dẫn bị ảnh hưởng và giữ nguyên index.

Hai cột trong `git status --short` phân biệt các thay đổi đã stage và chưa stage. recipe.txt được stage là đã giải quyết, trong khi thay đổi không liên quan trong notes.txt vẫn ở trạng thái chưa stage.

Bạn cũng có thể truyền một pathspec để giới hạn các đường dẫn chưa merge nào được xem xét. Kiểm tra dấu hiệu "tất cả hoặc không có gì" vẫn áp dụng trong lựa chọn đó: nếu bất kỳ tệp thông thường nào được chọn chứa dấu hiệu xung đột, Git sẽ không stage bất kỳ tệp nào trong số đó. Các tệp bị xóa đã giải quyết và xung đột nhị phân không có dấu hiệu văn bản, vì vậy Git có thể stage chúng bình thường.

Điều này cố tình hẹp hơn so với `git add -u` hoặc `git add -A`. `--resolved` không thể kết hợp với cả hai chế độ trên và nó bỏ qua các tệp đã theo dõi chưa từng bị xung đột. Điều đó làm cho nó trở thành một rào chắn an toàn hữu ích cho quy trình làm việc của người bảo trì, nơi quá trình merge có thể bắt đầu với các thay đổi cục bộ không liên quan đã tồn tại từ trước.

[nguồn, thảo luận]

Ngừng tìm kiếm lịch sử khi không còn merge base nào có thể tồn tại

Nhiều thao tác Git cần tìm (các) tổ tiên chung tốt nhất của hai commit. Các lệnh merge sử dụng chúng làm điểm bắt đầu để kết hợp các thay đổi, trong khi diff ba dấu chấm sử dụng tổ tiên chung tốt nhất để quyết định nơi công việc của một nhánh chủ đề bắt đầu. Các máy chủ lưu trữ kho lưu trữ thực hiện tính toán tương tự cho diff của pull request, kiểm tra khả năng merge, phạm vi đánh giá và các so sánh khác.

Git tìm các tổ tiên chung này bằng cách đi ngược lại từ cả hai đầu. Hãy tưởng tượng việc tô màu các commit có thể truy cập được từ một phía là màu xanh dương và các commit từ phía kia là màu đỏ. Một commit được cả hai màu chạm tới là một ứng viên merge-base.

Tìm một ứng viên là chưa đủ. Các merge chéo (criss-cross merges) có thể tạo ra nhiều merge base, không cái nào là tổ tiên của cái kia, vì vậy Git phải tiếp tục đi cho đến khi biết rằng nó đã tìm thấy tất cả. Nhưng quy tắc dừng cũ có thể tiếp tục xử lý một chuỗi dài các lịch sử cũ kỹ, vốn đã chung sau khi một merge base khác trở nên không thể tồn tại.

Git 2.56 theo dõi bao nhiêu commit trong hàng đợi vẫn được tô màu độc quyền bởi mỗi phía. Việc triển khai có các biện pháp bảo vệ bổ sung xung quanh quy tắc này, nhưng ở mức độ cao, khi một phía độc quyền đã cạn kiệt, không có điểm gặp gỡ mới nào có thể xuất hiện. Git có thể dừng lại trong khi vẫn trả về mọi merge base.

Sự khác biệt có thể rất đáng kể khi các nhánh phụ cũ đã được merge vào một lịch sử dài hơn nhiều. Trong một trường hợp monorepo thực tế, thời gian duyệt giảm từ 0,68 giây xuống 0,01 giây. Các đánh giá thực tế trên hai monorepo lớn cho thấy nhiều trường hợp nhanh hơn khoảng 70 lần ở một kho và cải thiện trung bình khoảng 20 lần ở kho kia.

Chuỗi thay đổi cuối cùng cũng đã sửa một trường hợp hiệu suất lâu đời của Linux-kernel. Với commit-graph v2 mặc định của Git, lệnh `git merge-base --all v4.8 v4.9` giảm từ 167.441 bước duyệt và 0,29 giây xuống còn 3.887 bước và 0,01 giây.

[nguồn]

Làm cho việc repack theo đường dẫn (path-walk) trở nên thiết thực cho máy chủ

Khi Git repack một kho lưu trữ, nó tìm kiếm các đối tượng tương tự có thể được lưu trữ hiệu quả dưới dạng delta. Việc tìm kiếm truyền thống nhóm các ứng viên bằng cách sử dụng băm tên. Thay vào đó, repack theo đường dẫn (path-walk) truy cập các đối tượng theo vị trí của chúng trong cây, đưa các phiên bản của cùng một đường dẫn lại gần nhau và thường tìm thấy các mối quan hệ delta tốt hơn nhiều.

Tiềm năng tiết kiệm dung lượng lưu trữ là rất đáng kể. Trong một bài kiểm tra hiệu năng sử dụng bản clone gần đây của kho lưu trữ Fluent UI và buộc Git tính toán lại delta, một bản repack bitmapped thông thường tạo ra gói 558,5 MB. Repack với `--path-walk` tạo ra gói 164,4 MB, nhỏ hơn khoảng 71%.

Nhưng các máy chủ lưu trữ kho lưu trữ cần nhiều hơn là các gói nhỏ. Chúng thường sử dụng reachability bitmap để trả lời các truy vấn liệt kê đối tượng nhanh chóng, và một số sử dụng delta island để ngăn các đối tượng trong một nhóm ref phụ thuộc vào các đối tượng chỉ có sẵn trong nhóm khác. Repack theo đường dẫn không tương thích với cả hai, hạn chế nơi có thể triển khai các cải tiến lưu trữ của nó.

Git 2.56 loại bỏ hai hạn chế đó. Một bản repack theo đường dẫn hiện có thể chọn các commit cho một bitmap mới. Các lệnh `git pack-objects` sau đó có thể sử dụng lại bitmap hiện có khi trả lời yêu cầu, và chỉ quay lại path-walk khi cần thiết.

Path-walk hiện cũng thực hiện việc quản lý cần thiết cho delta island: lan truyền tư cách thành viên island qua các commit và cây trước khi chọn cơ sở delta. Điều đó cho phép các máy chủ duy trì các quy tắc cô lập của chúng trong khi thử nghiệm với biểu diễn trên đĩa nhỏ hơn của path-walk.

Những thay đổi này không kích hoạt repack theo đường dẫn theo mặc định. Thay vào đó, chúng loại bỏ hai rào cản áp dụng quan trọng, giúp các máy chủ kho lưu trữ lớn có thể đánh giá mức tiết kiệm dung lượng mà không cần từ bỏ việc phục vụ nhanh nhờ bitmap hoặc các ràng buộc delta-island.

[nguồn, nguồn]

Phần nổi của tảng băng chìm…

Đó chỉ là một vài trong số những thay đổi trong Git 2.56. Dưới đây là một số tính năng mới và cập nhật khác đáng chú ý.

• Lệnh `git history` thử nghiệm tiếp tục phát triển. Git 2.54 đã giới thiệu nó với `reword` và `split`, và Git 2.55 đã thêm `fixup`. Git 2.56 bổ sung: `$ git history drop <commit>`. Lệnh này xóa commit đã chọn và phát lại các hậu duệ của nó lên trên cha của commit đó. Nếu HEAD di chuyển, Git cập nhật index và cây làm việc trong khi vẫn bảo toàn các thay đổi cục bộ không liên quan. Nó sẽ hủy bỏ nếu việc phát lại một hậu duệ gây xung đột hoặc ghi đè lên một thay đổi cục bộ. Lệnh này vẫn đang trong giai đoạn thử nghiệm, không thể hoạt động trên lịch sử chứa các commit merge, và không thể drop một commit gốc hoặc commit merge. [nguồn]

• Các lệnh ghi tham chiếu (reference-writing) trước đây thường nằm rải rác giữa `git update-ref`, `git symbolic-ref` và các công cụ cấp thấp (plumbing) khác. Git 2.56 tiếp tục hợp nhất việc quản lý tham chiếu cấp thấp vào bộ công cụ `git refs`: $ git refs create refs/heads/topic <new-value> $ git refs update refs/heads/topic <new-value> [<old-value>] $ git refs delete refs/heads/topic [<old-value>] $ git refs rename refs/heads/old refs/heads/new Các giá trị cũ tùy chọn cung cấp cơ chế bảo vệ "so sánh và thay thế" (compare-and-swap) cho các thao tác cập nhật và xóa. Đây là các lệnh cấp thấp có chủ đích. Cụ thể, `git refs rename` di chuyển tham chiếu và reflog của nó, nhưng không thực hiện các điều chỉnh cấu hình nhánh như `git branch -m` làm. [nguồn]

• Việc dọn dẹp các nhánh chủ đề (topic branches) cục bộ sau khi công việc của chúng đã được đưa lên upstream có thể bao gồm việc so sánh từng nhánh với nhánh theo dõi từ xa (remote-tracking branch) đã được cấu hình. Git 2.56 bổ sung một dạng lệnh xử lý hàng loạt: $ git branch --delete-merged 'origin/*' 'topic-*' --dry-run Trong lệnh này, `origin/*` khớp với các nhánh có upstream nằm dưới `origin`, `topic-*` giới hạn các ứng viên là những tên nhánh cục bộ bắt đầu bằng `topic-`, và `--dry-run` liệt kê những gì sẽ bị xóa mà không thực hiện xóa thực tế. Khi chạy mà không có `--dry-run`, Git chỉ xóa các nhánh có phần đỉnh (tip) nằm trong phạm vi có thể truy cập được từ upstream tương ứng của chúng. Các nhánh đang được checkout trong worktree, các nhánh thiếu upstream và một số cấu hình push mơ hồ sẽ bị bỏ qua. `branch.<name>.deleteMerged = false` có thể bảo vệ một nhánh khỏi việc dọn dẹp hàng loạt. [nguồn]

Bài gốc còn tiếp — xem tiếp tại bài gốc ↗