Thay vì một lịch sử cam kết phẳng dài, tại sao không có hệ thống phân cấp, vì vậy ở cấp cao nhất bạn có thể có các yêu cầu kéo, sau đó bạn có thể đi xuống một cấp và xem xét các cam kết trong PR đó. Tôi nhận ra rằng PR là dành riêng cho github, nhưng bạn hiểu ý. Tôi chỉ có nghĩa là nhóm một số cam kết như một tính năng hoặc sửa lỗi, ví dụ.
Chắc chắn nó sẽ làm cho lịch sử cam kết dễ dàng hơn rất nhiều để điều hướng.
Tôi chắc chắn có một câu trả lời rõ ràng cho câu hỏi này, nhưng dường như tôi không thể tìm thấy nó.
1
Một giao diện người dùng có thể có thể nhóm cam kết cho hiển thị và điều hướng. Nhưng nó dường như không đủ hữu dụng để kết nối cứng trong lõi (rất chung chung và không theo quy trình công việc).
Nếu các xác nhận là khác biệt về mặt logic, chúng không nên được nhóm lại. Nếu chúng là một phần logic của một thay đổi, thì chúng phải là một cam kết (đó là tất cả những gì các công cụ rebase dành cho). Và nếu chúng có liên quan với nhau, rất có thể chúng sẽ ở gần nhau và dễ dàng tìm thấy bằng mọi cách.
—
Jan Hudec
Điều này được thực hiện như bạn mô tả với việc sử dụng các nhánh tắt, đọc lên các nhánh tính năng.
—
iveqy
hỏi những người thiết kế git, tôi chắc chắn họ biết tại sao họ đưa ra quyết định thiết kế của họ.
—
jwenting
Tôi đồng ý với các poster về mặt khái niệm. Thực tế là một cái gì đó hoạt động theo một cách nhất định ngay bây giờ , không có nghĩa là nó nên . Cá nhân, tôi thường xuyên sử dụng "squash merge" để tóm tắt một số cam kết thành một và đưa nó vào nhánh chính. Mức độ chi tiết tôi muốn thấy trong tổng thể cao hơn so với phát triển chẳng hạn. Vấn đề với điều đó là về cơ bản không có mối quan hệ nào giữa cam kết squash mới được tạo và các cam kết bắt nguồn từ nó. Tôi chắc chắn có thể tưởng tượng việc có thể nhóm một số cam kết thành một, mà chính nó là một cam kết rõ ràng trước và sau
—
Daniel Langdon
