Hướng dẫn · 17/10/2026

Git ls-tree: Kiểm tra danh sách file trong commit mà không checkout

Một đồng nghiệp hỏi: “Bản phát hành này đã có file cấu hình mẫu chưa?” Bạn đang sửa mã trên nhánh khác và không muốn chuyển phiên bản chỉ để tìm một đường dẫn. Git ls-tree giúp kiểm tra danh sách file đã lưu trong commit, độc lập với những gì đang có trong thư mục làm việc.

Git ls-tree: Kiểm tra danh sách file trong commit mà không checkout

Một đồng nghiệp hỏi: “Bản phát hành này đã có file cấu hình mẫu chưa?” Bạn đang sửa mã trên nhánh khác và không muốn chuyển phiên bản chỉ để tìm một đường dẫn. Git ls-tree giúp kiểm tra danh sách file đã lưu trong commit, độc lập với những gì đang có trong thư mục làm việc.

1. Chọn đúng phiên bản cần kiểm tra

Các ví dụ dưới đây dùng HEAD, tức commit hiện tại. Khi kiểm tra bản phát hành, thay HEAD bằng tag hoặc mã commit đã xác nhận. Ghi lại mã commit trong kết quả bàn giao để người khác có thể đối chiếu đúng snapshot, ngay cả khi nhánh tiếp tục thay đổi.

git rev-parse HEAD
git ls-tree --full-tree --name-only HEAD

Lệnh thứ hai liệt kê các mục ở cấp gốc. Nếu thấy tên một thư mục, đừng kết luận rằng đã xem đủ file bên trong. Theo tài liệu Git ls-tree, tùy chọn -r cho phép đi vào các cây con; --full-tree giúp việc liệt kê không bị giới hạn bởi thư mục hiện tại.

2. Liệt kê file và thu hẹp phạm vi

git ls-tree -r --full-tree --name-only HEAD
git ls-tree -r --full-tree --name-only HEAD -- docs/

Dòng đầu phù hợp khi cần rà soát toàn bộ tên file trong snapshot. Dòng sau tập trung vào thư mục docs ở gốc repository. Ví dụ, trước khi bàn giao tài liệu, bạn có thể tìm docs/setup.md trong danh sách thay vì dựa vào file đang mở trong trình soạn thảo.

Nếu không thấy đường dẫn mong muốn, kiểm tra lại commit, cách viết hoa và vị trí thư mục. Kết quả rỗng không tự chứng minh rằng file chưa từng tồn tại trong lịch sử. File có thể nằm ở một nhánh khác hoặc đã đổi tên trước snapshot đang xem.

3. Phân biệt snapshot với thư mục đang làm việc

Giả sử commit hiện tại có docs/setup.md, nhưng bạn vừa tạo thêm docs/checklist.md và chưa commit. Danh sách từ HEAD vẫn chỉ phản ánh nội dung đã lưu ở commit đó. Ngay cả khi checklist đã được stage, HEAD cũng chưa thay đổi cho đến khi có commit mới.

Đây là lý do một file “có trên máy em” chưa đủ để xác nhận nó thuộc phiên bản bàn giao. Với mỗi kiểm tra, nên ghi rõ ba thông tin: commit được kiểm tra, đường dẫn cần tìm và kết quả quan sát. Không cần thay đổi nhánh hoặc xáo trộn công việc đang làm.

4. Xem thêm metadata khi cần

git ls-tree -r -l --full-tree HEAD -- docs/

Chế độ này hiển thị mode, loại đối tượng, mã đối tượng, kích thước blob theo byte và đường dẫn. Nó hữu ích để nhận ra một file tài liệu lớn bất thường trước khi điều tra sâu hơn. Không coi kích thước blob là dung lượng repository trên đĩa hay dung lượng bản build.

Danh sách đường dẫn cũng không xác nhận ứng dụng chạy được. Một bản phát hành còn có thể cần dependency, tài nguyên sinh khi build hoặc dữ liệu ngoài Git. Hãy kết hợp việc kiểm kê với quy trình build và kiểm thử của dự án.

5. Lưu ý khi đưa vào script

Để đọc thủ công, đầu ra theo dòng thường đủ thuận tiện. Khi xử lý tên file bất kỳ bằng chương trình, dùng -z và bộ đọc hỗ trợ ký tự phân cách NUL; không tách tên file theo dấu cách. Luôn kiểm tra mã thoát trước khi tin vào danh sách nhận được.

Checklist cuối: đúng commit, đúng phạm vi, có đường dẫn cần kiểm tra và không nhầm file chưa commit với nội dung phát hành. Một lần kiểm kê nhỏ như vậy giúp cuộc trao đổi về “file đã có trong bản nào” trở nên cụ thể và có thể kiểm chứng.

Thảo luận

Bình luận 0

Đăng nhập để bình luận

Bạn cần có tài khoản để tham gia thảo luận và trả lời độc giả khác.

Đăng nhậpĐăng ký

Chưa có bình luận. Hãy là người đầu tiên chia sẻ ý kiến.