Git rev-list: Đếm commit chênh lệch giữa hai nhánh

Trước khi review hoặc đồng bộ một nhánh, bạn muốn biết mỗi phía đang có bao nhiêu commit mà phía kia chưa có. Git rev-list có thể trả lời bằng hai con số, nhưng thứ tự nhánh và độ mới của dữ liệu quyết định cách hiểu kết quả. Bài này hướng dẫn một phép kiểm tra nhỏ, không tự merge hay sửa lịch sử.

1. So sánh hai nhánh có tên rõ ràng

Giả sử repository có main và feature/report. Chạy lệnh sau, thay tên nhánh theo dự án:

git rev-list --left-right --count main...feature/report

Theo tài liệu Git rev-list, phạm vi ba dấu chấm chọn các commit thuộc một phía nhưng không thuộc cả hai. Kết hợp --left-right với --count cho số lượng riêng của phía trái và phía phải, phân cách bằng tab.

Trong ví dụ đã kiểm thử, hai nhánh có chung commit gốc; main có thêm một commit, feature/report có thêm hai commit. Kết quả là:

1    2

Số 1 thuộc main, số 2 thuộc feature/report. Nếu đảo thứ tự thành feature/report...main, kết quả chuyển thành 2 và 1. Vì vậy, khi chia sẻ kết quả, luôn kèm câu lệnh hoặc tên hai phía; chỉ ghi “ahead 2” dễ khiến người đọc hiểu nhầm mốc so sánh.

2. Đọc các trường hợp thường gặp

Bảng này mô tả quan hệ lịch sử, không đưa ra quyết định merge hay rebase. Khi hai phía đều có commit riêng, cần xem nội dung và quy ước làm việc của nhóm trước khi chọn cách đồng bộ.

3. So với remote: kiểm tra dữ liệu đã cập nhật

origin/main là tham chiếu được lưu trên máy, không phải một truy vấn trực tiếp tới server mỗi lần bạn dùng nó. Với cấu hình fetch thông thường và quyền truy cập phù hợp, có thể cập nhật trước khi so sánh:

git fetch origin
git rev-list --left-right --count origin/main...HEAD

Chỉ chạy lệnh thứ hai sau khi fetch thành công và xác nhận cấu hình fetch có cập nhật origin/main. Cột trái là commit riêng của origin/main; cột phải là commit riêng của HEAD. Git fetch tải dữ liệu và cập nhật tham chiếu theo refspec; nó không tự merge vào nhánh đang làm việc.

Nếu không thể fetch, ghi rõ đây là so sánh với dữ liệu local hiện có. Không báo trạng thái “đã đồng bộ với server” chỉ dựa vào hai số 0 từ một tham chiếu cũ.

4. Đếm commit không phải đo khác biệt nội dung

Bài kiểm thử dùng commit rỗng để tạo hai nhánh phân kỳ: không có file nào thay đổi nhưng kết quả vẫn là 1 và 2. Điều này minh họa trực tiếp rằng số commit không phải số file, số dòng hay khối lượng công việc.

Tương tự, sau một quy trình viết lại lịch sử hoặc chuyển thay đổi sang commit khác, các commit khác mã có thể chứa thay đổi tương đương. Đừng dùng con số này làm thước đo năng suất hoặc kết luận rằng tính năng chưa có ở phía kia.

5. Checklist trước khi đưa vào báo cáo

Xác nhận hai tên tham chiếu tồn tại và lệnh kết thúc thành công. Nếu clone bị giới hạn lịch sử, kết quả có thể thiếu bối cảnh; cần kiểm tra phạm vi dữ liệu trước khi kết luận. Không biến lỗi tên nhánh hoặc lỗi truy cập dữ liệu thành số 0 trong script.

Một báo cáo hữu ích ghi rõ hai nhánh, thời điểm fetch nếu có, hai mã commit đầu nhánh và kết quả đếm. Sau đó mới review nội dung và quyết định bước đồng bộ. Nhờ vậy, hai con số trở thành bằng chứng có ngữ cảnh thay vì một nhãn ahead/behind mơ hồ.