Nó hầu như không có gì để sử dụng lịch sử cam kết được duy trì bởi hệ thống kiểm soát phiên bản. Tuy nhiên, trong nỗ lực tái cấu trúc dự án lớn (hoặc sắp xếp lại / dọn dẹp), các chức năng và các lớp và thậm chí các không gian tên sẽ được di chuyển xung quanh; đôi khi một số tệp sẽ được hợp nhất với nhau và các tệp khác sẽ bị tách. Những thay đổi này thường dẫn đến việc mất lịch sử cam kết ban đầu của một vài tệp.
Theo ý kiến cá nhân của tôi, việc duy trì tổ chức dự án quan trọng hơn việc giữ lịch sử mã nguồn. Tổ chức dự án tốt cho phép các tính năng mới được thêm liên tục với nỗ lực hợp lý, trong khi giá trị của lịch sử mã nguồn dường như không rõ ràng.
Hơn nữa, với việc sử dụng thử nghiệm đơn vị, các vấn đề hồi quy nhanh chóng được xác định. Miễn là phiên bản mới nhất tiếp tục đáp ứng tất cả các yêu cầu phần mềm, chúng ta có thực sự cần phải lưu giữ lịch sử của mã nguồn không?
Tôi hiểu rằng bất kỳ mã nguồn vận chuyển nào cũng phải được bảo tồn do cần phải cung cấp hỗ trợ cho khách hàng mà không yêu cầu họ thực hiện nâng cấp phiên bản chính. Nhưng ngoài điều này ra, có bất kỳ giá trị nào trong việc giữ lịch sử của mã nguồn cam kết không?
Liệu mã nguồn cam kết lịch sử có đóng vai trò nào trong việc liên lạc giữa các thành viên trong nhóm không? Điều gì sẽ xảy ra nếu chúng ta xóa bỏ lịch sử cam kết, nhưng thay vào đó dựa vào "mã nguồn" + "mã kiểm tra đơn vị" để liên lạc?
Có phải sự tồn tại của lịch sử cam kết khiến người ta tự mãn về tài liệu dài hạn về thông tin quan trọng về dự án, chẳng hạn như thay đổi thiết kế / yêu cầu chính và dòng suy nghĩ đã thúc đẩy những thay đổi đó?
These changes often lead to the loss of the original commit history of a few files.Có một cái nhìn ví dụ như "git đổ lỗi" - không có gì bị mất. Đôi khi nó có thể khó tìm hơn một chút, nhưng nó luôn ở đó.