2010-12-10 40 views
13

Tôi muốn buộc các thành viên khác không làm việc trên nhánh chính nhưng trên một nhánh phát triển. chúng tôi có một kho git trung tâm, nơi chúng tôi đẩy công việc của mình vào. tôi muốn biết nếu có thể chặn người dùng đẩy các thay đổi vào nhánh chính nhưng chỉ cho phép một số người dùng nhất định làm như vậy.git - khóa nhánh chính cho một số người dùng?

Tôi muốn có sau "công việc"

  • phát triển luôn luôn là chỉ thực hiện với một sự phát triển ngành
  • việc phát hành-quản lý chịu trách nhiệm về chi nhánh tổng thể và duy nhất anh được phép sáp nhập từ một nhánh phát triển vào master và đẩy nó vào master-branch trên kho trung tâm.

Điều này có thể và làm cách nào tôi có thể đạt được điều này?

+0

Kiểm soát truy cập được thuê ngoài từ git đến hệ điều hành đang chạy máy chủ. Nếu bạn đang chạy máy chủ của riêng mình, tôi khuyên bạn nên cài đặt gitosis: http://scie.nti.st/2007/11/14/hosting-git-repositories-the-easy-and-secure-way – blueberryfields

+0

cảm ơn, Tôi sẽ xem xét gitosis ... – aurora

+0

Tôi nghĩ rằng đó là chính xác vì 'git' được phân phối, bạn không cần phải kiểm soát quyền vì không có kho 'chia sẻ' tồn tại? Nói cách khác, bất kỳ thành viên nhóm nào làm việc trên dự án cũng sẽ làm việc trên bản sao kho lưu trữ của chính họ và đó là người duy trì hợp nhất các nhánh vào một kho lưu trữ 'master' (chỉ là tên cho nó, không bị nhầm lẫn với nhánh chính). – amn

Trả lời

6

Xem man githooks: Trong repo được chia sẻ, bạn có thể tạo tập lệnh $(git rev-parse --git-dir)/hooks/pre-receive hoặc $(git rev-parse --git-dir)/hooks/update để xác minh những gì người dùng của bạn đang cố gắng đẩy vào các lần chỉnh sửa nào. Git đi kèm với một móc ví dụ update-paranoid thực thi ACL mỗi ref.

+0

cảm ơn ... githook có vẻ rất mạnh mẽ. tôi sẽ xem xét cả gitosis và githooks – aurora

+0

Ai đó có thể mở rộng về điều này? Tôi đã nhìn vào móc nối '[update-paranoid] (http://git.kernel.org/cgit/git/git.git/tree/contrib/hooks/update-paranoid?id=HEAD)' nhưng tôi không chắc tôi hiểu ACL sẽ như thế nào đối với nhiều người dùng. Có phải người dùng sẽ có nhiều mục nhập cho các ủy viên được cho phép trong biểu mẫu: 'committer = John Doe <[email protected]>' và điều này có thể được sử dụng cho người dùng N như: ' committer = John Doe < [email protected]> committer = User2 <[email protected]> committer = User3 <[email protected]> ' ? – blong

+0

@ b.long: 'update-paranoid' dự kiến ​​một' người dùng/$ {USER} .acl' trong '/ vcs/acls.git' repo (không * này * repo) cho mỗi đăng nhập SSH; trong mỗi, có thể có nhiều 'committer =' dòng như mong muốn. Nhưng có thể bạn sẽ muốn sửa đổi hoặc viết lại kịch bản để sử dụng cho riêng bạn. – ephemient

1

Cách tiếp cận mức thấp của tôi chỉ đơn giản là để cho RM là người duy nhất có khóa SSH để đẩy tới kho lưu trữ mà mọi người khác sử dụng làm đường cơ sở chính. Bằng cách đó, không ai ngoài RM có thể thúc đẩy để làm chủ - nhưng mọi người đều có thể làm việc vì họ có các chi nhánh phát triển địa phương của riêng họ và các nhà phát triển có thể chia sẻ với nhau những nhánh họ thích.

Bước tiếp theo là làm thử nồi nấu ăn cho những thứ sẽ sớm đi vào chính. Nồi này thường được gọi là next hoặc dev. Ý tưởng là, càng có nhiều tác động mà một chi nhánh có, thì nó càng dài hơn trước khi hợp nhất để làm chủ. Điều này mang lại cho RM toàn quyền kiểm soát những nhánh nào nên tốt nghiệp và vẫn cho mọi người một cái đầu.

+0

cảm ơn. tôi nghĩ về ssh, quá và nó sẽ được khá dễ dàng để thiết lập. nhưng tôi nghĩ rằng nên có 'tốt hơn' cách ...? – aurora

Các vấn đề liên quan