أساسيات نظام Git للتحكم في الإصدارات البرمجية

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

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

الفئة المستهدفة

يستهدف برايان "بيج جورجينسن" هول Brian “Beej Jorgensen” Hall -مؤلف الدليل- طلاب الجامعة بشكل رئيسي لكن أسلوب الشرح مصمم بحيث يستطيع غيرهم من المبتدئين في البرمجة أن يستفيدوا منه أيضًا، وإن كنا نفترض معرفتك بكيفية التعامل مع سطر الأوامر في طرفيات POSIX مثل Bash أو Zsh وغيرهما، أي تعرف الأوامر الأساسية مثل cd, ls, mkdir, cp وغيرها، وكذلك تثبيت البرامج التي نتعرض لها أثناء الشرح.

ننصح باستخدام أحد أنظمة لينكس في تعلمك لنظام Git ورحلتك البرمجية عمومًا لأنها تُعد أنظمة شبيهة بيونكس UNIX LIKE من حيث موافقتها لمعايير POSIX لنظم التشغيل من ناحية، وجاهزيتها للأدوات والمكتبات البرمجية من ناحية أخرى، أو استخدام أنظمة أخرى شبيهة بيونكس مثل FreeBSD أو ماك، لكن إن كنت تستخدم ويندوز فإن نظام Git يأتي مع طرفية تسمى Git Bash، كما تستطيع تثبيت WSL.

ما هو نظام Git

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

فإذا عملت على المشروع وأجريت بعض التغييرات لإضافة ميزة جديدة مثلًا، تستطيع إيداع تلك التغييرات حين تكون جاهزة إلى مستودع ملفات المشروع فيما يعرف بعملية commit، وهو المكان الذي تحفظ فيه شيفرة العمل، وهكذا تكون تلك التغييرات متاحة في المستودع repository للاطلاع عليها لمن له وصول إليه، كزملائك في العمل مثلًا.

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

اصطلاحات

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

المستودع Repo/Repository: هو المكان الذي يُحفظ فيه مشروع برمجي ما داخل Git، ويكون لكل مشروع في العادة مستودع خاص، فقد تنشئ مستودعًا من أجل مشروع جديد تعمل عليه، ويكون إما موجودًا على حاسوبك الشخصي أو على حواسيب بعيدة.

المستودع البعيد Remote Repo: هو نسخة من مستودع في مكان غير حاسوبك المحلي.

الاستنساخ Clone: أن تنشئ نسخة محلية على حاسوبك من مستودع بعيد remote repo، وتسمى هذه النسخة نفسها clone أيضًا.

شجرة العمل Working Tree: الدليل أو المجلد الذي تعدل فيه ملفات المشروع، تُنشأ هذه الشجرة عند إنشاء نسخة clone من المستودع.

منطقة التحضير Stage: هي المكان الذي تضيف فيه الملفات التي تريد تحضيرها لعملية الإيداع commit، فإذا عدلت بعض الملفات لكن لم تضفها هنا أولًا فلن تشملها عملية الإيداع.

الفهرس Index: اسم آخر أقل شيوعًا لمنطقة التحضير.

الإيداع Commit: هو لقطة لحالة المشروع في لحظة معينة، تتضمن التعديلات التي أُضيفت إلى منطقة التحضير، ويُستخدم لتوثيق التغييرات وتتبعها عبر الزمن.

أمثلة على رسائل الإيداع:

إضافة الميزة س إلى القاعدة البرمجية
إصلاح خطأ ص
دمج تغييرات مساهمين آخرين في الشيفرة

ما هو GitHub

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

اقتباس

ربما تكون قد سمعت عن GitLab أو Gitea، وهما منافسان لموقع GitHub، مع ميزة لموقع Gitea أنه مفتوح المصدر ويمكنك تشغيل واجهة تشبه GitHub على خادمك الخاص.

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

مسار عمل بسيط في Git

يوجد عدة مسارات عمل قد تتبعها أثناء عملك مع Git، منها ما يكثر استخدامه ومنها الذي قد لا تستخدمه إلا نادرًا، فيما يلي أحد المسارات الشائعة:

الاستنساخ clone: في البداية تنسخ مستودعًا بعيدًا، أي ليس محفوظًا على حاسوبك المحلي، يكون في العادة على GitHub.
مرحلة التعديل: تنفذ بعض التغييرات في شجرة العمل working tree، وهي المكان الذي توجد فيه ملفات المشروع على جهازك.
الإضافة إلى الفهرس: تضيف بعدها تلك التغييرات إلى منطقة التحضير stage، والتي تعرف أيضًا بالفهرس Index.
الإيداع Commit: تودع هذه التغييرات لتسجيلها كلقطة snapshot.
مرحلة الدفع Push: ادفع اللقطة التي سجلتها لنقلها إلى المستودع البعيد.
عد إلى الخطوة رقم 2 وكرر المسار.

ما هو الاستنساخ

اقتباس

نظام التحكم الموزَّع في الإصدارات Distributed version control system

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

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

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

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

كيف تتفاعل النسخ مع بعضها

هناك عمليتان رئيسيتان نستخدمهما بعد إنشاء نسخة ما:

الدفع Push: تأخذ عملية الدفع اللقطات التي أودعتها على حاسوبك المحلي وترفعها إلى المستودع البعيد.
السحب Pull: بالعكس، تأخذ عملية السحب اللقطات الموجودة في المستودع البعيد وتنزلها إلى حاسوبك المحلي.

كما توجد عملية أخرى تحدث خلف الكواليس هي عملية الدمج merge، وينبغي أن تعلم أن تعديلاتك التي تجريها على نسختك المحلية لن تظهر في المستودع البعيد إلا عندما تدفع بذلك التغيير إلى المستودع البعيد، وبالمثل لن تظهر التعديلات الموجودة في المستودع البعيد على حاسوبك المحلي إلا عند سحبك pull للقطة الموجودة في المستودع.

الاستخدام الفعلي لنظام Git

يفترض هذا القسم أن أدوات سطر أوامر Git مثبتة لديك وأنك ستستخدم إحدى طرفيات يونكس مثل Bash أو Zsh.

اقتباس

من أين تحصل على هذه الطرفيات؟

إذا كنت تستخدم أحد الأنظمة الشبيهة بنظام يونكس، مثل لينكس أو BSD أو يونكس أو ماك فهي تأتي مع النظام، أما في حالة ويندوز فننصح بتثبيت نظام ويندوز الفرعي للينكس، أو استخدام طرفية Git Bash التي تأتي مع نظام Git.

سنفترض في حالتنا هنا أن لدينا مستودعًا في GitHub ونريد نسخه، وعليه سنمر بالخطوات التي ذكرناها قبل قليل، لكن سنضيف إليها خطوة جديدة تسبقها:

الخطوة 0: إعداد بياناتك لأول مرة

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

$ git config set --global user.name "اسمك"
$ git config set --global user.email "بريدك الإلكتروني"

اقتباس

إذا أردت تغيير الاسم أو عنوان البريد لاحقًا فكرر الأمرين في المثال السابق.

لا تنسخ المحث $ في المثال أعلاه فهو يتغير وفقًا للطرفية التي تستخدمها، فقد يكون $ أو # أو %، ونحن نضيفه في هذه الأمثلة ليدل على أن السطر الذي بعده يُكتب في الطرفية أو سطر الأوامر.

أخيرًا، نحدد اسم الفرع الافتراضي default branch ليكون main من خلال الأمر التالي:

$ git config set --global init.defaultBranch main

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

لكن اسم main ليس إجباريًا بل تستطيع اختيار ما شئت، حيث تسمى بعض المستودعات master مثلًا للفرع الرئيسي أو main و trunk و development، وكلها من الأسماء الشائعة للفروع الرئيسية للمستودعات.

الخطوة 1: استنساخ مستودع

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

$ git clone https://github.com/beejjorgensen/git-example-repo.git

ستلاحظ ظهور مخرجات مثل هذه:

Cloning into 'git-example-repo'...
remote: Enumerating objects: 10, done.
remote: Counting objects: 100% (10/10), done.
remote: Compressing objects: 100% (8/8), done.
remote: Total 10 (delta 2), reused 9 (delta 1), pack-reused 0
remote: (from 0)
Receiving objects: 100% (10/10), done.
Resolving deltas: 100% (2/2), done.

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

$ cd git-example-repo
$ ls -la

ستظهر الملفات التي يحتوي عليها المستودع كما يلي:

os@machine:~$ cd git-example-repo
os@machine:~/git-example-repo$ ls -la
total 20
drwxr-xr-x  3 os os 4096 فبر 23 17:29 .
drwxr-xr-x 22 os os 4096 فبر 24 00:09 ..
drwxr-xr-x  8 os os 4096 فبر 24 00:01 .git
-rwxr-xr-x  1 os os  175 فبر 24 00:09 hello.py
-rw-r--r--  1 os os  162 فبر 23 17:29 README.md

نلاحظ في خرج الأمر أعلاه أن المستودع يحتوي على الملفين hello.py و README.md إضافة إلى المجلد ‎.git الذي يخزن فيه نظام Git جميع البيانات الوصفية meta data والإيداعات commits الخاصة بالمشروع، وينبغي تجنب العبث بملفات هذا المجلد أو تعديلها لأن وجوده هو ما يمنح المجلد الرئيسي صفة "مستودع Git". نستخدم الأمر status لمعرفة حالة المستودع المحلي كما يلي:

$ git status

فتظهر لنا النتيجة التالية:

On branch main
Your branch is up to date with 'origin/main'.
nothing to commit, working tree clean

تخبرنا هذه النتيجة معلومات كثيرة عن حالة المستودع الراهنة، حيث نعرف منها ما يلي:

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

بالعودة إلى السطر الثاني نرى كلمة origin وهي مجرد اسم يشير إلى المستودع البعيد الذي أخذنا منه نسختنا وعليه فإن origin/main تعني فرع main من المستودع الأصلي الذي أخذت منه نسختك، وهذا يقودنا إلى ملاحظة أخرى وهي أن لدينا فرعين main هنا، واحد على المستودع المحلي والآخر على المستودع البعيد.

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

الخطوة الثانية: إجراء تعديلات على المستودع المحلي

لنحرر الآن أحد الملفات ونجري عليه بعض التعديلات، مرة أخرى لا تقلق بشأن تخريب بيانات المستودع البعيد فنحن لا نملك صلاحيات ذلك أصلًا. افتح الشيفرة في محرر النصوص الذي تفضله، وإذا كان محررك النصي هو VS Code فتستطيع تشغيله مباشرة في المجلد الحالي كما يلي:

$ code .

لنعدّل الآن في ملف hello.py الذي كانت بياناته الأصلية كما يلي:

#!/usr/bin/env python

print("Hello World!")
print("This is my program!")

أضف الآن سطرًا يمثل تعديلًا جديدًا:

#!/usr/bin/env python

print("Hello World!")
print("This is my program!")
print("And this is my modification!")

احفظ الآن هذا الملف، ولنسأل Git عن الحالة الجديدة للمستودع عن طريق الأمر status:

$ git status

في النتيجة هذه المرة سنحصل على:

On branch main
Your branch is up to date with 'origin/main'.

Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working
  directory)
  modified:   hello.py

 no changes added to commit (use "git add" and/or "git commit -a")

نرى من هذه الحالة الجديدة الآن ما يلي:

اكتشف Git أننا عدلنا على ملف hello.py تحديدًا لكنه يقول أيضًا no changes added to commit ، وهذا يعني أننا لم نضف الملف المعدل إلى منطقة التحضير stage التي نضع فيها العناصر التي نريد إرسالها في عملية الإيداع، لكن نريد مراجعة التغييرات أولًا قبل إرسالها، وهو ما سنفعله الآن باستخدام أداة git diff.

ترينا هذه الأداة -التي هي اختصار لكلمة difference- التفاصيل التي تغيرت في الملفات لكن مخرجاتها قد تكون غامضة بعض الشيء، انظر المثال التالي:

$ git diff

 diff --git a/hello.py b/hello.py
  index 9db78d2..1187d32 100755
  --- a/hello.py
  +++ b/hello.py
  @@ -2,3 +2,4 @@

   print("Hello, world!")
   print("This is my program!")
  +print("And this is my modification!")

ملخص ما تريد الاطلاع عليه هو ما يلي:

اسم الملف: حيث نرى أن التعديل جرى على الملف hello.py.
السطر الذي يبدأ بعلامة + وهو الذي أضفناه.

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

الخطوة 3: إضافة التعديلات إلى منطقة التحضير

no changes added to commit (use "git add" and/or "git commit -a")

في هذه المرحلة لم نقم بعد بإضافة التعديلات إلى منطقة التحضير، لذلك يخبرنا Git بعدم وجود تغييرات جاهزة للإيداع، ونحن نعلم أننا عدلنا الملف hello.py ونريد أن ننفذ عملية إيداع تجسد تلك التعديلات الجديدة لذا سنضيف الملف أولًا إلى منطقة التحضير باستخدام git add:

os@machine:~/git-example-repo$ git add hello.py
os@machine:~/git-example-repo$ git status
On branch main
Your branch is up to date with 'origin/main'.

Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
        modified:   hello.py

لقد تغيرت الرسالة الآن من Changes not staged for commit إلى Changes to be committed، وهذا يعني أننا نجحنا في نسخ الملف hello.py إلى منطقة التحضير.

نرى رسالة أخرى في السطر قبل الأخير حول كيفية إلغاء تحضير الملف، فإذا فرضنا أننا أضفناه دون قصد ونريد حذفه منها وعدم تضمينه في الإيداع الذي سنرسله، فما علينا إلا تنفيذ الأمر التالي:

$ git restore --staged hello.py

وسيعود الملف إلى مرحلة Changes not staged for commit.

الخطوة 4: إيداع التعديلات

نستطيع الآن تنفيذ عملية إيداع commit بما أننا نسخنا الملف إلى منطقة التحضير، ونعيد التذكير هنا أن هذا الإيداع يمثل لقطة snapshot لحالة المستودع بناء على الملفات المعدلة الموجودة في منطقة التحضير فقط -إضافةً إلى الملفات التي لم نعدلها-، أما الملفات التي عدلناها ثم لم نضفها إلى منطقة التحضير فلا تدخل في عملية الإيداع. هذا يعني أن عملية الإيداع تمثل حالة كاملة للمشروع، حيث تتضمن التعديلات التي أُضيفت إلى منطقة التحضير، بينما تبقى الملفات غير المعدلة كما هي من الإيداع السابق دون تغيير.

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

$ git commit -m "Add another print line"
[main a3c7285] Add another print line
   1 file changed, 1 insertion(+)

يسمح الخيار ‎-m بتحديد رسالة الإيداع مباشرة -التي بين علامات التنصيص- أما إذا لم نضفها فسيفتح Git محرر نصي لتعديل رسالة الإيداع، وإذا فتحت هذا المحرر فاعلم أن كل رسالة إيداع تبدأ بعلامة # هي تعليق يتجاهله Git عند تسجيل اللقطة، لنتحقق مرة أخرى من حالة المستودع:

$ git status
On branch main
Your branch is ahead of 'origin/main' by 1 commit.
  (use "git push" to publish your local commits)

nothing to commit, working tree clean

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

فمثلًا، نستطيع إيداع ملف وليكن foo.txt دون إضافته إلى منطقة التحضير عن طريق ما يلي:

$ git commit -m "jerbify the flurblux" foo.txt

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

إذا عدنا إلى مخرجات status مرة أخرى سنرى أننا متقدمون على origin/main بعملية إيداع واحدة أو لقطة واحدة، وهذا يعني أن سجل الإيداع المحلي على فرع main يحتوي على لقطة ليست في سجل main الخاص بالمستودع البعيد، وهذا منطقي نظرًا لأن المستودع البعيد يمثل نسخة مستقلة تمامًا عن النسخة المحلية التي على حاسوبنا، ولا تتأثر به إلا إذا حاولنا عمدًا أن نزامن النسختين، أما عدا هذا فلن يعرف المستودع البعيد أننا أجرينا تعديلات محلية.

يمثل Git دور المساعد الذكي حيث ينصحنا في الرسالة الظاهرة بين قوسين من المثال أعلاه بتنفيذ الأمر git push إذا أردنا تحديث المستودع البعيد ليستقبل التعديلات التي أجريناها لتتطابق النسختان معًا، وهو ما سنفعله في الخطوة التالية.

الخطوة 5: رفع التعديلات إلى المستودع البعيد

ننفذ الأمر git push لنرفع تعديلاتنا المحلية إلى المستودع البعيد:

$ git push

تظهر لنا النتيجة التالية:

Username for 'https://github.com':

ستحتاج هنا أن تدخل اسم المستخدم الخاص بك في موقع github وكلمة المرور، لكن تقابلنا الرسالة التالية:

Username for 'https://github.com': my_username
Password for 'https://beejjorgensen@github.com': [my_password]
remote: Support for password authentication was removed on August
        13, 2021.
remote: Please see https://docs.github.com/en/get-started/getting-
        started-with-git/about-remote-repositories#cloning-with-
        https-urls for information on currently recommended modes
        of authentication.
fatal: Authentication failed for 'https://github.com/beejjorgensen/
       git-example-repo.git/'

تظهر رسالة الفشل fatal: Authentication failed لعدة أسباب:

أولًا: لا تملك تصريحًا بالكتابة أو التعديل في هذا المستودع لأنك لست صاحبه.
ثانيًا: توقف دعم المصادقة بكلمات المرور التقليدية منذ 2021.

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

خاتمة

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