GitHub hướng dẫn cách chia nhỏ mã nguồn khổng lồ từ AI bằng kỹ thuật Stacked Pull Request

Thay vì một pull request khổng lồ, không thể đánh giá nổi, hãy dạy các coding agent cách phân tách công việc thành một chồng (stack) các pull request có thứ tự, gọn gàng với GitHub stacked pull requests.

Ngày 4 tháng 8 năm 2026

9 phút

Hãy nghĩ về tính năng lớn gần nhất mà bạn đã phát hành. Thành thật mà nói, bạn đã nhồi nhét nó vào một pull request khổng lồ, hay bạn đã chia nhỏ nó thành các pull request có phạm vi hẹp hơn? Trong nhiều năm, bạn đã âm thầm phải lựa chọn giữa việc nhìn một pull request phình to đến mức việc đánh giá trở thành cơn ác mộng, hoặc chia nhỏ nó thành một chuỗi các pull request mà bạn phải trông chừng, đồng bộ thủ công và gỡ rối xung đột mỗi khi có thay đổi ở các phần bên dưới.

Cả hai lựa chọn đều có những đánh đổi. Một bên thì khó đánh giá, bên còn lại thì khó bảo trì. Quyết định của bạn ngày hôm đó thường nghiêng về lựa chọn ít gây đau đầu hơn.

Giờ hãy thêm các coding agent vào. Theo Gartner, chúng cực kỳ hiệu quả và dự kiến sẽ thúc đẩy mức tăng năng suất 50% trong mọi giai đoạn của SDLC vào năm 2028. Tuy nhiên, chúng không thể thay thế việc bạn phải lựa chọn cách cấu trúc các pull request của mình. Chúng chỉ làm tăng thêm nhu cầu phải thực hiện việc đó.

Trong bài viết này, hãy cùng theo dõi ví dụ về cách bạn có thể sử dụng stacked pull requests để đơn giản hóa quá trình đánh giá.

Giả sử bạn đưa ra một prompt để thêm tính năng tìm kiếm sản phẩm vào một trợ lý mua sắm, rồi rời đi và chỉ vài phút sau, theo nghĩa đen, bạn quay lại để đánh giá, điều hướng và phê duyệt. Nhưng hãy nhìn kỹ những gì thường xuất hiện trong pull request đơn lẻ đó:

…tất cả những thứ này và nhiều hơn thế nữa trong một diff khổng lồ với hơn 1.000 dòng code.

Đối với các agent chủ yếu được huấn luyện dựa trên cách viết code truyền thống qua nhiều năm, mô hình này là cách mặc định để chúng thực hiện công việc. Hãy cùng xem điều gì xảy ra.

Bạn muốn thêm tính năng tìm kiếm sản phẩm vào một ứng dụng web hiện có và trạng thái bắt đầu của bạn là:

Một issue được mở để triển khai tính năng, và quy trình thông thường sẽ là tạo một feature branch, giao nó cho một coding agent (hoặc nhiều agent tùy chỉnh), nhận bản nháp đầu tiên của toàn bộ code triển khai và các bài kiểm thử đã cập nhật…

…bạn đọc code (à, có lẽ là bạn đọc). Sau đó, bạn vẫn cần xác minh thủ công hành vi của tính năng và thực hiện mọi cập nhật cần thiết, push và mở một pull request với phần mô tả do AI tạo ra vừa dài vừa hời hợt, đảm bảo các CI check đều xanh, tự đánh giá diff của chính mình rồi yêu cầu người khác đánh giá. Bạn bắt đầu…

Người đánh giá: 1.721 dòng đã thay đổi!! Mô tả này chẳng giúp ích được gì cả. Để lát nữa tôi xem sau.

Và những gì diễn ra tiếp theo đã quá quen thuộc:

Điều này khởi đầu cho một quy trình thủ công, lộn xộn, tốn thời gian và dễ xảy ra xung đột trước khi tính năng được hợp nhất, và cuối cùng nó được đưa vào sử dụng mà chưa được đánh giá kỹ lưỡng.

GitHub stacked pull requests

Stacked pull requests mang đến một cấu trúc phân phối khác biệt và tốt hơn. Nguyên tắc rất đơn giản: phân tách. Thay vì cố gắng tạo một pull request duy nhất giải quyết toàn bộ vấn đề, bạn chia nhỏ tính năng thành các lớp logic và xác định chuỗi phụ thuộc để đạt được mục tiêu mong muốn. Điều này cung cấp cho bạn và các agent của bạn một cách tự nhiên để phân tách công việc vốn dĩ sẽ nằm trong một pull request khổng lồ thành một chuỗi các lớp nhỏ, tập trung và có thể đánh giá độc lập.

Pull request lớn khó đánh giá đó trở thành một chồng các pull request nhỏ hơn, được sắp xếp theo logic, mỗi cái tập trung vào một vấn đề duy nhất, đủ nhỏ để người đánh giá có thể nắm bắt và có đủ ngữ cảnh cần thiết được truyền tải tự nhiên từ pull request đã đánh giá trước đó.

Hãy cùng thực hiện.

Cấu trúc của stack

Hãy xem xét các bước liên quan khi phân tách vấn đề và sắp xếp các lớp trong stack.

Đầu tiên, và quan trọng nhất, hãy thiết lập stack base (cơ sở của stack). Điều này rất quan trọng vì các CI check và quy tắc merge trong suốt vòng đời quản lý stack sẽ được đánh giá dựa trên stack base này.

Sau đó, xác định đơn vị công việc nền tảng cốt lõi và đặt nó gần với base (thấp nhất trong stack), và xếp các công việc phụ thuộc lên trên.

Giờ đây, các mối quan tâm độc lập đã rõ ràng: dữ liệu, API, kết nối, UX, giúp bạn có thể phân bổ các đối tượng đánh giá khác nhau cho từng phần. Dữ liệu được đánh giá bởi người quản lý dữ liệu, UX bởi người quản lý UI.

Hỗ trợ gốc của GitHub cho stacked pull requests có thể được khởi chạy từ giao diện pull request và mở rộng liền mạch ra terminal với CLI gh stack.

Cài đặt tiện ích mở rộng CLI cho stacked pull requests

Chạy lệnh sau:

Ngày xưa, bạn đã sẵn sàng để bắt đầu làm việc. Nhưng không phải hôm nay. Có những agent đang làm việc cùng bạn. Những agent này cần học cách các stack hoạt động cũng như cách tạo và quản lý chúng thay cho bạn. Các kỹ năng gh-stack sẽ dạy chúng điều này.

Hoặc, nếu bạn thích:

Đối với tính năng cụ thể từ ví dụ trên, quy trình phát triển của bạn có các agent tùy chỉnh, mỗi agent có các luồng công việc được xác định và tuân thủ kỷ luật phạm vi nghiêm ngặt để đạt được mục tiêu là các pull request nhỏ, tập trung vào một vấn đề duy nhất.

Phần cuối cùng của quá trình thiết lập là xác nhận CI đã tồn tại. Như đã đề cập trước đó, mỗi pull request sẽ được đánh giá dựa trên stack base, và các kiểm tra này sẽ chạy cho từng lớp.

Bây giờ công việc bắt đầu.

Lớp một: Nền tảng danh mục dữ liệu

Hầu hết các quy trình làm việc của agent hiện nay đều được tự động hóa và thực hiện tự chủ trong các vòng lặp, nhưng để minh họa, chúng ta sẽ thực hiện từng bước một.

Tại thời điểm này, tất cả các agent đều đã quen với cách hoạt động của stacked pull requests, vì vậy một quy trình làm việc điển hình ở giai đoạn này sẽ là:

Ghi chú của người đánh giá cho tương lai: Các kiểu dữ liệu đã đúng chưa? Dữ liệu đã được xác thực chưa? Query helper có an toàn không? Chấm hết.