Gerrit, git và xem xét toàn bộ chi nhánh

8

Bây giờ tôi đang học Gerrit (đây là công cụ đánh giá mã đầu tiên tôi sử dụng). Gerrit yêu cầu thay đổi được xem xét để bao gồm một cam kết duy nhất. Chi nhánh tính năng của tôi có khoảng 10 cam kết.

Cách ưa thích của gerrit là ép 10 cam kết đó thành một lần duy nhất. Tuy nhiên theo cách này nếu cam kết sẽ được sáp nhập vào nhánh mục tiêu, lịch sử nội bộ của nhánh tính năng đó sẽ bị mất. Ví dụ: tôi sẽ không thể sử dụnggit-bisect để chia đôi những cam kết đó. Tôi có đúng không

Tôi hơi lo lắng về tình trạng này. Lý do cho sự lựa chọn này là gì? Có cách nào để làm điều này trong Gerrit mà không mất lịch sử?

git code-reviews gerrit

— liori
nguồn

1

điều này có thể phù hợp hơn trong stackoverflow

1

Tôi không có bất kỳ kinh nghiệm nào với Gerrit. Tôi đã sử dụng Atlassian FishEye + Crucible và nó không có ràng buộc này. Có thể thêm các cam kết bổ sung vào một đánh giá không? Bạn có thể phải làm điều đó bằng tay.

— Andrew T Finnell

Theo tôi biết, Gerrit không hỗ trợ xem xét chi nhánh. Nó chỉ hỗ trợ xem xét và phê duyệt một bản vá duy nhất tại một thời điểm. Và họ tuyên bố rằng đó là một tính năng, không phải là một lỗi. Tôi không đồng ý và tôi đang tìm kiếm một công cụ có thể xem xét toàn bộ chi nhánh và về cơ bản hoặc phê duyệt chi nhánh hoặc không chấp thuận toàn bộ chi nhánh (và vẫn nhận được nhận xét trên mỗi bản vá / dòng).

— Mikko Rantalainen

2

Đánh giá mã có tác động tốt nhất khi nó là một hook pre-commit (pre-push trong trường hợp git). Nếu một lỗi gặp phải trong 5 trong số mười lần cam kết của bạn, bạn sẽ sửa nó như thế nào (bảo tồn lịch sử)? Chắc chắn, bạn có thể tạo một nhánh chủ đề khác, sửa lỗi cam kết đó, chọn 5 cam kết còn lại và gửi lại các khác biệt để xem xét, nhưng điều này rất phức tạp (mặc dù bạn có thể viết một kịch bản cho nó).

Các thay đổi được thực hiện cho một repo duy nhất nên duy trì trạng thái của nó (ví dụ: không phá vỡ bản dựng, kiểm tra, v.v.) Vì vậy, nếu các thay đổi của bạn được thực hiện theo cách này, chúng có thể được xem xét riêng, nếu không, xóa chúng sẽ tốt hơn so với rời khỏi repo không nhất quán

Bạn có thể tạo một lỗi trong trình theo dõi lỗi và đặt một tham chiếu trong mỗi cam kết, để người đánh giá và người đọc trong tương lai biết, bạn đang cố gắng đạt được điều gì.

— vissi
nguồn

2

Bạn sẽ sửa nó như thế nào - lỗi xảy ra, và bây giờ chúng tôi đã đủ để khắc phục sự cố trong bất kỳ cam kết nào sau này, miễn là nhánh chính trên máy chủ trung tâm không bao giờ trực tiếp chỉ ra bất kỳ cam kết nào giữa lỗi và sửa chữa. Vì vậy, trong trường hợp này, tôi sẽ đặt bản sửa lỗi là cam kết thứ mười một trong nhánh được xem xét. Là phương pháp này là một điều xấu?

— liori

1

Tiếp tục hội nhập thì sao? bạn đã thực hiện 10 lần cam kết trên một nhánh tính năng và nó sẽ được "xuất bản" cùng một lúc - đó sẽ là một tác động lớn đối với những người khác nên xem lại các cam kết / thay đổi đó.

Tuy nhiên, đáng để đẩy 10 lần xác nhận, nếu các xác nhận chứa các sửa đổi mã riêng biệt. Nhưng trong trường hợp các xác nhận chứa các sửa đổi liên tục trên một tính năng duy nhất (do đó, hầu hết các cam kết chỉ sửa chữa hoặc trạng thái trung bình của việc thực hiện định nghĩa hàm đang diễn ra) thì tốt hơn là nén chúng thành một cam kết duy nhất.

Nói chung, hãy suy nghĩ với các nhà phê bình - kích thước của một sửa đổi mã có thể được xem xét dễ dàng là gì.

Lưu ý: Gerrit không chỉ để xem lại mã - các thay đổi sẽ kích hoạt một số thử nghiệm chấp nhận. (kiểm tra đơn vị, kiểm tra khói) Vì vậy, nếu bạn có những thứ đó, thì việc xuất bản mã bị lỗi sẽ khó hơn. Vì vậy, từ quan điểm này, một cam kết nên chứa những thay đổi như vậy đáng để kiểm tra.

Vì vậy, Gerrit buộc bạn không cam kết thay đổi quá nhỏ và quá lớn. (bạn sẽ sử dụng --amendkhông chỉ để sửa một thay đổi đã được đẩy sang Gerrit, thay vì sửa một cam kết bạn muốn đẩy để xem xét)

— laplasz
nguồn