Cách ‘hack’ tốc độ Git Clone cho những Repository hàng chục GB

Git tutorial - IT technology blog
Git tutorial - IT technology blog

Cơn ác mộng lúc 2 giờ sáng với Repo 20GB

Đồng hồ điểm 2 giờ sáng. Mình đang trực chiến để deploy một hotfix gấp. Bỗng dưng, pipeline CI/CD báo lỗi ‘Timeout’. Kiểm tra log, mình tá hỏa khi bước git clone đã ngốn tới 15 phút mà vẫn chưa xong. Cái repo này đã tích tụ hơn 10 năm lịch sử, nặng gần 20GB với hàng tá file binary cũ rích.

Nếu cứ ngồi đợi kéo hết đống dữ liệu đó về, chắc khách hàng “xẻ thịt” mình mất. Trong cơn bĩ cực, mình chợt nhớ ra một điều. Mình không cần cả “gia phả” của dự án chỉ để sửa vài dòng code. Đó là lúc Shallow Clone và Partial Clone trở thành cứu cánh. Nếu bạn cũng đang ngán ngẩm cảnh đi pha cafe xong quay lại mà Git vẫn chưa clone xong, bài viết này là dành cho bạn.

Mì ăn liền: Tăng tốc Clone trong 30 giây

Bạn đang vội và chỉ muốn lấy code về ngay để fix bug? Hãy thử một trong hai lệnh dưới đây:

Cách 1: Chỉ lấy commit mới nhất (Shallow Clone)

git clone --depth 1 https://github.com/user/huge-repo.git

Lệnh này bỏ qua toàn bộ lịch sử. Nó chỉ tải về trạng thái mới nhất của code. Kết quả? Dung lượng tải về giảm từ 5GB xuống còn khoảng 100MB trong tích tắc.

Cách 2: Lấy mọi commit nhưng bỏ qua file nặng (Partial Clone)

git clone --filter=blob:none https://github.com/user/huge-repo.git

Cách này thông minh hơn. Nó tải toàn bộ lịch sử commit nhưng “quên” các file (blobs) đi. Git chỉ thực sự tải file khi bạn cần dùng đến (ví dụ khi checkout sang branch khác).


Tại sao Repo của bạn lại phình to như vậy?

Mặc định, lệnh git clone sẽ tải toàn bộ mọi thứ. Từ mọi phiên bản của từng file đến mọi branch và tag từ ngày đầu thành lập. Với những dự án Monorepo lâu đời, đây là gánh nặng khủng khiếp cho cả băng thông lẫn ổ cứng máy tính.

1. Shallow Clone (–depth) – Chỉ lấy phần ngọn

Hãy tưởng tượng bạn chỉ đọc chương cuối của một cuốn tiểu thuyết thay vì đọc từ đầu. --depth 1 tạo ra một lịch sử bị cắt cụt (truncated history).

  • Ưu điểm: Tốc độ cực nhanh, tiết kiệm bộ nhớ tối đa.
  • Nhược điểm: Bạn không thể xem git log các commit cũ. Đôi khi việc push hoặc merge sẽ lỗi vì Git thiếu thông tin về các commit cha.

Mình từng nếm trái đắng với Shallow Clone trên Jenkins. Do thiếu lịch sử, tool SonarQube không thể chạy git blame để gán bug cho đúng người. Báo cáo gửi về sai be bét. Vì vậy, chỉ nên dùng Shallow Clone cho các tác vụ build hoặc test nhanh.

2. Partial Clone (–filter) – Tải file theo nhu cầu

Tính năng này xuất hiện từ Git 2.20 và thực sự là một cuộc cách mạng. Nó giữ nguyên cấu trúc các commit nhưng để nội dung file lại trên server.

Có hai bộ lọc phổ biến bạn nên nhớ:

  • --filter=blob:none: Không tải bất kỳ file nào cho đến khi checkout. Đây là lựa chọn cân bằng nhất giữa tốc độ và tính linh hoạt.
  • --filter=blob:limit=1m: Chỉ tải các file nhỏ dưới 1MB. Những file nặng như ảnh, video hay file binary sẽ nằm lại server cho đến khi bạn thực sự chạm vào chúng.

Kỹ thuật nâng cao: Kết hợp với Sparse Checkout

Bạn chỉ cần folder /frontend trong một Monorepo khổng lồ chứa cả Backend và Mobile? Đừng tải hết. Hãy dùng combo Partial Clone + Sparse Checkout.

# 1. Clone nhưng không tải file, không checkout
git clone --filter=blob:none --no-checkout https://github.com/user/huge-repo.git
cd huge-repo

# 2. Chỉ định thư mục bạn thực sự cần
git sparse-checkout set web-app/src

# 3. Checkout để lấy file của folder đó
git checkout main

Cách này giúp bạn vừa tiết kiệm thời gian tải, vừa không phải chứa hàng nghìn file rác trong máy.


Kinh nghiệm thực chiến: Nên chọn phương án nào?

Sau nhiều lần “vã mồ hôi” với các hệ thống cũ, mình rút ra bộ quy tắc chọn lựa như sau:

Dùng Shallow Clone (–depth) khi:

  • Chạy CI/CD pipeline (build xong rồi xóa ngay).
  • Cần hotfix nhanh trên server production mà không muốn chờ đợi.
  • Bạn chắc chắn không cần rebase hay tra cứu lịch sử sâu.

Dùng Partial Clone (–filter) khi:

  • Làm việc lâu dài trong một dự án có repo quá nặng.
  • Cần dùng git log hoặc git blame để điều tra lịch sử code.
  • Muốn tiết kiệm ổ cứng nhưng vẫn giữ đầy đủ quyền năng của Git.

Có lần mình đã force push nhầm branch trên một shallow clone vì không thấy rõ lịch sử. Bài học xương máu là: luôn ưu tiên Partial Clone cho máy cá nhân. Hãy chỉ dùng Shallow Clone cho máy ảo (VM) hoặc Docker container.

Túm lại là

Làm chủ công cụ là cách tốt nhất để giữ mạch sáng tạo. Hiểu rõ Shallow và Partial Clone giúp bạn bớt ức chế khi làm dự án lớn. Đồng thời, nó giúp hệ thống CI/CD của team chạy mượt mà hơn hẳn. Đừng để thanh tiến trình git clone đứng yên làm bạn nản lòng. Thử áp dụng ngay vào dự án của bạn xem, sự khác biệt sẽ khiến bạn bất ngờ đấy!

Share: