كيف يعمل Git بشكل داخلي؟

Question

Accepted Answer

بشكل داخلي، Git هو **مخزن كائنات قابل للعنونة حسب المحتوى** — حيث يخزن كل شيء كـ **كائنات** (blobs, trees, commits, tags) يتم التعرف عليها من خلال **hash SHA-1** الخاص بها. فهم هذا النموذج يوضح Git ويشرح سبب تصرف عملياته بهذه الطريقة.

## مخزن كائنات Git القابل للعنونة حسب المحتوى

```text
Git stores 4 types of OBJECTS, each identified by the SHA-1 HASH of its content:
  BLOB   → file CONTENTS (just the data, no filename)
  TREE   → a directory: maps names → blobs (files) and trees (subdirs) + permissions
  COMMIT → a snapshot: points to a TREE (the root) + parent commit(s) + author/message
  TAG    → an annotated tag object (points to a commit, with metadata)
→ Content-addressable: an object's ID IS the hash of its content (same content = same hash).
```

## الـ Commit هو لقطة، وليس diff

```text
→ Each COMMIT points to a complete TREE (the full state of the project at that point)
→ Git stores SNAPSHOTS, not diffs (though it compresses/deduplicates internally):
  unchanged files → the commit's tree just REUSES the same blob (same hash) → efficient
→ Diffs you see are COMPUTED between snapshots, not stored.
```

## كيف يتناسب كل شيء معاً

```text
Branch (e.g. main) → a pointer (a ref) to a COMMIT
HEAD → points to the current branch (or commit)
Commit → tree → blobs (the snapshot)
Commit → parent → parent → ... (the history chain)
→ Branches/tags are just small files containing a commit hash (cheap pointers).
  That's WHY branching is so lightweight.
```

## لماذا يشرح هذا سلوك Git

```text
✓ Branches are cheap → they're just a 40-char hash in a file (not file copies)
✓ Integrity → content-addressing means corruption/changes are detectable (hash mismatch)
✓ Commits are immutable → changing anything = a new hash = a new commit (why rebase
  creates NEW commits, why history rewriting changes hashes)
✓ Deduplication → identical content stored once (shared blobs)
```

## لماذا يهم هذا

فهم كيفية عمل Git بشكل داخلي هو معرفة قيمة على مستوى كبير لأنها **توضح Git** وتشرح *لماذا* تتصرف عملياته بهذه الطريقة، مما يعمق قدرتك على التفكير في Git واستخدامه بثقة.

النموذج الأساسي — Git كـ **مخزن كائنات قابل للعنونة حسب المحتوى** مع أربعة أنواع من الكائنات (blobs للمحتويات الملفات، trees للمجلدات، commits للقطات، tags) يتم التعرف على كل منها من خلال **hash محتواها** — هو الأساس الذي يرتكز عليه كل شيء آخر.

فهم أن **الـ commit هو لقطة، وليس diff** (كل commit يشير إلى شجرة كاملة تمثل حالة المشروع الكاملة، مع إعادة استخدام الملفات غير المتغيرة للـ blobs ذاتها بكفاءة، والـ diffs يتم حسابها بدلاً من تخزينها) يصحح مفهوماً خاطئاً شائعاً ويشرح نموذج Git القائم على اللقطات.

رؤية **كيف يتناسب كل شيء معاً** (branches و tags كمؤشرات/refs رخيصة للـ commits، HEAD يشير إلى الـ branch الحالية، commits مربوطة عبر الآباء) تكشف البساطة الأنيقة التحتية.

الأهم من ذلك، هذا الفهم **يشرح السلوك المرئي لـ Git**: لماذا **الفروع خفيفة الوزن** (فقط hash في ملف صغير، وليس نسخ ملفات — مما يشرح سرعة الفروع)، لماذا لـ Git **سلامة** (العنونة حسب المحتوى تكتشف الفساد عبر عدم تطابق hash)، لماذا **الـ commits غير قابلة للتغيير** وعمليات إعادة كتابة السجل مثل rebase تنشئ **commits جديدة برموز hash جديدة** (تغيير أي محتوى يغير hash)، ولماذا Git **يقضي على التكرار** (المحتوى المتطابق يتم تخزينه مرة واحدة).

هذا النموذج الأعمق يحول Git من مجموعة من الأوامر المحفوظة إلى نظام قابل للفهم، مما يتيح التفكير الواثق حول العمليات المعقدة.

بما أن فهم النموذج الداخلي للكائن يشرح سبب تصرف Git بهذه الطريقة (فروع خفيفة الوزن، commits غير قابلة للتغيير، تغييرات hash عند إعادة الكتابة، السلامة) ويرفع المستوى من استخدام Git إلى فهمه حقاً، فإن فهم عمليات Git الداخلية هو معرفة قيمة على مستوى كبير — موضوع يعكس العمق المتوقع للأدوار الكبيرة ويوفر النموذج الذهني للتفكير في Git بثقة، مما يوضح سلوكه ويجعل العمليات المتقدمة مفهومة بدلاً من أن تكون غامضة.