progit · essa01442 · Mar 20, 2026 · Mar 20, 2026 · Mar 20, 2026 · Mar 20, 2026
diff --git a/book/01-introduction/sections/what-is-git.asc b/book/01-introduction/sections/what-is-git.asc
@@ -10,7 +10,7 @@
 
 الفرق الرئيسي بين Git وأي نظام VCS (نظام تحكم في الإصدارات) آخر (بما في ذلك Subversion وأصدقائه) هو الطريقة التي يفكر بها Git في بياناته.
 من الناحية المفاهيمية، تخزن معظم الأنظمة الأخرى المعلومات كقائمة من التغييرات القائمة على الملفات.
-تفكر هذه الأنظمة الأخرى (CVS و Subversion و Perforce وما إلى ذلك) في المعلومات التي تخزنها كمجموعة من الملفات والتغييرات التي يتم إجراؤها على كل ملف بمرور الوقت (يوصف هذا عادةً باسم التحكم في الإصدارات _delta-based_).
+تفكر هذه الأنظمة الأخرى (CVS و Subversion و Perforce وما إلى ذلك) في المعلومات التي تخزنها كمجموعة من الملفات والتغييرات التي يتم إجراؤها على كل ملف بمرور الوقت (يوصف هذا عادةً بنظام التحكم في الإصدارات _القائم على الفروق (delta-based)_).
 
 .Storing data as changes to a base version of each file (تخزين البيانات كتغييرات على إصدار أساسي لكل ملف)
 image::images/deltas.png[Storing data as changes to a base version of each file]

diff --git a/book/03-git-branching/sections/rebasing.asc b/book/03-git-branching/sections/rebasing.asc
diff --git a/book/04-git-server/sections/gitlab.asc b/book/04-git-server/sections/gitlab.asc
@@ -1,4 +1,4 @@
-=== GitLab
+=== GitLab (جيت لاب)
 
 (((serving repositories, GitLab)))(((GitLab)))
 GitWeb هو بسيط جداً على الرغم من ذلك.

diff --git a/book/04-git-server/sections/gitweb.asc b/book/04-git-server/sections/gitweb.asc
@@ -1,4 +1,4 @@
-=== GitWeb
+=== GitWeb (جيت ويب)
 
 (((serving repositories, GitWeb)))(((GitWeb)))
 الآن بعد أن أصبح لديك وصول أساسي للقراءة/الكتابة (read/write) والقراءة فقط (read-only) إلى مشروعك، قد ترغب في إعداد واجهة مرئية (visualizer) بسيطة قائمة على الويب (web-based).

diff --git a/book/05-distributed-git/sections/maintaining.asc b/book/05-distributed-git/sections/maintaining.asc
@@ -402,7 +402,7 @@ image::images/rebasing-2.png[History after cherry-picking a commit on a topic br
 
 الآن يمكنك إزالة (remove) فرع الموضوع (topic branch) وإسقاط (drop) التأكيدات (commits) التي لم تكن ترغب في سحبها.
 
-===== Rerere
+===== Rerere (إعادة استخدام الحل المسجل)
 
 (((git commands, rerere)))(((rerere)))
 إذا كنت تقوم بالكثير من عمليات الدمج وإعادة البناء (merging and rebasing)، أو كنت تحتفظ (maintaining) بفرع موضوع (topic branch) طويل العمر، فإن لدى Git ميزة تسمى "`rerere`" يمكن أن تساعد.

diff --git a/book/06-github/sections/5-scripting.asc b/book/06-github/sections/5-scripting.asc
@@ -291,7 +291,7 @@ image::images/scripting-07-status.png[Commit status via the API]
 يمكنك أيضاً أن ترى أن طلب السحب (Pull Request) يأخذ حالة (status) التأكيد الأخير (last commit) على الفرع (branch) ويحذرك (warns you) إذا كان فاشلاً (failure).
 يعد هذا مفيداً حقاً إذا كنت تستخدم API هذا لنتائج الاختبار (test results) بحيث لا تدمج (merge) شيئاً عن طريق الخطأ (accidentally) حيث يفشل التأكيد الأخير (last commit is failing) في الاختبارات (tests).
 
-==== Octokit
+==== Octokit (مكتبة Octokit)
 
 على الرغم من أننا كنا نفعل كل شيء تقريباً من خلال `curl` وطلبات HTTP (HTTP requests) البسيطة في هذه الأمثلة، إلا أن هناك العديد من المكتبات مفتوحة المصدر (open-source libraries) التي تجعل واجهة برمجة التطبيقات (API) هذه متاحة بطريقة أكثر اصطلاحية (idiomatic).
 في وقت كتابة هذا التقرير، تتضمن اللغات المدعومة (supported languages) Go و Objective-C و Ruby و .NET.

diff --git a/book/07-git-tools/sections/rerere.asc b/book/07-git-tools/sections/rerere.asc
@@ -1,5 +1,5 @@
 [[ref_rerere]]
-=== Rerere
+=== Rerere (إعادة استخدام الحل المسجل)
 
 تعتبر وظيفة (functionality) `git rerere` ميزة مخفية (hidden feature) نوعاً ما.
 الاسم يرمز إلى "`reuse recorded resolution`" ("`إعادة استخدام الدقة المسجلة`")، وكما يوحي الاسم، فإنه يسمح لك بأن تطلب من Git أن يتذكر (remember) كيف قمت بحل (resolved) تعارض جزء (hunk conflict) بحيث في المرة القادمة التي يرى فيها نفس التعارض (same conflict)، يمكن لـ Git حله لك تلقائياً (automatically).

diff --git a/book/07-git-tools/sections/searching.asc b/book/07-git-tools/sections/searching.asc
@@ -6,7 +6,7 @@
 سنستعرض القليل منها.
 
 [[_git_grep]]
-==== Git Grep
+==== Git Grep (البحث باستخدام Git Grep)
 
 يأتي Git مزوداً بأمر (command) يسمى `grep` يسمح لك بالبحث (search) بسهولة في أي شجرة مؤكدة (committed tree)، أو دليل العمل (working directory)، أو حتى الفهرس (index) عن سلسلة (string) أو تعبير نمطي (regular expression).
 بالنسبة للأمثلة (examples) التي تلي، سنبحث في الكود المصدري (source code) لـ Git نفسه.

diff --git a/book/08-customizing-git/sections/attributes.asc b/book/08-customizing-git/sections/attributes.asc
@@ -33,12 +33,12 @@
 
 ===== Diffing Binary Files (مقارنة الملفات الثنائية)
 
-You can also use the Git attributes functionality to effectively diff binary files.
-You do this by telling Git how to convert your binary data to a text format that can be compared via the normal diff.
+يمكنك أيضاً استخدام وظيفة سمات Git (Git attributes functionality) لمقارنة الملفات الثنائية (diff binary files) بفعالية.
+تفعل ذلك بإخبار Git كيفية تحويل (convert) البيانات الثنائية الخاصة بك إلى تنسيق نصي (text format) يمكن مقارنته عبر الـdiff العادي (normal diff).
 
 أولاً، ستستخدم هذه التقنية (technique) لحل واحدة من أكثر المشاكل المزعجة (annoying problems) المعروفة للبشرية: التحكم في إصدارات (version-controlling) مستندات Microsoft Word.
-If you want to version-control Word documents, you can stick them in a Git repository and commit every once in a while; but what good does that do?
-If you run `git diff` normally, you only see something like this:
+إذا كنت تريد التحكم في إصدارات مستندات Word، يمكنك وضعها في مستودع Git والتأكيد (commit) بين الحين والآخر؛ ولكن ما الفائدة من ذلك؟
+إذا قمت بتشغيل `git diff` بشكل عادي، فسترى فقط شيئاً مثل هذا:
 
 [source,console]
 ----
@@ -57,15 +57,15 @@ Binary files a/chapter1.docx and b/chapter1.docx differ
 *.docx diff=word
 ----
 
-This tells Git that any file that matches this pattern (`.docx`) should use the "`word`" filter when you try to view a diff that contains changes.
-What is the "`word`" filter?
+يخبر هذا Git أن أي ملف يطابق هذا النمط (`.docx`) يجب أن يستخدم مرشح "`word`" ("`word`" filter) عندما تحاول عرض فرق (diff) يحتوي على تغييرات.
+ما هو مرشح "`word`"؟
 عليك إعداده (set it up).
 هنا ستقوم بتكوين Git لاستخدام برنامج `docx2txt` لتحويل مستندات Word إلى ملفات نصية قابلة للقراءة (readable text files)، والتي سيقوم بعد ذلك بعمل فرق لها بشكل صحيح.
 
-First, you'll need to install `docx2txt`; you can download it from https://sourceforge.net/projects/docx2txt[^].
+أولاً، ستحتاج إلى تثبيت `docx2txt`؛ يمكنك تنزيله من https://sourceforge.net/projects/docx2txt[^].
 اتبع التعليمات (instructions) الموجودة في ملف `INSTALL` لوضعه في مكان يمكن للصدفة (shell) العثور عليه.
 بعد ذلك، ستكتب نصاً برمجياً تغليفياً (wrapper script) لتحويل المخرجات إلى التنسيق الذي يتوقعه Git.
-Create a file that's somewhere in your path called `docx2txt`, and add these contents:
+أنشئ ملفاً في مكان ما في مسارك (path) يسمى `docx2txt`، وأضف هذه المحتويات:
 
 [source,console]
 ----
@@ -81,11 +81,11 @@ docx2txt.pl "$1" -
 $ git config diff.word.textconv docx2txt
 ----
 
-Now Git knows that if it tries to do a diff between two snapshots, and any of the files end in `.docx`, it should run those files through the "`word`" filter, which is defined as the `docx2txt` program.
+الآن يعرف Git أنه إذا حاول إجراء فرق (diff) بين لقطتين (snapshots)، وانتهى أي من الملفات بـ `.docx`، فيجب تمرير تلك الملفات عبر مرشح "`word`"، والذي يُعرَّف على أنه برنامج `docx2txt`.
 وهذا بشكل فعال يصنع إصدارات نصية جيدة (nice text-based versions) من ملفات Word الخاصة بك قبل محاولة عمل فرق لها.
 
 إليك مثال: تم تحويل الفصل الأول (Chapter 1) من هذا الكتاب إلى تنسيق Word وتم تأكيده في مستودع Git.
-Then a new paragraph was added.
+ثم تمت إضافة فقرة جديدة (new paragraph).
 إليك ما يعرضه `git diff`:
 
 [source,console]
@@ -105,11 +105,11 @@ index 0b013ca..ba25db5 100644
  Many people's version-control method of choice is to copy files into another directory (perhaps a time-stamped directory, if they're clever). This approach is very common because it is so simple, but it is also incredibly error prone. It is easy to forget which directory you're in and accidentally write to the wrong file or copy over files you don't mean to.
 ----
 
-Git successfully and succinctly tells us that we added the string "`Testing: 1, 2, 3.`", which is correct.
+يخبرنا Git بنجاح وبإيجاز أننا أضفنا السلسلة "`Testing: 1, 2, 3.`"، وهو أمر صحيح.
 إنه ليس مثالياً (not perfect) – لن تظهر تغييرات التنسيق (formatting changes) هنا – ولكنه يعمل بالتأكيد.
 
-Another interesting problem you can solve this way involves diffing image files.
-One way to do this is to run image files through a filter that extracts their EXIF information – metadata that is recorded with most image formats.
+مشكلة مثيرة أخرى يمكنك حلها بهذه الطريقة تتعلق بمقارنة ملفات الصور (diffing image files).
+إحدى طرق القيام بذلك هي تمرير ملفات الصور عبر مرشح يستخرج معلومات EXIF الخاصة بها – وهي بيانات وصفية (metadata) يتم تسجيلها مع معظم تنسيقات الصور.
 إذا قمت بتنزيل وتثبيت برنامج `exiftool`، فيمكنك استخدامه لتحويل صورك إلى نص (text) حول البيانات الوصفية، لذلك على الأقل سيعرض لك الفرق تمثيلاً نصياً (textual representation) لأي تغييرات حدثت.
 ضع السطر التالي في ملف `.gitattributes` الخاص بك: