28 câu hỏi Git: answer và follow-up

Đáp án: Không. Blob chỉ lưu bytes; tree lưu tên, mode và object ID.
Follow-up: Vì sao hai file cùng content có thể dùng chung blob?

Đáp án: Một ref di chuyển, thường trỏ commit tip; commit không “thuộc” độc quyền branch.
Follow-up: Detached HEAD khác branch checkout thế nào?

Đáp án: Message nằm trong commit content; hash đổi và descendants cũng đổi vì parent ID đổi.
Follow-up: Điều này ảnh hưởng signed commits và review links ra sao?

Đáp án: Không; nó local, có expiry và không push. Nó là recovery window cho ref movements.
Follow-up: Recovery plan sau reset --hard là gì?

Đáp án: Proposed next tree, chứa path/mode/object ID và conflict stages.
Follow-up: Một file vừa staged vừa modified biểu diễn thế nào?

Đáp án: Lần lượt so worktree-index và index-HEAD.
Follow-up: Lệnh nào xem toàn bộ thay đổi trước commit?

Đáp án: Merge base, ours, theirs; resolve và add đưa path về stage 0.
Follow-up: Dùng git ls-files -u điều tra thế nào?

Đáp án: Loose lưu riêng; pack gom và delta-compress objects nhưng giữ nguyên IDs.
Follow-up: Delta chain dài tác động lookup ra sao?

Đáp án: Có đường đi từ root như refs/reflogs qua graph tới object đó.
Follow-up: Vì sao xóa branch chưa chắc giải phóng disk ngay?

Đáp án: Xóa ngay unreachable objects, phá recovery window và có rủi ro với writer đồng thời.
Follow-up: Quy trình cleanup production an toàn hơn là gì?

Đáp án: Tăng tốc graph walks, reachability/pack selection và lookup qua nhiều packs.
Follow-up: Khi nào acceleration data trở nên stale?

Đáp án: Wants/haves tìm common history, rồi server gửi pack missing reachable objects.
Follow-up: Nhiều refs và history phân kỳ ảnh hưởng bước nào?

Đáp án: Command-oriented capabilities và giảm eager ref advertisement; không tự giảm payload objects.
Follow-up: Trace packet có rủi ro bảo mật gì?

Đáp án: Chỉ update khi remote ref còn ở expected value, giảm overwrite thay đổi chưa biết.
Follow-up: Lease có thay thế team coordination không?

Đáp án: Merge tạo commit nhiều parent; rebase replay tạo commits mới trên base khác.
Follow-up: Vì sao rebase shared history gây disruption?

Đáp án: Không; semantic conflicts có thể merge sạch nhưng behavior sai.
Follow-up: Test/review nào bắt cross-branch invariant?

Đáp án: History tuyến tính/revert đơn giản nhưng mất individual ancestry/topology của branch.
Follow-up: Bisect và audit bị ảnh hưởng thế nào?

Đáp án: Cắt ancestry tại shallow boundary; merge-base/blame/describe có thể thiếu semantics.
Follow-up: CI cần fetch base commit bằng cách nào?

Đáp án: Cho phép blob thiếu và lazy-fetch từ promisor remote, vẫn giữ commit/tree graph.
Follow-up: Vì sao build toàn repo có thể chậm hơn?

Đáp án: Checkout giới hạn paths materialized; sparse index nén index bằng sparse-directory entries.
Follow-up: Tool compatibility cần test ở đâu?

Đáp án: Gitlink tới exact submodule commit; URL/path metadata nằm trong .gitmodules.
Follow-up: Vì sao phải push submodule trước superproject?

Đáp án: Git giữ pointer, LFS server giữ binary; thêm auth/quota/retention/backup dependency.
Follow-up: Clone thành công nhưng checkout LFS thất bại khi nào?

Đáp án: Dùng chung object database/refs; mỗi worktree có HEAD, index và files riêng.
Follow-up: Vì sao một branch không nên checkout hai nơi?

Đáp án: Không đáng tin cậy: không clone mặc định và có thể bypass. Enforce ở server/CI/protected refs.
Follow-up: Pre-receive hook cần chống resource exhaustion thế nào?

Đáp án: Chứng minh key đã ký exact commit nếu trust/key policy hợp lệ; không chứng minh review hay CI.
Follow-up: Key revocation và provenance xử lý ở lớp nào?

Đáp án: Poisoning, corruption, credential/object leakage và concurrent writes.
Follow-up: Thiết kế isolation, validation và clean-fetch fallback ra sao?

Đáp án: Kiểm integrity/connectivity theo Git model, không kiểm business correctness hay malware.
Follow-up: Khi repo hỏng, vì sao fresh clone thường tốt hơn sửa tay?

Đáp án: Không; deletion/corruption có thể replicate và còn thiếu LFS/config/hooks/permissions.
Follow-up: Một DR drill phải verify refs, LFS, RPO và RTO thế nào?