Git rebase có thể xóa hoàn toàn lịch sử từ xa không?

Question

Khi chúng tôi xem xét chuyển từ SVN sang git tại nơi làm việc, đồng nghiệp đã nêu lên mối lo ngại rằng nhà phát triển độc hại hoặc dễ bị tai nạn có thể sử dụng git rebase để xóa lịch sử từ xa khỏi kho lưu trữ được chia sẻ của chúng tôi.

Chỉnh sửa: Như được chỉ ra trong câu trả lời, toàn bộ nhánh cũng có thể bị xóa khỏi repo từ xa với git push origin :branch-name.

Đây có phải là vấn đề thực tế không? Nếu vậy, chúng ta có thể làm gì để ngăn chặn nó?

Answer 1

tôi có xu hướng đồng ý với đồng nghiệp của bạn rằng có một vấn đề ở đây bởi vì:

• không có vấn đề như thế nào mà bạn tin tưởng committers của bạn, luôn luôn có một khả năng lỗi của con người
• quá trình xem xét lựa chọn hợp lý hơn (ví dụ Gerrit) không phải lúc nào thích hợp
• khôi phục lại từ bản sao lưu có thể được làm chậm và một Pita

bạn đã xem các receive.denyNonFastForwards và receive.denyDeletes thông số cấu hình? AFAICT có sẵn trong Git 1.6 trở đi.

Từ Pro Git:

Nếu bạn rebase cam kết rằng bạn đã đẩy và sau đó cố gắng đẩy một lần nữa, hoặc nếu không cố gắng đẩy một cam kết một chi nhánh từ xa mà không chứa cam kết rằng chi nhánh từ xa hiện trỏ đến, bạn sẽ bị từ chối.Đây thường là chính sách tốt; nhưng trong trường hợp của việc rebase, bạn có thể xác định rằng bạn biết mình đang làm gì và có thể buộc cập nhật nhánh từ xa với cờ -f vào lệnh đẩy của bạn.

Để vô hiệu hóa khả năng ép cập nhật chi nhánh từ xa để tài liệu tham khảo không nhanh về phía trước, thiết lập receive.denyNonFastForwards

Một cách khác bạn có thể làm điều này là thông qua server-side nhận móc, mà tôi sẽ bao gồm trong một chút. Cách tiếp cận đó cho phép bạn thực hiện những điều phức tạp hơn như từ chối chuyển tiếp không nhanh tới một tập hợp con người dùng nhất định.

Như tác giả đề cập, quy tắc này cũng có thể được thực thi qua móc nhận (là described later in Pro Git).

Các kỹ thuật này sẽ bảo vệ chống lại lịch sử bị mất ngẫu nhiên (hoặc độc hại) trong kho lưu trữ được chia sẻ của bạn.

Answer 2

Lịch sử có thể bị rối loạn bằng cách sử dụng rebase, nhưng thông thường repo từ xa sẽ không chấp nhận thay đổi sửa đổi lịch sử (trừ khi bạn sử dụng git push --force), nhưng thậm chí nhiều hơn, nhà phát triển có quyền đẩy có thể xóa chi nhánh hoàn toàn (git push origin: branch-name). Vì vậy, các quy tắc đơn giản là:

• Không được phép cho phép các nhà phát triển mà bạn không tin tưởng.

• Khi repo được chia sẻ, không gây rối với lịch sử, tránh sử dụng rebase trên các commit trước đây. Sử dụng phối hoặc chọn cherry thay vì nếu bạn cần phải thêm một cái gì đó từ chi nhánh khác nhau, trong trường hợp đó lịch sử sẽ không bị ảnh hưởng.

• Bạn có thể duy trì chính sách không sử dụng 'push -f' trên repo được chia sẻ, trong trường hợp nhà phát triển sẽ biết rằng nếu bị từ chối thì có gì đó không ổn (nhiều khả năng chi nhánh địa phương không cập nhật từ xa) và nên giải quyết vấn đề cục bộ thay vì buộc đẩy.

Về câu hỏi của bạn làm thế nào để ngăn chặn - sử dụng Gerrit hệ thống sửa đổi, nó giống như một bước trung gian trên con đường của cam kết giữa nhà phát triển của địa phương kho và chủ repo với giao diện web tốt đẹp cho phiên bản, bạn có thể cung cấp cho quyền đẩy vào kho lưu trữ sửa đổi cho bất kỳ ai, nhưng thay đổi sẽ được hợp nhất vào chi nhánh chính của bạn sau khi xác minh và phê duyệt (yêu cầu một số quyền bạn thường cấp cho các nhà phát triển cốt lõi). Bạn có thể thấy nó trông như thế nào trên dự án Mahara: https://reviews.mahara.org Trong trường hợp đặc biệt này, chỉ có bot gerrit mới được phép đẩy tới master (là here) và không có ai khác.

Answer 3

Có các tiện ích mở rộng cho máy chủ Git của doanh nghiệp như Gerrit sẽ phát hiện ghi đè lịch sử và xóa chi nhánh, sẽ sao lưu chúng dưới một lần chỉnh sửa đặc biệt để chúng có thể được khôi phục nếu cần và sẽ không bị thu gom rác. Quản trị viên Gerrit vẫn có thể xóa các cam kết đã chọn nếu cần vì lý do pháp lý.