كيفية تثبيت Git وإعداده على Windows وmacOS وLinux

تثبيت Git أمر سهل، لكن تثبيته بطريقة تضمن تسجيل هوية صحيحة للالتزامات، والتعامل المتوقع مع نهايات الأسطر، واستخدام محرر مناسب، ومصادقة آمنة، يحتاج إلى بعض العناية.

يشرح هذا الدليل كيفية تثبيت Git على Windows وmacOS وLinux، ثم إعداد بيئة نظيفة للاستخدام للمرة الأولى. ولن يكتفي بعرض الأوامر المطلوبة، بل سيوضح وظيفة كل إعداد، والمكان الذي يحفظه Git فيه، وكيفية تشخيص المشكلات الشائعة.

عند الانتهاء، ستكون لديك بيئة Git جاهزة للعمل من سطر الأوامر، مع إعدادات مناسبة لإنشاء أول مستودع فعلي.

ما الذي سنقوم بإعداده؟

لا يقتصر الإعداد الصحيح للمبتدئ على التأكد من وجود الأمر git. بل يشمل المهام الأساسية التالية:

  • تثبيت Git بالطريقة المناسبة لنظام التشغيل لديك.

  • التحقق من ملف Git التنفيذي والإصدار الذي تستخدمه نافذة الأوامر.

  • ضبط الاسم والبريد الإلكتروني اللذين سيُسجَّلان في الالتزامات المستقبلية.

  • اختيار اسم الفرع الافتراضي للمستودعات الجديدة.

  • تحديد المحرر الذي يفتحه Git لكتابة رسائل الالتزام والعمليات الأخرى.

  • فهم مستويات الإعدادات وأولوية كل مستوى.

  • اختيار سياسة واضحة للتعامل مع نهايات الأسطر.

  • استخدام مساعد آمن لبيانات الاعتماد عند المصادقة عبر HTTPS.

  • مراجعة الإعدادات النهائية والملفات التي جاءت منها.

  • إنشاء مستودع تجريبي للتأكد من أن البيئة تعمل بصورة صحيحة.

قبل تثبيت Git

قبل تنزيل أي شيء، تحقّق أولًا مما إذا كان Git مثبتًا بالفعل:

git --version

ستظهر نتيجة ناجحة بشكل قريب من الآتي:

git version 2.x.x

يعتمد رقم الإصدار الدقيق على نظام التشغيل، ومصدر الحزمة، وتاريخ آخر تحديث.

إذا ظهرت رسالة تفيد بأن الأمر git غير معروف أو لا يمكن العثور عليه، فهذا يعني أن Git غير مثبت، أو أن مجلد الملف التنفيذي غير مضاف إلى متغير النظام PATH.

إذا كان Git مثبتًا، فمن المفيد أيضًا معرفة الملف التنفيذي المستخدم فعليًا.

في Windows PowerShell:

Get-Command git

في Command Prompt:

where git

في macOS أو Linux:

which git

يفيد هذا الفحص عند وجود أكثر من نسخة من Git على الجهاز. فقد توجد مثلًا نسخة مثبتة بواسطة نظام التشغيل وأخرى مثبتة من خلال مدير حزم.

اختر طريقة التثبيت بوعي

توجد ثلاث طرق شائعة لتثبيت Git:

  1. مثبّت رسمي أو تتم صيانته باستمرار: وهو الخيار الشائع على Windows.

  2. مدير الحزم الخاص بنظام التشغيل: وهو شائع على Linux ومفيد أيضًا على macOS.

  3. البناء من الشيفرة المصدرية: ويناسب المستخدمين المتقدمين الذين يحتاجون إلى إصدار محدد أو خيارات ترجمة خاصة.

بالنسبة إلى معظم المطورين، يكون المثبّت المعتمد أو مدير الحزم المعتاد هو الخيار الأفضل. أما البناء من المصدر فيضيف مسؤوليات صيانة لا يحتاج إليها غالبًا من يجهز Git للمرة الأولى.

تثبيت Git على Windows

التوزيعة القياسية على Windows هي Git for Windows. وهي تتضمن أدوات Git لسطر الأوامر، بالإضافة إلى Git Bash، وهو طرفية توفّر بيئة أوامر شبيهة بأنظمة Unix داخل Windows.

يمكن تثبيت Git for Windows باستخدام المثبّت الرسومي أو من خلال Windows Package Manager.

الطريقة الأولى: التثبيت باستخدام Git for Windows Installer

  1. افتح صفحة تثبيت Git الرسمية لنظام Windows.

  2. اختر المثبّت المتوافق مع معمارية المعالج، وغالبًا ما تكون x64 أو ARM64.

  3. شغّل ملف التثبيت الذي تم تنزيله.

  4. راجع شاشات التثبيت واختر الإعدادات عن قصد بدل قبولها دون فهم.

  5. أكمل التثبيت، ثم أغلق أي نوافذ أوامر كانت مفتوحة وأعد فتحها.

قد تتغير واجهة المثبّت بمرور الوقت، لذلك يمكن أن تختلف بعض التسميات قليلًا. ومع ذلك، تظل الخيارات التالية هي الأهم.

اختيار المكونات

المكونات الافتراضية مناسبة لمعظم المبتدئين. ويُعد Git Bash مفيدًا خصوصًا لأن كثيرًا من شروحات Git تستخدم صياغة أوامر تعمل فيه بصورة طبيعية.

قد تكون خيارات قائمة الزر الأيمن مثل “Git Bash Here” مريحة، لكنها ليست ضرورية لعمل Git نفسه.

اختيار المحرر الافتراضي

يفتح Git محرر نصوص أحيانًا عندما يحتاج إلى رسالة التزام، أو رسالة دمج، أو خطة إعادة تأسيس rebase، أو وصف لعلامة tag.

اختر محررًا تعرف كيف تحفظ الملف وتغلقه داخله. ويُعد Visual Studio Code خيارًا عمليًا إذا كان مثبتًا لديك. أما Vim فهو محرر قوي، لكن اختياره دون معرفة أوامره الأساسية قد يجعل المبتدئ يشعر بأنه عالق داخله.

يمكن تغيير هذا الإعداد لاحقًا، لذلك لا يُعد اختيار المثبّت نهائيًا.

إضافة Git إلى PATH

يعرض المثبّت عادة خيارات تحدد البيئات التي يمكن تشغيل الأمر git منها.

في جهاز تطوير اعتيادي، اختر إعدادًا يسمح باستخدام Git من Git Bash ومن بيئات سطر الأوامر الأخرى، مثل PowerShell وCommand Prompt وطرفيات بيئات التطوير وأدوات الأتمتة.

قد يؤدي اختيار PATH مقيّد إلى عمل Git داخل Git Bash فقط، وفشله داخل PowerShell أو بيئة التطوير.

اختيار تطبيق SSH

يمكن لـ Git for Windows استخدام عميل OpenSSH المرفق معه، أو استخدام تثبيت SSH آخر موجود مسبقًا على الجهاز.

يُعد OpenSSH المرفق الخيار الأبسط غالبًا عند الإعداد لأول مرة، لأنه يوفّر بيئة متوقعة. استخدم عميل SSH خارجيًا فقط عندما تكون لديك إعدادات SSH مدروسة على مستوى النظام.

اختيار طبقة HTTPS

قد يعرض المثبّت خيارات لطريقة نقل HTTPS. يكون الخيار الافتراضي مناسبًا في معظم الحالات. وقد تحتاج بيئات الشركات التي تستخدم شهادات مخصصة أو مخازن ثقة مُدارة في Windows إلى اختيار محدد تفرضه سياسة قسم تقنية المعلومات.

لا تعطل التحقق من الشهادات لتجاوز أخطاء HTTPS، بل أصلح إعداد الشهادات الموثوقة.

اختيار طريقة التعامل مع نهايات الأسطر

يستخدم Windows عادة نهايات الأسطر CRLF، بينما يستخدم Linux وmacOS غالبًا LF. لذلك قد يعرض Git for Windows سياسة تحويل افتراضية أثناء التثبيت.

يمكن للمطور الجديد قبول الإعداد الافتراضي كبداية. لكن نهايات الأسطر تخص المشروع والفريق أيضًا، لذلك يُفضّل أن يحددها الفريق لاحقًا من خلال ملف .gitattributes محفوظ داخل المستودع، بدل الاعتماد على خيارات التثبيت الفردية فقط.

سنشرح ذلك بالتفصيل في قسم لاحق من هذا الدليل.

خيارات الطرفية ووحدة التحكم

يستخدم Git Bash عادة بيئة طرفية خاصة به، لكن يمكن تشغيل أوامر Git أيضًا داخل Windows Terminal وPowerShell وCommand Prompt وطرفيات بيئات التطوير.

لست ملزمًا باستخدام طرفية واحدة فقط. المهم هو أن تعثر كل بيئة على نسخة Git التنفيذية المقصودة نفسها.

مدير بيانات الاعتماد

عندما يعرض المثبّت خيار Git Credential Manager، فهو مفيد غالبًا للمطورين الذين يتصلون بالمستودعات البعيدة عبر HTTPS. إذ يمكنه التكامل مع مخزن آمن في نظام التشغيل ومع آليات تسجيل الدخول الحديثة، بدل مطالبتك بإدخال الرموز أو حفظها يدويًا في كل مرة.

الطريقة الثانية: تثبيت Git باستخدام winget

افتح PowerShell أو Command Prompt ثم نفّذ:

winget install --id Git.Git -e --source winget

بعد اكتمال التثبيت، أغلق الطرفية وافتحها مجددًا، ثم تحقّق من التثبيت:

git --version
where git

أي طرفية ينبغي استخدامها على Windows؟

يعمل Git داخل عدة بيئات أوامر على Windows:

  • Git Bash: مناسب لأوامر Unix ولعدد كبير من الشروحات المتاحة على الإنترنت.

  • PowerShell: يتكامل جيدًا مع إدارة Windows وأدوات التطوير الحديثة.

  • Command Prompt: مدعوم، لكنه أقل مرونة من PowerShell في كتابة السكربتات.

  • Windows Terminal: تطبيق طرفية يمكنه استضافة PowerShell وCommand Prompt وGit Bash وملفات WSL.

  • طرفية بيئة التطوير: مفيدة عند العمل مباشرة داخل Visual Studio Code أو PhpStorm أو IntelliJ IDEA أو أدوات مشابهة.

لا يتطلب تعلم Git أن تتعلم Bash أولًا. استخدم الطرفية التي تفهمها، لكن انتبه إلى اختلاف أوامر إنشاء الملفات ومتغيرات البيئة وصياغة المسارات بين البيئات.

تثبيت Git على macOS

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

الطريقة الأولى: أدوات سطر أوامر Xcode

نفّذ:

xcode-select --install

اتبع التعليمات التي يعرضها macOS، ثم تحقّق:

git --version
which git

لا تتضمن Xcode Command Line Tools برنامج Git فقط، بل توفر أيضًا المترجمات والأدوات التي تحتاج إليها كثير من بيئات التطوير.

الطريقة الثانية: Homebrew

إذا كان Homebrew مثبتًا لديك، فنفّذ:

brew install git

ثم تحقّق من مسار الملف التنفيذي:

git --version
which git

إذا استمر macOS في استخدام نسخة أخرى من Git، فراجع متغير PATH الخاص بالصدفة. قد تختلف مسارات مدير الحزم بين أجهزة Apple Silicon وأجهزة Intel.

لتحديث نسخة Git التي يديرها Homebrew لاحقًا:

brew update
brew upgrade git

الطريقة الثالثة: MacPorts

إذا كانت بيئتك تستخدم MacPorts بالفعل:

sudo port install git

لا تثبت عدة مديري حزم من أجل Git فقط. استخدم نظام الحزم المعتمد أصلًا على جهازك.

لماذا قد يعرض macOS أكثر من نسخة من Git؟

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

اعرض جميع النسخ والمسار النشط:

which -a git
git --version

إذا كانت بيئة التطوير تعرض إصدارًا مختلفًا عن الطرفية، فتحقق من مسار Git التنفيذي المحدد في إعداداتها.

تثبيت Git على Linux

على Linux، استخدم مدير الحزم الذي توفره توزيعتك. يضمن ذلك تكاملًا متوقعًا مع تحديثات النظام والتبعيات.

Debian وUbuntu

sudo apt update
sudo apt install git

Fedora

sudo dnf install git

Arch Linux

sudo pacman -S git

openSUSE

sudo zypper install git

Alpine Linux

sudo apk add git

Gentoo

sudo emerge --ask --verbose dev-vcs/git

FreeBSD

sudo pkg install git

بعد التثبيت، تحقّق:

git --version
which git

حزمة التوزيعة أم أحدث إصدار رسمي؟

قد توفر التوزيعة إصدارًا من Git أقدم من أحدث إصدار رسمي متاح. لا يعني ذلك أنه غير صالح للاستخدام؛ فالتوزيعات المستقرة تعطي الأولوية غالبًا للحزم المختبرة والصيانة طويلة الأمد.

قبل استبدال حزمة التوزيعة، اسأل نفسك إن كنت تحتاج فعلًا إلى ميزة ظهرت في إصدار أحدث. فإضافة مستودعات خارجية أو البناء من المصدر يضيف مسؤولية صيانة أخرى.

Git على Windows مقارنةً بـ Git داخل WSL

يوفر Windows Subsystem for Linux بيئة Linux تعمل إلى جانب Windows. وتُعد نسخة Git المثبتة على Windows ونسخة Git المثبتة داخل إحدى توزيعات WSL تثبيتين مستقلين، ولكل منهما ملفات إعداد خاصة.

داخل WSL، ثبّت Git باستخدام مدير حزم التوزيعة:

sudo apt update
sudo apt install git

بعد ذلك، اضبط Git داخل WSL حتى لو كنت قد أعددت Git for Windows مسبقًا.

تذكّر الفروق التالية:

  • يستخدم Git على Windows مسارات Windows وإعداداته الموجودة في جانب Windows.

  • يستخدم Git داخل WSL مسارات Linux وإعداداته الموجودة في جانب Linux.

  • قد تستخدم بيئة التطوير إحدى النسختين بحسب فتح المشروع محليًا أو من خلال تكامل WSL.

للحصول على أداء أفضل وتقليل مشكلات الصلاحيات، يُفضّل عادة حفظ المشاريع التي تعتمد أساسًا على أدوات Linux داخل نظام ملفات WSL، بينما تبقى المشاريع التي تستخدم أدوات Windows الأصلية داخل نظام ملفات Windows.

التحقق من التثبيت

بعد تثبيت Git، أعد تشغيل الطرفية ثم نفّذ:

git --version

بعد ذلك، اعرض موقع الملف التنفيذي:

# Windows Command Prompt
where git

# Windows PowerShell
Get-Command git

# macOS or Linux
which git

تحقّق أيضًا من قدرة Git على فتح المساعدة المدمجة:

git help config

أو استخدم الأمر المختصر:

git config -h

إذا عملت هذه الأوامر، فهذا يعني أن التثبيت متاح للطرفية الحالية.

فهم إعدادات Git

يتحكم عدد من متغيرات الإعداد في سلوك Git، ويمكن تخزين هذه المتغيرات ضمن مستويات مختلفة.

المستوىالاستخدام المعتادالموقع الشائع
Systemإعدادات افتراضية لجميع مستخدمي الجهازملف إعداد تابع لتثبيت Git
Globalإعدادات افتراضية للمستخدم الحالي~/.gitconfig أو مجلد إعدادات المستخدم
Localإعدادات خاصة بمستودع واحد.git/config
Worktreeإعدادات خاصة بشجرة عمل مرتبطة عند تفعيلها.git/config.worktree

تتغلب المستويات الأكثر تخصيصًا على المستويات الأعم. فمثلًا، يمكن لبريد إلكتروني مضبوط داخل مستودع أن يتغلب على البريد العام، بينما يظل البريد العام مستخدمًا في بقية المستودعات.

يفيد ذلك عند استخدام جهاز واحد للمشاريع الشخصية ومشاريع الشركة.

الصياغة الحديثة والتقليدية لأمر git config

توفّر وثائق Git الحديثة أوامر فرعية صريحة:

git config set --global user.name "Jane Developer"
git config get --global user.name
git config list --global

لكن كثيرًا من الشروحات والسكربتات القديمة تستخدم الصياغة التقليدية:

git config --global user.name "Jane Developer"
git config --global --get user.name
git config --global --list

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

إعداد هوية الالتزامات

حدد الاسم والبريد الإلكتروني اللذين سيكتبهما Git داخل الالتزامات الجديدة:

git config --global user.name "Jane Developer"
git config --global user.email "jane@example.com"

تحقّق من القيم:

git config --global --get user.name
git config --global --get user.email

أو باستخدام الأوامر الفرعية الحديثة:

git config get --global user.name
git config get --global user.email

اسم Git ليس اسم المستخدم في منصة الاستضافة

تمثل قيمة user.name عادة اسم المؤلف المقروء للبشر، والذي يُسجل داخل الالتزام. وليس مطلوبًا أن يطابق اسم المستخدم في GitHub أو GitLab أو Bitbucket.

أما user.email فهو أيضًا جزء من بيانات الالتزام. وتُدار بيانات تسجيل الدخول بصورة منفصلة من خلال مساعد بيانات اعتماد HTTPS أو مفاتيح SSH.

لماذا يهم عنوان البريد الإلكتروني؟

قد تربط منصات الاستضافة الالتزام بحسابك عندما يطابق البريد المسجل فيه عنوانًا موثقًا، أو عنوان خصوصية توفره المنصة.

اختر البريد بوعي. يمكنك استخدام بريد شخصي للمستودعات الشخصية، بينما قد تتطلب مستودعات الشركة بريد العمل.

استخدام هوية مختلفة في مستودع واحد

نفّذ الأوامر داخل المستودع دون إضافة --global:

git config user.name "Jane Developer"
git config user.email "jane@company.example"

تحقّق من مصدر القيمة النهائية:

git config --show-origin --get user.email

منع Git من تخمين الهوية

يمكن للمطورين الذين ينتقلون باستمرار بين عدة هويات إجبار Git على طلب إعداد صريح:

git config --global user.useConfigOnly true

عند تفعيل هذا الخيار، يتجنب Git تخمين الاسم أو البريد بصمت إذا لم تكن الهوية المطلوبة مضبوطة. ويساعد ذلك على منع استخدام البريد الشخصي داخل التزامات العمل أو العكس.

تحديد اسم الفرع الأولي الافتراضي

اختر الاسم الذي سيستخدمه Git عند إنشاء مستودعات جديدة:

git config --global init.defaultBranch main

يؤثر هذا الإعداد في المستودعات التي ستُنشأ لاحقًا باستخدام git init، لكنه لا يعيد تسمية الفروع في المستودعات الموجودة.

تحقّق من القيمة:

git config --global --get init.defaultBranch

إذا كانت مؤسستك تستخدم اسمًا آخر مثل trunk، فاضبطه بدلًا من main.

إعداد محرر Git الافتراضي

يفتح Git محررًا عندما يحتاج إلى إدخال نص تفاعلي. ويجب أن ينتظر أمر المحرر حتى تنتهي من الكتابة؛ وإلا فقد يتابع Git العملية قبل حفظ الملف.

Visual Studio Code

git config --global core.editor "code --wait"

يجعل الخيار --wait عملية Git تنتظر حتى إغلاق تبويب المحرر.

Vim

git config --global core.editor "vim"

Nano

git config --global core.editor "nano"

Windows Notepad

git config --global core.editor "notepad"

اختبار إعداد المحرر

git config --global --edit

يُفترض أن يفتح المحرر المحدد ملف إعداد Git العام. إذا كنت تختبر فقط، فأغلقه دون إجراء تعديلات.

إذا بدا Git متوقفًا أثناء التزام أو دمج، فتحقق من وجود نافذة محرر أو محرر طرفية ينتظر إدخالًا منك.

إعداد نهايات الأسطر بعناية

تستخدم الملفات النصية عادة أحد نمطين لنهاية السطر:

  • LF: وهو النمط القياسي على Linux وmacOS.

  • CRLF: وهو شائع في الملفات النصية الأصلية على Windows.

قد تؤدي التحويلات غير المنضبطة إلى ظهور كل سطر في الملف على أنه تغيّر، وإلى مراجعات مليئة بضجيج غير ضروري، أو إلى تعطل سكربتات تشترط استخدام LF.

فهم core.autocrlf

القيم الشائعة هي:

  • true: يحوّل النص داخل المستودع إلى LF، ويستخدم عادة CRLF داخل شجرة العمل.

  • input: يحوّل CRLF إلى LF عند إضافة المحتوى، لكنه لا يحوّل LF إلى CRLF عند سحب الملفات إلى شجرة العمل.

  • false: يعطل التحويل التلقائي الذي يتحكم به هذا الإعداد.

إعداد شائع على Windows:

git config --global core.autocrlf true

وإعداد شائع على macOS أو Linux:

git config --global core.autocrlf input

هذه ليست قواعد إلزامية لجميع المشاريع. سياسة المستودع التي يعتمدها الفريق لها الأولوية.

استخدم .gitattributes في مشاريع الفرق

يوفّر ملف .gitattributes المحفوظ داخل المستودع سياسة مشتركة لجميع المساهمين.

مثال:

* text=auto

*.sh text eol=lf
*.bat text eol=crlf
*.cmd text eol=crlf

*.png binary
*.jpg binary
*.pdf binary

تُعد هذه الطريقة أكثر موثوقية من افتراض أن جميع المساهمين يستخدمون الإعدادات العامة نفسها.

تفعيل تحذيرات أمان نهايات الأسطر

يمكنك جعل Git يحذّرك من التحويلات التي قد لا يمكن عكسها بأمان:

git config --global core.safecrlf warn

استخدم true بدل warn فقط عندما تريد من Git رفض التحويلات التي لا تجتاز فحص الأمان.

لا تطبّق التطبيع على مستودع موجود دون تخطيط

قد تؤدي إضافة سياسة لنهايات الأسطر إلى مشروع قديم إلى إنشاء التزام ضخم يغيّر عددًا كبيرًا من الملفات. خطط لهذه العملية بصورة مستقلة، وابدأ من شجرة عمل نظيفة، وراجع النتيجة بعناية، ولا تخلط تغييرات التطبيع مع تغييرات وظيفية في الشيفرة.

إعداد ألوان المخرجات

تستخدم إصدارات Git الحديثة ألوان الطرفية تلقائيًا بصورة افتراضية. ويمكنك تثبيت هذا السلوك صراحة:

git config --global color.ui auto

تضيف القيمة auto الألوان عندما تُعرض النتائج داخل طرفية تفاعلية، لكنها لا تفرض رموز التحكم اللونية عند إعادة توجيه المخرجات إلى ملف أو أمر آخر.

إعداد ملف تجاهل عام

يجب أن يحتوي ملف .gitignore داخل المستودع على الأنماط الخاصة بالمشروع والتي يحتاج إليها جميع المساهمين.

أما ملف التجاهل العام فيناسب الملفات التي ينشئها نظام التشغيل أو المحرر الخاص بك فقط.

أنشئ الملف:

# macOS or Linux
touch ~/.gitignore_global

# Git Bash on Windows
touch ~/.gitignore_global

ثم اضبط Git لاستخدامه:

git config --global core.excludesFile ~/.gitignore_global

أمثلة لأنماط شخصية:

.DS_Store
Thumbs.db
.idea/workspace.xml
*.swp

لا تضع قواعد المشروع الضرورية داخل ملفك العام الشخصي فقط، لأن المطورين الآخرين وبيئات CI لن يحصلوا عليها.

إعداد بيانات اعتماد HTTPS بصورة آمنة

يمكن لـ Git استدعاء مساعد بيانات اعتماد عندما يحتاج مستودع HTTPS بعيد إلى المصادقة. وقد يخزن المساعد البيانات مؤقتًا، أو يحفظها داخل مخزن آمن في نظام التشغيل، أو يدير آليات تسجيل دخول حديثة عبر المتصفح.

اعرض المساعدات المضبوطة:

git config --show-origin --get-all credential.helper

على Git for Windows، يُثبّت Git Credential Manager عادة ويُضبط تلقائيًا إذا اخترته داخل المثبّت.

يتوفر Git Credential Manager كذلك على macOS وLinux، ويمكنه عند تثبيته التكامل مع منصات الاستضافة المدعومة ومخازن بيانات الاعتماد الآمنة.

تجنب تخزين بيانات الاعتماد كنص واضح

يكتب مساعد store المدمج بيانات الاعتماد في ملف غير مشفر. لا تستخدمه بسهولة على جهاز شخصي أو مشترك:

# Avoid unless you fully understand the security tradeoff
git config --global credential.helper store

استخدم بدلًا منه مخزن مفاتيح نظام التشغيل، أو Git Credential Manager، أو المصادقة عبر SSH.

بيانات الاعتماد ليست user.name وuser.email

يتحكم الإعدادان التاليان:

user.name
user.email

في هوية مؤلف الالتزام، لكنهما لا يسجلان دخولك إلى منصة الاستضافة البعيدة.

تتم المصادقة من خلال أحد الخيارات التالية:

  • مساعد بيانات اعتماد HTTPS.

  • رمز وصول شخصي يديره عميل معتمد.

  • مفتاح SSH ووكيل SSH.

  • نظام مصادقة خاص بالمؤسسة.

هل ينبغي إعداد SSH الآن؟

يفيد SSH في المصادقة مع المستودعات البعيدة، لكنه منفصل عن عملية تثبيت Git نفسها.

يتضمن إعداد SSH كاملًا:

  • إنشاء زوج من المفاتيح.

  • حماية المفتاح الخاص.

  • تحميله داخل وكيل SSH.

  • إضافة المفتاح العام إلى منصة الاستضافة.

  • اختبار الاتصال.

  • إدارة عدة حسابات عند الحاجة.

تستحق هذه العملية مقالًا مستقلًا. يكفي في هذا الدليل معرفة أن Git يستطيع استخدام روابط مستودعات بعيدة عبر HTTPS أو SSH.

إعدادات اختيارية لتحسين سهولة الاستخدام

الإعدادات التالية مفيدة، لكنها ليست ضرورية لإنشاء أول التزام.

إعداد الفرع البعيد تلقائيًا عند أول Push

git config --global push.autoSetupRemote true

يمكن أن يبسط هذا الإعداد أول عملية رفع لفرع جديد ضمن مسارات العمل المركزية الشائعة. أما الفرق التي تستخدم ترتيبات خاصة للمستودعات البعيدة فقد تفضّل الأوامر الصريحة.

إنشاء اختصارات بسيطة

git config --global alias.st status
git config --global alias.br branch
git config --global alias.co checkout
git config --global alias.last "log -1 HEAD"

ثم يمكنك استخدام:

git st
git br
git last

لا تنشئ عددًا كبيرًا من الاختصارات إلى درجة تجعلك غير معتاد على أوامر Git الأصلية. فالوثائق ورسائل الخطأ وزملاء الفريق يستخدمون عادة الأسماء القياسية.

لا تختَر استراتيجية Pull عامة دون فهمها

يمكن لـ Git دمج التغييرات التي جلبها باستخدام merge أو rebase أو السماح بالتقدم السريع فقط. تؤثر هذه الاختيارات في شكل سجل المشروع.

من أمثلتها:

git config --global pull.rebase false
git config --global pull.rebase true
git config --global pull.ff only

لا تنسخ أحد هذه الإعدادات لمجرد إخفاء رسالة تحذير. تعرّف أولًا إلى أسلوب عمل الفريق، ثم اختر السلوك المناسب بوعي.

مراجعة الإعدادات النهائية

اعرض جميع الإعدادات الفعالة والملفات التي جاءت منها:

git config --list --show-origin

وباستخدام الصياغة الحديثة:

git config list --show-origin

لفحص قيمة واحدة:

git config --show-origin --get user.email

لعرض الإعدادات العامة فقط:

git config --global --list

لفتح ملف الإعداد العام:

git config --global --edit

تشبه صيغة ملفات إعداد Git المثال التالي:

[user]
    name = Jane Developer
    email = jane@example.com

[init]
    defaultBranch = main

[core]
    editor = code --wait
    autocrlf = input

[color]
    ui = auto

يكون استخدام أوامر git config أكثر أمانًا عادة من تحرير الملف يدويًا، لأن الأمر يتحقق من أسماء المفاتيح ويكتب القيم بالصياغة الصحيحة.

إعداد مقترح للمبتدئين

استبدل بيانات الهوية التجريبية قبل تنفيذ الأوامر التالية:

git config --global user.name "Jane Developer"
git config --global user.email "jane@example.com"
git config --global init.defaultBranch main
git config --global core.editor "code --wait"
git config --global color.ui auto
git config --global core.safecrlf warn

بعد ذلك، اختر إعداد نهايات الأسطر المناسب لبيئتك وسياسة المشروع.

بداية شائعة على Windows:

git config --global core.autocrlf true

وبداية شائعة على macOS أو Linux:

git config --global core.autocrlf input

وأخيرًا، راجع النتيجة:

git config --list --show-origin

إنشاء مستودع تجريبي

لا يمكن اعتبار الإعداد مختبرًا فعليًا قبل نجاح Git في إنشاء التزام.

macOS أو Linux أو Git Bash

mkdir git-setup-test
cd git-setup-test

git init

echo "# Git Setup Test" > README.md

git add README.md
git commit -m "Create setup test repository"

git log --oneline --show-signature
git status

PowerShell

New-Item -ItemType Directory git-setup-test
Set-Location git-setup-test

git init

"# Git Setup Test" | Set-Content README.md

git add README.md
git commit -m "Create setup test repository"

git log --oneline
git status

النتائج المتوقعة هي:

  • يُنشأ المستودع باستخدام اسم الفرع الافتراضي الذي اخترته.

  • يكتمل الالتزام دون طلب معلومات هوية مفقودة.

  • يعرض السجل اسم المؤلف المقصود والالتزام الجديد.

  • يعرض git status أن شجرة العمل نظيفة.

لفحص تفاصيل المؤلف بدقة:

git log -1 --format=fuller

تغيير قيمة إعداد أو حذفها

لتعيين قيمة جديدة، نفّذ أمر الإعداد مرة أخرى:

git config --global user.email "new@example.com"

لحذف قيمة عامة:

git config --global --unset user.email

وباستخدام الصياغة الحديثة:

git config unset --global user.email

عندما يحتوي المفتاح على عدة قيم، اعرضها جميعًا أولًا:

git config --global --get-all credential.helper

بعد ذلك، استخدم أمر الحذف المناسب بعناية. فقد تحتوي إعدادات مساعد بيانات الاعتماد على عدة قيم مقصودة.

تحديث Git

ينبغي أن تتطابق طريقة التحديث مع طريقة التثبيت المستخدمة.

Windows

استخدم أداة تحديث Git for Windows، أو ثبّت أحدث إصدار معتمد فوق التثبيت الحالي، أو حدّثه باستخدام winget:

winget upgrade --id Git.Git -e

Homebrew على macOS

brew update
brew upgrade git

Debian أو Ubuntu

sudo apt update
sudo apt upgrade git

Fedora

sudo dnf upgrade git

بعد التحديث:

git --version

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

مشكلات التثبيت والإعداد الشائعة

ظهور “git is not recognized” على Windows

تشمل الأسباب المحتملة:

  • كانت الطرفية مفتوحة قبل تثبيت Git.

  • لم يضف المثبّت Git إلى PATH المناسب.

  • لم تحدّث بيئة التطوير متغيرات البيئة بعد.

  • فشل التثبيت أو تمت إزالة Git.

أغلق الطرفية وافتحها مجددًا أولًا، ثم نفّذ:

where git

إذا لم يظهر أي مسار، فأصلح تثبيت Git أو أعد تثبيته وراجع خيار PATH.

ظهور “command not found: git” على macOS أو Linux

تحقّق من تثبيت الحزمة ومن قيمة PATH:

which git
echo $PATH

على macOS، ثبّت Xcode Command Line Tools أو تحقّق من مسار مدير الحزم.

الطرفية وبيئة التطوير تعرضان إصدارين مختلفين من Git

قد تكون بيئة التطوير مضبوطة على مسار تنفيذي محدد. قارن:

git --version
which git

أو على Windows:

git --version
where git

ثم راجع إعدادات Git داخل بيئة التطوير.

تستخدم الالتزامات بريدًا إلكترونيًا غير صحيح

تحقّق من القيمة الفعالة ومصدرها:

git config --show-origin --get user.email

قد يتغلب إعداد محلي داخل المستودع على الإعداد العام.

يفتح Git محررًا غير مألوف

اضبط محررًا تعرف استخدامه:

git config --global core.editor "code --wait"

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

يظهر كل سطر على أنه تغيّر

يشير ذلك غالبًا إلى تحويل في نهايات الأسطر أو التنسيق. تحقّق:

git config --show-origin --get core.autocrlf
git diff --ignore-space-at-eol

راجع أيضًا ملف .gitattributes الخاص بالمستودع. لا تسجّل تغييرًا ضخمًا قبل أن تفهم ما إذا كان وظيفيًا أم مجرد تطبيع.

يحذر Git من أن المستودع غير آمن

قد يرفض Git مستودعًا يملكه مستخدم آخر في نظام التشغيل كإجراء أمني. أصلح الملكية أو الصلاحيات إذا كانت غير صحيحة.

أضف المستودع إلى safe.directory فقط إذا كنت تعرف سبب اختلاف الملكية وتثق بالمسار. وتجنب تعطيل الحماية عالميًا باستخدام رمز بدل شامل.

تستمر المصادقة في طلب بيانات الاعتماد

افحص رابط المستودع البعيد ومساعد بيانات الاعتماد:

git remote -v
git config --show-origin --get-all credential.helper

قد يكون السبب رمز وصول منتهي الصلاحية، أو بروتوكولًا بعيدًا غير صحيح، أو غياب مساعد بيانات الاعتماد، أو قفل مخزن المفاتيح، أو اشتراط المؤسسة طريقة مصادقة محددة.

أخطاء شهادات HTTPS

لا تحل المشكلة بتعطيل التحقق من SSL عالميًا:

# Do not use this as a general fix
git config --global http.sslVerify false

بدلًا من ذلك، ثبّت سلسلة الشهادات الموثوقة الخاصة بالمؤسسة بصورة صحيحة، أو اتبع إعدادات الوكيل والشهادات المعتمدة.

ظهور قيم إعداد مكررة

نفّذ:

git config --list --show-origin

قد يوجد المفتاح نفسه في مستويات System وGlobal وLocal. يطبق Git قواعد الأولوية، لذلك لا تكون القيم المكررة خطأ دائمًا. احذف فقط القيمة غير المقصودة من المستوى الصحيح.

يعمل Git في Windows ولا يعمل داخل WSL

ثبّت Git داخل توزيعة WSL واضبطه هناك. لا يشترك Windows وWSL تلقائيًا في الملف التنفيذي نفسه أو ملف الإعداد العام نفسه.

أخطاء إعداد ينبغي تجنبها

  • استخدام بريد وهمي أو غير مقصود في الالتزامات.

  • افتراض أن user.name هو اسم تسجيل الدخول إلى منصة الاستضافة.

  • اختيار محرر نصوص لا تعرف كيفية إغلاقه.

  • نسخ سياسة عامة لـ rebase أو pull دون فهم طريقة عمل الفريق.

  • تعطيل التحقق من شهادات HTTPS.

  • حفظ رموز الوصول باستخدام مساعد تخزين غير مشفر.

  • تطبيق تطبيع نهايات الأسطر على مستودع كبير دون مراجعة.

  • استخدام safe.directory=* كحل عام.

  • تحرير عدة ملفات إعداد دون التحقق من المستوى الذي يملك الأولوية.

  • افتراض أن نسخة Git التي تستخدمها بيئة التطوير هي نفسها التي تستخدمها الطرفية.

قائمة التحقق من التثبيت والإعداد

  • تشغيل git --version بنجاح.

  • التأكد من مسار الملف التنفيذي النشط.

  • ضبط اسم مؤلف الالتزام بصورة صحيحة.

  • ضبط البريد الإلكتروني الصحيح للالتزامات.

  • تعيين main أو اسم الفرع الأولي الذي تعتمد عليه المؤسسة.

  • اختيار محرر افتراضي واختباره.

  • مراجعة سياسة نهايات الأسطر.

  • التأكد من أن مساعد بيانات الاعتماد آمن.

  • فحص مصادر الإعدادات باستخدام --show-origin.

  • إنشاء مستودع تجريبي وتنفيذ التزام ناجح.

  • التحقق من مؤلف الالتزام باستخدام git log -1 --format=fuller.

الأسئلة الشائعة

هل أحتاج إلى GitHub لتثبيت Git؟

لا. Git نظام مستقل لإدارة الإصدارات، بينما GitHub واحدة من عدة خدمات يمكنها استضافة مستودعات Git البعيدة.

هل ينبغي تثبيت واجهة رسومية لـ Git؟

العميل الرسومي اختياري. يمنحك تعلم سطر الأوامر أولًا فهمًا قابلًا للنقل بين أنظمة التشغيل والخوادم وبيئات التطوير ومنصات الاستضافة. ويمكن إضافة واجهة رسومية لاحقًا دون أن تحل محل Git نفسه.

هل يمكن استخدام Git Bash وPowerShell على الجهاز نفسه؟

نعم. يمكن لكليهما استخدام نسخة Git for Windows نفسها إذا كان PATH مضبوطًا بصورة صحيحة.

هل يجب أن يطابق بريد Git بريد GitHub؟

يجب أن يطابق عنوانًا تتعرف إليه منصة الاستضافة عندما تريد ربط الالتزامات بالحساب. ويمكنك أيضًا استخدام عنوان خصوصية توفره المنصة.

هل يجب على مطوري Windows استخدام core.autocrlf=true دائمًا؟

ليس دائمًا. هو خيار شائع كبداية، لكن سياسة .gitattributes المحفوظة داخل المستودع ومتطلبات المشروع أهم من قاعدة عامة واحدة.

لماذا يحتاج Git إلى محرر؟

يستخدم Git المحرر لرسائل الالتزام والدمج، وعمليات rebase التفاعلية، والعلامات المشروحة، وتحرير الإعدادات عندما يحتاج إلى إدخال نص تفاعلي.

هل تؤثر الإعدادات العامة في المستودعات الموجودة؟

تُستخدم الإعدادات العامة ما لم يتغلب عليها إعداد محلي أكثر تخصيصًا. وبعض الإعدادات، مثل init.defaultBranch، لا تؤثر إلا في المستودعات التي تُنشأ بعد ضبطها.

هل يمكن استخدام هويات Git مختلفة لمشاريع العمل والمشاريع الشخصية؟

نعم. اضبط هوية عامة افتراضية، ثم حدد قيم user.name وuser.email محلية داخل المستودعات التي تحتاج إلى هوية مختلفة. ويمكن للمستخدمين المتقدمين استخدام ملفات إعداد شرطية أيضًا.

هل Git Credential Manager هو نفسه Git؟

لا. هو مساعد لبيانات الاعتماد يمكن لـ Git استدعاؤه لإدارة المصادقة الآمنة، بينما يتولى Git نفسه إدارة سجل المستودع.

الخلاصة

تبدأ بيئة Git الموثوقة بثلاث طبقات: ملف تنفيذي مثبت بصورة صحيحة، وإعدادات مستخدم مقصودة، ومسار عمل تم اختباره داخل مستودع فعلي.

يمنح التثبيت النظام القدرة على تشغيل Git. أما الإعدادات فتحدد كيفية تعريف مؤلفي الالتزامات، وتسمية الفروع الجديدة، وفتح النصوص التفاعلية، والتعامل مع نهايات الأسطر، والحصول على بيانات اعتماد المستودعات البعيدة. ويؤكد الاختبار أن جميع هذه الأجزاء تعمل معًا.

لا تتعامل مع أوامر الإعداد باعتبارها قيمًا تُنسخ دون فهم. اعرف مستوى كل إعداد ووظيفته، لأن هوية الالتزام ونهايات الأسطر والمصادقة وسلوك pull قد تؤثر في المطور وفي الفريق بأكمله.

بعد تثبيت Git وإعداده، تتمثل الخطوة التالية في إنشاء مستودع، وفحص حالته، وإضافة الملفات، وفهم العلاقة العملية بين مجلد العمل ومنطقة التجهيز وأول التزام.

المراجع الرسمية ومواد إضافية للقراءة