GitRoot

 (gitroot.dev)
2 điểm bởi GN⁺ 1 ngày trước | 1 bình luận | Chia sẻ qua WhatsApp
  • GitRoot là một Git forge nhỏ gọn, quản lý kho lưu trữ và quyền truy cập bằng một binary duy nhất, đồng thời kết hợp issue, board, hợp nhất nhánh và giao diện web dưới dạng các plugin độc lập
  • Không chỉ mã nguồn, mà cả issue, merge request và board: toàn bộ dữ liệu được lưu trong Git dưới dạng file thông thường, không phụ thuộc vào cơ sở dữ liệu riêng hay blob ẩn
  • Kiểm soát thay đổi bằng .gitroot/users.yml và quyền ghi theo từng nhánh; chỉ người dùng được phép mới có thể push lên nhánh mặc định, tức trạng thái hiện tại của kho lưu trữ
  • Hiện là phiên bản alpha; hỗ trợ kho lưu trữ, người dùng, plugin, lệnh Git qua SSH và xem qua HTTP, nhưng chưa phù hợp cho môi trường production
  • Trước bản 1.0, dự án sẽ thúc đẩy cập nhật, quyền theo từng file, lệnh Git qua HTTP, nhóm và nhóm con, cũng như ổn định plugin API; hiện việc đóng góp đòi hỏi hiểu biết về Git và luồng plugin grafter

Git forge nhỏ gọn, ghép đúng các chức năng cần thiết

  • GitRoot là một Git forge nhỏ gọn chạy bằng một binary duy nhất, giới hạn chức năng lõi ở việc tạo kho lưu trữ và quản lý quyền truy cập theo từng kho
  • Các chức năng còn lại do các plugin có thể cài đặt độc lập đảm nhiệm
    • Tạo issue, roadmap, sprint, milestone
    • Hiển thị các mục dưới dạng board
    • Rà soát và hợp nhất nhánh, được GitRoot gọi là graft
    • Cung cấp dữ liệu kho lưu trữ và nhiều chức năng qua giao diện web
  • Vì các plugin được tách rời hoàn toàn, bạn có thể chỉ dùng board mà không cần giao diện web, hoặc tự tạo plugin cho những chức năng dự án cần

Thiết kế cho phép tùy biến forge theo dự án

  • Dựa trên tiền đề rằng mỗi dự án có cách làm việc khác nhau, GitRoot được thiết kế để mỗi dự án có quyền tự do chỉnh sửa forge của riêng mình
  • Môi trường mà nhà phát triển mong muốn gồm
    • Lưu mã nguồn, issue, pull/merge request và board trong một kho lưu trữ duy nhất
    • Cung cấp các chức năng cần thiết cho quảng bá và vận hành dự án như landing page, bản dịch, hệ thống ticket, forum
    • Chuyển sang forge trên máy chủ khác mà không cần script migration, cũng không mất dữ liệu hay thông tin hiển thị về người đóng góp
  • Ngược lại, dự án muốn tránh các dạng phức tạp sau
    • Phải mở trình duyệt để quản lý pull/merge request hoặc issue
    • Cấu trúc bắt người mới tiếp cận dự án nhìn thấy danh sách file và thư mục trước tiên
    • Forge tự quyết định ý nghĩa và workflow của sprint, milestone, epic, user story
    • Cấu trúc phải đi qua nhiều menu chỉ để thiết lập một quyền người dùng

Tự chủ trong cài đặt và vận hành

  • Hướng tới bản phân phối không có dependency và cơ sở dữ liệu để quản trị viên dễ cài đặt và bảo trì
  • Quản trị viên có thể thiết lập thao tác được phép theo từng người dùng, còn người dùng phải có thể tự yêu cầu tạo và truy cập dự án/chức năng mà không cần email hay chat
  • Mục tiêu là giảm gánh nặng nâng cấp, đồng thời không giao dữ liệu dự án và người dùng cho bên thứ ba, cũng không phụ thuộc vào các nhà cung cấp lớn có thể bất ngờ thay đổi chính sách vận hành
  • Đây là dự án chưa hoàn thiện và đang nhận đóng góp từ bên ngoài

Quyền được quản lý bằng file thông thường và nhánh

  • Thay vì cơ sở dữ liệu hay blob ẩn bên trong Git tree, GitRoot lưu toàn bộ dữ liệu trong các file thông thường đặt cạnh mã nguồn
  • .gitroot/users.yml của mỗi kho lưu trữ chỉ định vị trí người dùng được phép ghi, và kiểm soát truy cập vận hành chủ yếu dựa trên giới hạn nhánh
    • Ban đầu chỉ chủ sở hữu có quyền truy cập nhánh mặc định
    • Nếu người dùng không có quyền push lên nhánh mặc định, GitRoot sẽ từ chối thay đổi
    • Bất kỳ ai cũng có thể tạo nhánh mới; người tạo sẽ có quyền ghi trên nhánh đó, còn người dùng khác không thể sửa
    • Nếu sửa .gitroot/users.yml hoặc hợp nhất một nhánh trong đó người dùng đã tự thêm mình, người dùng đó cũng có thể push lên nhánh mặc định
  • Bất kỳ ai cũng có thể đọc file và chỉnh sửa ở local hoặc trên nhánh mới, nhưng để phản ánh thay đổi vào nhánh mặc định đại diện cho trạng thái hiện tại của kho lưu trữ thì cần chủ sở hữu hợp nhất
  • Cấu hình của chính forge cũng được quản lý trong kho lưu trữ gốc
    • Nếu thêm thay đổi vào .gitroot/repositories.yml trên nhánh mặc định của kho lưu trữ gốc, hoặc hợp nhất thay đổi đó, kho lưu trữ sẽ được tạo
    • Có thể xem cách hoạt động chi tiết trong tài liệu

Chức năng được hỗ trợ trong bản alpha

  • Hiện đây là phiên bản alpha, nên có thể thử nghiệm nhưng không nên dùng cho production
  • Phạm vi hỗ trợ như sau
    • Tạo và xóa kho lưu trữ
    • Xử lý lệnh Git qua SSH
    • Quản lý vị trí ghi theo từng người dùng ở cấp kho lưu trữ và nhánh
    • Cài đặt plugin và kích hoạt theo từng kho lưu trữ
    • Chạy plugin trong working tree khi cài đặt
    • Sau khi cài đặt, chạy plugin trên diff ở mỗi commit
    • Xem kho lưu trữ qua HTTP

Kế hoạch phát triển đến bản 1.0

  • Trước phiên bản 1.0, dự án dự định triển khai các chức năng sau
    • Cập nhật GitRoot và plugin
    • Quản lý quyền người dùng ở cấp file
    • Xử lý lệnh Git qua HTTP
    • Quản lý kho lưu trữ bằng nhóm và nhóm con
    • Ổn định plugin API

Tự host và quy trình đóng góp

  • Website GitRoot là một instance GitRoot host chính mã nguồn GitRoot, được vận hành riêng cho dự án GitRoot
  • Nếu muốn thử nghiệm với dự án khác, hãy làm theo tài liệu cài đặt và sử dụng
  • Bản thân GitRoot cũng là một kho lưu trữ GitRoot nên có thể đóng góp theo cùng cách; quy trình có trong hướng dẫn đóng góp
  • Instance hiện tại dùng plugin grafter để tích hợp một phần mã vào nhánh mặc định, nên cần hiểu cách nó hoạt động trước khi đóng góp
  • Vì toàn bộ dữ liệu, gồm mã nguồn, issue và bản dịch, đều được lưu trong Git, để đóng góp hiện nay bạn cần biết cách dùng Git
  • Trong tương lai, mục tiêu là cho phép bất kỳ ai tham gia bằng cách chạy trực tiếp git commit và git push trong trình duyệt

Bài viết liên quan

1 bình luận

 
GN⁺ 1 ngày trước
Các ý kiến trên Lobste.rs
  • GitHub không chỉ là forge Git lớn nhất mà còn là forge có ảnh hưởng nhất, và dấu vết của nó cũng có thể cảm nhận được trong thiết kế của Forgejo và GitLab. Sự suy giảm của GitHub có thể mở đường cho nhiều forge khác nhau thoát khỏi mô hình hiện tại, nên có vẻ còn nhiều dư địa đổi mới
    • Trước đây Gitea gần như sao chép 1:1 frontend của GitHub, và khi Forgejo fork từ Gitea, nó cũng kế thừa nguyên dạng đó
  • Tôi là người tạo ra GitRoot; nếu có điều gì thắc mắc thì cứ thoải mái hỏi
    • Tôi có ba điều muốn hỏi. Tôi tò mò vì sao CSS được commit ở dạng đã minify: https://gitroot.dev/worktree/app/…
      Nguyên nhân khiến chiều rộng thẻ <pre> bị giới hạn ở 720px có vẻ là do display:grid của body; nếu bỏ thiết lập này thì nó mở rộng như mong đợi. Ngoài ra, URL không có thông tin về thời điểm commit cụ thể, nên người gửi liên kết và người nhận khó nhìn thấy cùng một màn hình. Tôi hiểu đây là dự án phục vụ nhu cầu cá nhân, và chỉ muốn chuyển tới vài điểm đáng cân nhắc
  • @manland, tôi muốn hỏi liệu có chính sách hoặc hướng dẫn nào cho phép hay cấm đóng góp được tạo bằng LLM không
    • Hiện tại chưa có chính sách riêng. Lý do là, ngoại trừ hai người đóng góp một lần, 99,999% mã đều do tôi tự viết
      Cá nhân tôi không dùng LLM để lập trình và phản đối việc đó, nhưng nếu bản vá đủ nhỏ thì tôi không chắc mình có từ chối chỉ vì đã dùng LLM hay không
      Vì tiếng Anh không phải tiếng mẹ đẻ nên tôi gặp khó khăn khi giải thích GitRoot, do đó trong giao tiếp đối ngoại có dấu vết của LLM. Trước đây tôi cũng từng nhờ giúp tại https://gts.gitroot.dev/@forge/statuses/01KFNWDKSZBEHTC16N5G02HJZ6 và https://gts.gitroot.dev/@forge/statuses/01KTP30NTY9FK91Q9B5Z9B4M52 nhưng không ai đến
      Việc phải dùng LLM khiến tôi buồn, nhưng thay vì không làm gì, tôi quyết định dùng ở mức tối thiểu. Nếu sau này có cộng đồng, tôi muốn loại bỏ hoàn toàn; cũng có thể trước đó nó sẽ tự biến mất vì lý do kinh tế. Trong danh sách việc cần làm có nhiều bài viết để giải thích triết lý, bảo mật và tương lai, nhưng cuối cùng ý nghĩ rằng LLM sẽ sửa câu, sửa lỗi chính tả hoặc dịch khiến tôi chần chừ không muốn viết
  • Tôi thích việc sử dụng TinyGo để biên dịch plugin Go sang WASM