Tình huống thực tế: Giải cứu dự án khỏi thảm họa Git

Dưới đây là những "tai nạn" thường gặp nhất trong các dự án thực tế và quy trình xử lý chuẩn Senior.

Tình huống 1: Lỡ tay Commit API Key lên GitHub Public

Đây là thảm họa bảo mật. Ngay cả khi bạn xóa file và commit mới, API Key vẫn nằm trong Lịch sử commit.

Giải pháp sai: git rm key.txt && git commit. (Key vẫn còn trong các commit cũ). Giải pháp đúng:

1. Đổi ngay API Key trên Dashboard (Vô hiệu hóa key cũ).
2. Dùng BFG Repo-Cleaner hoặc git filter-branch để xóa vĩnh viễn file đó khỏi TOÀN BỘ lịch sử.
3. Force push lên server.

Tình huống 2: Merge lộn xộn, PR có 100 commit rác

Bạn làm feature trong 2 tuần, mỗi ngày commit 10 lần kiểu "fix", "update", "test". Khi mở PR, reviewer sẽ phát điên.

Giải pháp: Interactive Rebase (Squash).

git rebase -i HEAD~100

Bạn chọn squash cho 99 commit và giữ lại 1 commit duy nhất với nội dung tổng quát. PR của bạn giờ đây cực kỳ sạch sẽ và dễ review.

Tình huống 3: Feature A phụ thuộc Feature B (Chưa được merge)

Bạn đang làm Feature A, nhưng nửa chừng nhận ra cần code từ Feature B của đồng nghiệp (nhưng B chưa được merge vào main).

Giải pháp:

1. Tuyệt đối không copy paste code.
2. Checkout một nhánh mới từ nhánh Feature B của đồng nghiệp.
3. Làm tiếp Feature A trên đó.
4. Khi B được merge vào main, bạn chỉ cần rebase nhánh A lên main. Git sẽ tự động nhận diện phần code chung.

Tình huống 4: "Người lạ" sửa code trên server trực tiếp

Có ai đó lên thẳng server sửa nóng code (Hotfix) mà không qua Git, gây ra sự lệch lạc dữ liệu giữa local và server.

Giải pháp:

1. git fetch origin.
2. Dùng git diff main origin/main để xem họ đã sửa cái gì.
3. Bring những thay đổi đó về máy mình, commit chính thức và push lại để đồng bộ hóa lịch sử.

Kết luận

Git không chỉ là công cụ lưu trữ, nó là một công cụ quản lý sự thay đổi. Mọi sai lầm đều có thể cứu vãn nếu bạn bình tĩnh và hiểu rõ cơ chế vận hành của nó.