Tại sao git sử dụng băm thay vì số sửa đổi?

Tôi luôn tự hỏi tại sao git thích băm hơn số sửa đổi. Số sửa đổi rõ ràng hơn và dễ tham khảo hơn (theo ý kiến ​​của tôi): Có một sự khác biệt giữa việc bảo ai đó hãy xem bản sửa đổi 1200 hoặc cam kết 92ba93e! (Chỉ để đưa ra một ví dụ).

Vì vậy, có bất kỳ lý do cho thiết kế này?

Một số sửa đổi duy nhất, tăng đơn điệu chỉ thực sự có ý nghĩa đối với một hệ thống kiểm soát phiên bản tập trung, trong đó tất cả các sửa đổi chảy đến một nơi duy nhất có thể theo dõi và gán số. Khi bạn vào thế giới DVCS, nơi tồn tại nhiều bản sao của kho lưu trữ và các thay đổi được kéo ra và đẩy chúng vào các quy trình công việc tùy ý, khái niệm này không được áp dụng. (Ví dụ: không có nơi nào để gán số sửa đổi - nếu tôi rẽ nhánh kho lưu trữ của bạn và bạn quyết định một năm sau đó để thay đổi, làm thế nào một hệ thống có thể đảm bảo rằng số sửa đổi của chúng tôi không xung đột?)

Bạn cần băm trong một hệ thống phân tán. Giả sử bạn và một đồng nghiệp đều làm việc trên cùng một kho lưu trữ và cả hai bạn đều cam kết thay đổi cục bộ và sau đó đẩy nó. Ai sẽ là số sửa đổi 1200 và ai là số sửa đổi 1201 cho cả hai bên không có bất kỳ kiến ​​thức nào về nhau? Giải pháp kỹ thuật thực tế duy nhất là tạo ra một hàm băm của các thay đổi bằng phương pháp đã biết và liên kết mọi thứ dựa trên đó.

Thật thú vị HG không hỗ trợ số phiên bản nhưng chúng rõ ràng là một tính năng chỉ cục bộ - kho lưu trữ của bạn có một bộ, repo của đồng nghiệp của bạn sẽ có một bộ khác tùy thuộc vào cách chúng đẩy và kéo. Nó làm cho việc sử dụng dòng lệnh thân thiện hơn một chút so với Git.

Toàn vẹn dữ liệu.

Tôi tôn trọng không đồng ý với các câu trả lời hiện tại. Băm không cần thiết cho DVCS, xem cách Bazaar . Bạn có thể làm tốt với bất kỳ loại định danh duy nhất toàn cầu nào khác. Các giá trị băm là một biện pháp để đảm bảo tính toàn vẹn của dữ liệu: Chúng đại diện cho một bản tóm tắt thông tin có trong đối tượng (cam kết, cây, ...) được gọi bằng hàm băm. Việc thay đổi nội dung mà không thay đổi hàm băm (nghĩa là một cuộc tấn công tiền đề hoặc tấn công va chạm ) được cho là khó khăn, mặc dù không phải là không thể. (Nếu bạn thực sự thích nó, hãy xem bài báo năm 2011 của Marc Stevens ).

Do đó, việc tham chiếu đến các đối tượng bằng hàm băm SHA của chúng cho phép kiểm tra xem nội dung có bị giả mạo hay không. Và, do chúng (gần như) được đảm bảo là duy nhất, chúng cũng có thể được sử dụng làm định danh sửa đổi - một cách thuận tiện.

Xem Chương 9 của sách Git để biết thêm chi tiết.

Theo cách nói của giáo dân:

• Băm được dự định là gần như duy nhất trên toàn cầu. Điều này KHÔNG được đảm bảo nhưng rất khó có khả năng cùng một SHA được tạo cho các nội dung khác nhau. Trong thuật ngữ thực tế cho một dự án nhất định, bạn có thể coi nó là duy nhất.
• Với số sửa đổi, bạn sẽ phải sử dụng một không gian tên để giới thiệu cụ thể đến sửa đổi 1200.
• Git có thể hoạt động cả phân tán và / hoặc tập trung. Vậy làm thế nào để bạn có được số sửa đổi chính xác và duy nhất?
• Ngoài ra, sử dụng số sửa đổi sẽ tạo ra phổ sai rằng các phiên bản mới hơn sẽ có số cao hơn và điều đó sẽ không đúng vì phân nhánh, hợp nhất, đánh lại, v.v.
• Bạn luôn có tùy chọn để đặt các thẻ để xác nhận.

Về mặt toán học:

• Một trật tự tổng so với cam kết của Git sẽ được yêu cầu cho monotonally ngày càng có nhiều phiên bản.
• Cam kết của Git tạo thành một biểu đồ chu kỳ (DAG) có hướng, chỉ có thể được đặt hàng một phần / theo cấu trúc liên kết .

Hash không phải là giải pháp duy nhất cho VCS phân tán. Nhưng khi đối phó với một hệ thống phân tán, chỉ có thể ghi lại thứ tự từng phần của các sự kiện. (Đối với VCS, sự kiện có thể là một cam kết.) Đó là lý do tại sao việc duy trì số sửa đổi tăng đơn điệu là không thể. Thông thường chúng ta áp dụng một cái gì đó như đồng hồ vector (hoặc dấu thời gian vector) để ghi lại mối quan hệ được sắp xếp một phần như vậy. Đây là giải pháp được sử dụng trong Bazaar .

Nhưng tại sao Git không sử dụng đồng hồ vector mà băm? Tôi nghĩ rằng nguyên nhân gốc rễ là anh đào chọn . Khi chúng tôi thực hiện chọn cherry trên kho lưu trữ, thứ tự cam kết một phần sẽ thay đổi. Đồng hồ vector của một số cam kết phải được gán lại để thể hiện thứ tự từng phần mới. Tuy nhiên, việc gán lại như vậy trong hệ thống phân tán sẽ gây ra đồng hồ vector không nhất quán. Đó là vấn đề thực sự mà băm giải quyết.