Đánh giá mã Gerrit, hoặc mô hình ngã ba và kéo của Github?


64

Tôi đang bắt đầu một dự án phần mềm sẽ được nhóm VÀ cộng đồng phát triển. Trước đây tôi đã được bán trên gerrit, nhưng bây giờ mô hình yêu cầu kéo và ngã ba của Github dường như gần như cung cấp nhiều công cụ hơn, cách để trực quan hóa các cam kết và dễ sử dụng.

Đối với một người có ít nhất một chút kinh nghiệm với cả hai, ưu / nhược điểm của từng loại là gì và sẽ tốt hơn cho một dự án dựa trên nhóm muốn bỏ ngỏ khả năng phát triển cộng đồng?

Câu trả lời:


84

Sự khác biệt chính giữa quy trình công việc của Gerrit và GitHub là cách các thay đổi được mô hình hóa.

Trong Gerrit, mỗi cam kết là một thay đổi tự đứng vững. Mặc dù Gerrit sẽ cho bạn thấy các mối quan hệ giữa các lần xác nhận, các đánh giá được thực hiện trên cơ sở mỗi cam kết. Các nhóm giỏi phá vỡ các thay đổi lớn thành các cam kết nhỏ, khép kín có thể sẽ có nhiều thành công hơn với Gerrit. Tuy nhiên, vì mô hình của Gerrit bao gồm các phiên bản kế tiếp cho một cam kết cụ thể, nó khuyến khích các quy trình công việc của Git mà nhiều nhà phát triển không quen, chẳng hạn như sửa đổi một cam kết trước đó và đẩy lại nó, hoặc xóa một loạt các cam kết đang phát triển từ một nhánh chủ đề thành một cam kết.

Trong Github, một yêu cầu kéo mô hình mối quan hệ giữa hai nhánh. Quy trình công việc dự kiến ​​trên Github là cam kết một hoặc nhiều thay đổi trong một nhánh chủ đề (thường là trong một nhánh của kho lưu trữ, nhưng không nhất thiết) và tạo một yêu cầu kéo giữa nhánh đó và nhánh "ngược dòng". Trong trường hợp này, những gì đang được xem xét là một tập hợp các cam kết tiếp tục phát triển khi đánh giá tiếp tục. Kết quả là một tập hợp các thay đổi sau đó có thể được hợp nhất về nguyên tử khi chúng hoàn tất. Yêu cầu kéo có thể có hiệu quả trong việc theo dõi các thay đổi với phạm vi lớn hơn có thể được thực hiện qua nhiều lần xác nhận. Các yêu cầu kéo cũng hỗ trợ các quy trình công việc SCM mà nhiều nhà phát triển đã quen với, chẳng hạn như trả lời nhận xét đánh giá bằng cách gửi cam kết tiếp theo trong cùng chi nhánh.

Một lợi thế lớn có lợi cho Github là số lượng nhà phát triển quen thuộc với nó so với Gerrit. Gerrit có thể phổ biến với những người sử dụng năng lượng Git, nhưng việc sử dụng nó không có ma sát đòi hỏi kiến ​​thức git trung cấp hoặc nâng cao và khả năng chịu đựng một đường cong học tập dốc.

Lợi thế của Gerrit là mối quan hệ sâu sắc hơn với Git. Yêu cầu kéo của Github đã bị xóa đủ xa khỏi mô hình dữ liệu tiêu chuẩn của Git mà người ta phải sử dụng giao diện người dùng web của Github hoặc API độc quyền của nó để tạo yêu cầu kéo. Giao diện của Gerrit để tạo và cập nhật các thay đổi là chính giao thức git.


8
Cảm ơn Martin, đó là một câu trả lời thú vị. Tôi đã có ý định nhìn vào Gerrit một lúc, nhưng nghĩ rằng tôi sẽ tạm gác điều đó. Nếu nó khuyến khích lịch sử chỉnh sửa và xóa sổ cam kết, tôi không muốn làm gì với nó. * 8 '(
Đánh dấu gian hàng

15
Nói rõ hơn (tôi sử dụng Gerrit thường xuyên tại nơi làm việc của tôi), những gì Martin nói ở đây, "Gerrit ... khuyến khích quy trình làm việc của Git ... chẳng hạn như sửa đổi một cam kết trước đó và đẩy lại nó, hoặc xóa bỏ một loạt các cam kết ngày càng tăng. .. một cam kết duy nhất "là chính xác. Làm rõ của tôi là nhận xét của @ MarkBooth về "lịch sử chỉnh sửa" không phải là những gì Martin nói. Sửa đổi cam kết (trong khi vẫn còn trên Gerrit và chưa được hợp nhất với nguồn gốc / chủ) không liên quan đến "lịch sử chỉnh sửa". Trong thực tế, quy trình làm việc này hoạt động tuyệt vời. Chỉnh sửa lịch sử 'xấu' mà Mark Gian đề cập đến là đẩy lại lịch sử đã chỉnh sửa thành nguồn gốc / chủ.
likeethesky

2
Cảm ơn bạn đã làm rõ @likethesky nhưng tôi có một cách giải thích theo nghĩa đen hơn về 'lịch sử chỉnh sửa', và theo như tôi quan tâm, bất cứ điều gì dẫn đến những thay đổi có chứa nội dung mà bạn không cam kết rõ ràng là 'lịch sử chỉnh sửa'. Mặc dù vậy, tôi nhận ra rằng đây là một cách giải thích khá hà khắc và một điều mà ít người khác tuân thủ. * 8 ')
Đánh dấu gian hàng

2
Đủ công bằng. :-) Không chắc chắn tôi hiểu ý của bạn là gì bởi "những thay đổi có chứa nội dung mà bạn không cam kết rõ ràng", vì vậy xin vui lòng. giải thích ... Tôi cho rằng bạn không nói rằng bạn chưa bao giờ cam kết tạm thời (cục bộ hoặc chia sẻ giữa các thành viên trong nhóm thông qua các chi nhánh từ xa) như "WIP: điều này cố gắng giải quyết vấn đề vòm mà chúng ta đã thảo luận", tiếp theo là squash / sửa đổi hữu ích hơn nói rằng, "Vấn đề 123: XYZ được tái cấu trúc để tăng khả năng phục hồi và dễ dàng mở rộng theo chiều ngang" như một thông điệp cam kết cuối cùng cho công việc đó. Nhưng dù sao, tất nhiên bạn có thể chọn sử dụng git theo bất kỳ cách nào làm cho bạn hạnh phúc!
likeethesky

7
Đây là một câu trả lời tuyệt vời. Thêm vào đó, tôi đã thấy rằng các yêu cầu kéo của GitHub thúc đẩy các cam kết nhỏ hơn, lặp đi lặp lại nhiều hơn và thường kết thúc bằng một nhật ký git mô tả nhiều hơn, không chỉ hiển thị sản phẩm công việc mà cả quá trình làm việc. Đánh giá mã của Gerrit thúc đẩy lịch sử kho lưu trữ sạch hơn nhiều (có rất, rất ít các cam kết hợp nhất thực tế) với các cam kết lớn hơn, được đánh bóng hơn.
tophyr
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.