Như một thực hành tốt nhất, nên cam kết thường xuyên, nhưng để xem lại mã, bạn có thể cần phải xem xét một bản vá bao gồm nhiều lần commit cùng một lúc. Có cách nào nhiều cam kết có thể được xem xét và sáp nhập hoặc bị từ chối cùng một lúc không?Gerrit: kết hợp nhiều cam kết thành một "thay đổi"
Không, Gerrit hiện không hỗ trợ ghép nối nhóm thành một bài đánh giá. Tuy nhiên, có một vài tùy chọn khác.
Tại $ DAYJOB, nhóm của tôi sử dụng các chi nhánh cho các thay đổi lớn hơn. Các cam kết nhỏ hơn được xem xét/sáp nhập vào chi nhánh riêng lẻ, nhưng nhánh tính năng chỉ được hợp nhất vào một khi mọi thứ ở một nơi tốt và tất cả các nhà phát triển đều hài lòng.
Gerrit cũng hỗ trợ các nhánh chủ đề - đây là cách thuận tiện để nhóm các cam kết có liên quan. Chúng được thảo luận ngắn gọn trong documentation. Các cam kết này vẫn phải được xem xét/hợp nhất riêng lẻ, nhưng chúng có thể được nhóm lại nhanh chóng trong giao diện người dùng web.
Một điều bạn có thể làm một bíp sáp nhập vào một nhánh tạm thời và sau đó đăng thay đổi đó để xem xét.
git checkout -b feature
git commit -m "start feature"
...
git commit -m "finish feature"
git checkout -b feature-review master
git merge --squash feature
git commit
Bây giờ chi nhánh feature-review của bạn sẽ chứa các diff cùng so với master như feature đã nhưng chỉ với phạm duy nhất.
Nếu bạn cần cập nhật các yêu cầu xem xét lại đã được đăng sau đó bạn có thể tận dụng sửa đổi cam kết:
git commit --amend -C HEAD
và sau đó đẩy để xem xét hậu quả.
Tôi tin rằng các cam kết công khai phải là nguyên tử và chứa đầy đủ chức năng mà bạn muốn đóng góp. Thông thường, bạn không muốn chia sẻ tất cả các cam kết trung gian của mình. Vì vậy, cam kết squashing trước khi xem xét là ý tưởng tốt.
Một trường phái tư tưởng cho biết tốt nhất là nên thực hiện các thay đổi gây rối như một chuỗi các cam kết nguyên tử nhỏ, mỗi trong số đó có thể đẩy được để sản xuất. Việc bảo quản các commit nhỏ này giúp dễ dàng xem những gì bạn đã làm và lý do tại sao, dễ dàng thực hiện reverts, làm cho bisections trở nên hữu ích hơn, và đánh giá dễ dàng hơn và nhanh hơn (ví dụ: khi tập tin dữ liệu được sắp xếp và có thêm một dòng, các thông điệp cam kết nhỏ gọn làm cho nó rất rõ ràng những gì đã xảy ra và tại sao. Squashing có nghĩa là sự khác biệt lớn từ các loại che khuất chèn.) Ý tưởng này là phổ biến ở những nơi tốt nhất mà tôi đã làm việc. –
Cảm ơn bạn đã trả lời. Nhưng làm thế nào để bạn sau đó đẩy/hợp nhất để làm chủ sau khi đánh giá mã có thể liên quan đến thay đổi mã? – Nonos
Bạn có thể tiếp tục làm việc trên bất kỳ nhánh nào (hoặc 'feature' hoặc' feature-review') mà bạn muốn, và đẩy nó khi nó được thực hiện. Bạn thậm chí có thể lặp lại quá trình thực hiện hợp nhất bíp cho cam kết cuối cùng của bạn để làm chủ, tùy thuộc vào số tiền bạn quan tâm về lịch sử và phá vỡ các cam kết. –
'git merge --squash' sẽ ghi lại lịch sử và sẽ không cho phép bạn sử dụng' git bisect' trên tính năng – summerbulb