Git chưa sẵn sàng cho làn sóng AI trong lập trình

Git chưa sẵn sàng cho làn sóng AI trong lập trình

Sự gia tăng ồ ạt của các tác nhân AI (AI agents) đang đẩy GitHub đến giới hạn và đặt ra thách thức lớn cho hệ thống kiểm soát phiên bản Git truyền thống.

GitHub quá tải trước sự bùng nổ của AI

Tháng trước, Mitchell Hashimoto, đồng sáng lập HashiCorp, đã công khai tuyên bố chuyển dự án giả lập terminal mã nguồn mở phổ biến Ghostty của mình khỏi GitHub. GitHub vận hành dịch vụ lớn nhất thế giới được xây dựng trên hệ thống kiểm soát phiên bản phân tán Git do Linus Torvalds tạo ra.

Từng là một người dùng nhiệt thành, Hashimoto đã trở nên thất vọng vì sự gián đoạn dịch vụ và các yêu cầu kéo (pull requests) ngày càng chậm trễ. "Đây không còn là nơi cho những công việc nghiêm túc nếu nó chặn bạn ra ngoài hàng giờ mỗi ngày, mỗi ngày," ông viết. Tuy nhiên, Hashimoto đã nhanh chóng bảo vệ Git: "Vấn đề không phải là Git, mà là cơ sở hạ tầng chúng ta dựa vào xung quanh nó: các vấn đề (issues), PRs, Actions, v.v."

Nhiều người đã đổ lỗi cho hiệu suất của GitHub cho Microsoft, công ty đã mua lại nền tảng này vào năm 2018. Nhưng công bằng mà nói, chính GitHub đang phải trải qua lượng truy cập lớn hơn nhiều so với dự kiến nhờ sự gia tăng của các pull requests do AI tạo ra.

Năm 2025, GitHub ghi nhận mức tăng trưởng 206% so với cùng kỳ năm trước đối với các dự án do AI tạo ra, được đo lường thông qua việc sử dụng các tập lệnh Bash shell - một cách phổ biến để chạy các tác nhân. Và mã AI nhiều hơn đồng nghĩa với việc lỗi nhiều hơn. Nghiên cứu từ GitClear cho thấy mã do AI tạo ra tạo ra 10,83 vấn đề trên mỗi pull request, so với 6,45 đối với loại mã do con người tạo ra theo cách truyền thống.

Lực lượng lao động dựa trên tác nhân mới của chúng ta đang đặt ra những câu hỏi lớn về cách toàn bộ vòng đời phát triển phần mềm (SDLC) nên phát triển như thế nào, và liệu Git có nên đi cùng hay không.

Cần một luồng làm việc liên tục

"Các tác nhân đang thúc đẩy chúng ta hướng tới một luồng liên tục," Peco Karayanev, đồng sáng lập của nhà cung cấp nền tảng DevOps Autoptic, cảnh báo. Autoptic kết nối các triển khai dựa trên Git với các công cụ quan sát để sửa lỗi tự động dựa trên tác nhân. Toàn bộ cơ sở người dùng của Autoptic hoạt động trên một dạng thức nào đó của Git, tự chế hoặc từ nhà cung cấp dịch vụ như GitLab.

Cho thấy quy mô và độ lớn của các thay đổi trên các kho chứa (repos), "chúng ta cần git bắt đầu hoạt động ở chế độ liên tục hơn," Karayanev viết trong một cuộc phỏng vấn qua email.

Các thao tác Git, đặc biệt khi được sử dụng trong các triển khai tự động kiểu GitOps, vẫn cần được quản lý bởi con người. Các bản cập nhật, cam kết (commits), đẩy (pushes), hợp nhất (merges) thường bị buộc vào các chuỗi tập hợp "dừng/chạy", nơi ai đó phải nhấn phím enter trên bàn phím vài lần để tiếp tục quy trình làm việc, Karayanev lưu ý. Mô hình này có thể không duy trì được khi các tác nhân bắt đầu được ưu tiên.

GitButler: Một "quản gia" cho Git

Luôn có những chỉ trích dành cho Git, đặc biệt là từ những người sử dụng công cụ này hàng ngày.

Có thể không có phần mềm nào khác được chấp nhận rộng rãi như vậy nhưng lại khó hiểu đến thế. Torvalds và các nhà phát triển nhân Linux khác đã xây dựng Git vào năm 2005 sau sự thất vọng khi cố gắng nhét mã Linux vào công cụ BitKeeper thương mại. Linux, một dự án nhóm quy mô toàn cầu khổng lồ, đòi hỏi một hệ thống kiểm soát phiên bản phân tán có khả năng hỗ trợ phát triển phi tuyến tính của hàng nghìn nhánh song song.

Giống như bất kỳ hệ thống phân tán nào, Git có thể khó hiểu. Một trong những đồng sáng lập của GitHub, Scott Chacon, đã đồng viết một cuốn sách về cách sử dụng Git (Pro Git năm 2009) và ông vẫn thấy mình đôi khi bị bối rối bởi hệ thống kiểm soát phiên bản này.

Vẫn còn những "góc cạnh sắc nhọn" đối với Git, Chacon chia sẻ với The Register. "Có nhiều thứ mà nó không làm tốt lắm từ góc độ khả năng sử dụng," ông nói.

Chacon đã đồng sáng lập GitButler như một cách để "tư duy lại lớp vỏ" (porcelain) của Git, nhằm làm cho Git phù hợp hơn với các quy trình làm việc hiện đại. (Tháng trước, GitButler đã nhận được 17 triệu đô la vốn đầu tư mạo hiểm).

Hãy tưởng tượng GitButler như một khách hàng Git siêu cấp. Nó cho phép nhà phát triển làm việc trên hai nhánh khác nhau cùng một lúc, sử dụng một kỹ thuật gọi là nhánh ảo (virtual branching). Nó hòa giải mã mà nhà phát triển đang làm việc với mã thượng nguồn (upstream). Họ có thể sắp xếp lại các lần cam kết, hoặc chỉnh sửa nhận xét của một lần cam kết trước đó. Nó cung cấp siêu dữ liệu phong phú hơn về các tệp đang được thực hiện. Nó có thể hiển thị những lần cam kết nào là duy nhất đối với nhánh đó. Tốt nhất của tất cả, nó loại bỏ những gì nhiều nhà phát triển gọi là "địa ngục rebase", nơi các lần hợp nhất vào cơ sở mã đã cập nhật phải được kiểm tra từng cái một, một vấn đề mà GitButler giải quyết bằng cách giữ mã của người dùng đồng bộ hóa với mã thượng nguồn. Nhiều hành động này của GitButler có thể được thực hiện thông qua chính lệnh Git - mặc dù ngôn ngữ lệnh và quy tắc của Git có thể khó hiểu đến mức "bạn có thể sẽ mắc sai lầm tại một số điểm," Chacon nói.

Một phiên bản Git dành cho tác nhân

Chacon tin rằng các vấn đề về độ tin cậy hiện tại của GitHub bắt nguồn từ làn sóng công việc của các tác nhân hiện nay.

Điều này "mỉa mai" vì GitHub được xây dựng để mở rộng quy mô Git, ông nói. "Nhưng sự gia nhập của các tác nhân đang đẩy dịch vụ đến bờ vực."

Vấn đề không nằm ở Git itself, mà ở việc mọi người đang sử dụng một dịch vụ duy nhất, Chacon lập luận. Năm ngoái, GitHub có khoảng 180 triệu người dùng làm việc trên 630 triệu kho chứa - với 121 triệu kho được tạo ra chỉ trong năm 2025, theo báo cáo Octoverse hàng năm gần nhất của công ty.

"Từ góc độ dài hạn, nó không cần phải như vậy," ông lập luận. Có lẽ Git nên được chạy cục bộ, phản chiếu toàn cầu và được quản lý với các khách hàng... như GitButler, Chacon gợi ý. Có lẽ các hệ thống kiểm soát phiên bản dựa trên Git có thể được tùy chỉnh cho các ngành dọc cụ thể.

Chúng ta cần nghĩ về cách chúng ta "phân phối các hệ thống này nhiều hơn," ông nói. "Git được thiết kế để phân tán nhưng chúng ta không đang phân tán nó," ông nói.

GitButler đã tạo ra một giao diện dòng lệnh cụ thể cho các tác nhân. Nó được thiết kế để cung cấp cho các máy chủ MCP một bản đồ tích hợp của kho chứa, nếu không sẽ yêu cầu ghép nối nhiều lệnh Git lại với nhau. Khái niệm Tệp ảo (Virtual Files) cho phép tác nhân làm việc trên một phần mã cũng đang được thực hiện bởi một nhà phát triển, hoặc một tác nhân khác.

Những thay đổi này chỉ ra một sự tư duy lại về cách quy trình làm việc của Git nên chạy.

"Tôi nghĩ tất cả các hệ thống này nên thay đổi cơ bản, bởi vì tất cả các quy trình làm việc của chúng ta đã thay đổi, đúng không? Cần có các nguyên thủy khác nhau, loại nào để xử lý các tập hợp vấn đề này," Chacon nói.

Một gợi ý từ phát triển game

Một công ty muốn nền tảng của mình thay thế hoàn toàn Git là Diversion, công ty đã xây dựng một hệ thống kiểm soát phiên bản phân tán cùng tên, ban đầu được định vị cho thiết kế game quy mô lớn.

"Kiến trúc của Git thực sự là một vấn đề ngăn cản việc mở rộng quy mô," Sasha Medvedovsky, CEO của Diversion, lập luận trong một cuộc phỏng vấn với The Register. "Về cơ bản, đây là một vấn đề kiến trúc không thể khắc phục và là nút thắt cổ chai cho người dùng cuối và dịch vụ lưu trữ."

Git là một hệ thống phân tán theo nghĩa là mọi người dùng, hoặc dịch vụ được lưu trữ, đều yêu cầu một cơ sở dữ liệu chuyên dụng (giống như blockchain). "Nó không được phân tán theo nghĩa thông thường mà là được sao chép," ông viết trong một trao đổi với The Register trên LinkedIn.

Các thao tác chạy trên một luồng đơn (single thread), khiến các thao tác đồng thời không thể thực hiện được. Kết quả là, kho chứa càng lớn, các thao tác cam kết càng chậm - một sự kết hợp chết người cho phát triển phần mềm dựa trên tác nhân nhanh chóng, Medvedovsky lưu ý.

Tất nhiên, mọi CEO sẽ sẵn sàng các luận điểm về điểm yếu của đối thủ cạnh tranh (Diversion đang hoàn thiện một bài đăng blog với các con số cụ thể về hiệu suất của Git và GitHub). Nhưng có một số lượng ngày càng tăng các sáng kiến khác xung quanh việc chuẩn bị cho Git cho những thời điểm thử thách phía trước.

Có lẽ đáng chú ý nhất là Jujutsu, một hệ thống kiểm soát phiên bản phân tán tương thích Git, được bảo trợ bởi kỹ sư phần mềm cấp cao của Google Martin von Zweigbergk. Giống như GitButler, Jujutsu (jj) nhằm mục đích loại bỏ nhiều phiền toái đi kèm với Git. Nó bao gồm một nút hoàn tác và khả năng tiếp tục cam kết ngay cả khi có xung đột.

Và vì mọi thứ được viết bằng C đều phải được chuyển sang Rust những ngày nay, người đóng góp lâu năm cho Git là Sebastian Thiel đã bắt đầu một dự án gọi là Gitoxide để xây dựng lại Git bằng Rust. Các lợi ích tiềm năng bao gồm cải thiện hiệu suất đáng kể thông qua xử lý đa lõi và an toàn bộ nhớ rất cần thiết mà Rust mang lại.

Git 3 sẽ giải quyết được mọi vấn đề?

Người bảo trì chính của Git là Junio Hamano, người đã nhận quyền chỉ đạo từ Torvalds vào năm 2005. Và ông vẫn bận rộn việc giữ cho Git được cập nhật. Tại FOSDEM vào tháng Hai, người đóng góp cốt lõi của Git và quản lý kỹ thuật của GitLab Patrick Steinhardt đã thảo luận về một số thay đổi sẽ có trong phiên bản tiếp theo của Git, phiên bản 3, đang được triển khai dần trong năm nay.

Một trong những cải tiến chính sẽ nằm ở cách Git quản lý các tham chiếu cam kết, các ID trỏ đến mỗi thay đổi đang được thực hiện. Ngạc nhiên là, thao tác này thực sự là một nút thắt cổ chai cho phần mềm. "Thiết kế không hiệu quả," Steinhardt nói với khán giả.

Mỗi khi một lập trình viên cam kết một thay đổi mã, nó được ghi lại trong một tệp "packed-refs", tệp này tiết kiệm thời gian bằng cách không cấp cho mỗi lần cam kết một tệp tham chiếu riêng.

Tuy nhiên, khi các dự án phát triển lớn hơn, việc Git sửa đổi hoặc xóa một tham chiếu trong packed-refs sẽ mất nhiều thời gian hơn (một kho GitLab có tệp packed-refs hơn 20 triệu tham chiếu, Steinhardt nói).

Điều này đặc biệt gây vấn đề khi bạn có nhiều người đọc và người viết đồng thời của tệp đó. Và hãy quên đi việc có được cái nhìn nhất quán về tất cả các tham chiếu.

Tính năng Reftable mới được triển khai, sẽ là mặc định trong Git 3.0, lưu trữ các tham chiếu ở định dạng nhị phân có thể lập chỉ mục. Những người làm Git đã mượn khái niệm này từ việc triển khai JGit Java của Git của Eclipse Foundation.

Reftable cho phép cập nhật theo khối, loại bỏ nhu cầu ghi lại một tệp kích thước 2 GB chỉ cho một mục nhập duy nhất. Và nó nhanh hơn nhiều để đọc, điều này sẽ mở đường cho Git hỗ trợ các kho chứa lớn hơn, lan rộng hơn - hoàn hảo cho một lực lượng lao động dựa trên tác nhân luôn bận rộn.

Trong gần hai thập kỷ, Git đã chứng minh là hệ thống kiểm soát phiên bản lựa chọn cho các tín đồ công nghệ trên toàn thế giới. Nhưng ngay cả với các tính năng mới và các cải tiến của bên thứ ba khác nhau, liệu nó có thể giữ được sự phù hợp cho một thế hệ lập trình viên được tăng cường bởi tác nhân hay không?

Cuộc chiến đã bắt đầu.