Gitea: nền tảng Git tự lưu trữ trọn gói cho phòng kỹ thuật nhỏ
Đăng ngày 12/10/2026
Mục lục bài nghiên cứu
Gitea từ góc nhìn người quyết định: kho mã, review và CI trong một dịch vụ tự lưu trữ
Gitea là phần mềm tự lưu trữ (self-hosted) gom nhiều việc của một nhóm phát triển vào một dịch vụ: lưu kho Git, quản lý mã, review, theo dõi vấn đề, bảng kanban dự án, wiki, cộng tác nhóm, kho gói (package registry) và CI/CD có thể dùng lại workflow kiểu GitHub Actions. Đó là mục tiêu mà README tự nêu, kèm cam kết thiết lập dễ, nhanh và ít đau đầu nhất. [1]
Bài viết đánh giá Gitea cho phòng công nghệ của một đài truyền hình địa phương ở Việt Nam. Kết luận sơ bộ: đáng thử nếu đơn vị muốn giữ mã nguồn, tài khoản và lịch sử thay đổi trong hạ tầng của mình, có ít nhất một người đủ kỹ năng vận hành máy chủ, và chấp nhận tự chịu trách nhiệm cập nhật bản vá. Không nên chọn nếu không có người vận hành, hoặc nếu chỉ cần chỗ lưu vài kho nhỏ mà dịch vụ thuê ngoài đã đáp ứng.
Có hai điểm cần đọc kỹ trước khi cam kết. Thứ nhất, chính sách bản vá bảo mật chỉ bao gồm bản chính mới nhất và nhánh main, nên trì hoãn nâng cấp là rủi ro thật. [3] Thứ hai, dự án có một công ty đứng sau tham gia ban điều hành kỹ thuật, nên cần hiểu rõ ranh giới giữa phần mềm mã nguồn mở và các dịch vụ thương mại đi kèm. [6][1]
Vì sao một đài truyền hình khu vực cần kho mã riêng thay vì thư mục chia sẻ
Đài truyền hình địa phương ngày nay không chỉ phát sóng. Phòng kỹ thuật thường duy trì website, ứng dụng di động, công cụ xuất lịch phát sóng, tập lệnh chuyển tệp giữa các hệ thống, và cấu hình cho đồ họa trên màn hình. Nếu các thứ đó sống trong thư mục mạng dùng chung và các tệp nén gửi qua chat, câu hỏi như ai sửa dòng nào, khi nào, vì sao, và bản nào đang chạy khi phát sóng không có câu trả lời đáng tin.
Gitea nhắm đúng khoảng trống này: cung cấp kho Git, review mã và theo dõi vấn đề trong cùng một nơi do chính đơn vị kiểm soát. [1] Việc tự lưu trữ đặc biệt phù hợp khi tổ chức nhạy cảm về nơi đặt dữ liệu, ví dụ tập lệnh chứa địa chỉ nội bộ của hệ thống phát sóng. Đây là lập luận phân tích của bài viết, không phải tuyên bố từ dự án.
Điều Gitea không giải quyết là lưu trữ tệp media dung lượng lớn. Mã nguồn có thư mục xử lý Git LFS, kèm giấy phép riêng ghi nhận nguồn gốc từ máy chủ kiểm thử LFS của GitHub, cho thấy có hỗ trợ ở mức mã. [8] Tuy vậy, tài liệu đã đọc không trình bày cách dùng hay giới hạn dung lượng, nên bài này không khuyến nghị đưa video vào kho.
Chi, XORM và quy tắc phụ thuộc một chiều của backend
Hướng dẫn backend của dự án cho biết phần máy chủ viết bằng Go, định tuyến web dùng chi và truy cập cơ sở dữ liệu qua XORM. [5] Các gói cấp cao nhất có phân vai rõ: cmd chứa các lệnh con như web, serv, hooks, doctor; models chứa cấu trúc dữ liệu và thao tác cơ sở dữ liệu; services chứa nghiệp vụ nối router với model; routers xử lý yêu cầu và tách thành api, web, install, private. [5]
Quy tắc đáng giá nhất cho người đánh giá là hướng phụ thuộc: cmd gọi routers, routers gọi services, services gọi models, models gọi modules, và không đi ngược. [5] Một kiến trúc phân tầng như vậy giúp việc đọc mã, viết thử nghiệm và đoán tác động của một thay đổi bớt khó. Tài liệu cũng quy định các thao tác phải hoàn tác cùng nhau thì chạy trong giao dịch qua một hàm riêng. [5]
Giao diện web dùng bộ khuôn HTML của Go. Tài liệu thừa nhận loại khuôn này yếu kiểu và khó bảo trì, và nêu điều kiện để thay thế: cần một bản thử nghiệm chạy được cho các màn hình phức tạp như xem pull request, cùng cam kết đủ nhân lực. [5] Đây là ví dụ về một nợ kỹ thuật được ghi nhận công khai.
Một lần push, một pull request, một job Actions: dòng chảy dữ liệu và quyền
Nguồn đã đọc không có sơ đồ luồng dữ liệu hoàn chỉnh, nên đoạn này ghép từ các mô tả rời và đánh dấu rõ phần suy luận. Một lập trình viên đẩy mã lên; phần hạ tầng xử lý có thể dựa trên các lệnh con như serv và hooks mà tài liệu backend liệt kê (đây là suy luận, tài liệu không mô tả luồng này). [5] Yêu cầu web hoặc API đi qua router, rồi tầng dịch vụ, rồi tầng model ghi vào cơ sở dữ liệu theo đúng chiều phụ thuộc đã nêu. [5]
Khi quy trình CI chạy, điểm đáng chú ý là mã thông báo tự động GITEA_TOKEN sinh cho mỗi job. Quyền của nó được tính qua nhiều bước: lấy quyền cơ sở từ khối permissions của workflow, nếu không có thì dùng chế độ mặc định của kho; sau đó kẹp theo trần quyền cấp kho; cuối cùng kẹp theo trần cấp tổ chức hoặc người dùng. [4] Mô tả này lấy từ tài liệu thiết kế nội bộ, không phải hướng dẫn người dùng.
Với pull request từ bản fork, tài liệu nói workflow luôn chạy ở chế độ hạn chế, quyền chuyển về đọc hoặc không có, và truy cập chéo sang kho riêng tư bị từ chối bất kể cấu hình. [4] Mặc định, token đọc được kho đang chạy và các kho công khai; việc đọc thêm kho riêng tư của cùng chủ sở hữu phải khai báo trong một danh sách cho phép. [4]
Danh mục tính năng được README và tài liệu xác nhận
Theo README, nền tảng bao gồm lưu kho Git, quản lý mã, review mã, theo dõi vấn đề, bảng kanban dự án, wiki, cộng tác nhóm, kho gói và CI/CD có thể tái sử dụng GitHub Actions. [1] Ảnh chụp trong README còn minh họa trang tổng quan người dùng, kho, issue, pull request, hoạt động và tổ chức, nhưng bài này không dựa vào ảnh để khẳng định chi tiết chức năng. [1]
Về API: tài liệu backend nói API phiên bản 1 được mô tả bằng Swagger và mô phỏng theo API của GitHub, dùng cùng điểm cuối và trường dữ liệu khi có thể. [5] Mọi danh sách phải hỗ trợ phân trang. Đồng thời tài liệu ghi rõ API v2 hiện không nằm trong kế hoạch. [5]
Về Actions: tài liệu thiết kế mô tả hai chế độ quyền token, Permissive và Restricted, cùng phạm vi như mã, phát hành, vấn đề, pull request, Actions, wiki và dự án. [4] Phạm vi gói được hỗ trợ trong khối permissions nhưng hiện ẩn khỏi giao diện cài đặt. [4] Phần ý tưởng về quyền gói theo cấp chủ sở hữu trong cùng tài liệu chỉ là hướng thiết kế đề xuất ("một cách tiếp cận khả dĩ"), không nên đọc thành tính năng đã có. [4]
Đội nào nên chọn, đội nào nên thuê dịch vụ ngoài
Gitea hợp với tổ chức vừa và nhỏ có đủ ba điều kiện: muốn kiểm soát dữ liệu, có người biết vận hành dịch vụ web kèm cơ sở dữ liệu, và cần nhiều chức năng cộng tác ngoài việc lưu mã. README định vị nó là dịch vụ phát triển phần mềm trọn gói chứ không chỉ máy chủ Git. [1]
Nhóm thứ hai là đội đã quen quy trình của GitHub. Vì API và cách dùng Actions hướng tới tương thích, chi phí chuyển đổi tư duy có thể thấp hơn. [5][1] Mức tương thích thực tế cần kiểm tra bằng thử nghiệm, vì tài liệu tự nói chỉ dùng cùng điểm cuối khi có thể.
Nhóm không phù hợp: đơn vị không có ai trực hệ thống, hoặc cần cam kết mức dịch vụ bằng hợp đồng mà phần mềm mã nguồn mở tự vận hành không cung cấp. Với họ, README nhắc đến lựa chọn Gitea Cloud có bản dùng thử miễn phí và dịch vụ gitea.com miễn phí với số kho giới hạn, đều là dịch vụ do dự án vận hành; điều khoản chi tiết nằm ngoài các tài liệu đã đọc. [1]
Đề xuất: phòng công nghệ của một đài truyền hình địa phương (giả định)
Đây là tình huống giả định để minh họa cách đánh giá, không phải một triển khai đã xảy ra. Hình dung một đài truyền hình cấp tỉnh có đội kỹ thuật số khoảng sáu người, gồm lập trình viên web, một kỹ sư hệ thống phát sóng và một người phụ trách ứng dụng di động. Mã nguồn hiện nằm rải rác trong máy cá nhân và tệp nén.
Đề xuất giai đoạn đầu: dựng một phiên bản Gitea trong mạng nội bộ cho ba loại kho. Một là website và ứng dụng. Hai là tập lệnh vận hành như xuất lịch phát sóng sang định dạng mà hệ thống khác nhận. Ba là cấu hình và mẫu đồ họa dạng văn bản. Theo README, đơn vị có thể triển khai bằng ảnh container chính thức. [1] Hệ thống theo dõi vấn đề thay cho bảng tính để ghi yêu cầu từ ban biên tập, và quy trình pull request bắt buộc có người thứ hai xem, tương tự thông lệ mà chính dự án áp dụng khi yêu cầu hai người duy trì duyệt mỗi thay đổi. [6]
Điều kiện an toàn đề xuất: không lưu tệp video hoặc tư liệu chưa phát trong kho; quyền Actions để ở chế độ hạn chế mặc định và chỉ nâng khi cần, phù hợp với cơ chế kẹp quyền trong tài liệu thiết kế. [4] Mọi tài khoản có quyền ghi bật xác thực hai lớp, một yêu cầu mà chính dự án áp dụng cho tài khoản có quyền ghi. [6]
Vận hành: cấu hình tĩnh và động, bản phát hành, nâng cấp
Tài liệu của dự án phân biệt hai loại cấu hình: tùy chọn động chỉnh trong trang quản trị, và tùy chọn tĩnh sửa tệp app.ini rồi khởi động lại. [1] Bảng tra cứu đầy đủ nằm ở trang tài liệu chính thức, mà bài chưa đọc. [1]
Về phiên bản, quy trình phát hành mô tả nhánh main là nhánh đầu ngọn, còn các nhánh phát hành được gắn thẻ để tải nhị phân. Nếu muốn chạy thật, tài liệu khuyên dùng thẻ phát hành mới nhất thay vì main. [7] Chính sách backport cho biết nhóm chuyển các sửa lỗi, sửa bảo mật và cải tiến nhỏ về nhánh cũ, nhưng không chuyển tính năng mới. [7]
Chu kỳ phát hành: tài liệu nêu mục tiêu một bản chính mỗi ba đến bốn tháng và liệt kê lịch từ tháng 4 đến tháng 12 năm 2026. [7] Tuy nhiên, các ví dụ trong chính tài liệu đó dùng số phiên bản như 28.0.1 và nhánh release/v29, còn bản phát hành mới nhất trong dữ liệu thu thập mang số 28.1.0. [7] Dòng lịch với số 1.26 đến 1.29 và các ví dụ này không khớp hoàn toàn, nên đơn vị cần xác nhận lược đồ đánh số hiện hành trên trang chính thức trước khi viết quy trình nâng cấp.
Bảo mật: kẹp quyền token Actions, báo cáo lỗ hổng, 2FA của người duy trì
Cơ chế nổi bật nhất trong nguồn là kẹp quyền cho GITEA_TOKEN. Quyền workflow yêu cầu luôn bị giới hạn bởi trần cấu hình ở kho và ở tổ chức; nếu tổ chức đặt trần chỉ đọc và kho không bật ghi đè, không kho nào dưới tổ chức đó cấp được quyền ghi. [4] Khối permissions rỗng nghĩa là thu hồi toàn bộ quyền. [4] Đây là hướng thiết kế an toàn theo mặc định, nhưng tài liệu thiết kế không thay thế kiểm thử cấu hình thực tế.
Về quy trình lỗ hổng: SECURITY.md yêu cầu không mở issue công khai mà báo riêng qua advisory trên GitHub hoặc thư tới địa chỉ bảo mật của dự án; chỉ bản chính mới nhất và nhánh main nhận bản vá, báo cáo chỉ ảnh hưởng bản không được hỗ trợ sẽ bị đóng. [3] Với người dùng, hệ quả là phải duy trì nhịp nâng cấp.
Về chuỗi cung ứng: tài liệu quản trị dự án quy định mọi tài khoản có quyền ghi, kể cả bot, phải bật 2FA, và thay đổi phải được xem xét trước khi nhập. [6] Đây là kiểm soát phía dự án, không thay thế rà soát của đơn vị khi nâng cấp.
MIT, tác giả Gogs và ranh giới với thành phần khác
Tệp LICENSE ở gốc là giấy phép MIT với dòng bản quyền của những người đóng góp Gitea từ năm 2016 và của các tác giả Gogs từ năm 2015. [2] README cũng nói dự án được cấp phép MIT và dẫn tới tệp này. [1] MIT cho phép dùng, sao chép, sửa đổi, phân phối và bán, miễn giữ thông báo bản quyền. [2]
Không dừng ở đó: mô-đun xử lý LFS có tệp giấy phép riêng ghi bản quyền của những người đóng góp Gitea và của GitHub cùng người đóng góp máy chủ kiểm thử LFS. [8] Nội dung đọc được là giấy phép dạng MIT, nhưng điều đó chỉ đúng với thư mục này. Các thư viện Go và thành phần giao diện đi kèm có giấy phép riêng; bài này chưa rà soát chúng.
Cần phân biệt phần mềm với dịch vụ. Giấy phép MIT áp dụng cho mã tại commit đã ghim, không áp dụng cho dữ liệu của bạn, các dịch vụ do công ty vận hành như Gitea Cloud hay gitea.com mà README nhắc đến, hay các dự án bên thứ ba. [2][1] Điều khoản dịch vụ thương mại nằm ngoài nguồn đã đọc. Bài này cũng không tìm thấy trong nguồn đã đọc điều khoản CLA hay chính sách nhãn hiệu, nên không kết luận về hai điểm đó.
Về tổ chức: tài liệu quản trị nói ban điều hành kỹ thuật có sáu vị trí, ba do cộng đồng bầu và ba do công ty Gitea chỉ định. [6] Điều này không đổi giấy phép mã, nhưng ảnh hưởng đến cách bạn đánh giá rủi ro định hướng dự án dài hạn.
Nguồn lực cần có để tự vận hành một nền tảng phát triển
Một là máy chủ: một máy ảo hoặc máy vật lý đủ cho ứng dụng Go, cơ sở dữ liệu và ổ lưu kho. Cấu hình cụ thể phụ thuộc số người dùng, kích thước kho và việc có chạy CI hay không. Hai là runner cho Actions: máy chạy job tách khỏi máy chủ chính là một thiết kế hợp lý, vì README nhắc đến runner riêng dành cho Actions. [1] Ba là sao lưu và nơi lưu bản sao, gồm cơ sở dữ liệu lẫn dữ liệu kho.
Bốn là thời gian vận hành: người cài đặt, theo dõi bản vá, thử nghiệm nâng cấp. Với chính sách chỉ vá bản chính mới nhất, thời gian nâng cấp định kỳ là khoản chi lặp lại, không phải một lần. [3] Năm là thời gian đào tạo cho người đã quen công cụ khác.
Phương án thay thế là thuê dịch vụ do dự án vận hành, mà README nhắc đến, hoặc dịch vụ khác; khi đó chi phí chuyển từ nhân lực sang phí thuê bao mà bài này không có số liệu. [1] Cần tính cả chi phí cơ hội của việc người giỏi nhất trong phòng phải trực hạ tầng thay vì làm sản phẩm.
Đặt cạnh các lựa chọn khác theo cách tiếp cận
Có thể so sánh theo bốn cách tiếp cận. Một là dịch vụ lưu mã đám mây của bên thứ ba, ví dụ GitHub hay GitLab: ít việc vận hành, nhưng dữ liệu nằm ở nơi khác và điều khoản do nhà cung cấp quy định. Hai là phần mềm tự lưu trữ trọn gói như Gitea hoặc phiên bản tự quản của GitLab: kiểm soát cao hơn, đổi lại phải tự vận hành. Ba là chỉ máy chủ Git cùng công cụ rời ghép lại, gọn nhẹ nhưng mất sự thống nhất. Bốn là giữ thư mục chia sẻ, rẻ nhất lúc đầu nhưng mất truy vết.
Bài viết không có nguồn đo lường để so sánh tài nguyên hay tính năng giữa Gitea và các sản phẩm này, nên không kết luận bên nào tốt hơn. Điều nguồn cho phép nói là Gitea chọn mục tiêu một dịch vụ trọn gói, dùng được trên nhiều hệ điều hành, viết bằng Go, và có API mô phỏng GitHub. [1][5]
Điều tài liệu chưa nói và những trường hợp nên tránh
Trước hết là các khoảng trống về bằng chứng. Các tài liệu đã đọc không công bố số liệu hiệu năng, giới hạn quy mô hay khuyến nghị cấu hình phần cứng, nên mọi tính toán dung lượng phải tự đo. Danh sách tính năng Actions tương thích với GitHub cũng không được liệt kê đầy đủ ở đây.
Thứ hai là rủi ro bản vá. Chỉ bản chính mới nhất và main nhận sửa lỗi bảo mật, nên một đơn vị chậm nâng cấp có thể rơi ngoài hỗ trợ. [3] Thứ ba là sự không nhất quán về số phiên bản giữa lịch trong tài liệu và các ví dụ, như đã nêu ở phần vận hành. [7]
Không nên dùng khi: không có người trực vận hành; cần lưu tệp media lớn trong kho; cần cam kết dịch vụ bằng hợp đồng nhưng không mua dịch vụ thương mại; hoặc hệ thống phát sóng quan trọng phụ thuộc trực tiếp vào việc triển khai từ máy chủ mã mà chưa có kiểm soát thay đổi riêng. Với nhóm chỉ có hai, ba người và vài kho nhỏ, chi phí vận hành có thể lớn hơn lợi ích.
Thử trong sáu tuần với một nhóm và một kho
Đề xuất kế hoạch, chưa thực hiện. Mục tiêu: xác định Gitea có đáp ứng nhu cầu quản lý mã và review của phòng kỹ thuật mà không tạo gánh nặng vận hành quá mức.
Giai đoạn 1, hai tuần đầu: dựng một bản trên máy thử trong mạng nội bộ, từ ảnh container chính thức theo README. [1] Nhập hai kho ít quan trọng, tạo tổ chức, nhóm và quyền. Kiểm tra quy trình sao lưu và khôi phục sang máy khác. Chỉ tiêu: khôi phục thành công toàn bộ kho và tài khoản trong một giờ làm việc.
Giai đoạn 2, hai tuần giữa: dùng cho một dự án thật, bắt buộc review bởi người thứ hai, thử một workflow Actions đơn giản với runner riêng, quyền token để chế độ hạn chế. [4] Chỉ tiêu: ít nhất 80 phần trăm thay đổi đi qua pull request, và không có job nào được cấp quyền rộng hơn thiết kế.
Tiêu chí đạt: khôi phục thành công; nâng cấp thử không mất dữ liệu; ít nhất bốn trong sáu người đánh giá quy trình mới rõ ràng hơn cách cũ; thời gian vận hành thực tế không vượt mức nhóm đã chấp nhận từ đầu. Tiêu chí dừng: không khôi phục được từ sao lưu, hoặc nâng cấp thử gây mất dữ liệu, hoặc không ai nhận trách nhiệm vận hành. Các ngưỡng là đề xuất để đội điều chỉnh.
Kết luận
Gitea là nền tảng tự lưu trữ trọn gói, giấy phép MIT, viết bằng Go, có tài liệu thiết kế công khai về quyền của Actions và quy trình phát hành. [1][2][4][7] Với một đài truyền hình địa phương muốn đưa mã và cấu hình kỹ thuật vào nơi có truy vết, đây là ứng viên hợp lý cho một đợt thử có kiểm soát.
Điều kiện đi kèm là có người vận hành, giữ nhịp nâng cấp vì chính sách bản vá hẹp, và không đưa tệp media lớn vào kho. [3] Các lợi ích nêu trong bài đều là kỳ vọng suy ra từ tài liệu, chưa được kiểm chứng bằng thử nghiệm của bất kỳ đơn vị nào.
Nguồn đã đọc và cách chọn Gitea
Đây là nghiên cứu tài liệu tại một commit cố định, không phải ấn phẩm khoa học được bình duyệt. Chúng tôi không cài, không chạy, không đo và không triển khai Gitea.
Gitea được chọn từ kho lưu trữ các trang GitHub Trending, danh sách ngôn ngữ Go, với 19 lần quan sát từ ngày 10 tháng 2 đến ngày 7 tháng 10 năm 2026; trang bằng chứng ví dụ là ngày 10 tháng 2 năm 2026. [9] Kho lưu trữ chỉ gồm danh sách Python, Go, JavaScript và Swift, thiếu ngày 3 tháng 9 và 12 tháng 10 năm 2026, và không phải bảng xếp hạng top 100 chính thức.
Commit kiểm tra là aa32eb97fad8224cc0ef9d4b40df255b8026dd49, ngày commit 11 tháng 10 năm 2026, đối chiếu ngày 12 tháng 10 năm 2026. Tệp đã đọc: README [1], LICENSE [2], SECURITY.md [3], thiết kế quyền token Actions [4], hướng dẫn backend [5], quản trị cộng đồng [6], quản lý phát hành [7] và giấy phép mô-đun LFS [8].
Bản phát hành 28.1.0 lấy từ dữ liệu phát hành thu thập kèm theo, không từ tệp trong kho. Không đọc: tài liệu trên trang docs.gitea.com, CONTRIBUTING, mã nguồn Go, tệp cấu hình mẫu. Tình huống đài truyền hình là đề xuất giả định. Tài liệu có thể đã đổi sau commit này.
Xem mã nguồn Gitea trên GitHub