Git staging: Kiểm tra đúng nội dung trước khi commit

Bạn sửa file, chạy test thành công rồi commit, nhưng đồng nghiệp vẫn nhận phiên bản thiếu một đoạn sửa. Nguyên nhân có thể không nằm ở Git mất dữ liệu: nội dung đã stage khác với nội dung đang có trong thư mục làm việc. Hiểu vùng staging giúp kiểm soát chính xác phần sẽ đi vào commit.

Hướng dẫn dành cho repository đã có commit đầu tiên và không đang giải quyết merge conflict. Đường dẫn dưới đây là ví dụ, cần thay bằng file thật. Các lệnh add và restore --staged có thay đổi vùng staging; chỉ thực hiện với file bạn đã xác định.

1. Phân biệt ba trạng thái

Theo tài liệu git-add, add ghi nhận nội dung file tại thời điểm chạy vào index. Nếu sửa thêm sau đó, phần mới không tự động cập nhật vào staging. Một file vì vậy có thể đồng thời có thay đổi đã stage và chưa stage.

Ví dụ giả định: bạn sửa hàm tính tổng rồi add; sau đó thêm kiểm tra đầu vào nhưng chưa add lại. Commit thông thường sẽ chứa phần đã đưa vào index, không tự lấy mọi dòng mới nhất đang hiện trong editor.

2. Dùng đúng diff cho câu hỏi đang hỏi

Git diff hỗ trợ các phép so sánh khác nhau. Với file được theo dõi, trong trạng thái bình thường:

git status --short
git diff -- src/Example.php
git diff --cached -- src/Example.php
git diff HEAD -- src/Example.php

• git diff: phần working tree khác index, tức thay đổi chưa stage.
• git diff --cached: phần index khác HEAD, tức phần đã stage so với commit hiện tại.
• git diff HEAD: thay đổi ròng giữa working tree và HEAD, không tách riêng hai lớp trên.

File chưa được theo dõi không tự xuất hiện như một bản diff thông thường chỉ vì nó đang nằm trong thư mục. Luôn xem status để tránh bỏ sót file mới. Không coi kết quả trống của git diff là bằng chứng “không có gì để commit”: có thể mọi thay đổi đã nằm trong staging.

3. Stage có phạm vi và xem lại

git add -- src/Example.php
git diff --cached --stat
git diff --cached

Danh sách thống kê giúp nhận ra file ngoài phạm vi, nhưng không thay thế đọc nội dung. Kiểm tra cả file cấu hình, dữ liệu mẫu, file sinh tự động và các dòng chứa thông tin nhạy cảm. Không dùng lệnh add toàn bộ theo thói quen khi thư mục có nhiều công việc chưa liên quan.

Khi một file chứa nhiều thay đổi độc lập, git add -p -- src/Example.php cho phép chọn từng hunk. Tuy nhiên, chia nhỏ bằng công cụ không bảo đảm từng phần là một thay đổi hoàn chỉnh: phần đã stage có thể phụ thuộc vào hàm hoặc import chưa được chọn.

4. Bỏ stage không đồng nghĩa xóa nội dung sửa

Tài liệu git-restore phân biệt đích khôi phục index và working tree. Trong phạm vi bài viết, lệnh sau đưa mục trong index về HEAD nhưng không sửa file working tree:

git restore --staged -- src/Example.php
git status --short
git diff -- src/Example.php

Đừng bỏ tùy chọn --staged hoặc tự thêm --worktree nếu mục tiêu chỉ là bỏ stage. Những biến thể khác có thể ghi đè thay đổi đang sửa. Unstage cũng không phải cách sao lưu một phiên bản trung gian chỉ tồn tại trong index; nếu cần giữ chính phiên bản đó, bảo toàn nó trước.

5. Test đúng thứ sẽ bàn giao

Đề xuất kiểm tra: sau khi chọn nội dung commit, đối chiếu xem working tree còn phần chưa stage mà test đang phụ thuộc không. Test chạy trong thư mục hiện tại thường dùng file của working tree, không tự dựng một bản ứng dụng chỉ từ index.

Nếu chia một sửa đổi lớn thành nhiều commit, cần xác minh từng snapshot bàn giao bằng quy trình test phù hợp của dự án, chẳng hạn trên môi trường kiểm thử tách biệt. Không dọn thay đổi chưa commit bằng lệnh phá hủy chỉ để làm môi trường “sạch”.

6. Checklist trước commit

git diff --cached --check
git diff --cached --name-status
git diff --cached
git status --short

--check hỗ trợ phát hiện một số lỗi whitespace và dấu conflict; nó không thay thế test, kiểm tra bảo mật hoặc review logic. Sau khi toàn bộ nội dung đã đúng phạm vi, mới thực hiện commit theo quy trình của nhóm.

• Phần staged phục vụ một mục đích rõ ràng.
• Không vô tình bỏ quên file mới hoặc thay đổi phụ thuộc.
• Không chứa token, mật khẩu, log nhạy cảm hay dữ liệu cá nhân.
• Test phản ánh đúng snapshot định bàn giao.
• Những phần chưa stage còn lại vẫn được giữ nguyên có chủ đích.

Staging không chỉ là bước trung gian phải bấm qua. Nó là nơi chọn nội dung bàn giao. Thói quen xem staged diff trước commit giúp lịch sử rõ hơn và giảm tình huống “máy mình chạy được” do commit thiếu phần sửa.