Git log --first-parent: đọc lịch sử tích hợp mà không lẫn với --no-merges

Nhánh chính có nhiều merge commit, còn git log hiển thị cả hàng loạt commit nhỏ của từng nhánh tính năng. Khi muốn biết các đợt tích hợp đi vào nhánh chính theo trình tự nào, --first-parent có thể tạo một góc nhìn dễ theo dõi hơn. Nó không xóa commit và cũng không đồng nghĩa với --no-merges.

Các lệnh trong bài chỉ đọc lịch sử đã có. Chạy trong repository local với nhánh main tồn tại; thay main bằng tên nhánh thực tế của dự án. Không có bước đổi nhánh, reset hoặc push trong quy trình đọc này.

1. Bắt đầu từ toàn bộ đồ thị liên quan

git log --graph --oneline --decorate main

Hãy quan sát các đường cha của merge trước khi rút gọn góc nhìn. Lịch sử minh họa dưới đây có hai commit tính năng F1, F2, một commit M1 trên main và merge I đưa nhánh feature vào main:

A---M1---I  main
 \      /
  F1---F2   feature

Với một merge thông thường thực hiện khi đang ở main, cha thứ nhất của I là đầu main trước merge; cha còn lại trỏ tới nhánh được nhập. Đây là quan hệ trong commit, không phải nhãn tên nhánh được lưu vĩnh viễn cho mỗi cạnh.

2. Theo đường cha thứ nhất

git log --first-parent --oneline main

Trong lịch sử minh họa, góc nhìn này đi qua I, M1 rồi A; không đi sâu vào F2 và F1. Các thay đổi của feature vẫn nằm trong snapshot sau merge. Danh sách ngắn hơn chỉ thay đổi cách duyệt lịch sử.

Với đội dùng merge commit làm mốc tích hợp, có thể dùng kết quả làm điểm bắt đầu để soạn ghi chú phát hành. Tuy nhiên commit trực tiếp trên main cũng xuất hiện; --first-parent không tự biến mọi dòng thành một pull request.

3. --no-merges lọc commit thay vì chỉ đi một đường

git log --no-merges --oneline main
git log --first-parent --merges --oneline main

Lệnh đầu bỏ merge commit khỏi output nhưng vẫn có thể hiển thị F1, F2 và M1 vì chúng đều thuộc lịch sử truy cập được từ main. Nó không tạo cùng góc nhìn với --first-parent.

Lệnh thứ hai theo đường cha đầu rồi chỉ hiển thị các merge trên đường đó. Trong ví dụ, còn I. Nếu đội có hotfix commit trực tiếp trên main, bộ lọc --merges sẽ bỏ chúng; đừng dùng riêng danh sách đó để khẳng định đã bao quát mọi thay đổi phát hành.

4. Kiểm tra cha và nội dung tại lần tích hợp

Chọn mã commit I từ output và thay COMMIT trong các lệnh sau bằng mã đó:

git show --no-patch --format=raw COMMIT
git diff --stat COMMIT^1 COMMIT --
git diff COMMIT^1 COMMIT -- src/

Định dạng raw cho thấy các parent theo thứ tự. So snapshot merge với cha đầu giúp xem kết quả mà lần tích hợp đưa vào so với trạng thái nhánh nhận trước đó, gồm cả kết quả xử lý conflict nếu có.

Trong PowerShell có thể đặt revision có ký tự đặc biệt trong dấu nháy đơn, chẳng hạn 'COMMIT^1', sau khi thay mã thật. src/ là ví dụ giới hạn đường dẫn; bỏ nó để đọc toàn bộ khác biệt hoặc đổi thành thư mục đúng.

Diff này không tự chứng minh thay đổi đã được review, test hoặc triển khai. Muốn xác nhận rollout, cần đối chiếu artifact, pipeline và môi trường thực tế.

5. Giới hạn mốc phát hành với ref đã xác nhận

git rev-parse --verify 'v1.0^{commit}'
git rev-parse --verify 'main^{commit}'
git log --first-parent --oneline v1.0..main

Ví dụ giả định tag v1.0 tồn tại. Nếu verify thất bại, dừng để sửa ref thay vì dùng một danh sách trống làm bằng chứng “không có thay đổi”. Hai dấu chấm chọn commit thuộc lịch sử main nhưng không thuộc lịch sử v1.0; cần chọn đúng baseline phát hành của sản phẩm.

Tên main ở đây là ref local. Đọc origin/main cũng chỉ đọc remote-tracking ref hiện có; git log không tự lấy trạng thái mới từ server. Nếu cần dữ liệu mới, việc fetch và thời điểm lấy phải được ghi nhận riêng.

6. Biết khi góc nhìn không đủ

• Fast-forward không tạo merge commit mới để làm mốc tích hợp.
• Squash tạo commit tổng hợp, không giữ toàn bộ chuỗi commit feature trong lịch sử main theo cách merge thông thường.
• Rebase thay đổi hình dạng lịch sử nên cần hiểu quy trình tích hợp của đội.
• Shallow clone có thể thiếu tổ tiên cần cho việc điều tra.
• Lọc theo đường dẫn hoặc kết hợp nhiều tùy chọn có thể thay đổi lịch sử được trình bày; bắt đầu với lệnh đơn giản.

Lịch sử hai nhánh đã được kiểm chứng trong repository tạm local: log thường thấy commit feature, --first-parent giữ đường tích hợp, --no-merges vẫn thấy commit feature, và diff với cha đầu cho thấy file được nhập. Kiểm thử không chạy trên repository sản phẩm hay dịch vụ hosting.

Tài liệu đối chiếu: git log, git rev-parse và git diff. Dùng --first-parent để trả lời câu hỏi về đường tích hợp, rồi mở rộng đồ thị khi cần hiểu chi tiết của từng nhánh.