gitosis vs gitolite? [đóng cửa]


139

Tôi đang tìm cách cài đặt một máy chủ git để chia sẻ dự án với nhóm của tôi. Tôi không muốn tạo tài khoản người dùng trên máy chủ có quyền truy cập SSH cho mỗi nhà phát triển cần quyền truy cập git. Dường như có hai giải pháp đồng thời bao gồm vấn đề này: gitosis & gitolite.

Tôi không thể tìm thấy bất kỳ so sánh giữa cả hai giải pháp. Sự khác biệt chính giữa chúng là gì? Có giải pháp tương tự khác?

Câu trả lời:


191

Tôi đang tìm cách cài đặt một máy chủ git để chia sẻ dự án với nhóm của tôi.

Bạn chỉ có thể sử dụng git.

Để có một máy chủ git, điều duy nhất bạn cần trên máy chủ từ xa là git. Nếu bạn không yêu cầu các quyền chi tiết (chỉ chia sẻ với nhóm của bạn cho thấy đó là khả năng) hoặc bất kỳ tính năng bổ sung nào, bạn không cần gitolite hoặc tương tự.

Giải pháp không cài đặt

Nếu git có sẵn trên máy chủ từ xa, bạn có thể làm những gì bạn yêu cầu ngay bây giờ mà không cần làm gì

ssh [user@]server
cd repos/are/here/
mkdir project.git
cd project.git
git init --bare

Tại địa phương:

cd projects/are/here/project
git remote add origin [user@]server:repos/are/here/project.git
git push -u origin master

Thiết lập một máy chủ git rất dễ dàng.

Nếu bạn muốn làm mọi thứ với người dùng git chuyên dụng, các tài liệu để thiết lập máy chủ git rất ngắn - bởi vì nó thực sự khá dễ thực hiện.

Tóm tắt:

  • Cài đặt git
  • Tạo người dùng có tên git
  • Thêm khóa công khai của bạn và nhóm của bạn vào .ssh/authorized_keystệp của người dùng git
  • Thay đổi vỏ của người dùng git thành git-shell
  • Tạo repos trên máy chủ
  • bắt đầu git kéo / đẩy đến git@yourserver.com

Sự khác biệt duy nhất giữa việc sử dụng một người dùng git chuyên dụng và không, là nếu bạn thiết lập người dùng git để sử dụng git-shellthì nó sẽ không cho phép bản thân làm bất cứ điều gì khác. Về mặt hoạt động như một máy chủ git, nó giống hệt với giải pháp không cài đặt


13
Sau khi cài đặt con thú là GitLab + Gitolite, nếu bạn không cần kiểm soát tốt các dự án, v.v., đây là cách để đi.
Andrew T Finnell

Cảm ơn bạn cho câu trả lời này! Thực tế khi tôi nói rằng tôi không muốn tạo tài khoản người dùng cho từng tài khoản, tôi cũng nên đề cập rằng tôi không muốn người dùng git của mình có quyền truy cập vào vỏ máy chủ thông qua ssh. Với giải pháp của bạn, tôi nghĩ rằng họ sẽ có quyền truy cập vào shell thông qua người dùng "git", phải không?
greydet

2
@wsams: git push -u origin mastervà bạn có thể sử dụng git pushsau nó. Tôi thích gito * vì theo tôi, không ai truy cập repo nên phải quan tâm đến đường dẫn tuyệt đối mà nó có trên hệ thống từ xa.
ThiefMaster

8
@ThiefMaster đang đoán mò về ý của bạn, nếu bạn đặt repos trong /home/git/url để truy cập vào một dự án git@server:project.git.
AD7six

1
@wsams đọc phần này của câu trả lời "Thay đổi shell của git thành git-shell".
fabspro

142

Sự khác biệt chính là gitosis hiện đã lỗi thời, và không được duy trì tích cực nữa.

Gitolite có nhiều tính năng hoàn chỉnh hơn , và vừa phát hành phiên bản thứ ba .

Tính năng thú vị nhất của nó là Tham chiếu ảo (viết tắt là VREF) cho phép bạn khai báo bao nhiêu hook cập nhật theo ý muốn, cho phép bạn hạn chế đẩy bằng cách:

  • Tên tệp / thư mục :
    Giả sử bạn không muốn các nhà phát triển cơ sở đẩy các thay đổi vào Makefile, vì nó khá phức tạp:
    - VREF/NAME/Makefile = @junior-devs

  • số lượng tệp mới :
    Giả sử bạn không muốn các nhà phát triển cơ sở đẩy hơn 9 tệp cho mỗi lần xác nhận, vì bạn muốn họ thực hiện các cam kết nhỏ :
    - VREF/COUNT/9/NEWFILES = @junior-devs

  • phát hiện kiểu tệp nâng cao :
    Đôi khi một tệp có phần mở rộng tiêu chuẩn (không thể là 'gitignore'd), nhưng nó thực sự được tạo tự động. Đây là một cách để bắt nó:
    - VREF/FILETYPE/AUTOGENERATED = @all
    Xem src/VREF/FILETETYPEđể xem cơ chế phát hiện.

  • kiểm tra email tác giả :
    Một số người muốn đảm bảo rằng "bạn chỉ có thể thực hiện các cam kết của riêng mình".
    - VREF/EMAIL-CHECK = @all
    Xem src/VREF/EMAIL-CHECK.

  • bỏ phiếu cho các cam kết :
    Việc triển khai cơ bản bỏ phiếu cho một cam kết rất dễ dàng đáng ngạc nhiên :
    - VREF/EMAIL-CHECK = @all.
    # 2 votes required to push master, but trusted devs don't have this restriction
    # RW+ VREF/VOTES/2/master = @trusted-devs
    # - VREF/VOTES/2/master = @devs
    Xem src/VREF/VOTESđể thực hiện.

  • và như thế...


3
Tôi đã sử dụng Gitolite được hơn 3 năm rồi. Chưa bao giờ có vấn đề gì với nó. Tôi các máy chủ sản xuất và dàn của chúng tôi có quyền truy cập chỉ đọc vào các repos cần thiết. Và đó là một công việc dễ dàng để chia sẻ một dự án với các nhóm Phát triển khác. Ngoài ra, thật dễ dàng để thiết lập nếu bạn đã biết unix và git :)
tuân thủ

Tài liệu về Gitolite bao gồm các so sánh với các lựa chọn thay thế: gitolite.com/gitolite/gitolite.html#alt
Quinn Comendant

15

Chỉ là một sidenote. Bạn cũng có thể sử dụng Gerrit cho nhu cầu của mình:

Đánh giá mã Gerrit

Đầu tiên, có vẻ như Gerrit được sử dụng để đánh giá Mã, nhưng bạn thực sự có thể sử dụng nó để quản lý người dùng và cung cấp cho họ các quyền được xác định tốt. Bạn có thể bỏ qua việc xem lại mã ( điều khiển truy cập máng ) và sử dụng nó chỉ để quản lý các dự án và khóa ssh. Gerrit có một cơ chế kiểm soát truy cập thực sự mạnh mẽ:

Kiểm soát truy cập Gerrit

Bạn có thể hạn chế đẩy cho bất kỳ chi nhánh, thẻ hoặc bất cứ điều gì bạn có thể tưởng tượng được xác định trong tài liệu kiểm soát truy cập.


8

Đối với một giải pháp thậm chí nhanh hơn và bẩn hơn, chỉ cần sử dụng git daemon và đi ngang hàng. Đây là một bài viết về làm điều đó.

Chỉnh sửa: Tôi nhận ra điều này không trả lời đúng câu hỏi của OP. Tôi đặt cái này ở đây chủ yếu cho những người, như tôi, người bắt gặp điều này trong khi tìm kiếm một cách bẩn thỉu để chia sẻ mã cho đến khi tài khoản github của doanh nghiệp được thiết lập.


2

Tôi đã loay hoay một lúc để có một máy chủ git hoạt động với quyền truy cập LDAP, kiểm soát truy cập chi tiết, v.v ... Tìm thấy một tiết lộ: Sử dụng Gitlab :

  • kho git
  • truy cập hạt mịn (afaik gitlab sử dụng gitolite dưới mui xe)

nếu bạn muốn phương pháp cài đặt nhanh và nhanh: sử dụng trình cài đặt bitnami


Có, nhưng GitLab (có vỏ gitlab) đã mất tất cả các móc VREF mà bạn có thể dễ dàng thiết lập với Gitolite. Và rất nhiều người muốn họ quay lại: github.com/gitlabhq/gitlab-shell/issues/14github.com/gitlabhq/gitlab-shell/pull/85
VonC
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.