Do mô hình phân nhánh của Git, các cam kết không thuộc về một hoặc nhiều chi nhánh. Các nhánh là các con trỏ tới các đối tượng cam kết đơn lẻ trong toàn bộ biểu đồ cam kết. Vì vậy, khi bạn nói một cam kết là "trên một chi nhánh X" trong X, bạn thường có nghĩa là nó có thể truy cập được khi bắt đầu tại cam kết chi nhánh X trỏ đến.
Đối với git log, hành vi mặc định bằng git log HEAD trong đó HEAD đề cập đến cam kết nhánh hiện tại hiện trỏ đến. Vì vậy, nếu bạn đang ở trên nhánh chính, nó bằng git log master, hiển thị tất cả các cam kết có thể truy cập được khi bắt đầu từ lần commit gần đây nhất.
Thật không may những gì bạn đang đề cập đến như một cam kết thực hiện cho một chi nhánh nhất định không được xác định rõ ràng trong Git. Nếu tôi thực hiện cam kết trên trang cái và sau đó tạo chi nhánh mới trỏ đến cùng một cam kết (ví dụ: sử dụng git branch newbranch), thì nhánh đó giống hệt với nhánh chính ngoại trừ tên. Vì vậy, mỗi thuộc tính “được thực hiện trên nhánh chính” bây giờ cũng sẽ ngụ ý “được thực hiện trên nhánh mớibranch”. Như vậy bạn không thể có tài sản này trong Git.
Ngay cả giải pháp của parkydr, cho thấy tất cả các cam kết chỉ được thực hiện trên một mặt hợp nhất không phải là giải pháp không thể thực hiện được. Lý tưởng nhất là nó sẽ che giấu tất cả những cam kết đã được thực hiện trên một chi nhánh không phải là chủ riêng biệt và sau đó được sáp nhập trở lại làm chủ. Như vậy, bạn sẽ chỉ nhận được các cam kết được thực hiện trực tiếp với luồng chủ hoặc hợp nhất cam kết hợp nhất trong một số cam kết khác. Tuy nhiên có hai điều đó sẽ ngăn chặn điều này làm việc:
- nhanh về phía trước kết hợp: Khi bạn chi nhánh khỏi tổng thể và tạo ra một số cam kết, trong khi tạo ra không mới về chủ trực tiếp, sau đó một
git merge somebranch trên tổng thể sẽ nhanh -trước các cam kết, dẫn đến nhánh chính trỏ đến cùng một cam kết như somebranch. Như vậy bạn "mất" thông tin rằng những cam kết ban đầu được tạo ra trên một chi nhánh riêng biệt. Bạn có thể buộc Git luôn tạo các cam kết hợp nhất, sử dụng git merge --no-ff nhưng điều này sẽ không giúp bạn sau đó.
- Đơn đặt hàng hợp nhất không được đảm bảo: Khi bạn đang ở chế độ chính và hợp nhất chi nhánh, thì cam kết chính trước đó sẽ luôn là làm cha mẹ đầu tiên. Vì vậy, bạn sẽ có được hành vi mong muốn của bạn. Tuy nhiên, hoàn toàn có thể là trên nhánh nói trên, và thay vào đó kết hợp với master, kết quả là master commit là cha thứ hai. Sau đó, chủ có thể được chuyển tiếp nhanh (hoặc đặt lại) đến cam kết mới dẫn đến chế độ xem "đảo ngược".
Vì vậy, điểm mấu chốt là bạn không thể có được lịch sử như vậy một cách an toàn. Bạn nên sử dụng cách hoạt động của mô hình phân nhánh linh hoạt của Git.
'--first-parent master' rất hữu ích cho một vấn đề mà tôi đã xử lý: xác định hợp nhất nào (--merges) đã đi vào chính, so với kết hợp trên một nhánh chủ đề. –
Cảm ơn. Tôi nghĩ rằng tôi nên thị trường như một giải pháp cho vấn đề này. –
Chỉ cần một đầu-up, nó không phải là hoàn hảo. Nếu lần commit trước đó thành 'master' xảy ra để được liệt kê như là một phụ huynh _second_ của commit, điều này sẽ cho bạn một sai lầm. Điều đó sẽ không thường xảy ra nếu bạn đang theo quy trình yêu cầu kéo/hợp nhất của GitHub. – PJSCopeland