Git range-diff: Kiểm tra chuỗi commit sau khi rebase

Sau rebase, mã commit thay đổi khiến việc so sánh lịch sử bằng mắt trở nên khó khăn. Git range-diff giúp đối chiếu hai phiên bản của một chuỗi commit để thấy patch nào được giữ, sửa, thêm hoặc không còn được ghép cặp. Đây là bước review hữu ích trước khi bàn giao lại nhánh cho đồng đội.

1. Chọn đúng câu hỏi cần kiểm tra

git diff so sánh nội dung giữa hai trạng thái. git range-diff đối chiếu các patch trong hai khoảng commit. Nếu chỉ đọc chênh lệch giữa hai đầu nhánh cũ và mới, bạn có thể thấy cả thay đổi từ upstream vừa được đưa vào, gây khó phân biệt với chỉnh sửa của tính năng.

Ví dụ một pull request có ba commit: thêm kiểm tra đầu vào, sửa xử lý lỗi và bổ sung test. Sau rebase, reviewer muốn biết commit xử lý lỗi có bị sửa lúc giải quyết conflict hay không. Range-diff hỗ trợ câu hỏi đó, còn test xác nhận hành vi cuối cùng.

2. Giữ mốc cũ trước khi viết lại lịch sử

Ví dụ dưới đây giả định bạn đang đứng trên nhánh tính năng tuyến tính, origin/main là upstream và working tree sạch. Các tên review branch phải chưa tồn tại. Trong PowerShell:

git status --short
git fetch origin
$oldBase = git merge-base HEAD origin/main
git branch review/base-v1 $oldBase
git branch review/topic-v1 HEAD
git branch review/base-v2 origin/main

git rebase review/base-v2

Nếu status có thay đổi, lưu công việc theo quy trình của nhóm trước khi rebase. Ba branch review giữ nguyên các mốc phục vụ đối chiếu; chúng không phải bản sao lưu file chưa commit. Fetch chỉ cập nhật thông tin remote, còn rebase sẽ thay đổi lịch sử nhánh đang làm việc.

Khi có conflict, đọc và sửa nội dung, chạy kiểm tra phù hợp, stage các file đã giải quyết rồi dùng git rebase --continue. Nếu cần dừng, xem trạng thái và dùng git rebase --abort. Chỉ tiếp tục bước so sánh khi rebase đã kết thúc.

3. So sánh hai khoảng rõ ràng

git log --oneline review/base-v1..review/topic-v1
git log --oneline review/base-v2..HEAD

git range-diff --no-color review/base-v1..review/topic-v1 review/base-v2..HEAD

Trong ký hiệu Git, A..B chọn commit có thể đi tới từ B nhưng không từ A. Hai lệnh log giúp kiểm tra phạm vi trước khi diễn giải range-diff. Dùng base riêng cho mỗi phiên bản làm rõ thay đổi nào thuộc series cũ và series mới.

Nếu hai phiên bản thật sự cùng base, có thể dùng dạng ngắn git range-diff base old-tip new-tip. Với quy trình review thường xuyên, bốn mốc rõ ràng vẫn dễ ghi vào mô tả PR và kiểm tra lại hơn việc dựa vào một reflog entry có thể thay đổi theo thao tác tiếp theo.

4. Đọc kết quả ghép cặp

Các dòng sau chỉ minh họa hình dạng output; hash và tiêu đề không đại diện cho repository cụ thể:

1: aaaaaaa = 1: ddddddd Validate input
2: bbbbbbb ! 2: eeeeeee Handle errors
3: ccccccc < -: ------- Add old test
-: ------- > 3: fffffff Add new test

Ghép cặp dựa trên độ tương đồng, không phải bằng chứng nhận dạng tuyệt đối. Squash, tách commit hoặc sửa quá nhiều có thể hiện thành một commit cũ mất đi và một commit mới xuất hiện. Đọc phần chi tiết dưới dấu !: thay đổi có thể nằm ở message hoặc patch, không nhất thiết là logic chương trình.

5. Review phần thay đổi có chủ đích

Với ví dụ xử lý lỗi, reviewer nên mở commit mới, kiểm tra đường đi của lỗi và test tương ứng. Tác giả nên giải thích vì sao resolution khác bản cũ: API upstream đổi, test cũ không còn phù hợp hay logic trước đó có lỗi.

git diff --stat review/base-v2 HEAD
git diff --check review/base-v2 HEAD
git diff review/base-v2 HEAD

Ba lệnh bổ sung kiểm tra kết quả cuối của nhánh so với base mới. Chạy bộ test phù hợp sau đó. Dấu bằng trong range-diff không bảo đảm runtime giống hệt, vì thư viện, cấu hình hoặc code ở base mới có thể đã thay đổi.

6. Những giới hạn cần biết

• Mặc định range-diff bỏ qua merge commit. Nhánh có cấu trúc merge cần kiểm tra thêm graph và tùy chọn hỗ trợ trên phiên bản Git đang dùng.
• Output dành cho người đọc và không được bảo đảm ổn định để parse như giao thức máy.
• Series bị squash/tách cần review quan hệ nhiều-một hoặc một-nhiều bằng diff và log bổ sung.
• Sai base có thể làm upstream commit lọt vào khoảng so sánh và tạo kết luận sai.

7. Bàn giao kết quả review

Trong mô tả PR, ghi các mốc cũ/mới, lý do thay đổi đáng kể và test đã chạy. Không cần dán toàn bộ output nếu chỉ một patch thay đổi; hãy dẫn reviewer tới phần đó và giải thích tác động.

Giữ các review branch cho đến khi đối chiếu xong. Việc cập nhật nhánh remote đã chia sẻ cần theo quy ước phối hợp của nhóm; hoàn thành range-diff không tự cấp phép ghi đè lịch sử người khác. Công việc hoàn tất khi phạm vi commit đúng, mọi khác biệt quan trọng có giải thích và kết quả cuối đã được kiểm thử.

Tài liệu tham khảo

git range-diff, Git revision ranges, git rebase và git diff.