Nếu có thể tự tạo GitHub của riêng mình

 (matduggan.com)
4 điểm bởi GN⁺ 1 giờ trước | 1 bình luận | Chia sẻ qua WhatsApp
  • Các forge hiện đại như GitHub, GitLab, Gitea cùng chia sẻ mô hình kiểu GitHub, nhưng trọng tâm thực sự của công việc lại diễn ra bên trong các tính năng forge như PR, Actions, Issues, Releases nhiều hơn là trong git
  • Một forge mới nên chạy từ xa các pre-commit hook bắt buộc để đưa phản hồi trước khi push chứ không phải sau commit, từ đó giảm các commit lặp lại kiểu Feature, fix, actually fix, asdfasdf
  • Việc phê duyệt PR nên vượt ra ngoài kiểu nhị phân duyệt/từ chối để hỗ trợ cả phê duyệt mềm và đánh dấu xem lại sau như Gerrit, đồng thời các thay đổi nhỏ mà tác giả là maintainer và LLM đánh giá là rủi ro thấp cũng nên được thông qua linh hoạt hơn
  • Stacked PR nên là tính năng hạng nhất của cả forge lẫn VCS, và kho lưu trữ cục bộ cần biểu diễn được toàn bộ trạng thái repository, bao gồm cả phê duyệt PR và issue chứ không chỉ mã nguồn
  • Tổ hợp mong muốn là JJ làm VCS, một forge mới có thể tự host ở quy mô nhỏ, cùng Actions hỗ trợ chữ ký, SHA và chạy ngoại tuyến; nhưng trong thời đại GitHub là mặc định, vẫn chưa có lựa chọn thay thế thực sự rõ ràng

Vấn đề của forge hiện đại

  • GitHub, GitLab và Gitea tuy có khác biệt chi tiết nhưng gần như đều đi theo cùng một mô hình thiết kế, gần với việc các công cụ khác mang lại những khuôn mẫu ngành do GitHub tạo ra
  • Phần lớn chức năng của các forge hiện nay hầu như không còn liên hệ trực tiếp với chính git, và client cũng tách rời khỏi cách sử dụng thực tế
  • git là một hệ thống quản lý phiên bản phân tán rất hợp với các môi trường như phát triển kernel, nơi người dùng gửi patch qua email cho maintainer, maintainer quản lý khu vực của mình và quyết định có merge hay không trong một quy trình dựa trên mức độ tin cậy cao
  • Nhưng ở phần lớn nơi làm việc, git gần như chỉ là phương tiện để pull/push mã nguồn từ repository nằm trên forge trung tâm, còn công việc quan trọng diễn ra bên trong forge
    • Pull Request trở thành công cụ để thực thi nguyên tắc bốn mắt
    • GitHub Actions chạy test và lint trong Pull Request để kiểm tra tính đúng đắn về chức năng và việc đáp ứng các yêu cầu của tổ chức
    • Danh tính người dùng bên trong forge trở thành tiêu chí để xác thực người dùng
    • Issues được dùng để theo dõi vấn đề của mã nguồn, còn Releases được dùng để tạo các bản phát hành cho người dùng tải về
  • Vì quy trình như vậy có nhiều tính năng của forge nằm trên git hơn là chính git, nên nếu xây dựng một forge mới thì cũng không còn quá nhiều lý do phải bị ràng buộc tuyệt đối bởi giới hạn của git

Những tính năng mong muốn ở một forge mới

  • Phản hồi nên đến trước commit chứ không phải sau commit

    • Một PR phổ biến thường có chuỗi commit như Feature, fix, fix, actually fix, please, asdfasdf
    • Nếu vòng phản hồi chỉ đến sau commit thì người dùng sẽ phải khổ sở sửa đi sửa lại đến tận khuya
    • Forge nên cung cấp pre-commit hook bắt buộc chạy từ xa để người dùng có thể nhận phản hồi trước khi push

  • Phê duyệt PR quá nhị phân

    • PR hiện nay hoặc là được duyệt hoặc là chưa được duyệt, nhưng trong review mã nguồn thực tế có rất nhiều trạng thái nằm giữa hai cực đó
    • Những phản ứng mang tính con người như “tạm ổn, để xử lý sau” cũng nên có cách thể hiện bằng nút bấm
    • Gerrit cung cấp mô hình tốt hơn ở điểm này
    • Nếu maintainer phê duyệt mềm thì cần có cách đánh dấu để có thể xem lại sau

  • Chính sách PR nên linh hoạt hơn

    • Không phải mọi thay đổi đều cần review bốn mắt, đặc biệt là trong bối cảnh đã có LLM
    • Cái giá phải trả khi chờ một kỹ sư senior chỉ để lại LGTM cho một PR dài bốn dòng là quá lớn
    • Nếu tác giả là maintainer và LLM đánh giá là rủi ro thấp hoặc không có rủi ro, thì cần có cơ chế kiểm soát để cho phép đi tiếp ngay dễ dàng hơn

  • Stacked PR nên là tính năng hạng nhất

    • Stacked PR giúp việc review và hiểu thay đổi trở nên dễ hơn
    • Nó nên được xem như công dân hạng nhất trong forge và VCS, chứ không chỉ là tính năng bổ sung qua công cụ bên ngoài VCS

  • Forge không nên cố làm mọi thứ

    • Theo dõi issue là cần thiết, nhưng bảng Kanban có lẽ thì không
    • Sự cần thiết của Wiki cũng đáng nghi ngờ
    • Những công cụ cố nhét mọi tính năng vào cuối cùng sẽ giảm chất lượng; thêm tính năng thì dễ nhưng chi phí bảo trì vẫn tiếp tục tăng bất kể mức độ được dùng đến đâu
    • Một khi ai đó bắt đầu dùng ở đâu đó thì sẽ bị trói vào tính năng đó

  • Đơn vị host hiện nay quá lớn

    • Vận hành GitHub Enterprise là một việc lớn, còn vận hành GitLab cũng là một gánh nặng đáng kể
    • Các sản phẩm này là những hệ thống phức tạp với rất nhiều bộ phận chuyển động
    • Cần tạo ra những đơn vị host nhỏ hơn và có thể kết nối chúng lại để hình thành một tổ chức
    • Không nhất thiết phải là federation toàn cầu, và cũng không sao nếu phải tạo tài khoản theo từng tổ chức, nhưng tổ chức phải đủ linh hoạt để có thể nói “12 chiếc Raspberry Pi này là tổ chức của tôi”

  • Repository cục bộ phải biểu diễn được toàn bộ repository chứ không chỉ mã nguồn

    • Bản sao cục bộ phải biểu diễn được toàn bộ repository, bao gồm cả phê duyệt PR và issue chứ không chỉ mã nguồn
    • Cần có khả năng phê duyệt PR ngay trong cùng VCS dùng để check in mã nguồn
    • Cần có thể duyệt issue giống như cách lướt qua các tệp cục bộ

  • Không phải lúc nào cũng cần trả giá để lưu toàn bộ lịch sử

    • Muốn cộng tác đúng nghĩa với đội nhóm thì vẫn cần ở trạng thái online, nên không nhất thiết lúc nào cũng phải bắt người dùng gánh toàn bộ chi phí lưu trữ
    • VCS và forge cần hoạt động cùng nhau
    • Khi clone repository thì chỉ cần nhận lịch sử giới hạn; nếu muốn quay lại quá khứ thì có thể khởi chạy worker để lấy những gì cần từ VCS
    • Không cần tiếp tục bắt forge phải xử lý các yêu cầu clone khổng lồ chỉ vì giả định rằng một ngày nào đó người dùng có thể muốn dựng lại forge từ toàn bộ lịch sử dự án

  • Actions phải có chữ ký, SHA và dùng được khi offline

    • Actions rất quan trọng nên cần có chữ ký, SHA và khả năng dùng ngoại tuyến
    • Nếu muốn, người dùng phải có thể tải tarball của mọi action rồi đưa vào repository, đồng thời chỉ thị cho hệ thống dùng action checkout nằm trong repository cục bộ thay vì lấy từ bên ngoài
    • Nếu chỉ định latest thì nó nên hoạt động theo cách mở một PR để đưa tarball mới nhất vào repository, tương tự Dependabot hiện nay
    • Nếu muốn, Actions cũng phải có thể chạy trên máy cục bộ thông qua cùng VCS đó

Đã có công cụ làm được một phần, nhưng cần sự kết hợp

  • Đã có rất nhiều công cụ thực hiện được một phần của những yêu cầu này
  • Điều cần thiết là lấy các công cụ đó, ghép chúng lại và làm cho chúng khớp với nhau một cách đúng đắn
  • Tổ hợp mong muốn là JJ làm VCS, một hệ thống mới làm forge, cùng kỳ vọng rằng người dùng có thể hài lòng lâu dài khi dùng một Raspberry Pi đơn lẻ làm forge
  • Forge mới nên được thiết kế xoay quanh các khái niệm hiện đại như object storage, shallow clone và các yêu cầu liên tục từ bot LLM

Những vết nứt trong thời đại GitHub là mặc định

  • Nếu GitHub thực sự làm tốt thì đã không cần phải viết ra những ý tưởng như thế này
  • GitHub là mặc định, và việc cố thuyết phục người khác vượt ra khỏi mặc định đó thường gần như là lãng phí thời gian
  • Nếu đến năm 2026 mà còn dùng forge, thì cần có một lý do cực kỳ mạnh để không chọn công cụ mà ai cũng dùng
  • Cho đến gần đây, các forge khác thực sự không được xem là lựa chọn mong muốn mà giống như hàng thay thế hơn
  • Nhưng mô hình một forge khổng lồ duy nhất đang rạn nứt, trong khi lựa chọn thay thế thì vẫn chưa được tạo ra
  • Những người có tiền đang bận với tên lửa, những người có gu đang bận với công việc chính, còn số còn lại thì mở một PR tên asdfasdf lúc nửa đêm, chờ robot kiểm tra, rồi tự hỏi từ bao giờ công cụ mà họ dùng cả ngày lại không còn được tạo ra vì người dùng nữa

Bài viết liên quan

1 bình luận

 
GN⁺ 1 giờ trước
Ý kiến trên Hacker News

  • Chỉ trích rằng phê duyệt PR quá nhị nguyên nghe có vẻ mâu thuẫn. Phê duyệt PR là cấp quyền, nên rốt cuộc chỉ có thể là boolean: либо có thể hợp nhất mã hoặc không
    Điều đang được nói tới ở đây gần giống một cơ chế giúp người ta thấy nhẹ lòng hơn khi phê duyệt đoạn mã mình không thích, kiểu như “cần xem lại sau...”. Chỉ cần mở ticket mới là được

    • Gerrit có thang từ -2 đến +2
      -2: Ý tưởng tệ, đừng làm
      -1: Ý tưởng tốt nhưng cần cải thiện
      +1: Trông ổn nhưng không đủ kiến thức hoặc quyền để phê duyệt
      +2: Phê duyệt
    • Tôi muốn có nút kiểu “phê duyệt và hợp nhất 3 commit này ngay, còn 2 commit kia cần làm lại”
    • Cũng có trường hợp mã đã được phê duyệt nhưng không được hợp nhất. Khi đó quản trị viên có thể thêm thay đổi, áp dụng thủ công, rồi ghi tác giả PR là đồng tác giả của commit thay đổi đó
    • Có vẻ vấn đề lớn hơn là GitHub tách rời quá nhiều khỏi hệ thống theo dõi issue. Gánh nặng phải đồng bộ thủ công liên tục là rất lớn; Linear có giúp phần nào nhưng vẫn không lý tưởng
    • Nói “hoặc có thể hợp nhất mã hoặc không” thì chắc hẳn không phải người theo trực giác luận rồi

  • Nói rằng “Y cũng làm được một phần trong số đó” là đúng, nhưng tangled.org thực sự làm được phần lớn

    1. Dùng JJ làm hệ thống quản lý phiên bản: tangled hỗ trợ PR xếp chồng bằng jj change-id. https://blog.tangled.org/stacking Bản thân tangled cũng được xây khá nhiều theo cách này: https://tangled.org/tangled.org/core/pulls
    2. Một forge có thể chạy lâu dài trên Raspberry Pi: chuyện này cũng làm được. git server shim rất nhẹ, chỉ là lớp XRPC trên kho git và cơ sở dữ liệu sqlite3. Có người còn chạy nó trên bo mạch RISC-V RAM 512MB
    3. Actions rất quan trọng và phải chạy được trên máy local: tôi thấy yêu cầu này hơi lệch mục tiêu. Việc xây dựng môi trường kín, chạy ở mọi nơi và xử lý cross-build nhìn chung là việc của hệ thống build. Sẽ rất tuyệt nếu có thể “thăng hạng” kết quả build đó vào chính forge
    • Tôi ngạc nhiên khi Raspberry Pi được nhắc tới để host dữ liệu cốt lõi của quy trình làm việc. Trước đây tôi từng quá nhiều lần bị hỏng thẻ SD, nên tò mò không biết giờ họ dùng ổ NVME không
    • Đúng vậy, đó là việc của hệ thống build. Nhưng vấn đề mà mọi người muốn giải bằng Actions có thể chạy local phần lớn không phải bản thân lỗi build, mà là tích hợp tổng thể
      Những thứ như định nghĩa YAML, secret, chính xác lệnh nào được chạy, công cụ và cache được khôi phục ra sao. Hệ thống build có thể xử lý một phần, nhưng các tính năng gốc mà GHA cung cấp rất nghèo nàn. Rốt cuộc nó dẫn tới bài toán phải chạy toàn bộ hệ thống ở nơi khác, nên các hệ thống kiểu này thường thành ra thử sai là chính
    • Đúng, và hơn nữa ý tôi là sẽ tốt nếu mở rộng khái niệm build kín để có thể dễ dàng chạy local hoặc ở bất cứ đâu có tài nguyên tính toán
      Vấn đề gốc ở đây là việc cứ phải lặp đi lặp lại chu trình có thay đổi, commit, gọi mạng, rồi chờ CI xanh là cực kỳ đau đớn. Cách tốt nhất để tránh vòng lặp đó là đừng bao giờ viết bug! Đùa thôi
    • Cả Radicle lẫn Tangled đều bỏ lỡ điểm cốt lõi. Chúng phục vụ cộng tác công khai, vậy còn kho lưu trữ riêng tư thì sao? Nhiều người có side project và dùng GitHub private vì điều đó
      Một khi đã học GitHub, họ cũng sẽ bắt đầu các dự án công khai trên GitHub. Chừng nào chưa cho phép tạo kho riêng tư cho side project thì rất khó được dùng rộng rãi. Điều mọi người muốn là tạo kho riêng tư, bỏ đi vài tháng rồi quay lại vẫn thấy nó ở đó chờ mình
    • Wow, hỗ trợ jujutsu của Tangled đúng là thứ tôi đang tìm. Cuối tuần này chắc sẽ bay màu vào việc dựng self-hosting

  • Nếu muốn chỉ clone lịch sử giới hạn và lấy dữ liệu cũ khi cần, thì dùng blobless clone là được
    git clone --filter=blob:none
    Nó lấy lịch sử trước, còn blob thì chỉ tải khi cần. GitHub có bài viết hay ở đây: https://github.blog/open-source/git/get-up-to-speed-with-par...

  • Khi giải pháp trở thành vấn đề, đó là lúc mở ra cơ hội cho đổi mới mang tính phá vỡ. Gần đây nói về chuyện này khá nhiều, và tôi tò mò liệu trước khi GitHub chỉnh lại hướng đi thì một trong rất nhiều lựa chọn mới nổi có giành được đà phát triển hay không

    • Tôi nghĩ vấn đề là Microsoft đã all-in hoàn toàn vào AI. Không còn đường quay lại, và GitHub cũng buộc phải chịu ảnh hưởng
      PR của Microsoft sẽ nói AI là lời giải cho mọi thứ, nhưng ngoài đời thực thì cùng một vấn đề vẫn sẽ lặp lại. Sự cố dịch vụ GitHub có thể không liên quan trực tiếp tới AI, nhưng vì chiến lược của Microsoft đã đổi rồi nên phần lớn quyết định sẽ bị kéo theo kiểu kiểm soát từ trên xuống xoay quanh AI. Việc quy trình làm việc của người dùng GitHub có bị phá hay không với Microsoft cùng lắm chỉ là mối quan tâm thứ yếu, và vấn đề đó sẽ cứ tái diễn. Có thể yên ắng khoảng 3 tháng, nhưng chẳng bao lâu nữa sẽ 100% lại có một màn kịch mới về việc GitHub đi xuống. Ghostty sẽ không phải lần cuối. Việc có lựa chọn thay thế xuất hiện hay không thì thú vị đấy, nhưng các lựa chọn đó không được tệ, trong khi nhiều website hiện khá dở
    • Tôi đang tự làm công cụ của mình. Tôi nghĩ mọi người cũng nên tự làm công cụ của mình
      Có lẽ trong tương lai, thay vì phần mềm trả phí hay mã nguồn mở, người ta sẽ nhận được một bộ tài liệu yêu cầu cho code forge, kiểu như một công thức. Mỗi người tự nướng lấy và chỉnh cho hợp nhu cầu, sở thích của mình

  • Tôi nghĩ vẫn có khoảng trống thị trường cho một dịch vụ git đơn giản hơn nhiều. Thứ cần thiết chỉ là host từ xa để push dự án lên cho người khác xem, chứ không thực sự muốn PR hay Actions
    Có thêm tính năng “release” để tải lên các binary asset build ở local thì cũng hay. Fork có thể xử lý bằng cách để người ta clone kho rồi đưa lên thành dự án mới

    • Chẳng phải có thể giải quyết nhiều thứ trong số này bằng cách tắt các tính năng không cần thiết sao? Tôi vừa xem instance Forgejo của mình thì thấy có tùy chọn tắt theo từng kho: Code, Projects, Releases, Packages, Actions, Issues, PRs, Wikis
    • https://sr.ht/
    • Vậy là lại quay về cgit à?

  • Lập luận rằng dữ liệu review cũng có thể nằm trong kho git như mã nguồn là khá thuyết phục
    Có thể triển khai rất dễ bằng cách tạo một branch cho mỗi review với tiền tố đã biết, nhưng namespace branch mặc định sẽ nhanh chóng bừa bộn. Có thể tách khỏi namespace chính bằng git namespaces, hoặc tạo một branch đặc biệt như .reviews chỉ chứa ID commit cuối của từng branch review. Nếu ai đó đủ quan tâm để làm ra một đặc tả và một triển khai dùng được thực tế, có lẽ mọi người sẽ bắt đầu chấp nhận. Lý do GitHub và nhiều forge không chọn hướng này có lẽ là vì metadata review bị khóa trong hệ sinh thái của họ chính là giá trị nền tảng. Nếu ai cũng có thể review mã của người khác bằng công cụ local mình thích, thì mức độ khóa chặt nhà cung cấp sẽ giảm đi. Dù vậy cũng có thể còn những lý do khác muốn đặt metadata review ở kho khác, như kiểm soát truy cập hay review xuyên kho

  • Tôi thực sự thích quy trình Gerrit là review khác biệt thay vì PR. Nhưng so với gitea chẳng hạn, nó thiếu issue, lập kế hoạch dự án và những tính năng khác mà người ta đã quen kỳ vọng ở một dịch vụ host git, nên có vẻ khó thuyết phục được nhiều người
    Giá mà có một nền tảng review khác biệt tốt như Phabricator thì hay biết mấy

    • Nhưng tại sao Gitea lại không thêm thứ đó? Nó đã có mọi thứ còn lại rồi, tôi không hiểu sao các forge này lúc nào cũng chỉ dừng ở bản sao GitHub thay vì đi xa hơn

  • Tôi nghĩ nên dùng RFC2822 làm định dạng cơ bản để lưu mọi loại thông điệp như PR, bình luận review, issue, rồi dùng CommonMark để trình bày khi hiển thị
    Toàn bộ metadata có thể để trong header, và liên kết chúng với nhau bằng header Message-ID/In-Reply-To/References. Dùng một định dạng được định nghĩa rõ như vậy thì có thể chọn cách lưu và truyền mọi thông điệp. Có thể đặt trong kho git, dùng email, hoặc cách nào khác phù hợp. Cá nhân tôi thấy review mã kiểu Gerrit tốt hơn GitHub và các hệ khác rất nhiều. CI thì tôi muốn để ở ngoài càng nhiều càng tốt, chỉ cần vài hook để khởi động pipeline, hiển thị kết quả và quyết định có cho phép merge hay không

    • Tôi nghĩ một trong những điểm hấp dẫn của GitHub là nó tích hợp review mã, duyệt mã nguồn, theo dõi ticket và CI
      Nó không làm xuất sắc tuyệt đối cả bốn thứ, nhưng rất giỏi trong việc buộc chúng lại với nhau. Tôi đồng ý Gerrit có mô hình review mã tốt hơn, nhưng nếu thiếu ba mảnh còn lại thì chưa thành sản phẩm. Ngay cả khi dùng Gerrit hằng ngày ở Google, tôi vẫn khó chịu với sự tích hợp yếu giữa tìm kiếm mã, review mã và CI. Những công cụ nội bộ của Google như Google3/Critique/Forge gắn kết tất cả các phần đó tốt hơn nhiều

  • Tôi chợt nghĩ ra một lợi thế của quy trình dựa trên email. Nếu bạn bắt đầu xem email thì thường là lúc bạn đang ở đúng tâm thế cho việc đó, và trong trạng thái ấy bạn kỳ vọng sẽ ít bị xao nhãng hơn nên tập trung tốt hơn
    Vấn đề của thông báo là chúng tạo ra lực kéo khiến bạn muốn dọn chúng đi ngay khi hiện lên. Nhưng không có gì đảm bảo lúc đó bạn có đủ năng lượng để xử lý chúng. Phần lớn hệ thống thông báo trên web trông như một bản bắt chước vụng về những gì trình đọc email đã làm được từ vài chục năm trước. Có lẽ người xưa dùng email đúng là có lý thật

    • Email cũng là thông báo mà, bạn có thể giải thích rõ hơn việc đúng lúc nó đến thì làm sao bạn lại có tâm trạng để nhận nó không?

  • Khi Microsoft thâu tóm GitHub, đã có nhiều người bực bội sẵn rồi. Nhưng thực tế là các lựa chọn thay thế thường không tốt. Sourceforge thì việc tạo issue phiền vô tận, GitLab khá hơn Sourceforge nhưng tôi vẫn ghét tạo issue ở đó. Codeberg có vẻ gần đây đã đổi UI, nhưng vẫn khá khó chịu
    Điều GitHub làm tốt từ đầu là UI và việc tập trung vào những người dùng GitHub để khiến mọi thứ dễ hơn hoặc ít nhất cũng đỡ khó hơn. Dĩ nhiên không phải cái gì họ cũng làm tốt; tôi thấy hỗ trợ wiki rất tệ. Nó dở tới mức tôi gần như không dùng wiki. Vấn đề thật sự lớn, theo tôi, là lợi ích thương mại, tức lợi ích tư nhân. Microsoft chỉ là một ví dụ; đây là vấn đề hiện diện ở gần như mọi site tương tự. Trước đây tôi từng nêu ví dụ về phần thảo luận issue liên quan tới tiện ích backdoor xz, và tôi cũng tham gia bàn luận, nhưng hôm sau Microsoft đã gỡ sạch. Là Microsoft hay chủ kho làm chuyện đó thì không quan trọng. Vấn đề là một cá nhân có thể kiểm duyệt thông tin có khả năng hữu ích quá dễ dàng. Thảo luận issue đó hữu ích, và nó đã bị kiểm duyệt. Tôi nhớ là khi ấy không phải toàn bộ thông tin đều được khôi phục. Có thể ai đó đã mirror, nhưng tôi không thấy link. Điều này cho thấy kiểm soát từ trên xuống thực sự có thể gây hại. Thành thật mà nói, có thể tin Microsoft tới mức nào? Chúng ta cần thứ gì đó phi tập trung, vận hành ổn định, UI mặc định tốt, và đơn giản hoặc ít nhất là có quy trình làm việc tốt. Cũng phải tránh tình huống một tác nhân tư nhân bắt mọi người làm con tin. Tôi hoàn toàn không biết giải bài toán này thế nào; có thể sẽ cần nhiều cách tiếp cận cùng lúc. Web đã thay đổi, và đặc biệt là lợi ích tư nhân của các siêu tập đoàn lớn trong 10–15 năm qua khiến mọi thứ tệ hơn rất nhiều. Điều đó cần phải thay đổi

    • Vấn đề là vận hành sản phẩm SaaS rất tốn tiền
      Các tập đoàn lớn có thể trả khoản đó, còn rất nhiều lập trình viên ngân sách nhỏ gộp lại cũng không đủ tiền để làm điều tương tự. Vì vậy bất kỳ dự án thương mại nào cuối cùng cũng khó tránh khỏi việc nghiêng về phục vụ lợi ích của các tập đoàn lớn hơn là người bình thường