Series Git CLI Thực chiến #6: Trạm cuối – Thao túng lịch sử với Rebase và Truy vết Bug bằng Bisect

1. git rebase: Nghệ thuật là sự đường thẳng

Ở Bài 4, chúng ta đã dùng git merge để gộp nhánh. Đặc điểm của merge là nó tạo ra một "nút thắt" (merge commit) nối hai nhánh lại với nhau. Nếu 10 người cùng merge vào nhánh main, lịch sử Git (hiển thị qua lệnh git log --graph) sẽ trông như một cái mạng nhện chằng chịt các đường chéo.

Để giữ cho lịch sử main là một đường thẳng tắp, sạch sẽ và dễ đọc, các Senior Engineer thường dùng git rebase thay vì merge.

Cách Rebase hoạt động: Giả sử nhánh main đang có commit A ➔ B. Anh em tách nhánh feature từ B, tạo ra commit C ➔ D. Trong lúc đó, đồng nghiệp đã kịp push commit E lên main. Thay vì gộp chéo (Merge), lệnh Rebase sẽ làm một thao tác ma thuật: Nó "bứng" cái gốc của nhánh feature (đang ở B), dời lên nối tiếp vào E. Code của anh em lúc này sẽ trở thành A ➔ B ➔ E ➔ C' ➔ D'. Tất cả nằm trên một đường thẳng hoàn hảo.

Thực chiến:

# 1. Đứng ở nhánh feature của anh em
git checkout feature/vitess-sync

# 2. Rebase nhánh của mình lên bản mới nhất của main
git rebase main

# 3. (Nếu có conflict thì sửa tay, sau đó gõ lệnh tiếp tục)
git rebase --continue

Tuyệt chiêu Interactive Rebase (-i): Xóa dấu vết "tội lỗi" Trong lúc code, chắc hẳn anh em hay có những commit rác kiểu:

• commit -m "fix typo"
• commit -m "quen cham phay"
• commit -m "test thu CICD"

Nếu bê nguyên đống rác này gộp vào main, Leader sẽ đánh giá không cao. Trước khi gộp, hãy dùng lệnh:

git rebase -i HEAD~3

(Lệnh này mở giao diện tương tác để xử lý 3 commit gần nhất).

Một bảng text sẽ hiện ra. Anh em có thể chọn chữ squash (hoặc s) để "nghiền nát" các commit rác, gộp chung chúng vào cái commit tử tế đầu tiên. Từ 3 commit lẻ tẻ, anh em chỉ giữ lại 1 commit sạch đẹp duy nhất trước khi đẩy lên cho Jenkins build.

2. git bisect: Thám tử truy vết Bug bằng thuật toán Nhị phân

Đây là tình huống thực tế kinh điển: Thứ Sáu tuần trước, luồng xử lý giao dịch offline của hệ thống Metro chạy cực kỳ hoàn hảo. Thứ Sáu tuần này, hệ thống báo lỗi không thể đồng bộ dữ liệu. Nhìn vào lịch sử, trong 1 tuần qua cả team đã đẩy lên 50 commit mới. Không ai biết chính xác dòng code nào, ở file nào, do ai viết đã gây ra cái lỗi này. Nếu anh em checkout từng commit một để test lại thì đến sáng mai cũng chưa xong.

Xin giới thiệu: Cỗ máy dò mìn git bisect.

Git sẽ dùng thuật toán tìm kiếm nhị phân (Binary Search) để chia đôi lịch sử. Thay vì test 50 lần, anh em chỉ cần test tối đa 5-6 lần là tóm được tận tay thủ phạm.

Cách triển khai:

Bước 1: Bật máy dò mìn

git bisect start

Bước 2: Đánh dấu trạng thái hiện tại là LỖI

git bisect bad

Bước 3: Đánh dấu tọa độ thời gian HOẠT ĐỘNG TỐT

Anh em dùng git log tìm lại mã Hash của cái ngày thứ Sáu tuần trước (ví dụ Hash là a1b2c3d), và báo cho Git:

git bisect good a1b2c3d

Bước 4: Quá trình Thẩm vấn

Ngay lúc này, Git sẽ tính toán và tự động "nhảy" đến cái commit nằm ngay chính giữa khoảng thời gian đó (commit thứ 25). Anh em tiến hành chạy thử code (ví dụ: gõ go test ./... hoặc chạy thử ứng dụng).

• Nếu code vẫn lỗi ➔ Gõ git bisect bad. Git biết lỗi nằm ở nửa đầu, nó sẽ chặt tiếp nửa đó ra làm hai (nhảy đến commit thứ 12).
• Nếu code chạy tốt ➔ Gõ git bisect good. Git biết lỗi phải nằm ở nửa sau, nó nhảy đến commit thứ 37.

Cứ lặp lại như vậy, rất nhanh chóng, Git sẽ in ra màn hình một dòng kết luận đanh thép:

7f8a9b is the first bad commit

Anh em dùng git show 7f8a9b, xem ai là người viết đoạn code đó, sửa lại, và kết thúc tiến trình điều tra bằng lệnh:

git bisect reset

Đưa không gian làm việc trở lại hiện tại. Vụ án khép lại!

Tổng kết toàn bộ Series Git CLI

Vậy là chúng ta đã hoàn tất bản đồ kho báu mang tên Git.

Khởi đầu từ việc hiểu kiến trúc 3 khu vực (Xưởng mộc ➔ Đóng gói ➔ Kho lưu trữ), vươn ra giao tiếp với Remote qua GitHub, sử dụng Branching để làm việc nhóm, học cách đối mặt với sự cố bằng Conflict Resolution / Stash, và cuối cùng là chạm đến cảnh giới thiết kế lịch sử với Rebase và Bisect.

Một Kỹ sư hệ thống (Backend/DevOps) thực thụ không bao giờ hoảng loạn khi hệ thống vỡ vụn, bởi vì họ biết trong tay mình luôn có cỗ máy thời gian Git để quay lại, và đường ống CI/CD Jenkins để tự động triển khai những bản vá một cách chuẩn xác nhất.