Git merge-base: Kiểm tra commit đã nằm trong nhánh hay chưa

Trước khi phát hành, nhóm thường hỏi: commit sửa lỗi đã nằm trong nhánh release chưa? Tìm một dòng message giống nhau chưa đủ để trả lời. Git merge-base kiểm tra quan hệ tổ tiên trong đồ thị commit, giúp tách bằng chứng lịch sử khỏi cảm giác “hình như đã merge”.

1. Xác định chính xác hai đầu kiểm tra

Ví dụ dùng hai ref minh họa fix/login và release. Thay bằng branch, tag hoặc commit đã xác minh của dự án:

git rev-parse --verify "fix/login^{commit}"
git rev-parse --verify "release^{commit}"
git log --graph --oneline --decorate -20 release

Ghi lại hai hash trước khi đưa kết quả vào hồ sơ. Tên branch có thể di chuyển sau lần kiểm tra, còn câu hỏi của báo cáo cần gắn với trạng thái cụ thể. Nếu muốn kiểm tra một commit sửa lỗi riêng, dùng hash của nó thay vì đầu nhánh có thể chứa nhiều commit mới hơn.

2. Kiểm tra theo đúng chiều

git merge-base --is-ancestor fix/login release

Theo tài liệu merge-base, mã thoát 0 nghĩa là đối số đầu là tổ tiên của đối số sau; 1 nghĩa là không; mã khác báo lỗi. Hai đối số cùng trỏ một commit cũng được chấp nhận. Lệnh này không merge hay đổi working tree.

Đảo hai đối số là hỏi câu khác. Cần thống nhất “commit cần tìm” đứng trước và “đích cần kiểm tra” đứng sau. Không dựa vào việc terminal không in gì để kết luận thành công.

3. Đọc mã thoát trong PowerShell

git merge-base --is-ancestor fix/login release
$ancestryExit = $LASTEXITCODE
if ($ancestryExit -eq 0) {
    Write-Output "Commit is reachable from release"
} elseif ($ancestryExit -eq 1) {
    Write-Output "Commit is not an ancestor of release"
} else {
    throw "Ancestry check failed: exit $ancestryExit"
}

Lưu mã thoát ngay sau lệnh Git, trước khi gọi chương trình khác. Với pipeline, lỗi ref không tồn tại hoặc lỗi đọc repository phải đi theo nhánh lỗi, không bị biến thành kết luận “chưa merge”. Ví dụ chỉ báo cáo quan hệ lịch sử, không tự cho phép deploy, xóa branch hoặc cherry-pick.

4. Tìm tổ tiên chung để hiểu chỗ phân nhánh

git merge-base --all fix/login release

Merge base là tổ tiên chung tốt nhất theo đồ thị, không nhất thiết là commit có ngày gần nhất. Lịch sử merge chéo có thể có nhiều kết quả, nên script cần xử lý tập kết quả thay vì mặc định chỉ có một dòng.

Dùng git log để xem thêm bối cảnh:

git log --graph --oneline --decorate --all -30

Giới hạn 30 chỉ là cửa sổ hiển thị. Không thấy commit trong cửa sổ đó không chứng minh commit không thuộc lịch sử. Đồ thị giúp giải thích kết quả; phép kiểm tra tổ tiên mới trả lời câu hỏi quan hệ cụ thể.

5. Ba tình huống dễ kết luận sai

Cherry-pick hoặc squash: thay đổi tương đương có thể được đưa vào bằng commit khác. Kết quả không phải tổ tiên chưa chứng minh bản sửa lỗi bị thiếu. Đọc diff, hồ sơ pull request và chạy ca tái hiện để kiểm tra nội dung thực tế.

Revert: commit gốc vẫn có thể là tổ tiên dù tác dụng đã bị hoàn tác. Kết quả 0 không chứng minh lỗi đã được sửa trong phiên bản hiện tại. Kiểm tra mã nguồn và hành vi vẫn là bước cần thiết.

Checkout thiếu hoặc cũ: remote-tracking ref phản ánh lần đồng bộ trước, còn clone nông có thể thiếu lịch sử cần kiểm tra. Xác minh nguồn ref, thời điểm fetch và mức đầy đủ của dữ liệu trước khi đưa ra kết luận cho server hiện tại.

6. Đưa vào checklist release

• Ghi rõ hash sửa lỗi và hash release đã kiểm tra.
• Phân biệt ba trạng thái: có quan hệ tổ tiên, không có và không kiểm tra được.
• Kiểm tra khả năng cherry-pick, squash hoặc revert khi lịch sử không trả lời đủ câu hỏi.
• Chạy ca kiểm thử của lỗi trên artifact thực tế sẽ phát hành.
• Giữ quyết định triển khai tách khỏi một phép kiểm tra Git đơn lẻ.

Git merge-base cung cấp bằng chứng về đường đi trong lịch sử. Kết hợp bằng chứng đó với diff và kiểm thử giúp nhóm xác nhận bản sửa lỗi chắc chắn hơn mà không biến quan hệ tổ tiên thành lời bảo đảm về hành vi ứng dụng.