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

اقتباس

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

إنشاء حساب GitHub

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

إنشاء مستودع جديد في GitHub

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

• يوجد زر New أخضر على يسار اللوحة في الغالب، كما توجد قائمة منسدلة عليها علامة + أعلى جهة اليمين تحتوي خيار New Repository، هاتان طريقتان لإنشاء مستودع جديد تستطيع استخدام أيهما.

• أدخل اسم المستودع في الصفحة التي تلي ذلك، اختر أي اسم تريد بشرط ألا يكون لديك مستودع سابق بنفس الاسم، لنكتب test-repo لغرض مثالنا هنا.

• فعِّل خيار Add a README file لإضافة ملف Readme. لاحظ أن عليك تجنب هذا الخيار في المستقبل إذا كان لديك مستودع محلي وتريد دفعه push إلى هذه المستودع الجديد، لأن هذا سيمنع عملية الدفع.

• انقر على زر Create repository في أسفل الصفحة.

وهكذا صار لدينا أول مستودع خاص بنا.

مصادقة الحسابات

ينبغي أن نشرح عملية المصادقة authentication أولًا قبل الانتقال إلى شرح الاستنساخ cloning، ذلك أنك إذا جربت مزامنة مستودع محلي على حاسوبك مع مستودع بعيد على GitHub فلن تنجح لأن دعم المصادقة بكلمة المرور قد ألغي في 2021، فأمامنا الآن عدة خيارات:

• استخدام أداة GitHub CLI.
• استخدام مفاتيح SSH.
• استخدام مفاتيح المصادقة الشخصية Personal Authentication Tokens.

يُعد الخيار الأول هو الأسهل، أما مفاتيح SSH فهي خيار متقدم بالنسبة للمبتدئين.

واجهة سطر أوامر GitHub

تمثل أداة GitHub CLI واجهة نصية لموقع GitHub وتؤدي عدة وظائف أهمها تسهيل عملية المصادقة لحسابك فيه لتتمكن من تنفيذ مهامك مع Git كدفع ملفاتك إلى مستودع بعيد مثلًا.

لتثبيت هذه الأداة، زر صفحتها واتبع تعليمات التثبيت الخاصة بنظام تشغيلك، ثم جرب تشغيل الأمر gh --version بعد التثبيت لتتأكد من نجاح تثبيتها من خلال عرض معلومات إصدارها:

$ gh --version
  gh version 2.42.1 (2024-01-15)
  https://github.com/cli/cli/releases/tag/v2.42.1

ثم نفذ الأمرين التاليين:

$ gh auth login
$ gh auth setup-git

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

أما الأمر الثاني gh auth setup-git فننفذه مرة واحدة فقط حيث يضيف بعض العناصر المساعدة في عملية المصادقة إلى الإعدادات العامة.

مفاتيح SSH

لدينا خيار آخر للمصادقة هو مفتاح SSH، وذلك إن لم ترغب في استخدام أداة GitHub CLI السابقة، سنبدأ بتوليد مفتاح أولًا ثم استخدامه، تجاوز هذه الخطوة إذا كان لديك زوج من مفاتيح SSH بالفعل -ستعرف أنها لديك إذا نفذت الأمر:

ls ~/.ssh

ورأيت ملفًا مثل id_rsa.pub أو id_ed25519.pub. نفذ الأمر التالي لإنشاء زوج جديد من المفاتيح:

$ ssh-keygen -t ed25519 -C عنوان بريد الإلكتروني هنا

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

نصيحة أمنية

يفضل استخدام كلمة مرور للوصول إلى هذا المفتاح، ذلك أن وصول شخص غيرك إليه يمكّنه من انتحال شخصيتك والوصول إلى حسابك في GitHub، ويلجأ المطورون إلى استخدام Key Agent يتذكر كلمة المرور لفترة زمنية محددة.

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

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

استمر بالنقر على مفتاح الإدخال إذا ظهرت أي أسئلة على الشاشة حتى تصل إلى شيء شبيه بما يلي:

Generating public/private ed25519 key pair.
Enter file in which to save the key (/home/user/.ssh/id_ed25519):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in id_ed25519
Your public key has been saved in id_ed25519.pub
The key fingerprint is:
SHA256:/lrT43BQBRPJpUXxpTBFInhdtZSQjQwxU4USwt5c0Lw user@locahost
The key's randomart image is:
+--[ED25519 256]--+
|        .o.X^%^=+|
|        ..oo*^.=o|
|        ..o = o..|
|         . + E   |
|        S .      |
|       .   o     |
|        . + +    |
|         o = .   |
|        ... .    |
+----[SHA256]-----+

سنحتاج إلى إجراء بعض الإعدادات الإضافية على المفتاح إذا اخترنا اسم ملف غير الاسم الافتراضي لكي نتمكن من تشغيله مع GitHub بشكل صحيح.

لاحظ هذا الرسم العشوائي الغريب في المثال أعلاه، وهو مجرد تمثيل بصري للمفتاح، وتوجد طرق لإعداد SSH بحيث تُعرض لك هذه اللوحة في كل مرة تسجل فيها الدخول، وفكرتها أنك إذا رأيت اختلافًا في اللوحة في مرة ما فهذا يعني أن شيئًا ما قد تغير في إعدادات الأمان. اكتب الآن ls ~/.ssh، يجب أن تظهر نتيجة كهذه:

id_ed25519    id_ed25519.pub

لا تشارك الملف الأول مع أحد أبدًا لأنه مفتاحك الخاص private key، بل لا يوجد سبب يدعوك حتى لنسخه، أما الملف الثاني هو المفتاح العام public key، وهو ما تستطيع مشاركته بأمان، وسنشاركه مع GitHub بعد قليل لكي تسجل الدخول باستخدامه.

اقتباس

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

 chmod 700 ~/.ssh $
*/chmod 600 ~/.ssh $

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

نعطي المفتاح العام الآن إلى GitHub عبر نسخه.

لنحصل أولًا على نسخة منه ننفذ الأمر التالي -غير اسم الملف لاسم الملف الخاص بك-:

$ cat ~/.ssh/id_ed25519.pub

ينبغي أن تظهر لديك نتيجة كالتالي:

ssh-ed25519 AAAC3N[بعض المحارف هنا]V+znpoO عنوان بريدك

انسخ السطر كاملًا إلى الحافظة لتستطيع لصقه لاحقًا.

ربط المفتاح بـ GitHub

اذهب الآن إلى GitHub وانقر على صورتك الشخصية في أعلى اليمين ثم اتبع ما يلي:

1. اختر الإعدادات Settings.
2. اختر SSH and GPG keys.
3. اختر New SSH key
   • أدخل عنوانًا مناسبًا مثل "my laptop key" في حقل Title.
   • تأكد من اختيار Authentication key في حقل Key type.
   • الصق المفتاح الذي نسخناه قبل قليل في حقل key.
   • انقر على Add SSH key.

اقتباس

تذكر أننا استخدمنا بروتوكول SSH لاستنساخ روابط المستودعات لاحقًا.

استخدام مفاتيح الوصول الشخصي

حان الوقت لننشئ كلمات مرور جديدة نستخدمها مع GitHub، وستكون هذه المرة من نوع المفتاح الشخصي personal token، يوفر GitHub توثيقًا مفصلًا حول الموضوع لكن ملخصه أننا سننشئ مفتاح token يمثل بعض الصلاحيات، مثل القراءة والكتابة في مستودعاتي، وسنستخدمه بدلًا من كلمة المرور العادية في سطر الأوامر كما يلي:

Username for 'https://github.com': [اسم المستخدم]
Password for 'https://beejjorgensen@github.com': [مفتاح Token]

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

لنفرض أنك حفظت المفتاح في ملف باسم mytoken.txt، نستطيع حينها إثبات هويتنا عبر واجهة أوامر GitHub كما يلي:

$ gh auth login --with-token < mytoken.txt

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

إنشاء نسخة محلية من المستودع

نحتاج الآن إلى معرفة رابط المستودع كي نستنسخه:

1. انقر على أيقونة صورتك الشخصية في الزاوية العلوية اليمنى ثم اختر Your repositories، ستظهر لك صفحة تضم جميع مستودعاتك، قد لا تجد هنا سوى المستودع test-repo الذي أنشأناه، فانقر على اسمه.
2. تنتقل الآن إلى صفحة المستودع حيث تتصف الملفات الخاصة به، لكن هدفنا الأساسي هو الحصول على رابط الاستنتساخ، فانقر على زر Code الأزرق الكبير.

لننسخه الآن من GitHub إلى الحاسوب المحلي، سيختلف هذا إذا كنت تستخدم GitHub CLI أو مفاتيح SSH، لكن سنشرح الطريقتين.

الاستنتساخ من GitHub باستخدام CLI

لدينا خياران هنا:

الخيار الأول: أشرنا سابقًا إلى تذكر أننا سنستخدم بروتوكول SSH عندما أثبتنا هويتنا باستخدام gh auth login، وعليه سنختار التبويب الموافق لذلك في هذه النافذة، لكن إذا اخترت HTTPS فستختار تبويبها. انسخ الرابط واذهب إلى سطر الأوامر ونفذ الأمر:

 git clone [url]

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

$ git clone https://github.com/user/test-repo.git

وهذه في حالة SSH:

$ git clone git@github.com:user/test-repo.git

الخيار الثاني: اختر تبويب GitHub CLI من القائمة المنسدلة ثم نفذ الأمر كما هو مكتوب هناك تمامًا، سيكون شبيها بالسطر التالي:

$ gh repo clone user/test-repo

الاستنساخ من GitHub باستخدام مفاتيح SSH

نستخدم هذه الطريقة إذا كنا أعددنا مفتاح SSH من قبل:

1. تأكد من اختيار تبويب SSH بعد النقر على زر Code الأخضر.
2. انسخ هذا الرابط.
3. انتقل إلى سطر الأوامر ونفذ الأمر git clone [URL] حيث تضع الرابط الذي نسخته بدلًا من الأقواس بحيث يكون كالتالي:

$ git clone git@github.com:user/test-repo.git

إجراء التعديلات ودفع الملفات إلى المستودع البعيد

ننتقل الآن إلى مجلد المستودع بعد استنساخه باستخدام الأمر git clone، ثم ندخل إليه باستخدام الأمر

cd اسم المجلد

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

git add اسم الملف

ثم ننفذ عملية إيداع باستخدام:

git commit -m "message"

وأخيرًا لدفعه إلى النسخة البعيدة على GitHub مرة أخرى:

git push

يجب أن نرى هذه التغييرات الآن إذا عدنا إلى صفحة المستودع على GitHub وأعدنا تحميل الصفحة.

هذا يعيدنا إلى مسار العمل الشائع على نظام Git:

1. استنساخ مستودع بعيد
2. إجراء بعض التعديلات على النسخة المحلية.
3. إضافة التغييرات إلى منطقة التحضير.
4. تسجيل هذه التغييرات وإيداعها من خلال عملية commit.
5. دفع هذه التغييرات إلى المستودع البعيد.
6. العودة مرة أخرى إلى الخطوة رقم 2.

التعاون في GitHub

توجد طريقتان أساسيتان للتعاون في موقع GitHub هما:

1. الاشتقاق وطلب السحب Fork/Pull Request.
2. إضافة مساهم collaborator.

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

1. اختر الإعدادات Settings.
2. اختر collaborators من القائمة الجانبية اليسرى.
3. أكد هويتك ثم انقر على زر Add people.
4. أدخل اسم المستخدم للشخص الذي تريد التعاون معه.

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

خاتمة

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

اقرأ أيضًا

• إنشاء طلب سحب على GitHub
• أساسيات نظام Git للتحكم في الإصدارات البرمجية

ترجمة -بتصرف- للفصل الثاني من دليل Beej إلى Git لصاحبه Brian “Beej Jorgensen” Hall

يرى العديد من المبتدئين في مجال البرمجة أن نظام إدارة المشاريع البرمجية 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، منها ما يكثر استخدامه ومنها الذي قد لا تستخدمه إلا نادرًا، فيما يلي أحد المسارات الشائعة:

1. الاستنساخ clone: في البداية تنسخ مستودعًا بعيدًا، أي ليس محفوظًا على حاسوبك المحلي، يكون في العادة على GitHub.
2. مرحلة التعديل: تنفذ بعض التغييرات في شجرة العمل working tree، وهي المكان الذي توجد فيه ملفات المشروع على جهازك.
3. الإضافة إلى الفهرس: تضيف بعدها تلك التغييرات إلى منطقة التحضير stage، والتي تعرف أيضًا بالفهرس Index.
4. الإيداع Commit: تودع هذه التغييرات لتسجيلها كلقطة snapshot.
5. مرحلة الدفع Push: ادفع اللقطة التي سجلتها لنقلها إلى المستودع البعيد.
6. عد إلى الخطوة رقم 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!")

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

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

أما علامة - إذا جاءت في بداية السطر فهي تشير أن السطر قد حُذف، ورغم أننا لم نحذف السطر كله بل عدلناه فقط إلا أن نظام 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 وكيفية العمل عليه.

اقرأ أيضًا

• الدليل المرجعي للعمل على نظام غيت Git
• ما هو Git؟
• كيفية استعادة إصدارات الملفات القديمة في جيت Git

ترجمة -بتصرف- للفصل الثاني من دليل استخدام Git لصاحبه Brian “Beej Jorgensen” Hall

يعرض هذا المقال مواصفات لجعل رسائل الإيداع commit messages مقروءة للبشر ولبرامج الأتمتة على حد سواء.

مقدمة

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

هذا الاصطلاح متوافق مع الإدارة الدلالية لنُسخ البرمجيات SemVer، عن طريق وصف المميزات features، والإصلاحات fixes، والتغييرات الجذرية breaking changes في رسائل الإيداع.

يجب أن تكون هيكلية رسائل الإيداع كما يلي:

<type>[optional scope]: <description>
[optional body]
[optional footer(s)]

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

1. إصلاح :fix رسالة إيداع من نوع fix تصلح أو ترقع patch الخطأ في الشيفرة البرمجية، وهذا مرتبط بمصطلح الترقيع PATCH في إدارة النسخ الدلالية Semantic Versioning.
2. ميزة :feat رسالة إيداع من نوع feat تضيف ميزة جديدة للشيفرة البرمجية، وهذا مرتبط بمصطلح الترقيم البسيط MINOR في إدارة النسخ الدلالية.
3. تغيير جذري :BREAKING CHANGE رسالة إيداع بتذييل BREAKING CHANGE: أو بإضافة ! بعد كتابة النوع type أو النطاق scope، والتي تعرض تغييرًا جذريًا في الواجهة البرمجية. هذا مرتبط بمصطلح الترقيم الجذري MAJOR في إدارة النسخ الدلالية. يمكن أن تكون BREAKING CHANGE جزءًا من أي نوع في رسائل الإيداع.
4. تعد الأنواع المختلفة عن :fix أو :feat مسموح بها، مثلًا، commitlint/config-conventional@ بناءً على رسائل الإيداع الاصطلاحية في Angular التي تقترح هذه الأنواع: للبناء :build والعمل الروتيني :choreوالتكامل المستمر:ciوالتوثيقات :docsومتعلقات التصميم :styleوإعادة الهيكلية:refactorوالأداء :perfوالاختبار:test وغيرها.
5. قد تتبع التذييلات -بخلاف التغييرات الجذرية <BREAKING CHANGE: <description مواصفات شبيهة بتنسيقات git trailer format.

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

قد يُضاف النطاق scope، إلى نوع الإيداع لإضافة معلومات سياق contextual، وتُضّمن بين قوسين. مثلًا:

feat(parser): add ability to parse arrays

أمثلة

رسالة إيداع مع الوصف description وتغيير جذري مكتوب في التذييل

feat: allow provided config object to extend other configs
BREAKING CHANGE: `extends` key in config file is now used for extending other config files

رسالة إيداع مع ! للفت الانتباه بوجود تغيير جذري

feat!: send an email to the customer when a product is shipped

رسالة إيداع مع نطاق و ! للفت الانتباه بوجود تغيير جذري

feat(api)!: send an email to the customer when a product is shipped

رسالة إيداع مع ! ونص BREAKING CHANGE في التذييل

chore!: drop support for Node 6
BREAKING CHANGE: use JavaScript features not available in Node 6.

رسالة إيداع دون متن body

docs: correct spelling of CHANGELOG

رسالة إيداع مع نطاق

feat(lang): add polish language

رسالة إيداع مع متن مكون من عدة فقرات وعدة تذييلات

fix: prevent racing of requests

Introduce a request id and a reference to latest request. Dismiss
incoming responses other than from latest request.

Remove timeouts which were used to mitigate the racing issue but are
obsolete now.

Reviewed-by: Z
Refs: #123

المواصفات Specification

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

1. يجب أن تُسبق رسائل الإيداع بالنوع، والذي يحتوي على اسم مثل: featأوfix، أو غيرها، متبوعة بالنطاق (اختياريًا)، أو علامة التعجب!اختياريًا. وبعدها النقطتين:` وبعدها مسافة.
2. يجب استخدام النوع feat عندما تُضاف ميزة جديدة للتطبيق أو المكتبة.
3. يجب استخدام النوع fix عندما تُحل مشكلة في مشروعك.
4. قد يُضاف النطاق بعد النوع، ويجب أن يحتوي النطاق على اسم يصف جزءًا من الشيفرة البرمجية محاطة بقوسين، مثل :fix(parse)‎.
5. يجب أن يكون الوصف description مسبوقًا بالنطاق أو النوع التي تتبعهما النقطتان :. الوصف هو خلاصة قصيرة للتغييرات في الشيفرة البرمجية، مثل:

array parsing issue when multiple spaces were contained in string

6. قد يُضاف متن طويل لرسالة الإيداع بعد الوصف القصير، مضيفًا المزيد من المعلومات لهذا السياق المتعلق بتغييرات الشيفرة البرمجية، ويجب أن يبدأ المتن بسطر فارغ بعد الوصف.
7. ليس لمتن رسالة الإيداع شكل معيّن مفروض، وقد تحتوي على فراغات من أسطر متعددة
8. قد يحتوي تذييل واحد أو أكثر سطرًا فارغًا بعد المتن، ويجب على كل تذييل أن يحتوي رمزًا token متبوعًا إما بفراغ أو فراغ وعلامة "#"، ثم بعدها قيمة. وهذا مستلهم من git trailer convention.
9. يجب أن يستخدم رمز التذييل - بديلًا عن الفراغات بين الكلمات، مثل: Acked-by، وهذا يساعد في التفريق بين التذييل عن المتن ذي الأسطر المتعددة. الاستثناء الوحيد هو للتغييرات الجذرية BREAKING CHANGE، والتي قد تُستخدم رمزًا للتذييل.
10. قد يحتوي محتوى التذييل (وهو ما يأتي بعد الرمز) على فراغات وأسطر فارغة، ويجب أن ينتهي عند وجود الزوج الثاني الصالح من الرمز/الفاصل.
11. يجب أن تُوضّح التغييرات الجذرية في بادئة النوع والنطاق لرسالة الإيداع، أو أن تحل محل الرمز في التذييل.
12. إذا ذكرت التغييرات الجذرية في التذييل، يجب على التغيير الجذري أن يحتوي النص بالأحرف الكبيرة BREAKING CHANGE متبوعًا بالنقطتين : فالفراغ، والوصف. مثًلا:

BREAKING CHANGE: environment variables now take precedence over config files

13. لو ضُمّنت التغييرات الجذرية في بداية النوع أو النطاق، فيجب توضيح وجود تغيرات جذرية عن طريق علامة التعجب ! مباشرةً بعد النقطتين :. لو استخدمت علامة التعجب، فيمكن مسح BREAKING CHANGE: من التذييل، ويتوجب أن يحتوي الوصف على وصف هذه التغييرات الجذرية.
14. قد تُستخدم الأنواع -بخلاف feat أو fix- في رسائل الإيداع، مثل: docs: update ref docs
15. يجب ألا يُتعامل مع وحدات المعلومات في رسائل الإيداع الاصطلاحية على أنها حساسة لحالة الأحرف case sensitive من قبل من يستخدم باستثناء التغيير الجذري الذي يجب أن يبقى بأحرفه الكبيرة.
16. يجب أن يكون BREAKING-CHANGE مساويًا إلى BREAKING CHANGE، عند استخدامه رمزًا في التذييل.

لماذا يُعتمد نظام رسائل الإيداع الاصطلاحية؟

• إنشاء سجلات التغيير CHANGELOGs تلقائيًا.
• تحديد الإصدارات الدلالية لنُسخ البرمجيات semantic version bump تلقائيًا، استنادًا إلى أنواع رسائل الإيداع المكتوبة.
• إيصال طبيعة التغييرات إلى الزملاء في الفريق، والعامة، وكل من له علاقة بالمشروع.
• تفعيل عمليات البناء والنشر.
• تسهيل مشاركة الآخرين في مشاريعك، من خلال إعطائهم سجل تغييرات أكثر تنظيمًا.

الأسئلة الأكثر شيوعا

كيف يجب أن أتعامل مع رسائل الإيداع في مرحلة التطوير الأولية؟

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

هل الأنواع الموجودة في عنوان رسالة الإيداع ذات أحرف كبيرة أم صغيرة؟

يمكن استخدام أي منها ولكن من الأفضل أن يكون متسقًا.

ماذا أفعل إذا كانت رسالة الإيداعات تحتوي على تغييرات من أكثر من نوع؟

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

هل تثبط النقطة السابقة التطوير والانتقال السريع؟

لا تشجع على التحرك بسرعة غير منظمة، ولكنها تساعدك على التحرك بسرعة على المدى الطويل في مشاريع متعددة مع مساهمين متنوعين.

هل يمكن أن تؤدي رسائل الإيداع الاصطلاحية إلى دفع المطورين بتقييد نوع الإيداعات التي يعملونها لأنهم سيفكرون في الأنواع المقدمة؟

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

كيف يرتبط هذا بالإدارة الدلالية لنسخ البرمجيات SemVer؟

يجب ترجمة عمليات الإيداع إلى التالي من النسخ الدلالية SemVer:

• يُترجم النوع fix إلى إصدارات PATCH.
• يُترجم النوع feat إلى إصدارات MINOR.

يجب ترجمة BREAKING CHANGE إلى إصدارات MAJOR، بغض النظر عن نوع رسالة الإيداع.

كيف يمكنني إصدار الامتدادات وفقا لمواصفات رسائل الإيداعات الاصطلاحية، مثلا jameswomack/conventional-commit-spec@؟

نوصي باستخدام الإدارة الدلالية لنُسخ البرمجيات SemVer لإصدار الامتدادات لهذه المواصفات ونشجعك على إنشاء هذه الامتدادات.

ماذا أفعل إذا استخدمت نوع الإيداع الخاطئ دون قصد؟

عند استخدام نوع اصطلاحي ولكن ليس النوع الصحيح مثل fix بدلا من feat

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

عند استخدام نوع ليس من المواصفات مثل feet بدلا من feat

في أسوأ الأحوال، لن تكون نهاية العالم إذا كانت منطقة الالتزام لا تفي بمواصفات الإيداع التقليدية، فهذا يعني ببساطة أن الإيداع سيفوّت missed بالأدوات المستندة إلى المواصفات.

هل يحتاج جميع المساهمين إلى استخدام رسائل الإيداع الاصطلاحية؟

لا، إذا كنت تستخدم سير عمل قائم على squash على غيت Git، فيمكن للمشرفين الرئيسيين تنظيف رسائل الإيداع أثناء دمجها مما لا يضيف أي عبء عمل على مرسلي رسائل الإيداعات العاديين.

يتمثل سير العمل الشائع common workflow في جعل نظام غيت git يسحق squash رسائل الإيداع تلقائيًا من طلب سحب pull request ويقدم نموذجًا للمشرف الرئيسي لإدخال رسالة إيداع git المناسبة للدمج.

كيف تتعامل الإيداعات الاصطلاحية مع الإيداعات العكسية revert commits؟

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

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

إحدى التوصيات هي استخدام النوع revert، والتذييل الذي يشير إلى إيداعات ترميز SHA المعكوسة:

revert: let us never again speak of the noodle incident

Refs: 676104e, a215868

ما شكل الكتابة الذي يجب أن أستخدمه؟

نوصي بكتابة وصف رسائل الإيداع: وصفها ومتنها بصيغة الأمر Imperative mood. يوجد عدد كبير من الأمثلة على أسلوب الكتابة هذا لرسائل الإيداع 1 و 2 و 3 و 4 و 5

حول رسائل الإيداع الاصطلاحية

مواصفات رسائل الإيداع الاصطلاحية مستوحاة من إرشادات Angular لرسائل الإيداع وتعتمد عليها اعتمادًا كبيرًا.

كتبت المسودة الأولى لهذه المواصفات بالتعاون مع بعض الأشخاص الذين ساهموا في:

• conventional-changelog: مجموعة من الأدوات لتحليل رسائل الإيداع الاصطلاحية من سجلات git.
• bumped: أداة لإصدار البرامج التي تسهل تنفيذ الإجراءات قبل وبعد إطلاق إصدار جديد من برنامجك.
• unleash: أداة لأتمتة إصدار البرنامج والنشر.
• lerna: أداة لإدارة المشاريع ذات المستودع الواحد، والتي انبثقت من مشروع Babel.

أدوات لرسائل الإيداعات الاصطلاحات

• go-conventionalcommits: قوة لغة غو الكاملة لتحليل رسائل الإيداعات الاصطلاحية.
• go-conventional-commit: مكتبة لغة غو لتحليل رسائل الإيداعات الاصطلاحية وفقًا للمواصفات.
• chglog: أداة لتحليل رسائل الإيداعات الاصطلاحية من سجلات git وتحويلها إلى نماذج سجلات تغيير CHANGELOGS.
• fastlane-plugin: إضافة تتبع المواصفات لإدارة النسخ وتوليد سجل التغييرات تلقائيًا.
• php-commitizen: أداة مصممة لإنشاء رسائل إيداع وفقًا لمواصفات رسائل الإيداع الاصطلاحية، وهي قابلة للتكوين وللاستخدام لمشاريع PHP لأنها تابعة للمؤلف أو قابلة للاستخدام عالميًا لمشاريع غير PHP.
• php-conventional-changelog: أداة صممت لإنشاء سجل التغيير من رسائل محفوظات رسائل الإيداع الخاصة بالمشروع وبيانات التعريف وأتمتة الإصدار باستخدام Semver، باتباع مواصفات الالتزامات التقليدية، وهي قابلة للتكوين وقابلة للاستخدام لمشاريع PHP إذ أنها تابعة للمؤلف أو قابلة للاستخدام عالميًا لمشاريع غير PHP.
• conform: أداة يمكن استخدامها لفرض السياسات على مستودعات غيت، بما في ذلك رسائل الإيداع الاصطلاحية.
• standard-version: تصدير تلقائي للنسخ وإدارة سجل التغييرات، باستخدام زر GitHub لـ squash وسير عمل رسائل الإيداع الاصطلاحية الموصى به.
• Git Commit Template: يضيف دعم رسائل الإيداع الاصطلاحية لمحررات JetBrains (IntelliJ IDEA و PyCharm و PhpStorm…).
• commitsar: أداة لغة غو للتحقق ما إذا كانت رسائل الإيداع على الفرع متوافقة مع رسائل الإيداع الاصطلاحية، وتأتي بنسخة دوكر للتكامل المستمر.
• semantic-release: أداة تعمل على أتمتة سير عمل إصدار الحزمة بالكامل بما في ذلك: تحديد رقم الإصدار التالي وإنشاء ملاحظات الإصدار ونشر الحزمة.
• ngx-semantic-version: يؤتمت رسائل إيداع مشروع Angular وسير عمل الالتزام عن طريق تكامل commitizen, commitlint, husky and standard-version في مشروعك وتكوينها لاستخدام رسائل الإيداع الاصطلاحية.
• Pyhist: أداة مساعدة من لغة بايثون لتحديث إصدار الباقة من سجل git وإنشاء سجل التغيير CHANGELOG.
• commitizen-tools/commitizen: أداة للغة بايثون مصممة لإنشاء قواعد رسائل الإيداع الاصطلاحية للمشاريع، ورفع إصدارات المشروع، وإنشاء سجل التغيير. قابلة للتكوين وقابلة للاستخدام لكل من مشروع بايثون وغير بايثون، وقابلة للتوسيع توسعًا كبيرًا من خلال بايثون.
• git-mkver:أداة لتطبيق الإصدار الدلالي تلقائيًا على مستودعات git استنادًا إلى رسائل الإيداع الاصطلاحية.
• Conventional Commits Next Version: أداة مساعدة حيادية للأدوات واللغات لحساب الإصدار الدلالي التالي استنادًا إلى رسائل الإيداعات الاصطلاحية منذ الإصدار السابق في المشاريع ذات المستودع الواحد.
• change: أداة لتوليد وتحديث سجل التغيير باستخدام رسائل الإيداع الاصطلاحية.
• sv4git: أداة سطر الأوامر للتحقق من صحة رسائل الإيداع الاصطلاحية، ونسخ الإصدارات وإنشاء الوسوم وسجلات التغيير.
• semantic-gitlog أداة بسيطة لإدارة الإصدار الدلالي تعتمد على رسائل الإيداع الاصطلاحية. يشتق تلقائيًا أرقام الإصدارات وإدارتها وتوليد سجلات التغيير ذات نمط إطار عمل Angular. دعم Maven و Gradle.
• idea-conventional-commit الإكمال التلقائي للسياق والقوالب، لرسائل الإيداع الاصطلاحية ورسائل النسخ الدلالية.
• Versio: أداة متوافقة مع المشاريع ذات المستودع الواحد (monorepos) التي تحدّث أرقام الإصدارات بناءً على رسائل الإيداع الاصطلاحية، واعتماديات المشروع، ويمكنه توليد الوسوم وسجلات التغيير أيضًا.
• Git Changelog Lib: مكتبة جافا Java تدعم عرض سجل التغيير في سياق مشتق من Git. تدعم رسائل الإيداع الاصطلاحية مع Handlebars Helpers، ومُستخدمة في المشاريع التالية:
• Gradle
• Maven
• Jenkins
• Command Line
• Cocogitto: مجموعة من أدوات سطر الأوامر لرسائل الإيداعات الاصطلاحية ومواصفات الإدارة الدلالية لنُسخ البرمجيات semver.
• منقّح صياغة رسائل الإيداع الاصطلاحية: أداة تنقيح صياغة رسائل الإيداع الاصطلاحية، وهي أداة محايدة للغات والأدوات الأخرى.
• Uplift: الإصدار الدلالي بطريقة سهلة. مدعوم من رسائل الإيداع الاصطلاحية. مصمم لكي يستخدم مع التكامل المستمر.

المشاريع التي تستخدم رسائل الإيداع الاصطلاحية

• NFPM: NFPM is Not FPM -أداة تجميع بسيطة لـ deb و rpm و apk مكتوبة بلغة غو
• yargs: محلل وسيطات سطر الأوامر المفضل لدى الجميع.
• istanbuljs: مجموعة أدوات مفتوحة المصدر ومكتبات برمجية لإضافة الاختبارات الآلية للغة جافا سكريبت.
• uPortal-home و uPortal-application-framework:محسن اختياري لواجهة الاستخدام Apereo uPortal.
• massive.js: مكتبة وصول للبيانات لـ Node و PostgreSQL.
• electron: بناء تطبيقات تعمل على أكثر من نظام تشغيل باستخدام جافا سكريبت و HTML و CSS.
• scroll-utility: أداة بسيطة لتسهيل التمرير للعناصر المتوسطة مع حركيات سلسلة.
• Blaze UI: أدوات واجهة استخدام غير مرتبط بإطار عمل معين.
• Monica: نظام إدارة العلاقات الشخصية مفتوح المصدر.
• mhy: بيئة عمل معدة بالأدوات ومتعددة الاستخدامات ولا تحتاج إلى إعداد مسبق.
• ‎@tandil/diffparse: محلل بسيط للتغييرات بين الملفات في نظام إدارة التحكم في الإصدارات.
• ‎@tandil/diffsplit: يسهل تقسيم ملفات التغييرات من نوع .diff و .patch إلى ملفات من نوعها.
• ‎@thi.ng/umbrella:  مستودع لقرابة مئة مشروع TypeScript التي تتخذ منهجية التطوير المقادة بالبيانات Data Driven Development ذات المستودع الواحد.
• yii2-basic-firestarter: قالب تطبيق Yii2 محسّن.
• Nintex Forms: إنشاء نماذج إدخال ديناميكية سهلة لإرسال واستقبال بيانات دقيقة وآنية.
• Tina CMS: مجموعة أدوات لبناء إدارة محتوى واجهات الاستخدام في موقعك.
• Uno Platform: منصة بناء تطبيقات جوال وسطح مكتب وتقنية ويب أسمبلي عن طريق لغة برمجة #C و XAML، وتدعم البرمجيات مفتوحة المصدر والاحترافية.
• AutoSort.NetCore: استخدام سمات الكائن للترتيب الافتراضي.
• Undercut: خطوط إمداد وأدوات لمعالجة البيانات المؤجلة في لغة جافا سكريبت.
• Stats Builder: باني إحصائيات لـ Blox Fruits
• Jenkins X: يوفر Jenkins X خطوط إمداد الأتمتة، وتطوير عمليات Git، وعرض بيئة التشغيل لمساعدة التعاون بين فريق العمل وتسريع نشر البرمجيات مهما كان حجمها.
• GearLock: بديل مخصص لاستعادة Android-x86..
• rsql-querydsl: تكامل لغة الاستعلامات RSQL وإطار عمل Querydsl.
• Changeloguru: توليد سجل التغييرات آليًا من رسائل الإيداع الاصطلاحية، مكتوبة بلغة غو.

ترجمة -وبتصرف- للدليل Conventional Commits لصاحبه Damiano Petrungaro وكل المساهمين.

اقرأ أيضًا

• بدء العمل مع نظام إدارة الإصدارات جيت Git
• استخدامات متقدمة لنظام التحكم بالإصدار Git لإدارة مشاريع بايثون
• أدوات رسومية للأداة سطر الأوامر جيت Git

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

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

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

إيداعات غيت Git

يتيح لك غيت Git حفظ حالة ملفات مشروعك، المسماة لقطات snapshots أو إيداعات commits، أثناء إجراء التغييرات عليها. يمكنك بهذه الطريقة العودة إلى أي لقطة سابقة إذا احتجت إلى ذلك. قد يكون الإيداع اسمًا أو فعلًا بحسب السياق، إذ يودع المبرمجون (أو يحفظون) إيداعاتهم (أو لقطاتهم)، والمصطلح الآخر للإيداع هو تسجيل الوصول check-in إلا أنه أقل شيوعًا.

دورة تطوير التطبيقات باستخدام لغة Python

احترف تطوير التطبيقات مع أكاديمية حسوب والتحق بسوق العمل فور انتهائك من الدورة

اشترك الآن

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

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

استخدام أداة Cookiecutter لإنشاء مشاريع بايثون جديدة

نسمي المجلد الذي يحتوي على الشيفرة المصدرية والوثائق والاختبارات والملفات الأخرى المتعلقة بالمشروع باسم "دليل العمل" أو "شجرة العمل working tree" في أداة غيت، أو ملف المشروع عمومًا. تسمى الملفات الموجودة في دليل العمل ككل بنسخة العمل. لننشئ قبل إنشاء مستودع غيت الملفات الخاصة بمشروع بايثون.

كل مبرمج لديه طريقة مفضلة لإنشاء الملفات، ومع ذلك، تتبع مشاريع بايثون اصطلاحات أسماء المجلدات والتسلسلات الهرمية. قد تتكون برامجك الأبسط من ملف "‎.py" واحد، ولكن عندما تتعامل مع مشاريع أكثر تعقيدًا، ستبدأ بتضمين ملفات "‎.py" وملفات بيانات وتوثيق واختبارات للوحدات والمزيد. يحتوي عادةً جذر مجلد المشروع على مجلد باسم src لملفات التعليمات البرمجية المصدرية "‎.py" ومجلد اختبارات لاختبارات الوحدات ومجلد مستندات لأي وثائق، مثل تلك التي تُنشأ بواسطة أداة التوثيق سفينكس Sphinx، بينما تحتوي الملفات الأخرى على معلومات المشروع وأداة الضبط على النحو التالي: ملف README.md للحصول على معلومات عامة، وملف ‎.coveragerc لتغطية أداة ضبط الشيفرة، و LICENSE.txt لترخيص برنامج المشروع، وما إلى ذلك. هذه الأدوات والملفات خارج نطاق هذه السلسلة، لكنها جديرة بالبحث عنها والتعرف إليها.

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

لتثبيت Cookiecutter، نفذ الأمر التالي على ويندوز:

pip install --user cookiecutter

أو الأمر التالي على على ماك macOS ولينكس Linux:

 pip3 install --user cookiecutter 

يتضمن هذا التثبيت برنامج سطر أوامر Cookiecutter ووحدة cookiecutter الخاصة ببايثون. قد يحذرك الخرج من تثبيت برنامج سطر الأوامر في مجلد غير مدرج في متغير PATH كما يلي:

Installing collected packages: cookiecutter
  WARNING: The script cookiecutter.exe is installed in 'C:\Users\Al\AppData\Roaming\Python\Python38\Scripts' which is not on PATH.
  Consider adding this directory to PATH or, if you prefer to suppress this warning, use --no-warn-script-location.

تذكّر إضافة المجلد (C:\Users\Al...\Scripts في هذه الحالة كما في الشيفرة السابقة) إلى متغير بيئة PATH. وإلا فسيتعين عليك تنفيذ Cookiecutter مثل وحدة بايثون عن طريق إدخال ملف تعريف الارتباط python -m في ويندوز، أو ملف تعريف الارتباط python3 -m في نظامي ماك أوإس ولينكس بدلًا من الاكتفاء بكتابة cookiecutter.

سنُنشئ في هذه المقالة مستودعًا لوحدة تسمى wizcoin، وهي وحدة تتعامل مع العملات المعدنية من نوع galleon، و sickle و knut وهي عملات خيالية لعالم سحري. تستخدم وحدة cookiecutter قوالب لإنشاء ملفات البداية لعدة أنواع مختلفة من المشاريع. يكون القالب غالبًا مجرد رابط لموقع غيت هب GitHub.com. على سبيل المثال، يمكنك من مجلد "C:\Users\Al" إدخال ما يلي في الطرفية Terminal لإنشاء مجلد "C:\Users\Al\wizcoin" مع الملفات الاعتيادية لمشروع بايثون الأساسي. تحمّل وحدة cookiecutter بدورها القالب من غيت هب GitHub وتسألك سلسلةً من الأسئلة حول المشروع الذي تريد إنشاءه:

C:\Users\Al>‎‎‎cookiecutter gh:asweigart/cookiecutter-basicpythonproject
project_name [Basic Python Project]: WizCoin
module_name [basicpythonproject]: wizcoin
author_name [Susie Softwaredeveloper]: Al Sweigart
author_email [susie@example.com]: al@inventwithpython.com
github_username [susieexample]: asweigart
project_version [0.1.0]:
project_short_description [A basic Python project.]: A Python module to represent the galleon, sickle, and knut coins of wizard currency.

يمكنك أيضًا تنفيذ python -m cookiecutter إذا حصلت على خطأ بدلًا من cookiecutter، إذ يحمّل هذا الأمر نموذجًا مُنشأ من cookiecutter-basicpythonproject، وستجد قوالبًا للعديد من لغات البرمجة على الرابط، ونظرًا لاستضافة قوالب Cookiecutter غالبًا على غيت هب، فيمكنك أيضًا كتابة ":gh" اختصارًا للرابط https://github.com في سطر الأوامر.

عندما يسألك Cookiecutter أسئلة، يمكنك إما إدخال إجابة أو ببساطة الضغط على مفتاح الإدخال ENTER لاستخدام الإجابة الافتراضية الموضحة بين قوسين مربعين. على سبيل المثال، يطلب منك project_name [Basic Python Project]:‎ تسمية مشروعك، فإذا لم تدخل شيئًا سيستخدم Cookiecutter النص ‎"Basic Python Project"‎ اسمًا للمشروع، كما تساعدك هذه الإعدادات الافتراضية أيضًا لمعرفة نوع الإجابة المتوقعة. يعرض ما يلي اسم المشروع بأحرف كبيرة يتضمن مسافات:

 project_name [Basic Python Project]:‎ 

بينما يوضح اسم الوحدة بأحرف صغيرة ولا تحتوي على مسافات:

module_name [basicpythonproject]:‎

لم ندخل ردًا لموجّه project_version [0.1.0]:‎، لذا فإن الإستجابة الافتراضية هي "0.1.0".

يُنشئ Cookiecutter بعد الإجابة على الأسئلة مجلد wizcoin في مجلد العمل الحالي مع الملفات الأساسية التي ستحتاجها لمشروع بايثون، كما هو موضح في الشكل 1.

[الشكل 1: الملفات الموجودة في مجلد wizcoin الذي أُنشئ بواسطة Cookiecutter.]

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

تثبيت غيت git

قد يكون غيت git مثبتًا فعلًا على حاسوبك، وللتيقن من ذلك، نفّذ git --version من سطر الأوامر، فإذا رأيت رسالةً، مثل git version 2.29.0.windows.1، فهذا يعني أن غيت مثبتًا فعلًا، أما إذا رأيت رسالة الخطأ "الأمر غير موجود"، فيجب عليك تثبيت غيت. إذا كنت تستخدم نظام ويندوز فانتقل إلى "https://git-scm.com/download"، ثم حمّل مثبّت غيت Git installer وشغّله، أما إذا كنت تستخدم نظام التشغيل ماك macOS Mavericks (10.9)‎ أو إصدارًا أحدث، فما عليك سوى تنفيذ git --version من الطرفية وستبدأ عملية تثبيت غيت في حال عدم وجوده، كما هو موضح في الشكل 2.

أما إذا كنت تستخدم أوبنتو لينكس Ubuntu أو ديبيان لينكس Debian نفذ sudo apt install git-all من الطرفية Terminal، أو إذا كنت تستخدم ريدهات لينكس Red Hat، فنفذ sudo dnf install git-all من الطرفية، وإذا كنتَ تستخدم نظامًا آخر ابحث عن إرشادات لموزعين لينكس الآخرين على git-scm.com/download/linux، وتأكد من أن عملية التثبيت نجحت عن طريق تنفيذ git --version.

[الشكل 2: سيُطلب منك في المرة الأولى التي تنفّذ فيها git --version على macOS 10.9 أو أحدث بتثبيت غيت.]

ضبط اسم المستخدم والبريد الإلكتروني الخاصين بغيت

ستحتاج إلى ضبط اسمك وبريدك الإلكتروني بعد تثبيت غيت بحيث تتضمن إيداعاتك معلومات المؤلف (أنت)، ولفعل ذلك، نفّذ الأمر git config من الطرفية وذلك باستخدام اسمك ومعلومات بريدك الإلكتروني كما يلي:

C:\Users\Al>‎‎‎git config --global user.name "Al Sweigart"
C:\Users\Al>‎‎‎git config --global user.email al@inventwithpython.com

تُخزن هذه المعلومات في ملف "‎.gitconfig" في المجلد الرئيسي الخاص بك، مثل "C:\Users\Al" على حاسوبك الذي يعمل بنظام ويندوز. لن تحتاج أبدًا إلى تعديل هذا الملف النصي مباشرةً، بل بدلًا من ذلك، يمكنك تغييره عن طريق تنفيذ الأمر git config كما يمكنك إظهار إعدادات ضبط غيت الحالية باستخدام الأمر git config --list.

ثبيت أدوات واجهة المستخدم الرسومية لغيت GUI Git

تركز هذه المقالة على أداة سطر أوامر غيت، ولكن تثبيت البرنامج الذي يضيف واجهة المستخدم الرسومية لغيت يمكن أن يساعدك في المهام اليومية. يستخدم المبرمجون المحترفون الذين يعرفون سطر أوامر غيت CLI Git أدوات واجهة المستخدم الرسومية لغيت. تحتوي صفحة الويب https://git-scm.com/downloads/guis على العديد من هذه الأدوات، مثل TortoiseGit لنظام التشغيل ويندوز و GitHub Desktop لنظام التشغيل ماك و GitExtensions لنظام التشغيل لينكس.

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

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

[الشكل 3: تضيف TortoiseGit لنظام التشغيل ويندوز واجهة مستخدم رسومية لتنفيذ أوامر غيت من مستعرض الملفات.]

سير عمل غيت

يتضمن استخدام مستودع غيت الخطوات التالية: أولًا، إنشاء مستودع غيت عن طريق تنفيذ الأمر git init أو الأمر git clone. ثانيًا، إضافة ملفات باستخدام الأمر git add <filename>‎‎‎‎ لتتبع المستودع. ثالثًا، بمجرد إضافة الملفات، يمكنك إيداع التغييرات الحاصلة فيها باستخدام الأمر:

git commit -am "<descriptive commit message>‎‎‎‎"‎

وبعد ذلك أنت جاهز لإجراء التغييرات على شفرتك مجددًا.

يمكنك عرض ملف التعليمات لكل من هذه الأوامر عن طريق تنفيذ git help <command>‎‎‎‎، مثل git help init أو git help add. صفحات المساعدة هذه سهلة الاستخدام والرجوع إليها على الرغم من أنها مملة وتقنية لاستخدامها مثل وسيلة تعليمية، وستتعرف على مزيد من التفاصيل بخصوص كل من هذه الأوامر لاحقًا، ولكن أولًا، تحتاج إلى فهم بعض مفاهيم غيت لتسهيل استيعاب بقية هذه المقالة.

كيفية تتبع غيت لحالة الملف

الملفات الموجودة في مجلد المشروع هي ملفات مُتتبعة tracked من غيت أو غير متتبعة untracked والملفات المتتبعة هي الملفات التي تُضاف وتودع في المستودع، بينما يُصنّف أي ملف آخر على أنه ملف غير متتبع. قد لا تتواجد الملفات التي لم يجري تتبعها في مجلد المشروع في مستودع غيت، بينما توجد الملفات المتتبعة بإحدى الحالات الثلاث:

• حالة الإيداع committed state: هي عندما يكون الملف بنسخة مجلد المشروع مطابقًا لأحدث إيداع في المستودع، وتسمى هذه الحالة أحيانًا بالحالة غير المعدلة unmodified state أو بالحالة النظيفة clean state.
• الحالة المعدلة modified state: هي الحالة التي يكون عندها الملف في مجلد المشروع مختلفًا عن أحدث إيداع في المستودع.
• الحالة المُدرجة staged state: هي عندما يُعدّل الملف وتوضع علامة عليه ليُضمَّن في الإيداع التالي، ونقول عندها أن الملف مدرج أو في منطقة الإدراج، وتُعرف منطقة الإدراج أيضًا بالفهرس index أو ذاكرة التخزين المؤقتة cache.

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

[الشكل 4: الحالات المحتملة لملف في مستودع غيت والتنقل بينها.]

نفذ git status في أي خطوة بعد إنشاء المستودع لعرض حالة المستودع الحالية وحالة ملفاته. ستُنفذ هذا الأمر بصورةٍ متكررة أثناء عملك مع غيت. في المثال التالي، أعددت ملفات في حالات مختلفة، لاحظ كيف تظهر هذه الملفات الأربعة في خرج git status:

C:\Users\Al\ExampleRepo>‎‎‎git status
On branch master
Changes to be committed:
  (use "git restore --staged <file>‎‎‎..." to unstage)
       1 new file:   new_file.py
       2 modified:   staged_file.py

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)
       3 modified:   modified_file.py

Untracked files:
  (use "git add <file>‎‎‎..." to include in what will be committed)
       4 untracked_file.py

في مشروعنا هذا، يوجد new_file.py (سطر 1) الذي أُضيفَ مؤخرًا إلى المستودع وبالتالي فهو في الحالة المُدرجة. هناك أيضًا ملفان متتبعان، وهما staged_file.py (سطر 2) و modified_file.py (سطر 3)، وهما في الحالة المُدرجة والمعدلة، على التوالي، ثم هناك ملف غير مُتتبع اسمه untracked_file.py (سطر 4). يحتوي خرج git status أيضًا على تذكيرات لأوامر غيت التي تنقل الملفات إلى حالات أخرى.

ما هي الفائدة من وضع الملفات في الحالة المدرجة؟

قد تتساءل ما هو الهدف من الحالة المُدرجة، لمَ لا ننتقل فقط بين التعديل والإيداع دون الملفات المُدرجة؟ التعامل مع الحالة المُدرجة مليء بالحالات الخاصة الشائكة ومصدر كبير للارتباك للمبتدئين في غيت. على سبيل المثال، يمكن تعديل الملف بعد إدراجه، مما يؤدي إلى وجود ملفات في كل من الحالات المعدلة والمُدرجة، كما هو موضح في القسم السابق.

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

إنشاء مستودع غيت على حاسوبك

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

من الطرفية، نفذ الأوامر التالية لإنشاء مجلد "‎.git". ستحتاج في نظامي ماك أو إس ولينكس، إلى تنفيذ mkdir بدلًا من md.

C:\Users\Al>‎‎‎md wizcoin
C:\Users\Al>‎‎‎cd wizcoin
C:\Users\Al\wizcoin>‎‎‎git init
Initialized empty Git repository in C:/Users/Al/wizcoin/.git/ 

عند تحويل مجلد إلى مستودع غيت بتنفيذ git init، تبدأ جميع الملفات الموجودة فيه بدون تتبع. بالنسبة لمجلد wizcoin الخاص بنا، يُنشئ الأمر git init مجلدًا يدعى "wizcoin/.git"، الذي يحتوي بدوره على البيانات الوصفية لمستودع غيت. يؤدي وجود هذا المجلد "‎.git" إلى جعل المجلد مستودع غيت؛ وبدونه سيكون لديك ببساطة مجموعة من ملفات الشيفرة المصدرية في مجلد عادي. لن تضطر أبدًا إلى تعديل الملفات في "‎.git" مباشرةً، لذا تجاهل هذا المجلد. في الواقع، سُميَ المجلد "‎.git" بهذا الاسم لأن معظم أنظمة التشغيل تخفي تلقائيًا المجلدات والملفات التي تبدأ أسماؤها بنقطة.

الآن لديك مستودع في المجلد "C:\Users\Al\wizcoin". يُعرف المستودع الموجود على حاسبك باسم المستودع المحلي local repo؛ يُعرف المستودع الموجود على حاسوب شخص آخر باسم المستودع البعيد remote repo. هذا التمييز مهم، لأنه سيتعين عليك غالبًا مشاركة الإيداعات بين المستودعات البعيدة والمحلية حتى تتمكن من العمل مع مطورين آخرين في المشروع ذاته.

يمكنك الآن استخدام الأمر git لإضافة ملفات وتتبع التغييرات داخل مجلد المشروع، إذ سترى ما يلي إذا نفذت git status في المستودع الذي أنشأته حديثًا:

C:\Users\Al\wizcoin>‎‎‎git status
On branch master

No commits yet

nothing to commit (create/copy files and use "git add" to track)

يخبرك خرج هذا الأمر أنه ليس لديك أي إيداعات حتى الآن في هذا المستودع.

تنفيذ أمر git status مع أمر watch

أثناء استخدام أداة سطر أوامر غيت، ستنفّذ غالبًا الأمر git status لمعرفة حالة المستودع الخاص بك، وبدلًا من إدخال هذا الأمر يدويًا، يمكنك استخدام الأمر watch لتنفيذه نيابةً عنك. ينفّذ الأمر watch أمرًا معينًا بصورةٍ متكررة كل ثانيتين، مع تحديث الشاشة بأحدث خرج لها.

يمكنك الحصول على أمر watch عن طريق تنزيل InventWithPython في نظام التشغيل ويندوز، أو يمكنك الحصول على أمر watch عن طريق تنزيل InventWithPython ووضع هذا الملف في مجلد "PATH"، مثل "C:\Windows"، بينما يمكنك الانتقال إلى https://www.macports.org/ في نظام ماك، لتنزيل MacPorts وتثبيته، ثم نفذ sudo ports install watch. يحتوي نظام لينكس على هذا الأمر فعلًا، وبمجرد تثبيته، افتح موجه أوامر جديد أو نافذة طرفية جديدة، ونفذ cd لتغيير المجلد إلى مجلد مستودع غيت الخاص بك، ونفذ watch "git status"‎؛ إذ سيعمل الأمر watch على تنفيذ git status كل ثانيتين، ويعرض أحدث النتائج على الشاشة. يمكنك ترك هذه النافذة مفتوحة أثناء استخدام أداة سطر أوامر غيت في نافذة طرفية مختلفة لترى كيف تتغير حالة المستودع في الوقت الفعلي، كما يمكنك فتح نافذة طرفية أخرى وتنفيذ watch "git log -oneline"‎ لعرض ملخص الإيداعات التي تفعلها، والتي يجري تحديثها أيضًا في الوقت الفعلي. تساعد هذه المعلومات في إزالة الغموض المتعلق بما تفعله أوامر غيت التي تكتبها في المستودع الخاص بك.

إضافة ملفات لغيت لتعقبها

يمكن فقط إيداع أو التراجع عن أو التفاعل مع الملفات المتتبعة من خلال الأمر git. نفّذ git status لمعرفة حالة الملفات في مجلد المشروع:

C:\Users\Al\wizcoin>git status
On branch master

No commits yet

1 Untracked files:
  (use "git add <file>..." to include in what will be committed)

        .coveragerc
        .gitignore
        LICENSE.txt
        README.md
--snip--
        tox.ini

nothing added to commit but untracked files present (use "git add" to track)

لم يحدث تعقب لأي من الملفات الموجودة في مجلد "wizcoin" حاليًا (سطر 1)، ويمكننا تتبعها عن طريق إجراء إيداع أولي لهذه الملفات، الذي يكون على خطوتين: تنفيذ git add لكل ملف يجري إيداعه، ثم تنفيذ git commit لإنشاء إيداع لكل هذه الملفات، ويتتبع غيت الملف بمجرّد إيداعه.

ينقل الأمر git add الملفات من حالة عدم التتبع أو الحالة المعدلة إلى الحالة المُدرجة، إذ يمكننا تنفيذ git add لكل ملف نخطط لتعديله. على سبيل المثال، git add .coveragerc و git add .gitignore و git add LICENSE.txt وما إلى ذلك، لكن هذا أمر ممل. بدلًا من ذلك، دعنا نستخدم الرمز * لإضافة عدة ملفات مرة واحدة. على سبيل المثال، يضيف git add *.py جميع ملفات "‎.py" في مجلد العمل الحالي والمجلدات الفرعية الخاصة به. لإضافة كل ملف لم يجري تعقبه، استخدم نقطة واحدة (.) لإخبار غيت بمطابقة جميع الملفات:

C:\Users\Al\wizcoin>‎‎‎git add .

نفّذ git status لرؤية الملفات التي أدرجتها:

C:\Users\Al\wizcoin>git status
On branch master

No commits yet

1 Changes to be committed:
  (use "git rm --cached <file>..." to unstage)

     2 new file:   .coveragerc
        new file:   .gitignore
--snip--
        new file:   tox.ini

يخبرك خرج git status عن الملفات التي ستُنفَّذ على مراحل في المرة التالية التي تنفّذ فيها git commit (سطر 1)، ويخبرك أيضًا أن هذه ملفات جديدة أُضيفت إلى المستودع (سطر 2) بدلًا من الملفات المُعدّلة الموجودة في المستودع.

بعد تنفيذ git add لتحديد الملفات المراد إضافتها إلى المستودع، نفذ الأمر التالي:

git commit -m "Adding new files to the repo.”

و git status مرةً أخرى لعرض حالة المستودع:

C:\Users\Al\wizcoin>git commit -m "Adding new files to the repo."
[master (root-commit) 65f3b4d] Adding new files to the repo.
 15 files changed, 597 insertions(+)
 create mode 100644 .coveragerc
 create mode 100644 .gitignore
--snip--
 create mode 100644 tox.ini

C:\Users\Al\wizcoin>git status
On branch master
nothing to commit, working tree clean

لاحظ أن أي ملفات مدرجة في ملف "‎.gitignore" لن تُضاف إلى منطقة الإدراج، كما سيوضح القسم التالي.

تجاهل الملفات في المستودع

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

• الملفات المؤقتة في مجلد المشروع.
• ملفات "‎.pyc" و "‎.pyo" و "‎.pyd" التي ينشئها مُفسر بايثون عند تنفيذ برامج "‎.py".
• ملفات "‎.tox" و "htmlcov" والمجلدات الأخرى التي تنشئها أدوات تطوير البرامج المختلفة docs/_build.
• أي ملفات أخرى مجمعة أو مُنشأة يمكن إعادة إنشائها (لأن المستودع مخصص للملفات المصدرية، وليس للمنتجات المُنشأة من الملفات المصدرية).
• ملفات الشيفرة المصدرية التي تحتوي على كلمات مرور قاعدة البيانات أو رموز المصادقة المميزة أو أرقام بطاقات الائتمان أو غيرها من المعلومات الحساسة.

لتجنب تضمين هذه الملفات، أنشئ ملفًا نصيًا باسم "‎.gitignore" يحتوي على المجلدات والملفات التي يجب ألا يتتبعها غيت مطلقًا، وسيستثني غيت بدوره هذه الملفات والمجلدات تلقائيًا من أوامر git add أو git commit، ولن تظهر عند تنفيذ git status.

يبدو ملف "‎.gitignore" الذي ينشئه قالب cookiecutter-basicpythonproject على النحو التالي:

# Byte-compiled / optimized / DLL files
__pycache__/
*.py[cod]
*$py.class
--snip--

يستخدم ملف "‎.gitignore" الرمز * لأحرف البدل wildcards و # للتعليقات. يمكنك قراءة المزيد عنها على صفحة gitignore في التوثيق الرسمي.

يجب عليك إضافة ملف "‎.gitignore" الفعلي إلى مستودع غيت حتى يتمكن المبرمجون الآخرون من الحصول عليه إذا استنسخوا clone مستودعك. إذا كنت تريد معرفة أي الملفات في دليل العمل قد جرى تجاهلها بناءً على الإعدادات في ‎.gitignore، فنفذ الأمر التالي:

git ls-files --other --ignored --exclude-standard

الخلاصة

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

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

ترجمة -وبتصرف- لقسم من الفصل ORGANIZING YOUR CODE PROJECTS WITH GIT من كتاب Beyond the Basic Stuff with Python.

اقرأ أيضًا

• المقال السابق: تلميحات النوع Type Hints في بايثون
• بدء العمل مع نظام إدارة الإصدارات جيت Git
• مبادئ Git الأساسية

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

تعامل جيت git مع الكائنات الثنائية المصدرية Binary Blobs

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

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

يعد Git Large File Storage (اختصارًا LFS) مشروعًا مفتوح المصدر من جيت هاب بدأ كفرع من Git-media، إذ Git-media و git-annex هما إضافات لجيت يهدفان إلى إدارة الملفات الكبيرة، وكل منهما له طريقته الخاصة وميزاته التي يتفرد بها، والتالي يمثل بعضًا منها:

• Git-annex هو نظام مزامنة ملفات موزع يسمح لك بإدارة الملفات الكبيرة، حيث تُنشئ أنت والمستخدمين مستودعاتكم الخاصة ويكون لكل مستودع مجلد محلي ‎.git/annex يتم فيه تخزين الملفات الكبيرة. تتم مزامنة كل شيء بانتظام وبالتالي كل البيانات اللازمة تكون متاحة لجميع المستخدمين. افتراضيًا يفضل git-annex التخزين المحلي قبل التخزين خارج الموقع، لكن يمكنك تغيير ذلك من خلال annex-cost.
• Git-portal هو أيضًا نظام مزامنة ملفات موزع، وكما هو الحال في git-annex لديها خيار المزامنة مع موقع مركزي، ويستخدم أدوات مساعدة شائعة، مثل باش Bash وجيت وبرنامج rsync.
• Git-LFS هو نموذج مركزي، ومستودع للملفات والبيانات المشتركة. أنت تخبر Git-LFS أين هو المكان الذي يتم فيه تخزين ملفاتك الكبيرة، سواء كان على قرص صلب أو مخدم أو خدمة تخزين سحابية، ويتعامل كل مستخدم في مشروعك مع هذا المكان باعتباره الموقع الرئيسي المركزي للملفات الكبيرة.

نموذج git-portal

يؤمن Git-portal لجيت إمكانية إدارة الكائنات الثنائية باستخدام أدوات يونكس الأساسية مثل باش وجيت نفسها وبرنامج rsync اختياريًا. ينسخ Git-portal الملفات الثنائية الكبيرة إلى وحدة تخزين محلية أو خارجية (بعيدة)، ويعطيك روابط لينة symlinks يمكنك إيداعها جنبًا إلى جنب مع بقية ملفات مشروعك.

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

يمكنك تثبيت Git-portal من صفحة المشروع الخاصة به على جيت لاب.

كل أوامر هذه الأداة تعكس الأوامر المستخدمة في جيت، فمثلًا لاستخدام Git-portal في مشروع:

$ git-portal init

لإضافة ملف وليكن مثلًا bigfile.png وهو صورة كبيرة الحجم، ننفذ الأمر التالي:

$ git-portal add bigfile.png

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

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

$ git remote add _portal alice@myserver.com:/home/alice/umbrella.git/_portal

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

نموذج git-annex

يمتلك git-annex مسار عمل مختلف قليلًا، لكن الأفكار الأساسية هي نفسها، ويعتبر نظام مزامنة ملفات موزع يهدف إلى حل مشكلة إدارة ومشاركة ومزامنة الملفات الكبيرة دون الحاجة إلى خدمة تجارية أو حتى خادم مركزي، فهو يجعلك قادرًا على إدارة الملفات الكبيرة على جيت من دون تخزين محتوياتها في جيت. يجب أن تكون قادرًا على تثبيت git-annex من مستودع البرامج software repo، أو يمكنك الحصول عليه من موقعهم على الويب. كما هو الحال مع git-media، يجب على أي شخص يستخدم git-annex تثبيته على جهازه.

الإعداد الأولي أبسط من git-media. لإنشاء مستودع مجرد bare repository على خادمك، نفّذ هذا الأمر مع استبدال المسار الظاهر بالمسار الخاص بك:

$ git init --bare --shared /opt/jupiter.git

ثم انسخه على حاسوبك المحلي، وميّزه كموقع git-annex خاص:

$ git clone seth@example.com:/opt/jupiter.clone
Cloning into 'jupiter.clone'... warning: You appear to have cloned
an empty repository. Checking connectivity... done.
$ git annex init "seth workstation" init seth workstation ok 

بدلًا من استخدام المرشحات filters لتحديد أماكن وجود ملفات الوسائط أو الملفات الكبيرة، يمكنك استخدام الأمر التالي لإضافة الملفات إلى git annex وهو تلقائيًّا يحديد فيما إذا كانت كبيرة أم لا:

$ git annex add bigblobfile.flac
add bigblobfile.flac (checksum) ok
(Recording state in Git...)

الآن تنفيذ عملية الإيداع كالمعتاد بدون اختلاف يذكر:

$ git commit -m 'added flac source for sound fx'

لكن عملية الدفع مختلفة، لأن git-annex تستخدم فرعها الخاص لتتبع الملفات، لذلك عند تنفيذ عملية دفع لأول مرة ربما تحتاج لإضافة الخيار u-، وذلك اعتمادًا على كيفية إدارتك لمستودعك:

$ git push -u origin master git-annex
To seth@example.com:/opt/jupiter.git
* [new branch] master -> master
* [new branch] git-annex -> git-annex 

كما هو الحال مع git-media، فإن عملية الدفع العادية لا تنسخ ملفاتك إلى الخادم وإنما ترسل فقط معلومات تتعلق بالوسائط. أخيرًا عندما تكون جاهزًا لمشاركة الملفات مع باقي أعضاء الفريق، نفّذ أمر المزامنة sync:

$ git annex sync --content

إذا شارك شخص آخر الملفات مع الخادم واحتجت إلى سحبها، فإن الأمر git annex sync سيسحب الملفات غير الموجودة على جهازك والموجودة على الخادم.

يعتبر Git Annex حلًا مضبوطًا بدقة لإدارة الملفات الكبيرة وهو مرن وسهل الاستخدام ومتيّن (قليل الأخطاء) وتم اختباره جيدًا.

نموذج git-lfs

كُتِب git-lfs بلغة Go، ويمكنك تثبيته من الشيفرة المصدر أو كملف ثنائي يتم تنزيله وتثبيته على جهازك، وكافة تعليمات التثبيت موجودة على الموقع، وهو برنامج متعدد المنصات cross-platform لذا لن تواجه مشاكل في عمله وتثبيته على مختلف أنواع الأنظمة.

بعد تثبيته يمكنك تحديد أنواع الملفات التي تريد أن يتجاهلها جيت ويديرها Git-LFS، مثلًا لكي يتتبع Git-LFS جميع الملفات التي تحمل الامتداد png. نكتب:

$ git lfs track "*.png"

في كل مرة تضيف فيها نوع جديد من الملفات لكي يتتبعها Git-LFS، يجب عليك إضافة ثم إيداع الملف gitattributes. كما يلي:

$ git add .gitattributes
$ git commit -m "LFS track *.png"

عندما تغير حالة ملف من هذه الأنواع ليصبح ملف مرحلي (مُدرج)، يُنسَخ الملف إلى git/lfs..

Git-LFS هو مشروع لشركة جيت هاب وهو مرتبط كثيرًا ببنيتها، وإذا كنت ترغب في تشغيل خادم جيت يسمح بدمج Git-LFS، فيمكنك الاطلاع على المثال الموجود في: lfs-test-server من github.

يتميز git-portal و git-annex بالمرونة ويمكنهما استخدام المستودعات المحلية بدلًا من الخادم، وهذا مفيد لإدارة المشاريع المحلية الخاصة.

الملفات الكبيرة وجيت

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

ترجمة -وبتصرف- للمقال How to manage binary blobs with Git لصاحبه Seth Kenlon.

اقرأ أيضًا

• المقال السابق: كيفية بناء خادم جيت لـ Git
• بدء العمل مع نظام إدارة الإصدارات جيت Git
• إنشاء أول مستودع لك من خلال جيت Git
• الدليل المرجعي للعمل على نظام غيت Git
• التعامل مع كائن البيانات الثنائية Blob في جافاسكربت

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

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

خادم جيت المشترك

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

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

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

بفرض كان لديك خادم متاح (ليست مشكلة إذا لم يكن لديك خادم، حيث أن جيت يمكنها أن تساعدك في حل هذه المشكلة، كما أنه بإمكانك استخدام حاسوب راسبيري باي على نظام CentOS كمخدم في البداية)، فإن الخطوة الأولى هي تمكين عمليات تسجيل الدخول عبر خدمة SSH باستخدام ترخيص مفتاح SSH فقط، ويعد هذا أقوى بكثير من عمليات تسجيل الدخول باستخدام كلمة المرور لأنه محصن ضد هجمات القوة الغاشمة brute-force (طرق الاختراق التي تعتمد على تجريب كافة الاحتمالات الممكنة) كما أنه يمكن تعطيل المستخدم ببساطة من خلال حذف مفتاحه.

بمجرد تمكين المصادقة من خلال مفتاح SSH أنشئ مستخدم جيت gituser، وهو عبارة عن مستخدم مشترك لجميع المستخدمين المُصرّح لهم:

$ su -c 'adduser gituser'

ثم قم بالتبديل إلى هذا المستخدم، وأنشئ إطار عمل ‎~/.ssh مع الأذونات المناسبة، وهذا مهم من أجل حمايتك، فإن لم تضع الأذونات اللازمة ستفشل فكرة استخدام مفتاح SSH للحماية.

$ su - gituser
$ mkdir .ssh && chmod 700 .ssh
$ touch .ssh/authorized_keys
$ chmod 600 .ssh/authorized_keys

يحتوي ملف authorized_keys على مفاتيح SSH العامة لجميع المطورين الذين تمنحهم الإذن للعمل في مشروعك على جيت، وينبغي من كل مطوريك إنشاء أزواج من مفاتيح SSH الخاصة بهم وإرسال مفاتيحهم العامة إليك، وأنت ينبغي عليك نسخ المفاتيح العامة في ملف authorized_keys الخاص بمستخدم جيت (انظر مقال العمل مع خواديم SSH: العملاء والمفاتيح)، على سبيل المثال بالنسبة لمطور يسمى Bob، قم بتشغيل هذه الأوامر:

$ cat ~/path/to/id_rsa.bob.pub >> \
/home/gituser/.ssh/authorized_keys

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

عمومًا، قد لا ترغب في منح مطوريك حق الوصول إلى خادمك، حتى لو كان الوصول كمستخدم جيت فقط، وتريد فقط منحهم حق الوصول إلى مستودع جيت، لهذا السبب يوفر جيت صدفة shell تسمى git-shell.

نفّذ هذه الأوامر (كمستخدم جذر root) لإضافة git-shell إلى نظامك، ثم اجعلها الصدفة الافتراضية لمستخدم جيت:

# grep git-shell /etc/shells || su -c \
"echo `which git-shell` >> /etc/shells"
# su -c 'usermod -s git-shell gituser'

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

فمثلًا:

# usermod -a -G gituser seth

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

في الحقيقة، ليس عليك فعليًّا أن تجعل هذا المستودع فارغًا؛ بإمكانه العمل كمستودع عادي، لكن يجب أن تعلم أن المستودع المجرد bare repository لا يحتوي على شجرة عمل working tree، أي لا توجد فيه فروع للتنقل بينها من خلال أمر checkout، وهذا مهم (أن يكون مجردًا) لأنه لا يُسمح للمستخدمين البعيدين بالانتقال إلى فرع نشط (أي يتم العمل عليه حاليًّا)، فمن المؤكد أنك لن تكون سعيدًا في حال كنت تعمل على فرع ما وليكن "Dev" وفجأة يأتي شخص ويدفع تعديلاته ضمن عملك!

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

إن لم ترد وضع المجلد في المجلد الرئيسي، مثلًا لأن الأذونات فيه حازمة ودقيقة للغاية، وتريد تخزينه في موقع آخر مثل ‎/opt أو /usr/local/share، فأنشئ مستودعًا مجردًا كمستخدم جذر:

# git init --bare /opt/jupiter.git
# chown -R gituser:gituser /opt/jupiter.git
# chmod -R 770 /opt/jupiter.git

الآن يمكن لأي مستخدم تمت مصادقته على أنه مستخدم جيت أو موجود في مجموعة مستخدم جيت أن ينفذ عمليات القراءة من مستودع jupiter.git والكتابة عليه.

يمكنك تجريبه على جهازك كالتالي:

$ git clone gituser@example.com:/opt/jupiter.git jupiter.clone
Cloning into 'jupiter.clone'...
Warning: you appear to have cloned an empty repository.

تذكر أنه يجب على المطورين إدخال مفتاح SSH العام الخاص بهم في ملف authorized_keys الخاص بمستخدم جيت، أو إذا كان لديهم حسابات على الخادم مثلك، فيجب أن يكونوا أعضاء في مجموعة مستخدم جيت.

خطافات جيت git hooks

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

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

$ mkdir jupiter
$ cd jupiter
$ git init

ثم أنشئ خطاف جيت يعرض الرسالة "hello world":

$ echo "#\!/bin/tcsh" > .git/hooks/post-commit
$ echo "echo 'POST-COMMIT SCRIPT TRIGGERED'" >> \
~/jupiter/.git/hooks/post-commit
$ chmod +x ~/jupiter/.git/hooks/post-commit

والآن اختبره:

$ echo "hello world" > foo.txt
$ git add foo.txt
$ git commit -m 'first commit'
! POST-COMMIT SCRIPT TRIGGERED
[master (root-commit) c8678e0] first commit
1 file changed, 1 insertion(+)
create mode 100644 foo.txt

والآن أصبح لدينا خطاف جاهز ونشط.

خطاف الدفع إلى الويب

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

متغيرات جيت

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

لا يتم تشغيل خطافات جيت من خلال المستخدم مباشرةً، لذا قد تكون معرفة كيفية جمع المعلومات المهمة أمرًا محيرًا. حقيقةً، يشبه خطاف جيت أي نص برمجي آخر، حيث يستلم المعطيات من مجرى الدخل القياسي stdin بنفس طريقة باش BASH وبايثون Python وسي بلس بلس C++‎ وأي لغة أخرى. الفرق هو أننا لا نقدم هذه المدخلات بأنفسنا، لذا لاستخدامها عليك أن تعرف ما يمكن توقعه.

قبل إنشاء خطاف جيت، انظر إلى العينات التي يوفرها جيت في مجلد ‎.git/hooks‎ الخاص بمشروعك مثل ملف pre-push.sample، وانظر إلى ما ينصّه في قسم التعليقات:

# $1 -- اسم المستودع البعيد الذي يتم إجراء عملية دفع إليه
# $2 – للمستودع البعيد URL عنوان 
# إذا تمت عملية الدفع من دون استخدام اسم المستودع البعيد، فإن هذه المعطيات ستكون متساوية
# يتم توفير معلومات تتعلق بالإيداع كما يلي
# <local ref> <local sha1> <remote ref> <remote sha1>

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

مثال عن الخطافات التي تنجز مهام محددة بناءً على الفرع المُتأثر

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

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

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

#!/bin/tcsh

foreach arg ( $< )
  set argv = ( $arg )
  set refname = $1
end

تقرأ حلقة for-loop هذه المُعطى الأول $1، ثم تعيد التكرار من أجل استبداله بالمُعطى الثاني ‎$2، ثم مرة أخرى من أجل المعطى الثالث ‎$3. هناك طريقة أفضل للقيام بذلك في باش Bash، عن طريق استخدام الأمر read ووضع القيم في مصفوفة.

عندما يكون لدينا اسم المرجع refname للشيء الذي يتم إيداعه، يمكننا استخدام جيت لاكتشاف اسم الفرع المقروء:

set branch = `git rev-parse --symbolic --abbrev-ref $refname`
echo $branch #DEBUG

بعد ذلك وازن اسم الفرع بالكلمات المفتاحية التي نريد أن نبني الإجراء عليها:

if ( "$branch" == "master" ) then
  echo "Branch detected: master"
  git \
    --work-tree=/path/to/where/you/want/to/copy/stuff/to \
    checkout -f $branch || echo "master fail"
else if ( "$branch" == "dev" ) then
  echo "Branch detected: dev"
  Git \
    --work-tree=/path/to/where/you/want/to/copy/stuff/to \
    checkout -f $branch || echo "dev fail"
  else
    echo "Your push was successful."
    echo "Private branch detected. No action triggered."
endif

الآن نحوّل الشيفرة البرمجية إلى ملف تنفيذي:

$ chmod +x ~/jupiter/.git/hooks/post-receive

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

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

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

سوف نتعلم في المقال التالي والأخير من هذه السلسلة كيفية استخدام جيت لإدارة الكائنات الثنائية غير النصية، مثل ملفات الصوت والرسومات.

ترجمة -وبتصرف- للمقال How to build your own Git server لصاحبه Seth Kenlon.

اقرأ أيضًا

• المقال التالي: كيفية إدارة الكائنات الثنائية Binary Blobs باستخدام جيت Git
• المقال السابق: أدوات رسومية للأداة سطر الأوامر جيت git
• بدء العمل مع نظام إدارة الإصدارات جيت Git
• إنشاء أول مستودع لك من خلال جيت Git
• الدليل المرجعي للعمل على نظام غيت Git

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

استخدام جيت في كيدي دولفين KDE Dolphin

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

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

لتفعيل إضافة جيت، انتقل إلى قائمة الإعدادات Settings في أي نافذة لدولفين واختر ضبط دولفين Configure Dolphin، ثم انقر فوق أيقونة الخدمات Services في العمود الأيسر، ثم ابحث ضمن قائمة المكونات الإضافية المتاحة حتى تجد جيت.

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

الآن عند النقر بزر الفأرة الأيمن داخل مستودع جيت ستجد العديد من الخيارات، مثل تنفيذ عمليات checkout أو push أو pull، وحتى تنفيذ عمليات git add و git remove على ملفاتك.

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

سباركل شير SparkleShare

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

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

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

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

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

بإمكان سباركل شير العمل مع مشاريع جيت ذاتية الاستضافة، أو المشاريع المستضافة على خدمات جيت العامة مثل جيت هاب GitHub وبيت بوكيت BitBucket، ولتتمكن من الوصول الكامل لمشروعك، غالبًا ستحتاج إلى استخدام مُعرّف العميل Client ID الذي تمنحك إيّاه سباركل شير، وهو مفتاح SSH يعمل كمفتاح مصادقة مع الخدمة التي تستخدمها لاستضافة مشروعك، وهذا يشمل أيضًا خادم جيت الخاص بك والذي يجب أن يستخدم أيضًا المفتاح SSH بدلًا من تسجيل الدخول باستخدام كلمة المرور. إذًا انسخ معرّف العميل ضمن ملف authorized_hosts المخصص لك كمستخدم لجيت على الخادم، أو في لوحة مفاتيح SSH لمضيف جيت الذي تستخدمه.

بعد إعداد المضيف الذي تريد استخدامه، يُحمّل سباركل شير مشروع جيت، كما يوفر لك إمكانية تنزيل سجل الإيداعات حسب اختيارك، ويمكنك رؤية الملفات في "SparkleShare/~".

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

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

جيت-كولا Git-Cola

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

من ميزات هذا التطبيق هي التركيز، فربما أنت لا تهتم بكل ملفات مشروعك البالغ عددها 125، حيث أنك تهتم فقط بعدد محدد منها ولنقل 3 ملفات فقط، لذلك يكون من الجيد وضع الملفات الأكثر أهمية في المقدمة.

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

إن أكثر البرامج متعددة المنصات Cross-platform وأكثرها قابلية للتكوين هو تطبيق جيت-كولا مفتوح المصدر الذي كُتِب بلغة Python و Qt.

إذا كنت تستخدم نظام لينوكس، فقد يكون جيت-كولا في مستودع البرامج لديك، وإلا نزِّله من الموقع وثبته على نظامك:

$ python setup.py install 

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

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

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

عمومًا، أيًّا كان تصميمك، فما يلي هو شرح للمكونات التي تظهر في واجهة جيت-كولا:

تظهر التغييرات في لوحة الحالة Status panel. انقر بزر الفأرة الأيمن فوق إدخال تغيير، أو حدد ملفًا وانقر فوق الزر Stage في لوحة الإجراءات Action، لجعل الملف ملفًا مرحليًّا (ملف مُدرج).

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

في أي وقت يمكنك مراجعة التغييرات من لوحة Diff، وعندما تكون جاهزًا للإيداع أدخل رسالة الإيداع وانقر فوق الزر "Commit".

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

جيت أو الواجهات الرسومية لجيت؟

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

سنتعلم في المقال التالي كيفية إعداد خادم جيت وإدارته، وهذا يشمل آلية وصول المستخدم والإدارة، وتشغيل البرمجيات المخصصة.

ترجمة -وبتصرف- للمقال 3 graphical tools for Git لصاحبه Seth Kenlon.

اقرأ أيضًا

• المقال التالي: كيفية بناء خادم جيت لـ Git
• المقال السابق: كيفية استعادة إصدارات الملفات القديمة في جيت Git
• مدخل إلى نظام التحكم في النسخ Git
• الأسئلة العشرة الأكثر تكرارا حول Git

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

يتم تحديد مكان تواجدك في سجل المشروع من خلال مؤشر يُسمى الرأس HEAD، وللانتقال عبر السجل الزمني لمشروعك، يجب عليك تحريك هذا الرأس ليشير إلى المكان الذي تريد، وهذه العملية تتم من خلال الأمر git checkout. هناك طريقتان لاستخدام هذا الأمر، الأولى هي استعادة ملف من خلال العودة إلى إيداع سابق (استعادة الملف إلى الحالة التي تم إيداعه بها في وقت سابق)، والثانية هي الانتقال إلى فرع آخر.

استعادة ملف في مستودع git

كثيرة هي السيناريوهات التي قد تؤول بنا إلى الحاجة إلى استعادة حالة حُفِظ فيها الملف في نقطة زمنية سابقة؛ على سبيل المثال أثناء عملنا على أحد الملفات وتحقيقنا تقدمًا جيدًا للغاية في العمل عليه، ثم إضافته ثم إيداعه، ثم بعد شرب فنجان شاي وأخذ قسط من الراحة نستنتج أننا بحاجة إلى تعديل آخر، وخلال إجراء هذا التعديل نلاحظ أن ما فعلناه كان عبثًا، فنندم وتؤول بنا الحاجة إلى استعادة الملف إلى حالته السابقة (قبل هذه الفوضى)، وهنا يأتي دور الأمرgit checkout، حيث يتجلى الحل بالعودة إلى آخر إيداع نفذته، وفي هذه الحالة فهو يمثل الرأس:

$ git checkout HEAD filename

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

$ git log --oneline

سيكون الخرج:

79a4e5f bad take
f449007 The second commit
55df4c2 My great project, first commit.

إن أردت الانتقال إلى الإيداع الأول ذي المعرف 55df4c2 فنفذ ما يلي:

$ git checkout 55df4c2 filename

الآن، بفرض أنك استعدت الإصدار الأقدم من الملف إلى موقعك الحالي (بإمكانك الاطلاع على موقع الحالي من خلال الأمر git status)، فستحتاج إلى إضافة الملف، ثم إيداعه لأنه تغير.

$ git add filename
$ git commit -m 'restoring filename from first commit.'

يمكنك الآن أن تبحث في سجل جيت للتحقق مما فعلته:

$ git log --oneline
d512580 restoring filename from first commit
79a4e5f bad take
f449007 The second commit
55df4c2 My great project, first commit.

العودة في الخط الزمني

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

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

$ git log --oneline
d512580 restoring filename from first commit
79a4e5f bad take
f449007 The second commit
55df4c2 My great project, first commit.

$ git checkout 55df4c2

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

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

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

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

لإنشاء فرع جديد في جيت والانتقال إليه، يمكنك استخدام الأمر التالي:

$ git checkout -b remix
Switched to a new branch 'remix'

أو يمكنك استخدام الكود التالي لإنشاء فرع جديد، لكن دون الانتقال إليه:

git branch <branch-name>

بذلك تكون قد أنشأت الفرع الجديد، لكنك تبقى في الفرع الأساسي، وفي حال أردت الانتقال إلى الفرع الجديد، استخدم الأمر:

git checkout <branch-name>

يمكنك أيضًا إنشاء فرع جديد، من فرع آخر (أي ليس من الفرع الحالي)، من خلال الأمر:

git checkout -b <new-branch-name> <from-branch-name>

الآن في حال رأيت أن فكرتك الثانية أو أن النهج الجديد فاشل، يمكنك العودة ببساطة إلى الفرع الرئيس:

$ git checkout master

أما إذا رأيت أنها تعطي نتائج أفضل، فعد إلى فرعك الرئيس وادمجها ضمنه:

$ git checkout master
$ git merge remix

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

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

العمل على المستودعات البعيدة

أصبحت تعرف الآن كيفية الاحتفاظ بالمستودع على جهازك المحلي والتعامل معه، ولكن ماذا عن استخدامه عندما تعمل مع المساهمين الآخرين؟

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

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

يتضمن التعاون مع الآخرين إدارة هذه المستودعات البعيدة ودفع البيانات Push وسحبها pull منها وإليها عندما تحتاج إلى مشاركة العمل. تتضمن إدارة المستودعات البعيدة معرفة كيفية إضافة مستودعات بعيدة، وإدارة مختلف الفروع البعيدة وتعريفها على أنها متتبعة أم لا، وغيرها العديد من الأمور الأخرى.

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

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

عندما تقوم بنسخ مستودع مع أذونات قراءة وكتابة من مصدر آخر، فإن نسختك ترث المستودع البعيد كما هو كاملًا، وسيكون الاسم الافتراضي للمستودع الذي تم تنزيله هو origin، وهو الاسم المختصر الافتراضي الذي يعطيه جيت للخادم الذي نسخت منه المستودع، ويستخدم الاسم المختصر كمرجع للدلالة على المستودع بدلًا من كتابة مساره كاملًا (عنوان URL لذاك المستودع).

يمكننا تغيير اسم المستودع من الأصل origin إلى اسم آخر أيضًا. عادة ما يحتفظ الناس باسم المستودع "الأصل" نفسه، لكن من الضروري تغيير اسم المستودع المحلي (المستودع الذي قمت بتنزيله على جهازك) إذا كان هناك العديد من المستودعات (المشاريع) التي تعمل عليها.

يمكن استخدام الأمر التالي الذي يُظهر مسارات URL التي خزنها جيت للاستخدام عند القراءة من المستودع أو الكتابة فيه، وإن كان لديك أكثر من مستودع بعيد فسيعرضها كلها.

$ git remote --verbose
origin  seth@example.com:~/myproject.Git (fetch)
origin  seth@example.com:~/myproject.Git (push)

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

يمكنك إضافة مستودع جديد باسم مختصر يعد مرجعا للمستودع، من خلال الأمر التالي:

git remote add [shortname] [url]

على سبيل المثال:

$ git remote add seth@example.com:~/myproject.Git

إذا قمت بإجراء تعديلات على الملفات وأردت إرسالها إلى المستودع البعيد ولديك أذونات القراءة والكتابة في المستودع، فاستخدم الأمر git push:

git push [remote-name] [branch-name]

حيث [remote-name] يمثل الفرع على الخادم البعيد و [branch-name] على الخادم المحلي، حيث أنه في المرة الأولى التي تدفع فيها التغييرات يجب عليك أيضًا إرسال معلومات الفرع الخاص بك، ومن الأفضل دومًا عدم العمل على الفرع الرئيسي master، ما لم يُطلب منك القيام بذلك:

$ git checkout -b seth-dev
$ git add exciting-new-file.txt
$ git commit -m 'first push to remote'
$ git push -u origin HEAD

يؤدي هذا إلى دفع موقعك الحالي HEAD والفرع الموجود عليه إلى المستودع البعيد، وبعد أن تقوم بدفع فرعك أول مرة يمكنك الاستغناء عن الخيار ‎-u:

$ git add another-file.txt
$ git commit -m 'another push to remote'
$ git push origin HEAD

دمج الفروع

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

$ git checkout contributor
$ git pull
$ less blah.txt  # review the changed files
$ git checkout master
$ git merge contributor

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

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

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

خاتمة

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

ترجمة -وبتصرف- للمقال How to restore older file versions in Git لصاحبه Seth Kenlon.

اقرأ أيضًا

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

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

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

آلية عمل جيت

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

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

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

الآن بعد أن تعرّفنا على آلية التسجيل الصوتي في السبعينات، يمكننا أن نشبه هذه الآلية بآلية عمل جيت.

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

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

• إنشاء مجلد جديد (يمكنك أيضًا إنشاؤه مباشرةً من خلال واجهة المستخدم الرسومية).
• الانتقال إلى موقع المجلد من خلال الطرفية.
• تهيئته بحيث يصبح مجلدًا يديره جيت.

وهذه هي الأوامر المطلوبة بالترتيب:

$ mkdir ~/jupiter  # make directory
$ cd ~/jupiter     # change into the new directory
$ git init .       # initialise  your new Git repo

الآن أصبح المجلد jupiter عبارة عن مستودع جيت ولكنه فارغ حاليًّا.

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

العمل داخل مستودع جيت هو نفس العمل الذي تنجزه مع أي مجلد آخر؛ بمعنى عمليات إنشاء الملفات أو نسخها داخل المجلد أو حفظ الملفات فيه وغيرها من العمليات الأخرى هي نفسها مع المجلدات العادية، وجيت لا تؤدي أي عملية إلى عندما تستدعيها.

في مستودع جيت المحلي، يمكن أن يكون الملف بإحدى الحالات التالية:

• غير متتبع Untracked: ملفات يتم إنشاؤها في المستودع، ولكن لم تتم إضافتها إلى جيت حتى الآن.
• متتبع Tracked: ملف تمت إضافته إلى جيت.
• مُدرج Staged: ملف مُدرج (أو مرحلي)، أي تم إدراجه تمهيدًا إلى إيداعه في مستودع جيت.

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

جيت يخبرك بالملفات التي يتم تتبعها والتي لا يتم تتبعها من خلال الأمر git status:

$ echo "hello world" > foo
$ git status
On branch master
Untracked files:
(use "git add <file>..." to include in what will be committed)    
    foo    
nothing added but untracked files present (use "git add" to track)

كما تلاحظ، يخبرك جيت أيضًا بكيفية بدء تتبع الملفات.

استخدام جيت من خلال خدمات الويب الشهيرة

إنشاء المستودعات في جيت هاب Github وجيت لاب Gitlab أكثر سهولة، فكل ما عليك فعله هو نقرة على الزر New Repository واتباع التعليمات، ومن الممارسات الجيدة عند إنشاء المستودعات إنشاء ملف README، هذا الملف عبارة عن توضيح للهدف الذي تم إنشاء المستودع من أجله. بالنسبة لنسخ المستودع فلا يختلف الأمر عن المعتاد، لكن الحصول على إذن الكتابة على هذا المستودع في جيت هاب أكثر تعقيدًا إلى حد ما، لأنه من أجل المصادقة على جيت هاب، يجب أن يكون لديك مفتاح SSH.

في حال كنت تعمل على حاسوب مثبت عليه إحدى توزيعات لينوكس، فيمكنك إنشاء مفتاح من خلال الأمر التالي:

$ ssh-keygen

ثم انسخ مفتاحك الجديد، وهو نص عادي يمكنك فتحه في محرر نص عادي، أو استخدام الأمرcat:

$ cat ~/.ssh/id_rsa.pub

الآن الصق مفتاحك في ملف ضبط SSH الخاص بجيت هاب، أو تكوين GitLab الخاص بك.

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

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

الملفات المتتبعة

كما لاحظت منذ قليل عندما استخدمت الأمر git status، فهو يخبرك بضرورة إضافة الملف لكي يبدأ بتتبعه، وذلك من خلال الأمر git add الذي يقوم بوضع الملف في منقطة مرحلية خاصة تنتظر فيها الملفات إلى حين إيداعها، أو الاحتفاظ بها ضمن لقطة snapshot إلى وقت لاحق. الهدف من الأمر git add هو التمييز بين الملفات التي تريد تضمينها في لقطة، والملفات الجديدة أو المؤقتة التي تريد أن يتجاهلها جيت، على الأقل في الوقت الحالي.

بمجرد إضافة ملف، سيتعرف عليه جيت كملف متتبع:

$ git add foo
$ git status
On branch master
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)
new file:   foo

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

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

إذا رأيت أن الملف ليس جاهزًا حقًا ليتم إيداعه (حفظه في سجلات جيت)، فيمكنك حينئذٍ إخراجه من المنطقة المرحلية، تمامًا كما وصفت رسالة جيت التي رأيناها منذ قليل:

$ git reset HEAD foo

إيداع الملفات

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

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

لتنفيذ عملية الإيداع نستخدم الأمر التالي:

$ git commit -m 'My great project, first commit.'

هذا يؤدي إلى حفظ جميع الملفات ضمن نقطة زمنية ثابتة لديها مؤشر مرجعي للرجوع إلى هذا الإيداع (هذه النقطة) في سجل جيت الخاص بك:

$ git log --oneline
55df4c2 My great project, first commit.

للحصول على تقرير مفصل أكثر، يمكنك استخدام الأمر git log دون خيار ‎--oneline.

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

في المقالة التالية، سوف نتعرف على الأمر git head بتفصيل أكبر، وسنكتشف معًا كيفية السفر عبر الزمن في جيت.

ترجمة -وبتصرف- للمقال Creating your first Git repository لصاحبه Seth Kenlon.

اقرأ أيضًا

• المقال التالي: كيفية استعادة إصدارات الملفات القديمة في جيت Git
• بدء العمل مع نظام إدارة الإصدارات جيت Git
• الدليل المرجعي للعمل على نظام غيت Git
• إعداد Git للمرة الأولى

يدير فريق مطوِّري البرامج مفتوحة المصدر والمشرفون عليها مشاريعهم عادةً من خلال نظام غيت، وهو نظام إدارة الإصدارات الموزعة التي تدعم المشاركة.

يقدم لك هذا الدليل المُعَدّ على نمط الورقة المرجعية cheat sheet مرجعًا سريعًا للأوامر التي تفيدك في العمل والمشاركة في مستودع غيت. ولتثبيت نظام غيت وإعداده اِقرأ المقالة "كيف تساهم في المشاريع مفتوحة المصدر: ابدأ بتعلم نظام غيت Git".

إليك بعض الملاحظات قبل البدء بهذا الدليل:

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

الإعداد والتهيئة

تحقَّق من إصدار نظام غيت لديك بالاستعانة بالأمر التالي، والذي سيؤكد أيضًا أن النظام مثبَّتٌ على جهازك:

$ git --version

يتيح لك غيت ضبط بعض الإعدادات، التي تُطبَّق على جميع المستودعات الموجودة على جهازك المحلي. على سبيل المثال، اِضبط اسم مستخدمٍ سيستخدمه غيت ليوثِّق به أية تعديلات تجريها على مستودع محلي:

$ git config --global user.name "firstname lastname"

اضبط عنوان البريد الإلكتروني ليُربَط مع كل علامة سجل محفوظة history marker على النحو التالي:

$ git config --global user.email "valid-email"

اضبط محرر النصوص الذي تفضله أيضًا:

$ git config --global core.editor "nano"

يمكنك تهيئة دليل العمل working directory الحالي على أنه مستودع غيت باستخدام الأمر init على النحو التالي:

$ git init

لنسخ مستودع غيت مُستضاف عن بُعد، ستستخدم الأمر git clone مع عنوان url للمستودع أو موقع الخادم (في حالة إضافة موقع الخادم، ستستخدم الأمر ssh):

$ git clone https://www.github.com/username/repo-name

اِعرض المستودع البعيد لدليل غيت الحالي لديك:

$ git remote

للحصول على خرج مطوَّل verbose، استخدم الراية v- على النحو التالي:

$ git remote -v

أضِف فرع غيت الأولي primary، ,الذي قد يكون عنوان url، أو مُستضافًا على خادم (في هذه الحالة اتصل بالخادم باستخدام الأمر ssh):

$ git remote add upstream https://www.github.com/username/repo-name

التحضير للإدراج

عندما تعدل ملفًا وتضع علامةً عليه للانتقال إلى الإيداع التالي، فإنه يُعد ملفًا مُدرجًا staged. يمكن التحقق من حالة مستودع غيت لديك، بحيث يتضمن الملفات المضافة المُدرجة وغير المُدرجة على النحو التالي:

$ git status

استخدم الأمر add لإدراج الملفات المُعدَّلة، إذ يمكنك تنفيذه عدّة مرات قبل ملف الإيداع؛ وإذا أجريت تعديلات لاحقة تريد إدراجها في الإيداع التالي، عليك تنفيذ الأمر add مجددًا. كما يمكنك تحديد ملفٍ معين في الأمر add على النحو التالي:

$ git add my_script.py

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

$ git add .

إذا أردت إضافة جميع الملفات الموجودة في الدليل الحالي إضافةً إلى الملفات الموجودة في الدلائل الفرعية، فيمكنك استخدام الراية all- أو A-:

$ git add -A

يمكنك إزالة ملف من مرحلة الإدراج مع الاحتفاظ بالتعديلات ضمن دليل العمل الخاص بك باستخدام الأمر reset:

$ git reset my_script.py

الإيداع

بمجرد انتهائك من إدراج التحديثات التي أجريتها، فأنت جاهزٌ لإضافة إيداع، والذي سيسجِّل التعديلات التي أجريتها على المستودع. لإيداع ملفاتٍ مُدرجة، نفِّذ الأمر commit وأضف رسالة إيداعٍ ذات مغزًى حتى تتمكن من متابع الإيداعات:

$ git commit -m "Commit message"

يمكنك اختصار جميع الملفات التي تتابعها من خلال إضافة إيداعٍ لها في خطوةٍ واحدة:

$ git commit -am "Commit message"

يمكنك تعديل رسالة الإيداع بإضافة الراية amend--:

$ git commit --amend -m "New commit message"

الفروع

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

اعرض جميع الفروع الحالية بتنفيذ الأمر branch، إذ ستظهر علامة النجمة (*) بجوار فرعك النشط حاليًا:

$ git branch

أنشئ فرعًا جديدًا. ستبقى في فرعك النشط حاليًا حتى تبدّل إلى الفرع الجديد:

$ git branch new-branch

بدِّل إلى أيّ فرعٍ موجود، وتحقق منه في دليل العمل الحالي لديك:

$ git checkout another-branch

يمكنك دمج عمليتي إنشاء فرع جديد والتحقق منه باستخدام الراية b- على النحو التالي:

$ git checkout -b new-branch

أعِد تسمية فرعك على النحو التالي:

$ git branch -m current-branch-name new-branch-name

ادمج سجلات الفرع المحدد مع الفرع الذي تعمل فيه حاليًا:

$ git merge branch-name

بإمكانك إلغاء عملية الدمج في حال وجود تعارضات على النحو التالي:

$ git merge --abort

كما يمكنك تحديد إيداعٍ معيّن لدمجه باستخدام الأمر cherry-pick وكتابة سلسلة المحارف التي تشير إلى ذلك الإيداع:

$ git cherry-pick f7649d0

عندما تدمج فرعًا ولم تعد بحاجة إليه، يمكنك حذفه على النحو التالي:

$ git branch -d branch-name

إذا لم تدمج فرعًا مع الفرع الرئيسي، لكنك متأكد من رغبتك في حذفه، فيمكنك فرض حذف الفرع:

$ git branch -D branch-name

المشاركة والتحديث

يمكنك استخدام الأمر fetch لتنزيل التعديلات من مستودع آخر، مثل المستودع الأوّلي البعيد على النحو التالي:

$ git fetch upstream

يُستخدم الأمر التالي لدمج الإيداعات التي جلبناها fetched. تذكر أن بعض المستودعات قد تستخدِم master بدلاً من main:

$ git merge upstream/main

ومن أجل دفع أو نقل إيداعات الفرع المحلي إلى فرع المستودع البعيد، استخدم الأمر التالي:

$ git push origin main

ولجلب ودمج أية إيداعات من فرع المتابعة tracking البعيد:

$ git pull

الفحص Inspecting

اِعرض سجل الإيداع للفرع النشط حاليًا:

$ git log

اِعرض الإيداعات التي عدَّلت ملفًا معينًا، إذ يتبَع هذا العرض الملف بغض النظر عن إعادة التسمية:

$ git log --follow my_script.py

اعرض الإيداعات الموجودة في فرعٍ محدد وليست موجودة في الفرع الآخر، إذ سيعرض الأمر التالي الإيداعات في الفرع a-branch وغير الموجودة في الفرع b-branch:

$ git log a-branch .. b-branch

اطلع على السجلات المرجعية reflog لتعرف آخر مرةٍ حُدِّث فيها أحدث إيداعٍ في الفروع والمراجع الأخرى ضمن المستودع:

$ git reflog

اعرض أي كائنٍ في غيت من خلال سلسلة محارف إيداعه أو القيمة المعمَّاة Hash بصياغةٍ قابلة للقراءة على النحو التالي:

$ git show de754f5

عرض التغييرات

يعرض الأمرgit diff الفروقات بين الإيداعات والفروع وغيرها. يمكنك الاطلاع على المزيد عنها من خلال قراءة توثيق غيت. يُستخدم الأمر التالي لموازنة الملفات المُعدّلة الموجودة في مرحلة الإدراج:

$ git diff --staged

اعرض التغييرات على ما هو موجود في الفرع a-branch وغير الموجود في الفرع b-branch على النحو التالي:

$ git diff a-branch .. b-branch

اِعرض التغييرات بين إيداعين محدّدين على النحو التالي:

$ git diff 61ce3e6 .. e221d9c

تتبع مسار التغييرات من خلال حذف ملف من مشروعك ونظِّم هذا الحذف لإضافته إلى إيداع على النحو التالي:

$ git rm file

أو غيِّر مسار ملفٍ موجود، ثم نظِّم الانتقال:

$ git mv existing-path new-path

تحقَّق من سجل الإيداع لتعرف ما إذا نُقلت أية مسارات:

$ git log --stat -M

الإخفاء Stashing

ستجد أحيانًا نفسك بعد إجراء بعض التعديلات على جزءٍ من الشيفرة البرمجية وقبل الانتهاء مضطرًا إلى بدء العمل على أمرٍ آخر، وأنت لست مستعدًا لاعتماد التعديلات التي أجريتها حتى الآن، لكنك لا تريد أن يضيع عملك. في هذه الحالة، سيتيح لك الأمر git stash حفظ تعديلاتك المحلية في مكان ما والعودة مرةً أخرى إلى دليل العمل الذي يتوافق مع أحدث إيداع HEAD وتدعى هذه العملية بعملية الإخفاء أو الادخار stashing. لإخفاء عملك الحالي:

$ git stash

اطلِّع على ما اخفيته حاليًا:

$ git stash list

تُسمى الأعمال المُخبأة كما يلي: {stash@{0، و {stash@{1 وهكذا. لعرض معلومات عن عملٍ مُخبأ stash معين:

$ git stash show stash@{0}

أضف apply لاستخراج الملفات الموجودة في عملٍ مُخبأ حالي منه مع الاحتفاظ به:

$ git stash apply stash@{0}

إذا أردت استخراج الملفات من العمل المُخبأ ولم تعد بحاجته، أضف pop:

$ git stash pop stash@{0}

إذا لم تعد بحاجة الملفات المحفوظة في ملفٍ مُخبأ معين، أضف drop لإلغائه:

$ git stash drop stash@{0}

إذا كان لديك عدة أعمال مُدخرة محفوظة لم تعد تحتاج إلى استخدام أيٍّ منها، أضِف clear لإزالتها:

$ git stash clear

تجاهل الملفات

إذا أردت الاحتفاظ بالملفات في دليل غيت المحلي لديك لكنك لا تريد إضافة إيداعٍ لهم إلى المشروع، أضِف هذه الملفات إلى ملف "gitignore." لديك حتى لا تتسبب بأية تعارضات.

استخدم محرر نصوص مثل نانو، لإضافة الملفات إلى ملف "gitignore." على النحو التالي:

$ nano .gitignore

إذا أردت أن تجد نماذج لملفات "gitignore."، اطلع على مستودع قالب gitignore. لموقع غيت هَب GitHub.

إعادة تأسيس الفروع

تتيح لنا عملية إعادة التأسيس Rebase نقل الفروع من خلال تغيير الإيداع المبنية عليه، كما تتيح لك إزالة squash الإيداعات أو إعادة صياغتها.

يمكنك بدء عملية إعادة التأسيس، إما باستدعاء عدد الإيداعات التي أنشأتها وتريد إعادة تأسيسها (العدد هو 5 في مثالنا التالي):

$ git rebase -i HEAD~5

أو يمكنك إعادة التأسيس بالاعتماد على سلسلة محارف إيداع معين أو القيمة المُعمَّاة Hash:

$ git rebase -i 074a4e5

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

$ git rebase upstream/main

لتتعلم المزيد عن إعادة التأسيس والتحديث اقرأ كيف تعيد تأسيس طلب سحب وتحدِّثه الذي يمكن تطبيقه على أي نوع إيداعٍ تريده.

التراجع وإعادة الضبط

يمكنك التراجع عن التعديلات التي أجريتها على إيداعٍ معين باستخدام الأمر revert، إذ يجب أن تكون شجرة العمل نظيفةً حتى يتحقق ذلك:

$ git revert 1fc6665

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

$ git reset --hard 1fc6665

لفرض دفع push أحدث إيداعٍ معروف وغير متعارض لديك إلى المستودع الأصلي، عليك استخدام force-- على النحو التالي:

$ git push --force origin main

اقتباس

تحذير: تكون عملية فرض الدفع إلى الفرع الرئيسي main (الأساسي master أحيانًا) غالبًا غير محبَّذة ما لم يكن لديك سببٌ وجيهٌ فعلًا لتنفيذها؛ لذلك استخدمها بحذر عند العمل على مستودعاتك الخاصة، واعمل على تجنُّبها عندما تشارك في عملٍ ما.

لإزالة الملفات والدلائل الفرعية غير المتتبعة من دليل غيت للحصول على فرع عملٍ نظيف، استخدم الأمر git clean:

$ git clean -f -d

إذا أردت تعديل مستودعك المحلي ليبدو مثل الفرع الرئيسي الأولي الحالي (أي عندما توجد كثيرٌ من التعارضات)، يمكنك تنفيذ استعادة الإعدادات الأصلية hard reset على النحو التالي:

$ git reset --hard upstream/main

ملاحظة: سيجعل تنفيذ هذا الأمر مستودعك المحلي يبدو تمامًا مثل الفرع الأولي، وستُتلف أية إيداعات أنشأتها ولم تسحبها إلى الفرع الأولي.

الخاتمة

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

توجد العديد من الأوامر التي قد تجدها مفيدةً لعملك على غيت. لمعرفة المزيد حول جميع الخيارات المتاحة لك، يمكنك تنفيذ الأمر التالي للحصول على معلومات مفيدة:

$ git --help

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

ترجمة -وبتصرف- للمقال How To Use Git: A Reference Guide لصاحبته Lisa Tagliaferri.

اقرأ أيضًا

• [فيديو] أساسيات Git
• مدخل إلى نظام التحكم في النسخ Git
• مبادئ Git الأساسية
• إعداد Git للمرة الأولى
• أساسيات سير عمل نظام التحكم في النسخ git

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

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

القراءة والكتابة

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

سنتحدث في مقالتنا هذه عن القراءة من المستودع فقط، ونغطي الكتابة في مقال آخر.

جيت أم جيت هاب؟

جيت ليس نفسه جيت هاب GitHub أو جيت لاب GitLab أو بت باكت Bitbucket، جيت هو برنامج سطر أوامر command-line، وهو يبدو كالتالي:

$ git
usage: Git [--version] [--help] [-C <path>]
  [-p | --paginate | --no-pager] [--bare]
  [--Git-dir=<path>] <command> [<args>]

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

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

تثبيت جيت

جيت يأتي مثبت مع جميع توزيعات لينوكس الأساسية، حيث يمكنك أن تجده ضمن مستودع البرامج software repository (بالنسبة لمستخدمي توزيعة BSD، فهو موجود ضمن شجرة المنافذ Ports tree ضمن قسم devel). عمومًا، يمكنك تثبيته باستخدام مدير حزم لينكس توزيعات ديبيان من خلال الأمر التالي:

$ sudo apt install git

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

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

الوصول إلى جيت

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

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

لنفترض أنك تريد تثبيت سلة المهملات Trash-Bin لاستخدامها في الطرفية Terminal، وذلك لأنك لسوء الحظ تتعرض كثيرًا لحالات مثل حذف ملفات عن طريق الخطأ أو مثلًا كنت تريد حذف بعض الملفات فقط من مجلد ولكنك حذفت الملفات عن طريق الخطأ من المجلدات الفرعية أيضًا، وذلك من خلال الأمر rm.

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

تنويه: لحسن الحظ يتم استضافة Trashy على غيت لاب بشكل افتراضي، ويمكنك الاطلاع عليها من هنا.

تحميل مستودع جيت بالكامل و تخزينه على جهازك

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

لجلب كامل المستودع من خلال جيت، نستخدم الأمر git clone إضافةً إلى تحديد عنوان URL لمستودع جيت المطلوب الحصول عليه، وفي حال لم تكن متأكدًا من عنوان المستودع، فيمكنك التأكد من العنوان من الصفحة الرئيسية للمستودع، حيث يكون معروضًا هناك.

على سبيل المثال، عنوان URL لمستودع Trashy من جيت لاب يكون معروضًا كما يلي:

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

قد تلاحظ أنه في بعض الخدمات يتم توفير روابط SSH و HTTPS، لذا تجدر الملاحظة إلى أنه لا يمكنك استخدام روابط SSH إلا إذا كان لديك وصول SSH إلى المضيف (تمكّن العديد من خدمات الاستضافة لجيت استخدام هذه الروابط من خلال السماح لك بتحميل مفتاح SSH العام الخاص بك)، وإلا يجب عليك استخدام عنوان URL الخاص ببروتوكول HTTPS فقط.

بعد الحصول على عنوان URL، يصبح موضوع استنساخ المستودع بسيطًا، فكل ما عليك فعله هو استخدام الأمر git clone متبوعًا بالعنوان، كما يمكنك أيضًا (إذا أحببت) تحديد مجلد لوضعه فيه.

افتراضيًا، يتم نسخ مجلد جيت إلى مجلدك الحالي؛ على سبيل المثال، يتم وضع 'trashy.git' في مجلدك الحالي باسم 'trashy'. بالنسبة لي، أنا استخدم الامتداد .clone كاختصار للمستودعات التي يمكن قراءتها فقط، و .git للمستودعات التي يمكن قراءتها والكتابة عليها، ولكن هذا يعود لك، فهو لا يمثل قاعدة رسمية.

$ git clone https://gitlab.com/trashy/trashy.git trashy.clone
Cloning into 'trashy.clone'...
remote: Counting objects: 142, done.
remote: Compressing objects: 100% (91/91), done.
remote: Total 142 (delta 70), reused 103 (delta 47)
Receiving objects: 100% (142/142), 25.99 KiB | 0 bytes/s, done.
Resolving deltas: 100% (70/70), done.
Checking connectivity... done.

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

الطريقة الثانية لجلب نسخة من المستودع هي من خلال واجهة الويب، حيث يوفر كل من جيت هاب وجيت لاب لقطات لأي مستودع على هيئة ملفات بامتداد ‎.zip“‎” أي ملفات مضغوطة.

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

الحصول على ملف محدد من مستودع جيت

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

تكمن مشكلة استخدام هذه الطريقة في أنك قد تجد أن بعض الملفات غير موجودة ضمن مستودع جيت في الحالة الخام Raw (أي بدون تنزيله وبنائه)، حيث قد يكون الملف موجودًا بشكل كامل فقط بعد تنفيذ أمر make لبناء الملف، وهو الأمر الذي لن يحدث حتى تقوم قم بتنزيل المستودع، وقراءة ملف README أو INSTALL، ثم تنفيذ أوامر التثبيت والبناء. عمومًا، إذا كنت متأكدًا من وجود الملف يمكنك القيام بهذه العملية دون الحاجة لتنزيل المستودع.

في GitLab و GitHub، انقر فوق روابط الملفات Files لعرض الملف، واعرض الملف في الحالة الخام Raw، ثم احفظه من خلال متصفح الويب الذي تستخدمه، على سبيل المثال في Firefox نختار File ثم Save Page As.

في مستودع GitWeb، يكون هناك رابط للعرض بالحالة الخام Raw ضمن قائمة الملفات.

أفضل الممارسات

يمثل نسخ مستودع جيت بأكمله الطريقة الصحيحة للتفاعل مع جيت، وذلك لعدة أسباب، أولها سهولة تحديث النُسخ (الإصدارات) باستخدام الأمر git pull، حيث أنك لن تضطر في هذه الحالة إلى العودة إلى موقع الويب في كل مرة تحتاج فيها إلى الحصول على نسخة جديدة من الملف عندما يتم إجراء تحسين عليها.

السبب الثاني يتجلى في حالة إجراء تحسينات أو تعديلات بنفسك، حيث سيكون من الأسهل إرسال هذه التعديلات إلى مؤلفها الأصلي في حال كان كل شيء جيد ومرتب في مستودع جيت.

بدايةً، سيكون من الجيد لك التدرب على نسخ مستودعات جيت من الإنترنت إلى حاسوبك كما تعلمنا، وفي حال لم تكن تعرف كيفية استخدام الطرفية Terminal جيدًا، فتابع الفقرة التالية.

أساسيات الطرفية

بدايًة، يجب أن تضع في ذهنك أن جميع الملفات على جهاز الحاسوب لها مسار “path.“ لنفرض الآن أنك تريد فتح ملف بالطريقة الاعتيادية، وليكن اسم الملف monkey، في هذه الحالة يتوجب عليك الذهاب إلى موقع الملف، وهذا يتضمن التنقل بين عدة مجلدات وصولًا إلى موقع الملف، على سبيل المثال الذهاب إلى المجلد HOME ثم Pictures وأخيرًا المجلد InktoberSketches الذي يتضمن الملف monkey المطلوب، وبالتالي يكون مسار الملف المطلوب هو:

$HOME/Pictures/InktoberSketches/monkey.kra

عموماً، تبدأ جميع مسارات الملفات بالمجلد ‎$HOME“‎” (أو إذا أردت يمكنك استبدالها بالمؤثر ~) متبوعة بقائمة من المجلدات وتنتهي باسم الملف المطلوب.

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

$ git clone https://gitlab.com/foo/bar.git $HOME/Documents/bar.clone

بعد تنفيذ هذا الأمر، يمكنك الذهاب إلى مجلد المستندات، وستجد مجلد “bar.clone“ فيها.

يمكنك بعد ذلك زيارة هذا المستودع في وقت لاحق، واستخدام الأمر git pull لمعرفة ما إذا كانت هناك تحديثات للمشروع:

$ cd $HOME/Documents/bar.clone
$ pwd
bar.clone
$ git pull

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

ترجمة -وبتصرف- للمقال Getting started with Git لصاحبه Seth Kenlon.

اقرأ أيضًا

• المقال التالي: إنشاء أول مستودع لك من خلال جيت Git
• الدليل المرجعي للعمل على نظام غيت Git
• مبادئ Git الأساسية
• إعداد Git للمرة الأولى
• مدخل إلى نظام التحكم في النسخ Git

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

هذا المقال جزء من سلسلة مقالات حول جيت Git، وإليك روابط جميع المقالات ضمن هذه السلسلة:

1. ماهو جيت git؟
2. بدء العمل مع نظام إدارة الإصدارات جيت
3. إنشاء أول مستودع لك من خلال جيت
4. كيفية استعادة إصدارات الملفات القديمة في جيت
5. ثلاث أدوات رسومية للأداة جيت
6. كيفية بناء خادم جيت
7. كيفية إدارة الكائنات الثنائية Bainary Blobs باستخدام جيت

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

لذا انسَ ما تعرفه أو ما تعتقد أنك تعرفه عن جيت، ودعنا نتعرف عليه من البداية.

ما هو نظام إدارة الإصدار؟

بدايةً يجب أن نعلم أن جيت هو نظام إدارة الإصدار (وتسمى أيضًا "إدارة النُسخ") version control system واختصارًا VCS. هناك العديد من أنظمة التحكم في الإصدار: مثل CVS و SVN و Mercurial و Fossil وبالطبع جيت.

يُمثل جيت اللبنة الأساسية للعديد من الخدمات، مثل جيت هاب GitHub وجيت لاب GitLab، ولكن يمكنك استخدام جيت لوحدها، أي بعيداً عن أي خدمة.

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

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

عند التعامل مع المشاريع العلمية أو حتى الفنية عادةً ما يتم تطوير نسخة تجريبية من شيء ما؛ نسخة أولى وثانية وثالثة و بمسميات مختلفة مثل project_justTesting.kdenlive و project_betterVersion.kdenlive، و project_best_FINAL.kdenlive وهكذا حتى نصل إلى النُسخة النهائية الأفضل.

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

لقطات Git

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

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

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

أوامر غيت

جيت هي الأداة السائدة للتحكم في الإصدار هذه الأيام. إليك كيفية استخدام هذه الأداة بشكل فعال.

الأساسيات - عند العمل مع جيت بمفردك أو مع الآخرين

إليك أهم الأوامر الأساسية من أوامر غيت يليها شرحها:

git status

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

git diff

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

يمكنك أن تستخدم مع هذا الأمر الراية ‎--name-only لرؤية أسماء الملفات التي تم تغييرها.

git add

يستخدم لإدراج تعديلات على الملفات المتتبعة وغير المتتبعة.

git commit

يستخدم لإنشاء إيداع جديد يتضمن التغييرات التي أضفتها، وتشبه نقطة الحفظ في الألعاب Save Point حيث يمكن من خلالها العودة إلى نسخة معينة تم الحفظ عندها. في حال أردت إرفاق عملية الإيداع برسالة توضيحية (تسمى رسالة الإيداع) استخدم ‎-m وأضف رسالة ذات معنى معبر.

git push

لإرسال التغييرات إلى المستودع البعيد الذي تم إنشاؤه (من الشائع استخدامه أكثر مع GitLab أو GitHub).

رايات flags مهمة - للحفاظ على كل شيء منظما

git reset HEAD --

يؤدي إلى إزالة كل التغييرات التي لم يتم إيداعها والعودة إلى آخر إيداع، وهذا ما يشير إليه HEAD، وبتعبير أدق فإن HEAD هو مؤشر يشير دائمًا إلى الإيداع الحالي، وقد ينتمي أو لا ينتمي أحيانًا إلى الفرع الحالي.

git add -u

يستخدم لإدراج الملفات المحدثة فقط، والتي تم إيداعها مسبقًا.

git log --graph
--pretty=oneline
--abbrev-commit

لتأريخ الفرع بشكل أرتب وأجمل أنشئ قشرة shell أو استخدم الاختصارات Aliases (الأمر git alias) لتسهيل الوصول، على سبيل المثال git lg.

العمل مع مستودع بعيد

إليك أهم الأوامر يليها شرحها:

git fetch --all

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

git pull --rebase <remote><branch>

يستخدم لدمج جميع الإيداعات بدءًا من آخر إيداع مشترك لك من الفرع البعيد دون إنشاء إيداع دمج.

git stash

يستخدم لحفظ التغييرات التي لم يتم إيداعها محليًا (المرحليّة وغير المرحليّة) مما يسمح لك بإجراء التغييرات وتبديل الفروع وتنفيذ أوامر جيت الأخرى.

git stash pop

لإعادتها، حيث أن pop يزيل التغييرات من stash ويعيد تطبيقها على نسخة العمل.

gi t add [-A or . or -- <filename>]

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

git commit -m "commit message"

تم شرحه مسبقًا.

git push origin <branch>

دفع الفرع الحالي إلى المستودع البعيد الذي يحمل العنوان "origin" والفرع المسمى branch.

git checkout -b <new_branch>

اختصار:

git branch

والأمر:

git checkout

وهو أمر مفيد عندما تريد تجربة فكرة ويكون لديك فرع جديد لتجربتها فيه ويمكن دمجها أو حذفها لاحقًا.

git checkout master && git pull --rebase

يستخدمان في حال أردنا الوصول إلى أحدث إيداع في مشروع لا تتابعه إلا نادرًا.

git reset --hard origin/master

يستخدم عند الحاجة إلى الوصول إلى حالة معروفة.

تنبيه: يؤدي هذا إلى مسح جميع التغييرات، حتى الإيداعات، بدءًا من الإيداع الأخير و وصولًا إلى المستودع البعيد origin في الفرع master.

git push origin master

عندما تُجري بعض العمليات الصحيحة، يمكنك استخدامه لإرسال تغييراتك إلى المستودع البعيد المسمى origin في الفرع master.

تعليمات الحصول على المساعدة

git <cmd> -h

لمراجعة مختصرة للرايات الخاصة بالأمر المحدد.

git <cmd> --help

لمشاهدة جميع الخيارات المتاحة للأمر المحدد.

الفروع الأساسية

تمثل الفروع سلسلة من الارتباطات وإليك أهم الأوامر للتعامل معها يليها شرحها:

git branch --all

قائمة بجميع الفروع المحلية والبعيدة.

git checkout <branch>

التبديل إلى فرع موجود.

git checkout -b <branch> master

إنشاء فرع قائم على الفرع master ثم الانتقال إليه.

git checkout master && git merge <branch>

دمج التغييرات في الفرع master.

سلسلة أوامر: سلسلة أوامر نستخدمها بشكل يومي مع غيت

استخدم الأمر cd للانتقال إلى مشروعك المحلي الذي تريد بدء إصداره باستخدام (المجلد الذي يحتوي ملفات المشروع على جهازك).

بعد ذلك كل ما عليك فعله هو تنفيذ الأمرgit init لأول مرة لإعداد المجلد وتتبع الإصدار:

git init
git status
git add --all
git status
git commit -m "meaningful initial commit message"
git show

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

git diff
git commit -a -m "Another commit message. -a performs the add step for you"
git status
git log --graph --pretty=oneline --abbrev-commit

بعد فترة، قد يصبح لديك 3 إيداعات، وبالتالي سيكون من الأفضل اعتبارها إيداعًا واحدًا:

git log --graph --pretty=oneline --abbrev-commit
git reset --soft HEAD~3
git diff --cached
git commit -a -m "Better commit message for last 3 commits"

وأخيرًا ، ربما تحتاج لحذف بعض الملفات غير الضرورية في المجلد الحالي:

git status
git diff --cached
git add -u
git commit -m "Another commit message. -u adds updates, including deleted files"
git status
git log --graph --pretty=oneline --abbrev-commit
git push origin master

التطوير الموزع باستخدام جيت

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

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

إذًا لن يكون هناك أي التباس حول من لديه نسخة معينة من المشروع، أو النسخة الأساسية، أو التي توجد تعديلات فيها، فكل نسخة يتم تطويرها محلياً بشكل كامل، ثم يتم دفعها Push أو سحبها pull بما يتناسب مع هدف المشروع.

واجهات جيت

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

يُعتبر جيت أداة مجانية تمامًا وبإمكان الجميع استخدامه، ويأتي على شكل حزم كل منها مخصص للعمل على نظام تشغيل مختلف ("مثل" Linux و BSD و Illumos وأنظمة تشغيل أخرى شبيهة بيونكسـ Unix)، ويمكنك معرفة إصدار حزمة جيت المثبتة لديك بالشكل التالي:

$ git --version
git version 2.5.3

إن واجهات جيت الأكثر شهرة معظمها قائم على الويب: مواقع مثل bitbucket و gitlab و github و sourceforge و Savannah جميعها توفر إمكانية استضافة الشيفرة على الإنترنت والهدف الرئيسي لهذه المواقع هو تعظيم المحتوى مفتوح المصدر للعامة، إضافةً إلى أنها توفر (وبدرجات مختلفة) واجهات المستخدم الرسومية المبنية على المتصفحات لتسهيل استخدام جيت.

واجهة GitLab تظهر بالشكل التالي:

إضافة إلى ذلك من الممكن أن يكون لخدمة جيت أو للمطورين المستقلين؛ واجهة مخصصة لا تعتمد على الويب، وبالتالي هي مفيدة في حال لم تكن ترغب بالعمل من خلال المتصفحات. أوضح مثال على ذلك هو مدير الملفات، على سبيل المثال يمكن لمدير ملفات KDE مثل Dolphin التحقق من حالة ملفات المستودع git status وتوليد أوامر الإيداع commit والسحب والدفع.

تطبيق Sparkleshare يستخدم جيت كأساس لواجهة مشاركة الملفات الخاصة كما هو الحال مع تطبيق Dropbox.

للمزيد من المعلومات راجع الصفحة الرسمية التالية Git wiki التي تعرض قائمة كاملة بمشاريع واجهة جيت الرسومية.

من يجب أن يستخدم جيت؟

السؤال الأفضل والأكثر دقة يجب أن يكون متى؟ ولماذا؟

متى يجب أن أستخدم جيت، وما الذي يجب أن أستخدمه من أجله؟

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

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

لكن ما هو النص؟ عندما تقوم بكتابة شيءٍ ما من خلال استخدام أحد التطبيقات المكتبية مثل Libre Office، فغالبًا قد لا تضع النص كما هو، أي ربما قد يكون النص الذي تكتبه موضوعاً ضمن ملفات XML، وربما أيضًا قمت بضغط ملفات XML مع بعضها البعض ضمن مجلد واحد من خلال أحد برامج الضغط مثل ZIP، وذلك لجمعها مع بعضها لتسهيل الرجوع إليها أو لضمان أن جميع الأشياء المهمة التي تريدها موجودة في ملف واحد عندما تريد إرسالها لشخص ما.

إن أنواع الملفات التي نحفظ بها مشاريعنا والتي نعتقد أنها أنواع معقدة لحفظ البيانات مثل Kdenlive، أو SVG من inkscape هي في الواقع مكونة من ملفات XML، وتستطيع جيت إدارتها بسهولة.

إذا كنت تستخدم "يونكس" Unix، فيمكنك معرفة مما يتكون منه الملف باستخدام الأمر file كما يلي:

$ file ~/path/to/my-file.blah

my-file.blah: ASCII text

$ file ~/path/to/different-file.kra: Zip data (MIME type "application/x-krita")

وإذا أردت التأكد من ذلك، يمكنك عرض محتويات الملف باستخدام الأمر head كما يلي:

$ head ~/path/to/my-file.blah

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

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

"<sky>ugly greenish-blue</sky>"

فإن تعديله إلى:

"<sky>blue-with-fluffy-clouds</sky>"

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

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

في حال كنت تعمل على مشروع يتضمن ملفات نصية وكائنات تمثل بيانات ثنائية حجمها كبير (كما في حالة ألعاب الفيديو التي تحتوي شيفرات مصدرية متساوية لكل من البيانات الرسومية والصوتية)، فهنا بإمكانك القيام بأحد الأمرين التاليين: إما ابتكار حل خاص بك، على سبيل المثال استخدام المؤشرات على محرك أقراص شبكة مشترك، أو استخدام أدوات إضافية مثل أداة جوي هيس الممتازة git annex، أو مشروع Git-Media.

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

ترجمة -وبتصرف- للمقال ?What is Git لصاحبه Seth Kenlon.

اقرأ أيضًا

• مبادئ Git الأساسية
• إعداد Git للمرة الأولى
• مدخل إلى نظام التحكم في النسخ Git

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

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

سيتناول هذا الدليل بعض النصائح حول الإشراف على المستودعات العامة للبرامج مفتوحة المصدر، إذ يترافق كونك قائدًا لمشروعٍ مفتوح المصدر مع مسؤولياتٍ تقنية وغير تقنية للمساهمة في تعزيز قاعدة المستخدمين والدائرة المجتمعية حول مشروعك. إن تولي دور المشرف هو فرصة للتعلُّم من الآخرين، واكتساب الخبرة في إدارة المشاريع، ومراقبة نمو مشروعك وتغيره عندما يصبح المستخدمون مساهمين مستثمرين.

كتابة توثيق مفيد

يساهم التوثيق Documentation الشامل وحسن التنظيم الذي يخدم الفئات المستهدفة في مشروعك على توسيع قاعدة مستخدميه، وستصبح قاعدة المستخدمين هذه مع مرور الوقت هي المساهمة في مشروعك مفتوح المصدر.

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

إليك بعض ملفات التوثيق التي يجب الاحتفاظ بها في مجلد المستوى الأعلى top-level directory الخاص بك، إلى جانب ملف شيفرتك البرمجية:

• ملف README.md، الذي يقدم ملخصًا عن المشروع وأهدافك منه.
• ملف CONTRIBUTING.md، الذي يحتوي على تعليمات المساهمة.
• ترخيص برنامجك، والذي يمكن أن يشجع الأشخاص على تقديم مساهماتٍ أكثر. ويمكنك قراءة المزيد حول اختيار ترخيص لبرنامجٍ مفتوح المصدر.

يوجد للتوثيق عدّة صيغٍ، ويمكن أن يُوجَّه لجماهير مختلفة، إذ يمكنك اختيار نوعٍ واحد أو أكثر من الأنواع التالية على أنه جزءٌ من توثيقك بناءً على مجال عملك:

• دليل عام general guide: لتعريف المستخدمين بالمشروع.
• دروس تعليمية Tutorials: لشرح حالات الاستخدام المختلفة.
• الأسئلة الشائعة FAQs: للإجابة على أكثر الأسئلة التي يطرحها المستخدمون.
• أدلة اكتشاف الأخطاء وتصحيحها Troubleshooting guides: لمساعدة المستخدمين على حل المشاكل.
• مرجع للواجهة البرمجية API reference: الذي يوفر للمستخدمين طريقةً سريعةً للعثور على معلومات الواجهة البرمجية API.
• ملاحظات الإصدار Release notes: إضافةً إلى الأخطاء البرمجية bugs المعروفة وذلك لإعلام المستخدمين ماذا يتوقعون في كل إصدار.
• الخصائص المخطط لها Planned features: لمتابعتها وشرح الخصائص المُخطط إضافتها لاحقًا.
• مقاطع فيديو توجيهية Video walkthroughs: لتزويد المستخدمين بنهج وسائط متعددة لاستخدام برنامجك.

قد تلائم أنواعٌ معينة من التوثيق مشروعك أكثر من غيرها، ولكن سيساعد تقديم أكثر من نهجٍ واحدٍ في البرنامج قاعدة المستخدمين لديك على فهم آلية التفاعل مع عملك بصورةٍ أفضل.

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

أصبحت اللغة الإنجليزية لغةً عالميةً في مجال التكنولوجيا، ومع ذلك عليك دراسة هوية المستخدمين المستهدفين وكيفية الوصول إليهم؛ إذ قد تكون اللغة الإنجليزية هي الخيار الأفضل للتواصل مع قاعدة مستخدمين واسعة، لكن عليك أن تُبقي في ذهنك أن توثيقك سيكون مُوجَّهًا للعديد من الأشخاص الذين لا تكون اللغة الإنجليزية لغتهم الأم، لذا اعمل على تفضيل لغةٍ يسهل الوصول إليها ولا تربك القراء أو المشاهدين.

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

تنظيم المشاكل

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

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

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

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

بالنسبة إلى المشاكل التي تتضمن طلبات خصائص أو تحسينات، يمكنك أن تسأل الشخص الذي قدَّم القضية عما إذا كان قادرًا على المساهمة في الشيفرة البرمجية بنفسه، ويمكنك توجيهه إلى الملف "CONTRIBUTORS.md" وأي توثيقٍ آخر ذي صلة.

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

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

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

أتمتة المهام

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

• أعِدَّ الاختبار المؤتمت للمساهمات الواردة من خلال فرض عمليات تحقق من الحالة، واحرص على إضافة معلوماتٍ حول آلية عمل الاختبار لمشروعك إلى ملف "CONTRIBUTORS.md".

• تحقق من الأدوات المُطوَّرة لأتمتة مهام الصيانة، إذ تقدِّم لك هذه الأدوات خياراتٍ متنوعة، مثل أتمتة الإصدارات الخاصة بك ومراجعة الشيفرة البرمجية، أو إغلاق المشاكل إذا لم يستجب كاتبها عند طلب معلوماتٍ منه.

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

اجعل المساهمة مجزية

كلما رحبت بالمساهمين في مشروعك وكافأت جهودهم، زادت احتمالية تشجيع تلقي مساهماتٍ أكثر. ولمساعدة الأشخاص على البدء، عليك أن تضع ملف "CONTRIBUTORS.md" في أعلى مستوى top-level من المستودع الخاص بك، ومؤشرٌ على مكان هذا الملف في ملف "README.md".

ستحدّد سمات ملف المساهمة النافع طريقة بدء المطور في العمل على المشروع، وتقديم دليلٍ مفصَّل أو قائمة تحقق يتّبعها المطورون، تشرح كيف ينجحون في دمج شيفرتهم البرمجية في المشروع من خلال طلب السحب.

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

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

بناء مجتمعك

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

إضافةً إلى ما سبق، يمكنك العمل على الترويج لمشروعك بعدة أساليب:

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

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

• ملفات توثيق ويكي، التي تقدم توثيقًا يُحفَظ في متناول المجتمع.
• منتديات لمناقشة الخصائص المحتمَلة والإجابة على الأسئلة.
• خادم قوائم بريدية للمشاركة المجتمعية المعتمدة على البريد الإلكتروني.

ادرس قاعدة المستخدمين الأساسية لديك ومجال مشروعك (وهذا يشمل عدد الأشخاص الذين يعملون على الإشراف على المشروع والموارد المتاحة لديك) قبل نشر هذه المساحات المحتمَلة؛ واِسعَ للحصول على آراء مجتمعك حول ما يناسبهم؛ وقبل كل شيء، لا بد أن تكون لطيفًا وأن تُظهر بعض المودة في جميع تفاعلاتك مع مجتمعك. قد يصعب أن تتسم بالحلم عندما تؤدي دور المشرف، لكن ذلك سيؤتي ثماره على مشروعك في المستقبل.

الخاتمة

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

ترجمة -وبتصرف- للمقال How To Maintain Open-Source Software Projects لصاحبته Lisa Tagliaferri

اقرأ أيضًا

• الفرق بين البرمجيات الحرة ومفتوحة المصدر
• طرق التعريف بمشروعك مفتوح المصدر
• صيانة المشاريع مفتوحة المصدر
• كيف تساهم في مشاريع مفتوحة المصدر على Github

تُعد مساهمتك في المشاريع مفتوحة المصدر تجربةً مجزيةً، إذ تتمثل في سعيك لتحسين تجربة المستخدمين النهائيين أمثالك في استخدام البرامج؛ فعندما تقدم طلب سحب pull request، ستتطلب عملية المساهمة في مشروعٍ ما بعضًا من إعادة تأسيس تفريعات rebase الشيفرة البرمجية وإعادة صياغتها قبل قبولها، متبوعةً بعملية تنظيفٍ عامة لفروعك.

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

المتطلبات الأساسية

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

ألغى موقع غيت هَب GitHub الاستيثاق Authentication من خلال كلمة المرور في شهر تشرين الثاني من عام 2020. لذلك، حتى تتمكن من الوصول إلى مستودعات repositories موقع غيت هَب من خلال سطر الأوامر، فعليك إنشاء مفتاح الوصول الشخصي Personal Access Token -أو اختصارًا PAT-، أو إضافة معلومات مفتاح SSH العام public SSH key.

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

إعادة تأسيس الشيفرة البرمجية وتنظيف التعليقات

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

CONFLICT (content): Merge conflict in your-file.py
Automatic merge failed; fix conflicts and then commit the result.

أو كما في الصورة التالية عندما تقدم طلب سحب على موقع غيت هَب:

(تعارضات)

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

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

سننتقل إلى مجلد الشيفرة البرمجية، تمامًا كما فعلنا في المقال السابق:

$ cd repository

ومن ثم ينبغي عليك التأكُّد من أنك في الفرع الصحيح بالانتقال إليه من خلال استخدام الأمر git checkout:

$ git checkout new-branch

ثم نفذ الأمر git fetch للحصول على أحدث نسخةٍ أولية للشيفرة البرمجية:

$ git fetch origin

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

لبدء هذه العملية، ستنفِذ عملية إعادة تأسيس التفريعات التفاعلية المُستخدمة لتعديل رسائل إيداع سابقة، أو جمع عدة رسائل إيداع في رسالة واحدة، أو حذف أو التراجع عن رسائل إيداع لم تَعُد ضرورية؛ ولتنفيذ ذلك، علينا أن نتمكن من ذكر رسائل الإيداع التي أنشأناها، إما برقمها، أو بسلسلة المحارف التي تذكر أساس الفروع لدينا.

لمعرفة عدد الإيداعات التي أنشأناها، يمكننا تفقُّد الرقم الإجمالي للإيداعات المُنشأة في المشروع من خلال الأمر التالي:

$ git log

وسيكون الخرج مشابهًا للخرج التالي:

commit 46f196203a16b448bf86e0473246eda1d46d1273
Author: username-2 <email-2>
Date:   Mon Dec 14 07:32:45 2015 -0400

    Commit details

commit 66e506853b0366c87f4834bb6b39d941cd034fe3
Author: username1 <email-1>
Date:   Fri Nov 27 20:24:45 2015 -0500

    Commit details

يعرض السجل جميع الإيداعات المُنشأة في مستودع المشروع المحدد، لذلك ستُعرَض الإيداعات التي أنشأها آخرون إلى جانب الإيداعات التي أنشأتها أنت. وبالتالي، عندما يكون للمشاريع سجلًا حافلًا من الإيداعات التي أنشأها عدة مؤلفين، ستحتاج إلى تحديد نفسك على أنك مؤلفًا من خلال الأمر:

$ git log --author=your-username

سيتيح لك هذا المعامل عدَّ الالتزامات التي أنشأتها؛ فإذا كنت تعمل على عدة فروع، تستطيع إضافة branches[=<branch>]‎-- في نهاية الأمر لتظهر النتيجة حسب الفرع.

والآن بعد أن عرفت عدد الإيداعات التي أنشأتها على الفرع الذي تريد إعادة تأسيسه، يمكنك تنفيذ الأمر git rebase كما يلي:

$ git rebase -i HEAD~x

تشير i- في هذا المثال إلى أن إعادة تأسيس التفريعات تفاعلية، و HEAD إلى أحدث إيداع في الفرع الرئيسي، بينما تشير x إلى عدد الإيداعات التي أنشأتها في فرعك منذ أن جلبته في البداية.

لكن إذا كنت لا تعرف عدد الإيداعات التي أنشأتها في فرعك، عليك أن تعرف ما هو الإيداع الذي يمثِّل أساس الفرع خاصتك، من خلال تنفيذ الأمر التالي:

$ git merge-base new-branch main

وسيكون خرج هذا الأمر سلسلة محارف طويلة تُعرف باسم الإيداع المعمَّى Hash، كما يبدو في المثال التالي:

66e506853b0366c87f4834bb6b39d341cd094fe9

سنمرر الإيداع المعمَّى هذا إلى الأمر git rebase:

$ git rebase -i 66e506853b0366c87f4834bb6b39d341cd094fe9

ستكون نتيجة كلا الأمرين السابقين فتح ملفٍ في محرر نصوص واجهة الأوامر يتضمن قائمةً بجميع الإيداعات في فرعك، ويمكنك الآن إما دمجها أو إعادة صياغتها.

دمج الإيداعات

تتمثل عملية دمج رسائل الإيداع بدمج أو جمع عدة إيداعات صغيرة في رسالة أكبر.

ستجد بداية كل إيداع كلمة انتقاء "pick"، لذا سيبدو ملفك مشابهًا للملف التالي إذا كان لديك إيداعين:

• الملف "‎…username/repository/.git/rebase-merge/git-rebase-todo":

pick a1f29a6 Adding a new feature
pick 79c0e80 Here is another new feature

# Rebase 66e5068..79c0e80 onto 66e5068 (2 command(s))

ولدمج الإيداع، ينبغي عليك تبديل الكلمة "pick" بالكلمة "squash" في كل سطر من سطور الملف الموجود ضمن المسار "username/repository/.git/rebase-merge/git-rebase-todo…" باستثناء السطر الأول:

pick a1f29a6 Adding a new feature
squash 79c0e80 Here is another new feature

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

ستتلقى ملاحظةً بمجرد إغلاق الملف على النحو التالي:

Successfully rebased and updated refs/heads/new-branch.

لقد جمعت الآن جميع الإيداعات في إيداعٍ واحد بدمجها معًا.

إعادة صياغة الإيداعات

تُعد إعادة صياغة رسائل الإيداع رائعةً عند ملاحظتك خطًأ إملائيًا، أو عندما تدرك أنك تستخدم صياغةً مختلفةً في كل إيداع لديك.

بمجرد أن تنفذ عملية إعادة تأسيس التفريعات التفاعلية باتباع الخطوات التي ذكرناها من خلال تنفيذ الأمر git rebase -i، سيُفتح ملفٌ مشابهٌ للملف في المسار "username/repository/.git/rebase-merge/git-rebase-todo…" على النحو التالي:

pick a1f29a6 Adding a new feature
pick 79c0e80 Here is another new feature

# Rebase 66e5068..79c0e80 onto 66e5068 (2 command(s))

بدِّل الكلمة "reword" بالكلمة "pick"، أي إعادة الصياغة في كل إيداع تريد إعادة صياغته، فمثلًا في الملف الموجود ضمن المسار "username/repository/.git/rebase-merge/git-rebase-todo…"، ستكون إعادة الصياغة على النحو التالي:

pick a1f29a6 Adding a new feature
reword 79c0e80 Adding a second new feature

# Rebase 66e5068..79c0e80 onto 66e5068 (2 command(s))

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

استكمال عملية إعادة تأسيس التفريعات

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

$ git rebase origin/main

سيبدأ نظام غيت في هذه المرحلة بإعادة تنفيذ إيداعاتك في أحدث نسخةٍ من الفرع الرئيسي؛ وفي حالة حدوث تعارضات في تلك العملية، سيوقفها غيت مؤقتًا ليطالبك بمعالجة تلك التعارضات قبل متابعة العملية؛ أما إذا لم يجد تعارضات، فسيرِد في الخرج ما يلي:

Current branch new-branch is up to date.

بعد معالجة التعارضات، نفِّذ الأمر:

$ git rebase --continue

إذ سيشير هذا الأمر إلى غيت بأنه يستطيع الآن متابعة إعادة تنفيذ إيداعاتك.

إذا سبق ودمجت الإيداعات من خلال استخدام أمر squash، فستضطر إلى معالجة التعارضات مرةً واحدةً فقط.

تحديث طلب السحب باستخدام الدفع القسري Force-Push

عندما تجري إعادة تأسيس التفريعات، يتغير سجل الفرع الخاص بك، ولن تتمكن من استخدام الأمر get push لأن المسار المباشر قد عُدِّل، وسنضطر عوضًا عن ذلك استخدام force-- أو الراية f- لفرض دفع التغييرات، وهذا يبلغ غيت أنك على درايةٍ كاملة بالذي تدفعه.

دعنا أولًا نتأكد من أن push.default الخاص بنا مضبوطٌ على simple (وهو الإعداد الافتراضي في الإصدار 2.0 وما بعده من نظام غيت) من خلال تنفيذ ما يلي لإعداده:

$ git config --global push.default simple

علينا أن نتأكد في هذه المرحلة أننا في الفرع الصحيح من خلال التحقُّق من الفرع الذي نعمل عليه على النحو التالي:

$ git checkout new-branch

Already on 'new-branch'
. . .

نستطيع حينها تنفيذ عملية الدفع القسري كما يلي:

$ git push -f

سيرد إليك الآن تعليقٌ عن التحديثات التي أجريتها إلى جانب رسالةٍ تشير إلى أن هذا التحديث كان forced update أي تحديثًا قسريًا، وأصبح طلب السحب الذي قدمته محدثًا الآن.

استعادة الإيداعات الضائعة

إذا أزلت في مرحلةٍ ما إيداعًا تحتاج فعلًا إلى دمجه مع مُجمَل المشروع، تستطيع استخدام الأمر git لاستعادة الإيداعات التي أزلتها من دون قصد.

سنستخدم الأمر git reflog للبحث عن الإيداعات الناقصة، ثم ننشئ فرعًا جديدًا من ذلك الإيداع، إذ تشير كلمة Reflog إلى اختصارٍ لعبارة السجل المرجعي reference log، الذي يسجل آخر تحديثٍ للإيداعات في الفروع والمراجع الأخرى ضمن المستودع المحلي.

سننفِّذ الأمر التالي من الدليل الحالي لمستودع الشيفرة البرمجية الذي نعمل فيه:

$ git reflog

وسيكون الخرج عند تنفيذ هذا الأمر مشابهًا للخرج التالي:

46f1962 HEAD@{0}: checkout: moving from branch-1 to new-branch
9370d03 HEAD@{1}: commit: code cleanups
a1f29a6 HEAD@{2}: commit: brand new feature 
38f2fc2 HEAD@{3}: commit: remove testing methods
. . .

ستعرف عند الاطلاع على رسائل الإيداع أيُّ الإيداعات التي أزلتها، وستجد سلسلة المحارف المتعلقة بها قبل معلومات HEAD@{x}‎ في الجهة اليسارية من نافذة الطرفية.

تستطيع الآن الاستفادة من تلك المعلومة وإنشاء فرعٍ جديدٍ من الإيداع المناسب:

$ git checkout -b new-new-branch a1f29a6

أنشأنا في المثال السابق فرعًا جديدًا من ثالث إيداع حصلنا عليه في الخرج السابق، وهو الإيداع الذي بدأ تنفيذ وسم خاصية جديدة "brand new feature"، مُتمثِّل بسلسلة المحارف a1f29a6.

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

اقتباس

ملاحظة: إذا نفذت الأمر git gc مؤخرًا لتنظيف الملفات غير الضرورية وتحسين أداء المستودع المحلي، قد لا تستطيع استعادة الإيداعات المفقودة.

ما الذي تتوقع رؤيته في مراجعة الشيفرة البرمجية؟

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

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

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

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

عندما تنشر شيفرتك البرمجية ليراجعها أقرانك، لا يجب أن تشعر أبدًا أن المراجعة تتخذ منحًى شخصيًا، لذا احرص على قراءة ملفات "CONTRIBUTION.md" ذات الصلة أو مدونات قواعد السلوك. ومن الضروري أن تتأكد من توافق إيداعاتك مع الإرشادات المحددة ضمن المشروع؛ ولكن إذا بدأت تشعر بالاستياء، فقد لا يستحق المشروع الذي تعمل عليه مساهمتك.

توجد العديد من المساحات الترحيبية في مجتمع البرامج مفتوحة المصدر، وبما أنك تتوقع أن يُنظَر إلى الشيفرة البرمجية التي تشاركها بعينٍ ناقدة، يجب أن تكون جميع الملاحظات التي تتلقاها مهنيةً ولبِقة.

قبول طلب السحب وحذف فرعك

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

يمكنك فعل ذلك من خلال تنفيذ عدة أوامر في نافذة طرفيتك:

$ git checkout main
$ git pull --rebase origin main
$ git push -f origin main

عليك الآن تنظيف كلٍ من فروعك المحلية والبعيدة بحذف الفرع الذي أنشأته في كلا الموضعين لأنك لن تحتاج إليهما بعد الآن. لنحذف أولًا الفرع المحلي:

$ git branch -d new-branch

مهمة الراية d- المُضافة إلى أمر git branch هي حذف الفرع الذي سنذكره في هذا الأمر، والذي سميناه في مثالنا السابق "new-branch".

ثم سنحذف الفرع البعيد على النحو التالي:

$ git push origin --delete new-branch

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

الخاتمة

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

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

ترجمة -وبتصرف- للمقال How To Rebase and Update a Pull Request لصاحبته Lisa Tagliaferri.

اقرأ أيضًا

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

نظام غيت Git هو نظام إدارة الإصدارات الموزعة distributed version الذي يسهّل إدارة المشاريع البرمجية المشتركة. تحتفظ العديد من المشاريع بملفاتها في مستودع غيت Git repository، كما جعلت مواقع، مثل غيت هَب GitHub مشاركة الشيفرة البرمجية والمساهمة فيها متاحةً ومفيدةً وفعالةً.

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

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

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

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

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

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

إنشاء نسخة عن المستودع

إن المستودع repository، والذي يُشار إليه بكلمة ريبو أو repo هو المجلد الرئيسي للمشروع أساسًا، ويحتوي على جميع الملفات المتعلقة بالمشروع، مثل ملفات التوثيق documentation، كما يحتفظ بسجل التعديلات revision history لكل ملف. ويمكن أن يشترك أكثر من شخص في العمل على المستودعات على موقع غيت هَب، كما يمكن أن تكون عامةً أو مغلقة.

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

اشتقاق المستودع

لاشتقاق مستودع على موقع غيت هَب انتقل إلى رابط المشروع مفتوح المصدر الذي تريد المساهمة فيه على الموقع من خلال المتصفح لديك، إذ تشير روابط المستودعات على غيت هَب إلى كلٍ من اسم المستخدم المرتبط بمالك المستودع إضافةً إلى اسم المستودع؛ فمثلًا إذا مالك مستودع مشروع "cloud_haiku" هو مجتمع DigitalOcean، فسيكون رابط هذا المشروع على موقع غيت هَب على النحو التالي:

https://github.com/do-community/cloud_haiku

يشير do-community في هذا المثال إلى اسم المستخدم و cloud_haiku إلى اسم المستودع.

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

https://github.com/username/repository

أو يمكنك البحث عنه في شريط بحث موقع غيت هَب.

عندما تفتح الصفحة الرئيسية للمستودع، ستجد زر الاشتقاق Fork في زاوية الصفحة العليا على اليمين، وأسفل أيقونة المستخدم الخاص بك:

(سهم وامض)

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

(الاشتقاق في غيت هَب)

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

إذًا سترى الآن في المثال الذي طرحناه your-username / cloud_haiku بدلًا عن do-community / cloud_haiku في أعلى الصفحة، حيث أن your-username هي اسم المستخدم الخاص بك، وسيكون الرابط الجديد على النحو التالي:

https://github.com/your-username/cloud_haiku

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

استنساخ المستودع

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

سيكون هذا الرابط مشابهًا للرابط الذي ذكرناه سابقًا، إلا أن هذا الرابط سينتهي باللاحقة git.، وسيكون الرابط حسب مثالنا عن "cloud_haiku" على النحو التالي:

https://github.com/your-username/cloud_haiku.git

أو يمكنك نسخ الرابط باستخدام الزر الأخضر الشيفرة Code⤓ الموجود في صفحة مستودعك الذي اشتققته من صفحة المستودع الأصلية، وبمجرد الضغط على الزر ستتمكن من نسخ الرابط من خلال النقر على زر المجلد binder بجانب الرابط:

(سهم يشير إلى زر المجلد في مربع الشيفرة)

عندما نحصل على الرابط سنكون جاهزين لاستنساخ المستودع، ولتنفيذ ذلك سنجمّع أمر git clone مع رابط المستودع في موجه الأوامر في الطرفية على النحو التالي:

git clone https://github.com/your-username/repository.git

أصبح لدينا الآن نسخةً محليةً من الشيفرة البرمجية، لذا يمكننا الانتقال إلى إنشاء فرعٍ branch جديدٍ لنعمل ضمنه على الشيفرة البرمجية.

إنشاء فرع جديد

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

يدعى الفرع الأولي primary من مستودع مشروع عادةً الفرع الرئيسي main. ومن أفضل الممارسات الشائعة أن تعد أي شيءٍ ضمن الفرع الرئيسي قابلًا للنشر ليستخدمه الآخرون متى شاؤوا.

ملاحظة: حدَّث موقع غيت هَب المصطلحات التي يستخدمها ليشير إلى مستودعات الشيفرة البرمجية المصدرية الافتراضية بالمستودع الرئيسي main بدل المستودع الأساسي master؛ فإذا كان الموقع لديك ما زال يشير إلى الفرع الرئيسي بمصطلح master، يمكنك تحديثه إلى main بتغيير إعدادات الفرع الافتراضية.

احرص على إنشاء الفرع الجديد من الفرع الرئيسي، كما عليك أن تختار اسمًا توصيفيًا لهذا الفرع؛ فبدلًا من تسميته "my-branch" سمّه "frontend-hook-migration" أي "تهجير-خطاف-الواجهة الأمامية"، أو fix-documentation-typos أي "تصحيح-التوثيق-الأخطاء الإملائية".

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

cd repository

ثم ننشئ فرعنا الجديد بواسطة الأمر git branch، لذلك احرص على تسميته تسميةً توصيفية كي يفهم الآخرون الذين يعملون على المشروع ما الذي تعمل عليه.

git branch new-branch

بعد أن أنشأنا فرعنا الجديد نستطيع الانتقال إليه لنتأكد أننا نعمل على ذلك الفرع من خلال تنفيذ الأمر git checkout على النحو التالي:

git checkout new-branch

سيرِد الخرج التالي عندما تدخل الأمر git checkout:

Switched to branch 'new-branch'

أو يمكنك اختصار الأمرين السابقين، وهما إنشاء فرع جديد والانتقال إليه، بواسطة الأمر التالي وإضافة الراية b-:

git checkout -b new-branch

إذا أردت العودة إلى الفرع الرئيسي أو main، استخدم الأمر checkout مع إدخال اسم الفرع الرئيسي:

git checkout main

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

تستطيع حتى الآن تعديل ملفات موجودة أو إضافة ملفات جديدة إلى المشروع الموجود ضمن فرعك.

إجراء التعديلات محليًا

دعنا نبدأ بإنشاء ملف جديد وليكن اسمه "poetry.md" باستخدام محرّر النصوص الذي تفضله، وسنستخدم في مثالنا هذا محرر النصوص نانو nano:

nano poetry.md

أضف أي محتوًى إلى ملفك الجديد، فمثلًا نحن أضفنا الاسم "haiku" في هذا الملف:

The taste
Of rain
—Why kneel?

“The Taste of Rain” by Jack Kerouac

بعد إدخال المحتوى الذي تريده، احفظ التعديلات وأغلق الملف؛ وإذا كنت تستخدم محرر النصوص نانو، يمكنك تنفيذ ذلك بالضغط على "CTRL + X"، ثم "y"، ثم "ENTER".

بعد أن عدّلت ملفًا موجودًا أو أضفت ملفًا جديدًا إلى المشروع، يمكنك إضافته إلى مستودعك المحلي عن طريق تنفيذ الأمر git add على النحو التالي:

git add filename.md

بدِّل الآن filename.md باسم الملف poetry.md الذي أنشأته لإضافته إلى مستودعك المحلي:

git add poetry.md

سيؤكد لك هذا الأمر أن ملفك جاهزٌ للإضافة. وإذا كنت تريد أن تضيف جميع الملفات الموجودة في مجلد معين، يمكنك إدراجها من خلال الأمر . git add، إذ ستضيف النقطة أو الفاصلة جميع الملفات المعنية؛ وإذا أردت إضافة جميع التعديلات متضمنةً المجلدات الفرعية بصورةٍ متكررة، نفذ الأمر git add -A أو git add -all لإدراج جميع الملفات الجديدة.

بعد إدراج ملفاتنا، يُفضَّل تسجيل التعديلات التي أجريناها في المستودع بتنفيذ الأمر git commit.

تُعد رسالة الإيداع commit عنصرًا مهمًا في مساهمتك في الشيفرة البرمجية؛ فهي تساعد المساهمين الآخرين على فهم التعديلات التي أجريتها كاملةً، وسبب إجرائها، ومدى أهميتها، إضافةً إلى توفير سجلٍ تاريخي للتغييرات المُجراة على المشروع عامةً، لمساعدة المساهمين المستقبليين.

إذا كانت الرسالة مقتضبةً، نستطيع تسجيلها بإضافة الراية m- ووضع الرسالة بين إشارتي اقتباس على النحو التالي:

git commit -m "Added a new haiku in poetry.md file"

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

nano more-poetry.md

ثم أضف إليه بعض المحتوى ليكون الملف "more-poetry.md" على النحو التالي:

The light of a candle
Is transferred to another candle—
Spring twilight

“Lightning One Candle” by Yosa Buson

بعد إضافة المحتوى إلى الملف، احفظ التعديلات وأغلقه؛ وإذا كنت تستخدم محرر النصوص نانو يمكنك تنفيذ ذلك بالضغط على "CTRL + X"، ثم "Y"، ثم "ENTER".

ثم نفذ الأمر git add لإضافة الملف الجديد إلى إلى مستودعك المحلي:

git add more-poetry.md

إذا أردت إضافة رسالة إيداع أطول، نفِّذ الأمر git commit دون إضافة أية رايات لفتح محرر النصوص الافتراضي على نظام التشغيل لديك.

git commit

إذا أردت ضبط محرر النصوص الافتراضي لديك، نفِّذ الأمر git config وحدد نانو مثلًا ليكون المحرر الافتراضي:

git config --global core.editor "nano"

أو ليكن محرر النصوص فيم vim:

git config --global core.editor "vim"

وبعد تنفيذ الأمر، ستعرض نافذة الطرفية مستندًا جاهزًا لتعديله حسب محرر النصوص الافتراضي الذي تستخدمه، وسيبدو المستند مشابهًا للنموذج التالي:

# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
# On branch new-branch
# Your branch is up-to-date with 'origin/new-branch'.
#
# Changes to be committed:
#       modified:   new-feature.py
#

أضف رسالة الإيداع إلى الملف النصي أسفل التعليقات الافتتاحية.

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

تعديلات الدفع push

بعد أن تحفظ ملف رسالة الإيداع النصي وتغلقه، يمكنك التحقق من رسالة الإيداع التي ستخصِّصها غيت بتنفيذ الأمر التالي:

 git status

وسيكون الخرج مشابهًا للنموذج التالي حسب التعديلات التي أجريتها:

On branch new-branch
nothing to commit, working tree clean

تستطيع في هذه المرحلة تنفيذ الأمر git push لتطبيق التعديلات على الفرع الحالي لمستودعك المُشتَق:

git push --set-upstream origin new-branch

سيزودك هذا الأمر بخرجٍ يُعلمك بمسار التقدم، وسيبدو مثل النموذج التالي:

Counting objects: 3, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 336 bytes | 0 bytes/s, done.
Total 3 (delta 0), reused 0 (delta 0)
To https://github.com/your-username/repository.git
   a1f29a6..79c0e80  new-branch  -> new-branch
Branch new-branch set up to track remote branch new-branch from origin.

انتقل الآن إلى مستودعك المشتق على صفحة موقع غيت هَب وبدِّل إلى الفرع الذي طبقت عليه التعديلات لمشاهدتها ضمن المتصفح، إذ يمكنك في هذه المرحلة إنشاء طلب سحب إلى المستودع الأصلي؛ لكن إذا لم تفعل ذلك مسبقًا، يُستحسن أن تتأكد أن مستودعك المحلي محدَّثًا مع المستودع الأولي upstream.

تحديث المستودع المحلي

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

سنبدأ باستعراض ضبط مستودع بعيد remote للاشتقاق، ثم مزامنته.

ضبط مستودع بعيد للاشتقاق

تتيح لك المستودعات البعيدة Remote repositories المساهمة مع الآخرين على مشروع في غيت، إذ يُعَد كل مستودعٍ بعيد إصدارًا من إصدارات المشروع المُستضافة على الإنترنت، أو الموجودة على شبكةٍ يمكنك الوصول إليها. ويجب أن يتوفر لديك وصول إلى كل مستودع بعيد؛ إما بصلاحيات قراءة فقط، أو صلاحيات قراءة وكتابة، ويعتمد ذلك على صلاحيات المستخدم الخاص بك.

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

لنبدأ بالتحقق ما هي الخوادم البعيدة التي ضبطتها، إذ سيعرض الأمر git remote المستودعات البعيدة التي حدَّدتها مُسبقًا؛ لذا إذا استنسخت مستودعك كما فعلنا سابقًا، سترى المستودع الرئيسي origin repository على الأقل، وهو الاسم الافتراضي الذي تطلقه غيت للمجلد المستنسَخ.

سنستخدم الأمر git remote إضافةً إلى الراية v عندما نكون ضمن مجلد المستودع في طرفيتنا لعرض الروابط التي خزَّنها غيت إضافةً إلى الأسماء المختصرة للمستودعات البعيدة ذات الصلة، مثل "origin":

git remote -v

سيبدو الخرج مشابهًا للنموذج التالي بما أننا استنسخنا مستودعًا:

origin    https://github.com/your-username/forked-repository.git (fetch)
origin    https://github.com/your-username/forked-repository.git (push)

إذا أعددت أكثر من مستودع مسبقًا، سيزودك الأمر git remote -v بقائمةٍ تعرضها جميعًا.

ثم سنحدد مستودعًا رئيسيًا بعيدًا جديد لنزامنه مع المستودع المُشتَق، وسيكون هذا المستودع بمثابة المستودع الأصلي الذي اشتقينا منه، وسننفِّذ ذلك بواسطة الأمر git remote add:

git remote add upstream https://github.com/original-owner-username/original-repository.git

تشير upstream في هذا المثال إلى الاسم المختصر المُسنَد إلى المستودع البعيد، بما أن "upstream" في مصطلحات غيت تشير إلى المستودع الذي استنسخنا منه؛ وإذا أردنا إضافة مؤشر بعيد remote pointer إلى مستودع أحد المساهمين، علينا تقديم اسم مستخدم ذلك المساهم، أو اسمًا مستعارًا مختصرًا للاسم المُختصر.

للتحقق من إضافة مؤشرنا البعيد إلى المستودع الأولي كما ينبغي، استعن بالأمر git remote -v مجددًا من مجلد المستودع:

git remote -v

وسيكون الخرج:

origin    https://github.com/your-username/forked-repository.git (fetch)
origin    https://github.com/your-username/forked-repository.git (push)
upstream    https://github.com/original-owner-username/original-repository.git (fetch)
upstream    https://github.com/original-owner-username/original-repository.git (push)

تستطيع الآن ذكر upstream في موجه الأوامر بدلًا من كتابة الرابط كاملًا، وأصبحت جاهزًا لمزامنة مستودعك المشتَق مع المستودع الأصلي.

مزامنة المستودع المشتَق

بعد ما ضبطنا مستودعًا بعيدًا يشير إلى المستودعين الأولي والأصلي على غيت هَب، أصبحنا جاهزين لمزامنة مستودعنا المشتق لنبقيه محدَّثًا، ولتحقيق ذلك سننفذ الأمر git fetch عندما نكون ضمن مجلد مستودعنا المحلي في الطرفية، ليجلب الفروع ورسائل الإيداع التابعة لها من المستودع الرئيسي. وبما أننا استخدمنا الاسم المختصر "upstream" للإشارة إلى المستودع الأولي، سنذكره في صيغة الأمر:

git fetch upstream

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

From https://github.com/original-owner-username/original-repository
 * [new branch]      main     -> upstream/main

ستُخزَّن الآن رسائل إيداع الفرع الرئيسي في فرعٍ محلي يُسمى "upstream/main". لننتقل إلى الفرع الرئيسي المحلي لمستودعنا:

git checkout main

Switched to branch 'main'

سندمج الآن أية تعديلات أجريت في الفرع الرئيسي للمستودع الأصلي مع فرعنا الرئيسي المحلي، إذ سنصل إلى الفرع الرئيسي من خلال فرعنا الرئيسي/الأولي المحلي:

git merge upstream/main

سيتغير خرج هذا الأمر، لكنه سيبدأ بكلمة "updating" إذا أجريت تعديلات؛ أو "Already up-to-date" في حال عدم إجراء أية تعديلات منذ اشتقاق المستودع.

أصبح الفرع الرئيسي للمستودع المشتَق متزامنًا مع المستودع الأولي، ولن تفقد أية تعديلات محلية تجريها.

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

إنشاء طلب سحب

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

انتقل إلى مستودعك المشتق واضغط على زر طلب سحب جديد New pull request الموجود على الجانب اليساري من الصفحة.

(زر طلب سحب جديد)

تستطيع تعديل الفرع في الصفحة التالية، كما يمكنك اختيار المستودع والفرع الملائمَين في كلا الصفحتين من القائمة المنسدلة؛ فمثلًا عندما تختار الفرع الرئيسي من المستودع الأصلي الموجود في الجانب اليساري من الصفحة، والفرع الجديد new-branch من مستودعك المشتق الموجود على الجانب اليميني من الصفحة، ستظهر لك صفحةٌ تنص على أنك تستطيع دمج فروعك، إذا لم يوجد فيها شيفرةً برمجيةً متضاربة:

(طلب سحب)

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

الخاتمة

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

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

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

ترجمة -وبتصرف- للمقال How To Create a Pull Request on GitHub لصاحبته Lisa Tagliaferri.

اقرأ أيضًا

• كيف تساهم في مشاريع مفتوحة المصدر على Github
• أساسيات Git

تفيد المساهمات التي يقدمها مجتمع المطوّرين العام المشاريع مفتوحة المصدر المستضافة في المستودعات repositories العامة، وتُدار عادةً من خلال نظام غيت Git.

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

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

يُعد هذا المقال جزءًا من سلسلة مقالات حول "المساهمة في المشاريع مفتوحة المصدر":

• كيف تساهم في المشاريع مفتوحة المصدر: ابدأ بتعلم نظام Git
• إنشاء طلب سحب pull request على GitHub
• إعادة تأسيس طلب السحب وتحديثه
• الإشراف على مشاريع البرمجيات مفتوحة المصدر عبر GitHub
• تراخيص البرامج مفتوحة المصدر
• الدليل المرجعي للعمل على نظام Git

المساهمة في المشاريع مفتوحة المصدر

البرنامج مفتوح المصدر: هو البرنامج المُتاح استخدامه وإعادة توزيعه وتعديله مجانًا.

تشجع المشاريع التي تتبع نموذج التطوير مفتوح المصدر على عملية تتسم بالشفافية وتحقق تقدمًا من خلال مراجعة النظراء الموزَّعة distributed peer review؛ ويمكن تحديث المشاريع مفتوحة المصدر بسرعة وحسب الطلب؛ كما أنها تقدِّم برنامجًا مرنًا وموثوقًا غير مبني على أنظمة مغلقة مسجَّلة الملكية.

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

يُعد البدء بالمساهمة في برنامج تستخدمه أصلًا أفضل طريقة تبدأ بها في المساهمة في المشاريع مفتوحة المصدر؛ فعندما تستخدم أداةً معينةً، تكون مدركًا جيدًا للوظائف الأنفع للمشروع. وبالتالي، احرص على قراءة أي توثيق مُتاحٍ عن البرنامج أولًا، إذ ستجد ملف "CONTRIBUTING.md" عادةً في الملف الجذر root directory للعديد من المشاريع مفتوحة المصدر؛ وهو ملف ينبغي قراءته بدقة قبل المساهمة في أي مشروع، كما يُنصَح بتكوين فكرةٍ عن التفاعل بين المطوّرين الآخرين في هذه المنظومة، إذا وجدت منتديات متاحةً تتناول هذا المشروع.

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

نظام الإصدارات Git

يُعد غيت أحد أكثر أنظمة إدارة إصدارات البرمجيات انتشارًا، وقد ابتُكر من قبل مبتكر نواة نظام التشغيل لينوكس لينوس تورفالدس Linus Torvalds عام 2005، إذ كان يُستخدَم في تطوير نواة نظام لينوكس، والمشرف الحالي عليه هو جونيو هامانو Junio Hamano.

يحتفظ العديد من المشاريع بملفاتهم في مستودع repository غيت، كما نظمت مواقع، مثل غيت هَب GitHub وغيت لاب GitLab وبيت بَكيت Bitbucket عملية مشاركة الشيفرات البرمجية والمساهمة فيها. ويُعد كل مجلد عمل working directory في غيت مستودعًا متكاملًا، إضافةً إلى تقديمه تاريخًا وتتبعًا كاملًا بصرف النظر عن الوصول إلى الشبكة، أو الخادم المركزي.

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

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

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

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

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

يمكنك التحقق ما إذا كان نظام غيت مثبتًا ومن إصداره الحالي بفتح نافذة طرفية terminal في نظامي التشغيل لينوكس أو ماك Mac، أو نافذة موجه الأوامر command prompt في نظام التشغيل ويندوز، وطباعة الأمر التالي:

$ git --version

إذا لم يكن نظام غيت مثبتًا، فسيرد خطأٌ مشابهٌ لما يلي:

-bash: git: command not found

'git' is not recognized as an internal or external command, operable program, or batch file.

وعليك في هذه الحالة تثبيت نظام غيت على جهازك، وسنستعرض في الفقرة التالية آلية التثبيت على أهم أنظمة التشغيل.

تثبيت نظام غيت على نظام التشغيل لينكس

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

تثبيت نظام غيت على توزيعة أبونتو Ubuntu أو ديبيان Debian

استخدم أداة APT لإدارة الحزم لتحديث دليل الحزم المحلي لديك، ثم يمكنك بعد ذلك تنزيل وتثبيت البرنامج:

$ sudo apt update
$ sudo apt install git

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

تثبيت نظام غيت على توزيعة سينتوس CentOS

سنستخدم yum؛ مدير الحزم الافتراضي في سينتوس للبحث عن أحدث حزمة غيت متوفرة في مستودعات سينتوس وتثبيتها. لنتحقق أولًا أن yum محدَّثة من خلال تنفيذ الأمر التالي:

$ sudo yum -y update

إذ تُستخدَم الراية y- لتنبيه النظام بأننا ندرك أنه ستجري تغييرات، فامنع الطرفية أن تطلب منا تأكيدها.

يمكننا الآن المتابعة وتثبيت غيت:

$ sudo yum install git

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

تثبيت نظام غيت على توزيعة فيدورا Fedora

إن حزم غيت متاحةٌ على توزيعة فيدورا من خلال مديري الحزم yum و dnf؛ إذ أن DNF أو دانديفايد يَم Dandified Yum استُحدث في إصدار فيدورا الثامن عشر، وأصبح مدير الحزم الافتراضي لتوزيعة فيدورا منذ إصدارها الثاني والعشرين.

يمكننا تحديث مدير الحزم dnf وتثبيت نظام غيت من نافذة الطرفية على النحو التالي:

$ sudo dnf update
$ sudo dnf install git

إذا كان إصدار فيدورا لديك أقدم، استخدم الأمر yum بدلًا عن ذلك. لنحدّث yum أولًا، ثم ثبِّت نظام غيت على النحو التالي:

$ sudo yum update
$ sudo yum install git

ويمكنك بعد ذلك المتابعة إلى فقرة إعداد نظام غيت.

تثبيت نظام غيت على نظام تشغيل ماك أو إس macOS

إذا طبعت أمر Git على نافذة طرفيتك وعلى جهاز محلي مُثبّتٌ عليه نظام تشغيل ماكنتوش Macintosh، مثل الأمر git --version المذكور سابقًا، فستُوجَّه prompt إلى تثبيت نظام غيت، إذا لم يكن مثبتًا مسبقًا على جهازك؛ وعندما تتلقى هذا التوجيه يجب أن تقبل تثبيت غيت واتباع التعليمات والاستجابة للتوجيهات التي تظهر على نافذة طرفية جهازك.

تستطيع تثبيت أحدث إصدار من نظام غيت على نظام ماك من خلال المثبت الثنائي binary installer.

يحتفظ نظام أو إس إكس OS X بمثبت نظام غيت، وهو متاحٌ للتنزيل تلقائيًا عن طريق موقع غيت.

بعد تثبيت نظام غيت بالكامل، يمكنك المتابعة إلى فقرة إعداد نظام غيت.

تثبيت نظام غيت على نظام ويندوز

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

بعد تثبيت نظام غيت بالكامل، يمكنك المتابعة إلى فقرة إعداد نظام غيت التالية.

إعداد نظام غيت

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

$ git config --global user.name "Your Name"
$ git config --global user.email "youremail@domain.com"

يمكننا الاطلاع على جميع عناصر الضبط المُعَدّة بكتابة الأمر التالي:

$ git config --list

وسيكون ضبط غيت على النحو التالي:

user.name=Your Name
user.email=youremail@domain.com

من المُلاحظ اختلاف هذه الصياغة اختلافًا طفيفًا، فالمعلومات مخزنةٌ في ملف ضبط غيت الخاص بك، الذي تستطيع تعديله يدويًا إذا أردت بمحرر نصوص، مثل نانو nano على النحو التالي:

$ nano ~/.gitconfig

وستظهر لك محتويات الملف "gitconfig./~" المشابهة لما يلي:

[user]
    name = Your Name
    email = youremail@domain.com

عندما تنتهي من تعديل ملفك، اضغط مفتاحي "ctrl" و"x" للخروج من محرر النصوص نانو، وعندما ترد رسالة حفظ الملف اضغط على مفتاح "y".

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

الخاتمة

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

تُعَد مساهمتك في البرامج مفتوحة المصدر طريقةً رائعةً للانخراط في مجتمع المطوّرين العام، والحرص على أن يكون البرنامج المُقدَّم للجميع مُتسمًا بالجودة العالية وممثلًا لكافة المستخدمين النهائيين.

ترجمة -وبتصرف- للمقال How To Contribute to Open Source: Getting Started with Git لصاحبته Lisa Tagliaferri.

اقرأ أيضًا

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

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

كان إنشاء مواقع الويب، إلى عهد قريب، بسيطًا للغاية وسحريًا في آن واحد. في الأزمان الغابرة للإصدار الأول من الويب Web 1.0 (هذا المصطلح لم يكن مستخدمًا حينها) كان بإمكانك زيارة أي موقع ويب، واستعراض شفرته المصدرية ثم برمجة ملفات HTML عكسيًّا (Reverse engineering)، بتنسيقاته السطرية وتصميمه المعتمد على الجداول، وتعدُّ نفسك مبرمجًا خلال يوم أو اثنين. لكن لا يزال عليك وضع الموقع الذي أنشأته على الويب، بمعنى أنك ستتعامل مع الخوادم وبروتوكولات نقل الملفات وصلاحيات مجلدات الجذر على الخادم. رغم أن المواقع الحالية أكثر تعقيدًا موازنةً بذلك الوقت إلا أن نشر موقعك بنفسك صار أسهل، وسيزداد سهولة عند استعمالك Git.

أنشئ موقعًا باستعمال Hugo

Hugo هو مولّد مواقع ساكنة (Static site generator) مفتوح المصدر. المواقع الساكنة هي ما كونت الإنترنت سابقًا (إذا عدنا بالزمن بعيدًا بما فيه الكفاية، لم يكن على الويب غيرها). هنالك عدة نقاط قوة لهذه المواقع الساكنة:

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

Hugo ليس المولدّ الوحيد للمواقع الساكنة، يقدِّم Grav، وPico، وJekyll، وPodwrite وبرامج أخرى طرقًا سهلة لإنشاء مواقع إنترنت مكتملة الوظائف وبالكاد تتطلب أعمال صيانة. لكن Hugo لديه تكامل مع خدمات GitLab بشكل مدمج، أي يمكنك إنشاء واستضافة موقعك باستعمال حساب GitLab مجاني.

أضف إلى ذلك امتلاك Hugo قاعدته الجماهيرية الخاصة، مثلا إنْ سبق واستعملت موقع Let's Encrypt فأنت بالفعل قد جربت موقعًا مبنيًا باستعمال Hugo.

تثبيت Hugo

يمكنك إيجاد إرشادات لتثبيت Hugo على أجهزة ماك، وويندوز، ولينكس وتوزيعات BSD، إذ يعدُّ عابرًا للمنصات.

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

$ sudo dnf install hugo

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

$ hugo help

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

ابدأ بإنشاء موقعك

لبناء موقع باستعمال Hugo، لابد من إنشاء بنية مجلدات بهيكلة خاصة، وهو ما يقوم به Hugo نيابة عنك عند تنفيذ الأمر التالي:

$ hugo new site mysite

هكذا أنشأت مجلّدًا باسم mysite يحوي جميع المجلدات الافتراضية اللازمة لبناء موقعك.

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

$ cd mysite
$ git init

كما أوضحنا سابقًا، Hugo متكامل مع خدمة Git، لذا يمكنك استعمال Git لتثبيت سمات لموقعك. إنْ لم تكن تخطّط لتطوير تصميم الموقع بنفسك، فيمكنك استعمال الخيار (depth--) لنسخ آخر إصدار من مصدر التصميم المختار كالتالي:

$ git clone --depth 1 \ 
https://github.com/darshanbaral/mero.git\
theme/mero

والآن لنُضف بعض المحتوى لموقعك:

$ hugo new posts/hello.md

استخدم محررك النصي المفضل لتعديل ملف hello.md على مسار content/posts.

يقبل Hugo الملفات المرمزة بمارك داون ويحولها إلى منشورات بترميز HTML لذلك يفضل كتابة وتنسيق المحتوى بترميز markdown.

إذا رغبت بإضافة الصور إلى منشوراتك، أنشئ مجلدًا باسم images في المسار الافتراضي. ضع جميع الصور بداخل هذا المجلد وقم بالإشارة إليها من ملف ماركداون مستعملًا المسار المطلق (Absolute path) أي بادئًا بمسار مجلد الصور (images/) كمثال:

![صورة لشيء](/images/thing.jpeg)

اختر تصميمك

يمكنك العثور على المزيد من القوالب في themes.gohugo.io، لكن يفضل استعمال التصميم الافتراضي أثناء فترة الاختبار. التصميم الأساسي لدى Hugo يسمى Ananke. بعض التصاميم لديها متطلبات معقدة وأخرى لا تقوم بتنسيق الصفحات بالشكل المتوقع بدون الدخول في ترتيبات متقدمة. تصميم Mero الذي سنستخدمه في المثال التالي يأتي ملحقًا بملف ضبط متخصص (config.toml)، ولكن بهدف التبسيط سنقتصر على ذكر الأساسيات فقط.

افتح باستخدام محرر نصوص الملف config.toml وأضف خيارات الضبط التالية:

languageCode = "en-us"
title = "My website on the web"
theme = "mero"

[params]
author = "Seth Kenlon"
description = "My hugo demo"

تحدّد الإعدادات أعلاه ترميز لغة الموقع (الإنكليزية الأمريكية en-us)، وعنوانه، والسمة المستخدمة، إضافة إلى اسم صاحب الموقع ووصفه.

معاينة موقعك

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

$ hugo server --buildDrafts --disableFastRender

أدخل العنوان http://localhost:1313 في متصفحك لتستعرض عملك الحالي.

النشر على GitLab باستخدام Git

لنشر واستضافة موقعك لدى GitLab، أنشئ مستودعًا لمحتوى موقعك. لإنشاء ذلك المستودع أضغط على زر إنشاء مشروع جديد (New Project) الموجود على صفحة مشاريع GitLab الخاصة بك، أنشئ مستودعًا فارغًا باسم (yourGitLabUsername.gitlab.io) مع إبدال yourGitLabUsername باسم المستخدم الخاص بحسابك على GitLab. من المهم استخدام هذا الاسم كاسم لمشروعك أيضًا ويمكنك لاحقًا تخصيص اسم نطاق لموقعك.

لا تُضِف ترخيصًا أو ملف "اقرأني" (README). في البداية، تعقّد إضافة الملف إلى المستودعات المنشأة محليَّا من مهمة إرسال البيانات إلى GitLab. يمكنك إضافة تلك الملفات لاحقا.

اضبط المستودع الفارغ على GitLab - بعد إنشائه - إلى إعدادات المجلّد الخاص بموقعك، وهو المجلّد الذي أعددناه سابقًا ليكون مستودع Git:

$ git remote add origin git@gitlab.com:skenlon/mysite.git

أنشئ ملفًا باسم gitlab-ci.yml لضبط إعدادات GitLab، وأدرج به الخيارات التالية:

image: monachus/hugo

variables: 
GIT_SUBMODULE_STRATEGY: recursive
pages:
    script:
        - hugo
    artifacts:
    paths:
       - public
   only:
       - master

يُعرِّف المعامل image حاوية الصور المستخدمة في موقعك. التعليمات الأخرى تمثّل في مجملها إرشادات لتهيئة خوادم GitLab للاستجابة بفعالية عندما ترسل شفرة مصدرية إلى مستودعك البعيد. اقرأ االتوثيق في القسم المختص على GitLab لمزيد من التفاصيل عن النشر والتكامل المستمرّيْن (CI/CD).

تحديد الاستثناءات

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

أولًا، أضف مسار (public/) الذي أنشأه Hugo مسبقًا عند إنشائه مشروع الموقع، أضفه إلى ملف (gitignore.). لست بحاجة لإدارة موقعك في شكله النهائي على Git، ما ستحتاجه هو تتبع التغييرات على الملفات المصدرية لمشروع Hugo.

$ echo "/public" >> .gitignore

أمر آخر، لا يمكن الحفاظ على مستودع Git داخل مستودع Git آخر إلّا باستخدام وحدة فرعية (Submodules). لتسهيل الأمور انقل المجلد git. من مجلّد السمات (themes) إلى مجلّد آخر ليبقى مجلد السمات خاصًّا بالتصميم فقط.

$ mv themes/mero/.git ~/.local/share/Trash/files/

يمكنك استعمال سلة مهملات مثل Trashy بديلًا عن الأمر السابق:

$ trash themes/mero/.git

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

هنا يمكنك إضافة جميع محتويات مشروعك من على مجلد جهازك ورفعها على GitLab:

$ git add .
$ git commit -m 'hugo init'
$ git push -u origin HEAD

انشر موقعك على الويب

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

بينما تنتظر GitLab ليقوم بتجميع موقعك، اذهب لصفحة الضبط واعثر على لوحة التحكم بالصفحات (Pages). عندما يجهز موقعك ستُزوَّد برابط URL الخاص به. وكما أسلفنا سيكون العنوان مشابهًا للتالي (yourGitLabUsername.gitlab.io/yourProjectName). تصفح ذلك العنوان لترى ثمرة أعمالك.

إذا حدث خطأ ما في تجميع الموقع، سيزودك GitLab بسجلات موقعك على قسم CI/CD. تصفح رسائل الخطأ لتحديد سبب المشكلة.

Git والويب

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

ترجمة -وبتصرف- للمقال Build and host a website with Git لصاحبه Seth Kenlon.

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

بعد ذلك، غرّد حول الموضوع مدعيا أن فريقك يستخدم التكامل المستمر.

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

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

ما هو التكامل المستمر؟

في الوقت الحاضر، تُطوّر البرمجيات في فرق نعمل على تطوير فروعٍ للميزات وعزل التعديلات أثناء تطويرها. ثم ندمج الفروع في فرع رئيسي master. وبعد كل عملية دمج، يُختبر المنتج بالكامل، وتُنفّذ جميع اختبارات الوحدة والتكامل المتاحة. وهذا ما يسمى «التكامل المستمر» (continuous integration ويعرف أيضا بالاختصار "CI").

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

هناك بعض الأدوات الجيدة المتاحة في السوق، والتي تُؤتمت إجراءات DevOps. بعضها مفتوح المصدر يمكنك تنزيله وتثبيته على الخوادم الخاصة بك. نذكر منها على سبيل المثال: Jenkins و Go و CruiseControl. وبعضها الآخر متاح كخدمات سحابية، مثل: Travis و Shippable و Wercker وغيرها الكثير.

لماذا لم يعد التكامل المستمر صالحًا؟

إن التكامل المستمر رائعٌ، ولكن في أغلب الأحيان كلما كان الفريق أكبر (وقاعدة الشيفرة كذلك)، كلما تعطلت الإنشاءات وكلما طالت المدة لإصلاحها. لقد رأيت العديد من الأمثلة يبدأ فيها فريق يعمل بجِدٍّ بتجاهل التنبيهات الحمراء، التي يرسلها Jenkins. بعد بضعة أسابيع، يصبح الفريق ببساطة غير قادر على إصلاح جميع الأخطاء في الوقت المناسب. وهذا، في الغالب، لأن العمل له أولويات أخرى. إذ لا يفهم مالكو المنتجات أهمية "البنية النظيفة" ولا يمكن للمدراء التقنيين شراء الوقت لتثبيت اختبارات الوحدة. كما أن الشيفرة المكسورة تكون أصلا في الفرع الرئيسي master، و في معظم الحالات، تكون قد نُشرت بالفعل على الإنتاج وسُلّمت للمستخدمين النهائيين. فما الحاجة إذن لإصلاح الاختبارات إذا كان العمل قد سُلّم فعليًا؟

اقتباس

لا يفهم مالكو المنتجات أهمية "البنية النظيفة" ولا يمكن للمدراء التقنيين شراء الوقت لتثبيت اختبارات الوحدة

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

ما هو الحل؟

منذ بضع سنوات، نشرت مقالًا بعنوان "منع التعارضات في مشاريع PHP الموزّعة والمرنة". اقترحت في المقالة حلولًا لهذه الإشكالات في Subversion و PHP.

منذ ذلك الوقت، استخدمت هذا النهج تجريبيًا في عدد من المشاريع مفتوحة المصدر وبعض المشاريع التجارية أيضا في PHP وجافا وروبي وجافاسكريبت و Git و Subversion. في جميع الحالات، كانت تجربتي إيجابية، ولهذا السبب رأى rultor.com النور لاحقًا.

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

بمعنى آخر، يجب أن تظهر تلك العلامة الحمراء للتنبيه قبل أن تنتقل الشيفرة إلى الفرع الرئيسي master. ويجب أن يتحمّل مسؤولية الاختبارات المكسورة من تسبّب فيها.

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

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

إنشاءات ما قبل الإقلاع

تقدم بعض خوادم التكامل المستمرّ CI ميزة "إنشاءات ما قبل الإقلاع"، وهذا يعني اختبار الفروع قبل دمجها في master رئيسي. لدى Travis، على سبيل المثال، هذه الميزة المفيدة للغاية. عندما تقوم بإيداع جديد في فرع ما، يحاول Travis إنشاءه على الفور، ويُبلغ عبر طلبات الإضافة في GitHub عن أي مشاكل قد تحدث.

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

موقع Rultor.com

من أجل البدء في العمل وفق ما هو موضح أعلاه، كل ما عليك فعله هو إلغاء أذونات الكتابة في الفرع الرئيسي master (أو ‎/trunk، في Subversion).

لسوء الحظ، هذا غير ممكن في GitHub. الحل الوحيد هو العمل من خلال الفروع وطلبات السحب فقط. ما عليك سوى إزالة الجميع من قائمة المتعاونين (collaborators) وسيكون عليهم إرسال تعديلاتهم من خلال طلبات السحب.

بعد ذلك، ابدأ في استخدام موقع rultor.com الذي سيساعدك على اختبار كل طلب للإضافة ودمجه ودفعه. في الأساس، Rultor هو السيناريو الذي كنا نتحدث عنه أعلاه، وهو متاح كخدمة سحابية مجانية.

ترجمة -وبتصرف- للمقال Master Branch Must Be Read-Only لصاحبه Yegor Bugayenko

يشرح هذا الفيديو كيفية استخدام GitHub Pages لاستضافة الصفحات. وسنشرح فيه صفحات المشاريع، وصفحات المستخدم أو المنظمة.

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

قسم Git في أكاديمية حسوب غني بالمقالات المفيدة حوله.

نشرح طريقة الاتصال بخدمة GitHub عبر SSH، وذلك بتوليد زوج المفاتيح مفتاح عام يضاف إلى إعدادات GitHub ومفتاح خاص نحتفظ به لدينا للمصادقة.