Giấc mơ về một "Forge" mới: Khi GitHub không còn là lựa chọn hoàn hảo

Giả sử tôi có một khối tài sản khổng lồ, đủ để mua một tàu ngầm hay một khu nghỉ dưỡng riêng, điều đầu tiên tôi muốn làm không phải là du lịch mà là xây dựng một nền tảng lưu trữ mã nguồn mới. Động lực này xuất hiện sau khi đọc về việc dự án Ghostty rời bỏ GitHub, nhưng thực chất nó là một ý tưởng tôi ấp ủ bấy lâu nay. Khi các nền tảng như GitHub, GitLab hay Gitea ngày càng bộc lộ những hạn chế trong công việc cốt lõi, tôi tự hỏi: Liệu chúng ta có thể làm tốt hơn không?

Vấn đề của các nền tảng hiện đại

GitHub, GitLab và Gitea đều mô phỏng theo cùng một thiết kế do GitHub khởi xướng. Vấn đề nằm ở chỗ Git được thiết kế như một hệ thống kiểm soát phiên bản phân tán, hoàn hảo cho phát triển nhân Linux với quy trình gửi bản vá qua email. Tuy nhiên, trong hầu hết các công việc hiện nay, Git chỉ là công cụ để đẩy và kéo code từ một kho lưu trữ tập trung trên "forge". Mọi thứ quan trọng như Pull Requests (PR), Actions hay quản lý vấn đề (Issues) đều diễn ra trên nền tảng trung gian này chứ không phải trên máy của lập trình viên.

Dưới đây là những vấn đề cốt lõi mà tôi muốn giải quyết nếu được xây dựng một "forge" của riêng mình.

Thứ tự thực hiện việc sai lầm

Chúng ta thường thấy các commit với tên gọi "fix", "fix again", hay "please" xuất hiện vào lúc nửa đêm. Vấn đề là phản hồi đến sau khi đã commit. Tôi muốn có các hook tiền commit (pre-commit hook) bắt buộc chạy trên máy chủ từ xa để cung cấp phản hồi cho người dùng trước khi họ đẩy code lên. Điều này giúp ngăn chặn các lỗi sai sót ngay từ đầu thay vì phải sửa đổi liên tục sau khi đã đẩy.

Quy trình phê duyệt PR quá nhị phân

Hiện tại, PR chỉ có hai trạng thái: được duyệt hoặc không được duyệt. Nhưng thực tế code review phức tạp hơn thế. Đôi khi câu trả lời hợp lý là "Được thôi, nhưng sửa lại sau". Gerrit có mô hình tốt hơn ở điểm này, cho phép phê duyệt một cách "yếu" (weakly approve) và đánh dấu để xử lý sau.

PR thiếu linh hoạt trước sự bùng nổ của LLM

Không phải thay đổi nào cũng cần 4 mắt (4 eyes principle) để duyệt, đặc biệt khi các AI (LLM) đã có thể kiểm tra rủi ro. Việc các kỹ sư cấp cao chờ đợi duyệt cho những thay đổi nhỏ là lãng phí tài nguyên. Hãy để người bảo trì (maintainer) có quyền tùy chỉnh quy trình này: nếu người dùng là maintainer và LLM đánh giá rủi ro thấp, hãy cho phép code tự động đi qua.

Stacked PRs và sự cồng kềnh

Stacked PRs (các PR xếp chồng lên nhau) là cách làm hiệu quả hơn để review và hiểu code, nhưng hiện tại chúng chỉ là tính năng phụ thay vì là công dân hạng nhất của hệ thống. Ngoài ra, một forge không nên cố làm mọi thứ như bảng Kanban hay Wiki. Các công cụ "làm tất cả" thường trở nên cồng kềnh, khó bảo trì và chất lượng trải nghiệm người dùng bị giảm sút.

Kiến trúc lưu trữ và khả năng làm việc offline

Chạy GitHub Enterprise hay GitLab là một nhiệm vụ lớn. Tôi muốn các đơn vị lưu trữ nhỏ gọn hơn có thể liên kết với nhau, thậm chí chạy trên một tổ hợp các máy Raspberry Pi. Bản sao local của kho chứa nên đại diện cho toàn bộ kho, bao gồm cả việc duyệt PR hay xem Issues, chứ không chỉ là code.

Hơn nữa, các Actions (CI/CD) cần được ký và có thể chạy offline. Tôi muốn tải xuống các tarball của Actions, lưu trong repo và hệ thống sẽ tự động cập nhật chúng thay vì phải phụ thuộc hoàn toàn vào kết nối mạng để tải về mỗi lần chạy.

Kết luận

Có nhiều công cụ thực hiện một phần các ý tưởng trên, nhưng tôi muốn một giải pháp tổng thể sử dụng VCS hiện đại như JJ, được thiết kế cho lưu trữ đối tượng (object storage) và shallow clone. Chúng ta đang sống trong một thế giới nơi các nền tảng khổng lồ đang xuống cấp và chưa có người thay thế xứng tầm. Nếu một ngày nào đó tôi có đủ tiền để thực hiện giấc mơ này, tôi sẽ xây dựng một công cụ thực sự dành cho những người viết code, chứ không phải cho những người sở hữu tên lửa.