Sự xuất hiện de Git 2.54 Điều này đánh dấu một bước tiến mới trong sự phát triển của hệ thống kiểm soát phiên bản được sử dụng rộng rãi nhất trên thế giới trong lĩnh vực phát triển phần mềm. Cộng đồng dự án, với hơn 130 người cộng tác trong chu kỳ này, đã tập trung vào việc đơn giản hóa các tác vụ thông thường mà không làm giảm đi sức mạnh vốn có của Git.
Trong số những tính năng mới có thể gây興味 nhất là một phương thức mới để viết lại lịch sử Nói một cách trực tiếp hơn, đó là khả năng cấu hình các hook dùng chung từ các tệp cấu hình chung và những cải tiến nội bộ nhằm mục đích tạo ra các kho lưu trữ nhanh hơn và dễ bảo trì hơn, đặc biệt là trong các dự án lớn hoặc dự án của doanh nghiệp.
Git 2.54: Tổng quan về phiên bản mới
Git 2.54 là phiên bản trung gian trên con đường hướng tới phiên bản 3.0 trong tương lai, nhưng nó mang đến những thay đổi ảnh hưởng đến công việc hàng ngày của nhiều nhà phát triển. Ví dụ, Lệnh thử nghiệm git history đã được phát hành.Được thiết kế cho các thao tác viết lại lịch sử đơn giản. Hơn nữa, hệ thống hook được mở rộng và hiện đại hóa, và giờ đây có thể được quản lý từ phần cài đặt; chiến lược bảo trì hình học hiện là mặc định.
Ngoài ra, các cải tiến cũng được tích hợp vào các lệnh đã biết như sau: git add -p, git replay, git status hoặc git rebaseCũng như những điều chỉnh đối với giao thức HTTP, cách hiển thị chữ ký GPG và hoạt động nội bộ của cơ sở dữ liệu đối tượng. Mặc dù nhiều tính năng mới này khá tiên tiến, nhưng tác động của chúng sẽ dễ nhận thấy trong các quy trình làm việc thông thường tại các doanh nghiệp, cơ quan hành chính công và các dự án mã nguồn mở có kho lưu trữ lớn.
Lệnh thử nghiệm mới git history: dễ dàng viết lại các commit
Một trong những bổ sung quan trọng trong Git 2.54 là lịch sử git, một lệnh vẫn đang trong giai đoạn thử nghiệm, được thiết kế để xử lý các trường hợp mà việc sử dụng rebase tương tác là không cần thiết. Cho đến nay, công cụ được sử dụng phổ biến nhất để sửa đổi lịch sử cục bộ là git rebase -iRất linh hoạt nhưng cũng phức tạp hơn và dễ khiến người dùng rơi vào tình trạng xung đột cần phải giải quyết thủ công.
với lịch sử git Đối với các nhiệm vụ cụ thể, cần tìm cách tiếp cận trực tiếp hơn: ví dụ, sửa lỗi chính tả Trong thông báo của một commit từ vài thay đổi trước đó, hoặc chia một commit đã trở nên quá lớn thành hai. Ý tưởng là cung cấp một cách thức có kiểm soát để điều chỉnh lịch sử mà không cần phải thiết lập toàn bộ cơ chế của một rebase tương tác với danh sách tác vụ và các bước trung gian.
Lệnh con `reword`: chỉnh sửa thông báo commit mà không ảnh hưởng đến cây thư mục làm việc.
Chế độ đầu tiên mà trật tự mới đang triển khai là git history reword <commit>Khi được gọi, Git sẽ mở trình soạn thảo do người dùng cấu hình với... thông báo cam kết được chỉ địnhĐiều này cho phép bạn chỉnh sửa trực tiếp. Khi bạn lưu và đóng trình chỉnh sửa, Git sẽ viết lại commit đó và tự động cập nhật các nhánh con của nó để trỏ đến phiên bản mới.
Điểm khác biệt chính so với thao tác rebase tương tác là: Lệnh `git history reword` không tác động đến cây làm việc hay chỉ mục.Nó chỉ cập nhật lịch sử. Điều này làm cho nó đặc biệt hữu ích trong môi trường tích hợp liên tục hoặc các kịch bản tự động, vì nó thậm chí có thể hoạt động trên các kho lưu trữ trống, điều thường thấy trong các máy chủ mã nội bộ của các công ty hoặc tổ chức nơi không có cây thư mục làm việc liên kết.
Lệnh con split: chia nhỏ một commit một cách tương tác
Chế độ thứ hai, git history split <commit>Lệnh này được thiết kế cho các trường hợp một commit duy nhất chứa các thay đổi cần được tách biệt. Khi được thực thi, Git sẽ hiển thị các hunk liên quan đến commit đó và cho phép bạn chọn hunk nào nên được trích xuất vào một commit cha mới, tương tự như cách hoạt động của lệnh `git extract`. git thêm -p khi quyết định thêm những đoạn mã nào vào mục lục.
Sau khi các đoạn mã được chọn, Git sẽ tạo ra một tệp Bản commit mới với các khối được chọn làm khối cha của khối gốc.Nó giữ lại các thay đổi chưa được chọn trong commit trước đó. Sau đó, nó viết lại các nhánh con để trỏ đến cấu trúc lịch sử mới. Một lần nữa, thao tác này chạy mà không làm thay đổi nội dung hiện tại của cây làm việc, giảm khả năng để lại kho lưu trữ ở trạng thái trung gian phức tạp.
Những hạn chế và khả năng tương thích với các quy trình làm việc khác
Để kiểm soát hành vi, Lệnh `git history` không hỗ trợ lịch sử có các commit hợp nhất. và từ chối tiếp tục nếu thao tác dẫn đến xung đột hợp nhất. Nó được thiết kế cho các điều chỉnh nhỏ, chứ không phải cho việc viết lại quy mô lớn như những gì thường được xử lý bằng các công cụ khác. git rebase -i hoặc các chiến lược xóa lịch sử mạnh mẽ hơn.
Về mặt nội bộ, bộ máy chỉ huy dựa vào cơ chế hoạt động của... git replayCông cụ này đã và đang được củng cố như một công cụ thử nghiệm để tái tạo các commit trên một base khác mà không cần chạm vào working tree. Một phần của công việc này bao gồm việc trích xuất logic đó vào một thư viện chung, để cả hai đều có thể sử dụng được. git history Các chức năng khác trong tương lai có thể được hưởng lợi từ một cơ sở hạ tầng có tính mô-đun cao hơn, dễ tự động hóa hơn thông qua các tập lệnh hoặc công cụ của bên thứ ba.
Các hook dựa trên cấu hình: chia sẻ và kết hợp các quy trình tự động hóa
Một tính năng mới đáng chú ý khác của Git 2.54 là khả năng... Định nghĩa các hook trực tiếp trong các tệp cấu hình., thay vì chỉ dựa vào các tập lệnh được đặt trong thư mục .git/hooks hoặc theo tuyến đường được chỉ định bởi core.hooksPathThay đổi này giúp việc chia sẻ các bản kiểm tra giữa các kho lưu trữ khác nhau trở nên dễ dàng hơn nhiều mà không cần phải sao chép tệp theo cách thủ công.
Cho đến nay, để áp dụng, ví dụ, một công cụ định dạng mã hoặc một công cụ phân tích bí mật trước mỗi lần commit trên nhiều dự án, cần phải sao chép tập lệnh hook vào từng kho lưu trữ hoặc sử dụng các công cụ quản lý hook bên ngoài. Với phương pháp mới, có thể định nghĩa móc trung tâm ~/.gitconfig hoặc trong một /etc/gitconfig và những điều này cần được áp dụng khi cần thiết.
Xác định các hook bằng cấu hình và nhiều lệnh cho mỗi sự kiện
Cú pháp mới dựa trên các khóa cấu hình kiểu. hook.<nombre>.command y hook.<nombre>.eventTham số đầu tiên cho biết lệnh nào sẽ được thực thi, và tham số thứ hai chỉ định cụ thể. Sự kiện hook nào kích hoạt nó?ví dụ như pre-commit hoặc một pre-pushVì đây là cấu hình tiêu chuẩn, các thiết lập này có thể cùng tồn tại ở các cấp độ khác nhau: người dùng, hệ thống hoặc kho lưu trữ.
Hơn nữa, Git hiện cho phép điều đó Nhiều hook được gán cho cùng một sự kiệnNói cách khác, bạn có thể định nghĩa, ví dụ, một công cụ kiểm tra cú pháp (linter) và một công cụ quét thông tin xác thực để chạy trên mỗi... pre-commitmà không cần phải tự tay kết hợp chúng thành một tập lệnh duy nhất. Git sẽ lặp qua các mục cấu hình theo thứ tự và thực thi từng lệnh, đồng thời vẫn duy trì hỗ trợ cho tập lệnh truyền thống. $GIT_DIR/hooks, và chương trình này tiếp tục chạy đến cuối để không làm hỏng các cấu hình đã thiết lập trước đó.
Quản lý, vô hiệu hóa và hiện đại hóa nội bộ các thiết bị kết nối.
Để kiểm tra xem những hook nào đang hoạt động và chúng đến từ đâu, lệnh sau được tích hợp sẵn. git hook listĐiều này cho thấy nguồn gốc của từng sản phẩm, một thông tin hữu ích khi quản lý. cấu hình tập trung Trong môi trường doanh nghiệp, nếu một kho lưu trữ cụ thể cần loại trừ một hook được kế thừa từ một tệp toàn cục, thì chỉ cần thiết lập là đủ. hook.<nombre>.enabled = falsemà không cần phải xóa hoặc sửa đổi cấu hình gốc.
Về mặt kỹ thuật, Git có... thống nhất và hiện đại hóa cách thức xử lý nhiều kết nối nội bộ của nó.Một số điểm tích hợp trước đây được quản lý bằng các tuyến đường tùy chỉnh, chẳng hạn như các hook cho pre-push, post-rewrite hoặc những người của receive-packHiện tại họ đang sử dụng API hook mới. Điều này không chỉ mang lại tính nhất quán mà còn giúp các môi trường tích hợp liên tục hoặc nền tảng tạo mã dễ dàng thích ứng với những thay đổi trong tương lai mà không cần phải viết lại các tích hợp cụ thể.
Bảo trì hình học như một chiến lược mặc định
Trong các phiên bản trước, Git đã giới thiệu cái gọi là chiến lược hình học trong git maintenanceĐược thiết kế để giảm chi phí đóng gói lại dữ liệu trong các kho lưu trữ lớn, chiến lược này phân tích các tệp đóng gói hiện có và tìm kiếm các tổ hợp tạo thành cấp số nhân theo số lượng đối tượng, nén nội dung của chúng mà không cần thực hiện thu gom rác toàn bộ mỗi lần.
Với Git 2.54, phương pháp này trở nên tùy chọn mặc định cho bảo trì thủ côngKhi nó chạy git maintenance run Nếu không chỉ định chiến lược, phương pháp hình học sẽ tự động được lựa chọn, thay vì trực tiếp sử dụng phương pháp cổ điển là... gc Nó cố gắng gom tất cả mọi thứ vào một gói duy nhất.
Trong thực tế, điều này có nghĩa là Các kho lưu trữ được duy trì hiệu quả hơn. Ngay từ đầu, điều này đặc biệt thú vị đối với các dự án có lịch sử lâu dài hoặc các tổ chức quản lý các kho lưu trữ đơn lẻ lớn. Chiến lược hình học kết hợp các gói tăng dần khi cần thiết và chỉ sử dụng đến một mức độ nhất định. gc Quá trình này hoàn tất khi nó thực sự hợp nhất mọi thứ vào một tệp packfile duy nhất. Trong quá trình này, biểu đồ commit, reflog và các cấu trúc phụ trợ khác được cập nhật liên tục.
Những người đã cấu hình maintenance.strategy = geometric Họ sẽ không nhận thấy bất kỳ thay đổi nào, vì sở thích đó được tôn trọng. Và những người muốn tiếp tục với phương pháp truyền thống có thể buộc chiến lược phải thực hiện gc cấu hình maintenance.strategy = gcnhờ đó duy trì tính tương thích với các dòng chảy bảo thủ hơn.
Cải tiến các lệnh tương tác và thử nghiệm
Bên cạnh các tính năng mới chính, Git 2.54 mang đến một loạt các thay đổi nhằm mục đích cải thiện trải nghiệm người dùng hàng ngàyđặc biệt là trong các lệnh được sử dụng tương tác để quản lý các thay đổi.
Những cải tiến trong git add -py new navigation options
Chế độ tương tác của git add -p và các lệnh liên quan nhận được nhiều cải tiến về khả năng sử dụng. Khi điều hướng giữa các khối bằng các phím J y KGit hiện hiển thị nếu một đoạn mã đã được chấp nhận hoặc bỏ qua trước đóTránh việc phải tự mình ghi nhớ từng quyết định.
Tùy chọn này cũng được thêm vào. --no-auto-advanceĐiều này làm thay đổi hành vi khi kết thúc xử lý các phần lớn của một tập tin. Thay vì tự động chuyển sang tập tin tiếp theo, phiên làm việc vẫn giữ nguyên ở tập tin hiện tại, cho phép bạn sử dụng... < y > Giúp bạn chuyển đổi giữa các tập tin một cách bình tĩnh hơn. Cách làm việc này hữu ích khi bạn muốn xem xét toàn bộ các thay đổi đã chọn trước khi xác nhận chúng.
git replay: cần có sự hoàn thiện hơn trong việc thực thi lại các commit.
Thứ tự thí nghiệm git replayTính năng được thiết kế để sao chép các commit lên một base mới mà không sửa đổi cây thư mục làm việc tiếp tục được nâng cấp. Trong phiên bản này, nó hiện thực hiện các thao tác sau: cập nhật nguyên tử các tham chiếu Theo mặc định, thay vì xuất ra các lệnh update-ref trên đầu ra tiêu chuẩn.
Ngoài ra, nó còn tích hợp một chế độ --revert cho phép Hoàn tác các thay đổi từ một loạt các commit.Nó có khả năng loại bỏ các commit trở nên trống rỗng trong quá trình xử lý và hiện hỗ trợ phát lại lịch sử về commit gốc. Những cải tiến này rất phù hợp với việc sử dụng... git history, dựa trên cùng một cơ sở hạ tầng để mang lại trải nghiệm an toàn hơn.
Tùy chọn mới – thêm trailer vào git rebase
Một điều chỉnh thú vị khác là việc bổ sung --trailer en cơ sở git rebasetận dụng logic của interpret-trailers para thêm cùng một đoạn trailer vào mỗi lần commit vượt quá giới hạn.Thay vì xây dựng các lệnh dài với -x và gọi đến git commit --amend --no-edit --trailer=...Bạn có thể trực tiếp chỉ định rơ moóc mong muốn khi khởi động chế độ chạy vượt.
Điều này giúp đơn giản hóa đáng kể các tác vụ lặp đi lặp lại như chèn các dòng chữ. Reviewed-by: hoặc các chú thích tương tự như một loạt các commit, điều khá phổ biến trong các quy trình đánh giá mã chính thức được sử dụng trong các nhóm làm việc phân tán.
Quản lý chữ ký và vận chuyển HTTP: hành vi tinh tế hơn
Về mặt giao tiếp mạng, Git 2.54 giới thiệu những thay đổi quan trọng trong việc xử lý phản hồi HTTP và trong việc giải thích các chữ ký mật mã liên quan đến các commit và tag.
Quản lý phản hồi HTTP 429 và khả năng cấu hình số lần thử lại.
Giao thức HTTP của Git học cách diễn giải chính xác các mã. 429 «Quá nhiều yêu cầu»Trước đây, khi máy chủ trả về lỗi 429, đó được coi là lỗi nghiêm trọng và thao tác thất bại. Bắt đầu từ phiên bản này, Git có thể thử lại yêu cầu trong khi vẫn giữ nguyên giá trị tiêu đề. Retry-After nếu có, hoặc sử dụng độ trễ có thể cấu hình thông qua tùy chọn mới. http.retryAfter.
Các điều chỉnh cũng được thêm vào. http.maxRetries y http.maxRetryTime, cho phép Kiểm soát số lần thử lại tối đa và tổng thời gian dành cho mỗi lần thử.Điều này rất hữu ích trong môi trường doanh nghiệp, nơi cần truy cập vào các máy chủ quá tải hoặc máy chủ có chính sách giới hạn yêu cầu nghiêm ngặt, giúp tối ưu hóa hoạt động. fetch y push Tăng khả năng phục hồi mà không gây ảnh hưởng xấu đến máy chủ.
Xử lý chữ ký GPG với khóa đã hết hạn
Về vấn đề bảo mật, một hành vi có khả năng gây hiểu nhầm đã được sửa chữa: khi một commit được ký bằng khóa GPG đã hết hạn, Git hiển thị chữ ký trong một màu đỏ đáng báo độngĐiều này cho thấy chữ ký không hợp lệ. Tuy nhiên, nếu chữ ký hợp lệ tại thời điểm đó, thì tính hợp lệ đó vẫn phải được duy trì ngay cả khi khóa đã hết hạn.
Git 2.54 điều chỉnh logic này và tiếp tục xem xét... Các chữ ký được thực hiện đúng cách trước khi khóa hết hạn đều hợp lệ.Điều này giúp tránh các cảnh báo không cần thiết. Nó cung cấp một bức tranh chính xác hơn về lịch sử của kho lưu trữ, điều này rất quan trọng đối với các dự án có vòng đời dài, chẳng hạn như phần mềm quản lý hành chính công hoặc thể chế được duy trì trong nhiều năm.
Các khả năng kiểm tra mới và tùy chỉnh lịch sử
Một số lệnh được thiết kế để khám phá lịch sử đã được cải tiến, giúp tăng tính linh hoạt và cho phép tạo ra các kết quả phù hợp hơn cho từng trường hợp.
`git log -L` tích hợp với cơ chế so sánh khác biệt tiêu chuẩn.
các tùy chọn git log -LChức năng cho phép theo dõi sự thay đổi của một loạt dòng trong một tệp cụ thể đã được lập trình lại để định tuyến đầu ra của nó thông qua... cơ chế so sánh Git tiêu chuẩnTrước đây, nó sử dụng đường dẫn riêng, điều này khiến nó không tương thích với nhiều tùy chọn hữu ích như... -S y -G (cái gọi là "cuốc"), hoặc với các định dạng vá khác nhau.
Với sự thay đổi được giới thiệu trong Git 2.54, -L trở nên tương thích với tìm kiếm nội dung nâng cao và định dạng khác biệtbao gồm --word-diff o --color-movedBằng cách này, đầu ra có thể được giới hạn ở một chức năng cụ thể và đồng thời được lọc chỉ những commit thêm hoặc xóa một ký hiệu cụ thể, điều này tạo điều kiện thuận lợi cho việc kiểm toán mã và phân tích hồi quy.
git blame với lựa chọn thuật toán khác biệt
Lệnh đổ lỗi, được dùng để xem commit nào đã thêm từng dòng vào một tập tin, học thêm một tùy chọn mới. --diff-algorithmĐiều này cho phép bạn lựa chọn giữa các thuật toán khác nhau, chẳng hạn như biểu đồ tần số, thuật toán kiên nhẫn hoặc thuật toán tối thiểu, khi tính toán sự phân bổ dòng.
Tùy thuộc vào loại thay đổi mà tệp tin đã trải qua, Việc lựa chọn thuật toán này thay vì thuật toán khác có thể mang lại kết quả rõ ràng hơn.Điều này giúp giảm thiểu nhiễu trong lịch sử mã nguồn hoạt động mạnh. Trong môi trường mà việc xem xét chi tiết được đánh giá cao, mức độ kiểm soát này có thể tạo ra sự khác biệt lớn khi điều tra xem ai đã đưa một khối mã cụ thể vào.
Tối ưu hóa lưu trữ và cơ sở dữ liệu đối tượng
Những thay đổi trong phiên bản này không chỉ giới hạn ở giao diện người dùng; mà còn có rất nhiều cải tiến đáng kể về cách thức hoạt động của Git. Tổ chức và truy cập dữ liệu nội bộĐiều này có tác động đặc biệt đáng kể đối với các kho lưu trữ lớn.
Chỉ số đóng gói đa lớp tăng dần và sự nén chặt
Các cuộc gọi chỉ số gia tăng đa gói (MIDX)Các tính năng đã được cải tiến trong các phiên bản trước, Git 2.54 giờ đây bao gồm hỗ trợ nén lớp. Cơ chế này kết hợp các lớp MIDX nhỏ hơn, cùng với các bitmap khả năng truy cập liên quan, để giữ cho chuỗi lớp có kích thước hợp lý.
Bước này rất quan trọng đối với Giúp triển khai MIDX tăng dần một cách thiết thực trong các kho lưu trữ có tuổi thọ dài.Ví dụ như các tổ chức lớn hoặc các dự án cộng đồng có lịch sử lâu đời. Việc nén các lớp giúp giảm độ phức tạp của tìm kiếm và cải thiện hiệu suất trong các hoạt động như... fetch, clone Kiểm tra một phần hoặc kiểm tra lịch sử.
Tái cấu trúc cơ sở dữ liệu đối tượng (ODB)
Về mặt nội bộ, một Tái cấu trúc sâu rộng API cơ sở dữ liệu đối tượng (ODB). Hiện nay, thiết kế backend dạng cắm ghép được sử dụng, trong đó các chức năng như read_object(), write_object() o for_each_object() Chúng được gửi đi bằng cách sử dụng con trỏ hàm theo nguồn gốc.
Mặc dù sự thay đổi này không thể nhận thấy ngay lập tức đối với người dùng cuối, nhưng nó đặt nền tảng cho... các hệ thống lưu trữ thay thế trong tương lai hoặc các cấu hình cơ sở dữ liệu đối tượng linh hoạt hơn. Đối với các công ty có yêu cầu tuân thủ quy định cụ thể hoặc tích hợp với hệ thống lưu trữ riêng của họ, tính mô-đun này có thể mở ra cánh cửa cho các giải pháp phù hợp hơn.
Cải tiến về trạng thái, bí danh, sao lưu dự phòng và các chi tiết khác.
Git 2.54 cũng tích hợp một số điều chỉnh, mặc dù nhỏ nhưng góp phần hoàn thiện việc sử dụng hàng ngày và thích ứng Git với nhiều ngữ cảnh ngôn ngữ và mạng khác nhau.
git status và so sánh với một số nhánh từ xa
Lệnh trạng thái git ra mắt tùy chọn cấu hình status.compareBranchesTheo mặc định, lệnh này hiển thị sự so sánh giữa nhánh hiện tại và nhánh chính đã được cấu hình, một kết quả điển hình như sau: origin/mainVới tùy chọn mới này, bạn có thể yêu cầu so sánh với nhánh đã được đẩy lên, hoặc so sánh với cả hai cùng một lúc.
Chức năng này được thiết kế để dòng chảy hình tam giácĐiều này khá phổ biến khi làm việc với các nhánh (forks): bạn có thể tải xuống từ kho lưu trữ từ xa chính thức và gửi các thay đổi đến một kho khác, luôn giữ rõ ràng số lượng commit phân tách mỗi nhánh, giúp giảm thiểu những bất ngờ khi đồng bộ hóa kho lưu trữ.
Bí danh với các ký tự quốc tế
Cho đến nay, các bí danh Git chỉ giới hạn ở các ký tự chữ số ASCII và dấu gạch ngang, ngăn cản việc sử dụng tên trong các ngôn ngữ khác có dấu hoặc bảng chữ cái khác nhau. Cú pháp mới hỗ trợ hầu hết mọi ký tự ngoại trừ xuống dòng và ký tự NUL. Việc so khớp được thực hiện dưới dạng byte thô và phân biệt chữ hoa chữ thường. Hơn nữa, hệ thống tự động hoàn thành của shell đã được cập nhật để xử lý các bí danh này, giúp Git dễ sử dụng hơn trong các nhóm đa ngôn ngữ.
Git backfill thực tế hơn trong trường hợp sao chép một phần.
Lệnh thử nghiệm git backfillLệnh dùng để tải xuống các blob bị thiếu trong các bản sao một phần cũng đang được củng cố. Trước đây, lệnh này luôn truy xuất các blob có thể truy cập được từ HEAD trải rộng khắp toàn bộ cây thư mục, điều này có thể trở nên quá mức đối với các kho lưu trữ đặc biệt lớn.
Git 2.54 bổ sung hỗ trợ cho xem xét các lập luận và đặc tả đường dẫnđể việc bổ sung dữ liệu có thể được giới hạn trong một phạm vi lịch sử nhất định (ví dụ, main~100..main) hoặc đến một số tuyến đường cụ thể (git backfill -- '*.c'), bao gồm cả các mẫu ký tự đại diện. Điều này giúp việc quản lý trở nên dễ dàng hơn nhiều khi bạn chỉ cần hoàn thiện lịch sử của một phần cụ thể trong mã.
Các điều chỉnh và cải tiến chi tiết khác
Nhật ký thay đổi của Git 2.54 bao gồm một danh sách dài các cải tiến nhỏ. Trong số đó có một bản sửa lỗi cho thuật toán so sánh khác biệt. biểu đồĐiều này giúp ngăn chặn giai đoạn nén di chuyển các nhóm thay đổi theo cách phá vỡ các đường neo đã chọn, tạo ra sự khác biệt sạch hơn và ít dư thừa hơn.
Các công cụ như git config list và điều này đang dần trở thành cách thức chính thức để liệt kê cấu hình. git merge-file Sau đó, hệ thống sẽ tôn trọng cấu hình hiện có ngay cả khi nằm ngoài kho lưu trữ, cùng với một số tiện ích liên quan khác. git send-emailĐiều này giúp tăng cường hỗ trợ cho chứng chỉ máy khách và xử lý cẩn thận hơn các bộ ký tự do người dùng lựa chọn.
Quá trình phát triển của Git tiếp tục diễn ra với tốc độ tốt với phiên bản 2.54, phiên bản này kết hợp... cải thiện rõ rệt cho người dùng, giống như trật tự mới git history hoặc các hook có thể cấu hình, đòi hỏi nhiều công sức vào cơ sở hạ tầng nội bộ của hệ thống. Tất cả những điều này cho thấy một hệ sinh thái mạnh mẽ và linh hoạt hơn, được chuẩn bị tốt hơn cho những thách thức của các kho lưu trữ ngày càng lớn và các nhóm làm việc đa dạng hơn.
