Git stash: Kiểm tra đúng bản lưu trước khi khôi phục

Sau vài lần chuyển việc, danh sách stash có thể chứa nhiều bản sửa dở với mô tả gần giống nhau. Khôi phục ngay bản mới nhất không chắc đưa bạn về đúng công việc cần tiếp tục. Một bước đọc lại nội dung trước khi áp dụng giúp tránh trộn thay đổi của hai nhiệm vụ.

1. Xác định trạng thái hiện tại trước

git status --short
git branch --show-current
git stash list

Đọc tên nhánh và các file đang sửa trước khi chọn stash. Nếu có thay đổi chưa lưu an toàn, hãy dừng để bảo vệ chúng theo quy trình của nhóm. Đừng dùng reset hoặc clean chỉ để làm thư mục “sạch” cho nhanh.

Ví dụ bạn cần tiếp tục sửa bộ lọc tìm kiếm nhưng stash mới nhất lại thuộc biểu mẫu đăng ký. Tên nhánh trong mô tả chỉ là gợi ý; danh sách file và diff mới giúp xác nhận nội dung thực sự.

2. Xem danh sách file rồi đọc diff

git stash show --stat 'stash@{0}'
git stash show -p --include-untracked 'stash@{0}'

Theo tài liệu Git stash, show cho phép xem bản lưu; -p hiển thị patch và --include-untracked đưa cả file chưa được theo dõi đã lưu trong stash vào phần xem. Tùy chọn này không lấy lại file vốn chưa từng được stash.

Thay số 0 bằng mục đã xác định trong danh sách. Dùng dấu nháy quanh tham chiếu như ví dụ để tránh shell diễn giải ký tự đặc biệt. Các lệnh xem không áp dụng thay đổi vào file đang làm việc.

Khi đọc diff, đối chiếu ít nhất ba điểm: chức năng đang sửa, file cấu hình đi kèm và file kiểm thử. Một bản lưu có đúng file chính nhưng kèm cấu hình thử nghiệm của nhiệm vụ khác vẫn cần được xem xét kỹ.

3. Chọn apply hay pop có chủ đích

apply áp dụng nội dung nhưng giữ mục stash. pop áp dụng và loại mục khỏi danh sách khi thành công; nếu có xung đột, mục được giữ lại. Vì vậy, khi muốn kiểm tra kết quả trước khi dọn bản lưu, có thể chọn apply:

git stash apply 'stash@{0}'

Lệnh này thay đổi working tree. Chỉ chạy sau khi đã chọn đúng bản, xác nhận nhánh đích và bảo vệ công việc hiện tại. Nếu cần khôi phục cả trạng thái staged, tìm hiểu --index trước; đừng mặc định rằng apply thông thường tái tạo nguyên trạng vùng stage.

Giữ lại stash sau apply là một điểm kiểm tra thuận tiện, không phải lý do để áp dụng lặp lại cùng bản. Sau lần đầu, hãy đọc kết quả lệnh và kiểm tra file trước khi làm tiếp.

4. Khi có xung đột, ngừng chạy lại lệnh

git status
git diff
git diff --cached

Nếu Git báo xung đột, đừng tiếp tục pop hoặc apply với hy vọng lần sau sẽ tự hết. Xác định file bị ảnh hưởng, đọc hai phía thay đổi và giải quyết theo ý nghĩa của chức năng. Không chọn toàn bộ “ours” hoặc “theirs” chỉ vì muốn hết dấu conflict.

Sau khi xử lý, chạy lint và test liên quan. Một patch áp dụng không báo lỗi chỉ cho biết thao tác ghép thay đổi đã thực hiện được, không chứng minh chức năng còn đúng với code hiện tại.

5. Chỉ dọn bản lưu sau khi xác minh

Chỉ cân nhắc xóa một mục stash khi thay đổi cần thiết đã được kiểm tra và lưu bền vững. Đọc lại danh sách ngay trước khi dọn vì chỉ số có thể thay đổi sau khi thêm hoặc xóa mục. Tránh xóa toàn bộ danh sách để xử lý một bản lưu đã dùng xong.

• Đúng repository và nhánh đích.
• Đã kiểm tra cả file đang sửa lẫn nội dung stash.
• Không bỏ sót file mới cần thiết cho chức năng.
• Đã xử lý xung đột và chạy kiểm thử phù hợp.
• Không coi stash trên một máy là bản sao lưu ngoài máy.

Các lệnh trên là quy trình tham khảo để thực hiện trên repository của bạn, không phải báo cáo đã khôi phục dữ liệu thật. Thói quen xem trước, áp dụng có chủ đích và xác minh sau cùng giúp stash phục vụ đúng vai trò lưu công việc tạm thời.