Project mein ek file hai hello.txt jisme hi\n likha hai.
Blob. Content hi\n → store = "blob 3\0hi\n" → kuch hash B.
Ye step kyun? File ke bytes ko apni identity milti hai, naam se independent.
Tree. Ek line: 100644 blob B<TAB>hello.txt → hashed → tree T.
Ye step kyun?Naamhello.txt aur uski permission 100644tree mein rehti hai, blob mein nahi — isliye file rename karne se tree badalta hai lekin blob reuse hota hai.
Commit. Tree T ko point karta hai, koi parent nahi (pehla commit), author + message → commit C.
Ye step kyun?C ek full snapshot hai: C se tum project ke har ek byte tak pahunch sakte ho.
commit C ──tree──▶ tree T ──hello.txt──▶ blob B ("hi\n")
Ab tum notes.txt = hi\n (same content!) add karte ho aur phir commit karte ho.
notes.txt ke liye Blob? Content hai hi\n → same store → same hash B. Koi naya blob store nahi hota.Ye step kyun? Content-addressing dedup karta hai: identical bytes ⇒ identical key.
Naya tree T2 ab do entries list karta hai (hello.txt→B, notes.txt→B). Naya tree hash.
Kyun? Directory listing badal gayi, isliye tree ke bytes badal gaye, isliye uska hash badal gaya.
Naya commit C2 with tree=T2 aur parent=C.
Kyun? Parent link hi DAG edge banata hai aur tumhe history deta hai.
blob (file content), tree (directory listing), commit (snapshot + parents), tag (named annotated pointer)
Ek blob kya store karta hai aur kya NAHI karta?
Raw file bytes store karta hai; filename, path, ya permissions NAHI store karta.
Git mein filenames aur file modes kahan store hote hain?
Tree object mein, entries (mode, type, hash, name) ke roop mein.
Git object ka SHA-1 kaise compute hota hai?
SHA1("<type> <size>\0" + content) — header include hota hai.
Ek empty file (blob) ka SHA-1 kya hai?
e69de29bb2d1d6434b8b29ae775ad8c2e48c5391
Ek commit object kya point karta hai?
Ek root tree + zero/one/many parent commits + author/committer + message.
Root commit / normal commit / merge commit ke kitne parents hote hain?
0 / 1 / 2 (ya zyada).
Git history ek DAG kyun hai aur tree ya general graph kyun nahi?
Directed (child→parent) aur acyclic kyunki parent ka hash child create hone se pehle fix hota hai; merges se ye fan in hoti hai.
Kya ek branch ek Git object hai?
Nahi — ye ek movable pointer hai (refs/heads mein ek file jisme ek commit hash hai).
Identical file content copy karne se koi naya blob kyun nahi banta?
Content-addressing: same bytes → same SHA-1 → same key → ek baar stored (deduplication).
Kya Git commits ke beech diffs store karta hai?
Nahi, har commit ek full tree snapshot hai; delta compression baad mein sirf packfiles ke andar hota hai.
Git history tamper-evident kaise hai?
Ek commit ka hash uske tree aur parent hashes par depend karta hai, isliye purani history edit karne se har descendant hash badal jaata hai.
Recall Feynman: 12-saal ke bachche ko samjhao
Ek magic toy box ki kalpana karo. Jab bhi tum usme koi toy daalte ho, box ek sticker print karta hai jo toy ki exact shape se bani ek secret code hai. Same toy ⇒ same sticker, hamesha. Blobs toys hain (actual cheezein). Ek tree ek labelled tray hai jo kehta hai "sticker #B ka naam hello.txt hai". Ek commit poore room ki ek photo hai plus ek note jo kehta hai "is photo se pehle wali photo woh wali thi." Kyunki har photo purani photo ko point karti hai, tum time mein peeche chal sakte ho — lekin kabhi chakkar mein nahi, kyunki tum us photo ki photo nahi le sakte jo abhi exist hi nahi karti. Naya version save karne ke liye, Git purani toys kabhi nahi mitata; bas ek nayi photo kheenchta hai. Isliye branch delete karna sirf ek bookmark phenk dena hai, photos nahi.