Thư mục dự án có nhiều file build, ghi chú thử nghiệm và cấu hình máy cá nhân. Một lệnh dọn dẹp có vẻ tiện lợi nhưng cũng có thể xóa bản công việc duy nhất chưa được lưu trong Git. Bài này hướng dẫn kiểm tra phạm vi của git clean mà không thực hiện xóa.
1. Untracked không có nghĩa là không cần thiết
Hãy chia dữ liệu thành ba nhóm trước khi dọn: file đang được Git theo dõi, file chưa được theo dõi và file chưa được theo dõi nhưng khớp quy tắc ignore. Một bản thiết kế mới có thể thuộc nhóm thứ hai; cấu hình môi trường hoặc dữ liệu thử nghiệm quý giá có thể thuộc nhóm thứ ba.
Đừng dùng trạng thái Git làm tiêu chí duy nhất để đánh giá giá trị của file. Trước khi xóa thật, cần biết file do công cụ nào tạo, có tái tạo được không và bản sao ở đâu.
2. Bắt đầu bằng chế độ xem trước
Theo tài liệu git clean, tùy chọn -n chỉ liệt kê việc dự kiến làm, không xóa dữ liệu. Thêm -d để xét cả thư mục untracked khi chưa chỉ định pathspec.
git clean -n -dVí dụ đầu ra minh họa:
Would remove scratch-notes.txt
Would remove build-preview/Đây là danh sách cần xem xét, không phải xác nhận rằng mọi mục đều an toàn để xóa. Dòng tên thư mục có thể đại diện cho nhiều file bên trong. Hãy mở thư mục đó bằng trình quản lý file hoặc IDE và kiểm tra cả những nội dung do người khác đang làm.
Chạy từ đúng vị trí trong repository. Khi đang đứng ở một thư mục con, đừng mặc định kết quả đã bao quát toàn bộ dự án.
3. Phân biệt -x và -X trước khi sao chép lệnh
Hai tùy chọn chỉ khác chữ hoa nhưng phạm vi khác nhau: -x đưa cả file ignored vào diện xem xét; -X chỉ xét file ignored. Cả hai ví dụ dưới đây vẫn giữ -n, nên chỉ xem trước.
git clean -n -d -x
git clean -n -d -XGiả sử dự án có một file ghi chú chưa được theo dõi và một thư mục đầu ra đã được ignore. Lần xem trước mặc định có thể hiện ghi chú; lần dùng -x có thể hiện cả hai; lần dùng -X chỉ hiện phần ignored. Danh sách thực tế còn phụ thuộc đường dẫn hiện tại, quy tắc ignore và cấu trúc repository.
Ignored không đồng nghĩa với có thể tái tạo. Một file chứa thiết lập kết nối hoặc tài liệu nội bộ có thể được ignore chính vì không nên đưa lên repository. Tuyệt đối không suy ra rằng chỉ dọn ignored là an toàn.
4. Thu hẹp kiểm tra về một đường dẫn
Nếu mục tiêu chỉ là thư mục đầu ra build-preview/, hãy đứng ở thư mục gốc dự án và chỉ định đường dẫn thay vì bắt đầu bằng toàn bộ working tree:
git clean -n -- build-preview/
git clean -n -X -- build-preview/Dấu -- tách tùy chọn khỏi đường dẫn. Lệnh đầu giữ quy tắc ignore thông thường; lệnh sau chỉ xem phần ignored trong phạm vi đó. Theo tài liệu Git, khi đã chỉ định pathspec, không cần dựa vào -d để xét các file untracked phù hợp bên trong.
Tên thư mục trong ví dụ là giả định. Không sao chép sang dự án thật nếu chưa xác nhận đúng đường dẫn và nội dung. Nếu có repository lồng bên trong, hãy dừng để xác định chủ sở hữu và mục đích thay vì cố vượt qua cơ chế bảo vệ.
5. Git không phải thùng rác cho mọi file
Nếu một file chưa từng được lưu vào lịch sử Git, không nên trông chờ việc đổi nhánh hoặc dùng reflog sẽ khôi phục nội dung vừa mất. Bản sao lưu, lịch sử cục bộ của IDE hoặc hệ thống đồng bộ có thể giúp trong một số trường hợp, nhưng không phải cam kết khôi phục.
Với dữ liệu cần giữ, tạo bản sao ở vị trí nằm ngoài phạm vi dọn và kiểm tra có thể mở được trước. Không đưa bí mật vào commit chỉ để có bản sao. Nếu thao tác thủ công qua thùng rác đáp ứng nhu cầu, đó có thể là lựa chọn dễ phục hồi hơn việc xóa bằng công cụ dòng lệnh.
6. Checklist ra quyết định
- Xác nhận repository và thư mục làm việc hiện tại.
- Chọn phạm vi nhỏ nhất, bắt đầu bằng lệnh có
-n. - Đọc từng mục, mở các thư mục được liệt kê và xác định dữ liệu cần giữ.
- Kiểm tra khả năng tái tạo hoặc bản sao lưu; không coi ignore là bảo đảm an toàn.
- Nếu file thay đổi sau lần xem trước, kiểm tra lại trước bất kỳ thao tác xóa nào.
Kết luận: Xem trước giúp hiểu phạm vi, nhưng không thay thế quyết định của người biết dữ liệu. Các lệnh trong bài đều chỉ kiểm tra; việc xóa thật nên là một bước riêng, có mục tiêu rõ ràng và phương án bảo vệ công việc chưa lưu.
Chưa có bình luận. Hãy là người đầu tiên chia sẻ ý kiến.