البحث في الموقع

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

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

يسألني الناس أينما ذهبت - في المؤتمرات، المحاضرات، لدى وكالات تطوير المواقع وغيرها - عن ملف composer.lock. يبدو وكأن الأمر يتعلّق بلغز يزرع الشكوك حول المعمورة! أقدّم لك هذا المقال لتوضيح ماهية هذا الملف وفكّ اللغز الذي يمثّله. يعدّ Composer أداة تدير الإصدارات الخاصة بمكتبات PHP التي يستخدمها المطوّرون في مشاريعهم البرمجية. سأفترض - لأغراض هذا المقال - أنه سبق لك استخدام Composer في مشاريع سابقة. فلنفترض أن لدينا مشروع PHP جديدا ندير اعتماديّاته Dependencies عن طريق Composer. نبدأ بملف composer.json الذي يُستخدَم لإعداد لائحة بالاعتماديّات التي نريد تثبيتها. يبدو الملف على النحو التالي: { "require": { "assassins/ezio": "1.1.0", "assassins/edward": "1.1.2", "templars/shay": "1.1.*", } } عرّفنا بوضوح الإصدارات التي نحتاجها بالنسبة للحزمتين الأولى والثانية؛ إلا أن الأمر مختلف قليلا يالنسبة للحزمة الثالثة templars/shay التي حدّدنا لها بطريقة أكثر مرونة فلم نعرّف إصدار الترقيع Patch version؛ وبالتالي سيكون أي ترقيع للإصدار 1.1 مناسبا للمشروع. تنبغي ملاحظة أن هذه الأسماء المذكورة في الشفرة أعلاه هي أسماء مفترضة لحزم وليست حزما حقيقية يمكن تثبيتها. يمكن القول إن ملف composer.json هو دليل “تقريبي” للإصدارات التي نريد تثبيتها؛ فاستخدام ماسك المكان * يجعل إصدارات عدّة متوافرة لاستخدامها. بمعنى آخر، يحدّد الملف هامشا مقبولا لهرميّة الاعتماديّات في التطبيق. لا يوجد لدينا لحدّ الساعة، أي في بداية المشروع، ملفّ composer.lock؛ إلا أنه سيظهر بعد تنفيذنا للأمر composer install. نجد مباشرة بعد تنفيذ الأمر composer install ملفّا غريبا باسم composer.lock في المجلّد الجذر للمشروع. إن ألقيت نظرة على ما بداخله فستجد أنه كبير نوعا ما. حان الوقت الآن لكشف اللّغز. في الواقع؛ الملف composer.json هو دليل تقريبي - كما قلنا - لإصدارات الاعتماديّات التي يتوجّب على Composer تثبيتها، بينما الملف composer.lock هو تسجيل دقيق بالإصدارات التي ثُبِّتت عند تنفيذ الأمر composer install. أي أنه يسجّل ما ثبّته Composer من مكتبات لمشروعك. في ما يلي مثال بسيط: "source": { "type": "git", "url": "https://github.com/templars/shay.git", "reference": "98c313c831e5d99bb393ba1844df91bab2bb5b8b" }, هل ترى سلسلة المحارف الطويلةَ تلك؟ هذا هو المعرّف الدقيق لإيداع Commit الإصدار المثبّت عندما اتّبع Composer تعليمات composer.json. يحتفظ الملف composer.lock كذلك بجميع إصدارات الاعتماديّات التي تتطلّبها اعتماديّات المشروع؛ والمكتبات التي تقوم عليها اعتماديّات اعتمديّات المشروع.. وهكذا دواليك. يعني هذا أن الملف composer.lock يحوي التسلسل الهرمي الكامل لاعتماديّات التطبيق. في ماذا يفيد وجود التسلسل الهرمي لاعتماديّات المشروع في الملف composer.lock؟ حسنا؛ يمكن أن تجرّب حذف المجلّد الذي توجد به اعتماديّات المشروع، مثلا vendor في Laravel؛ ثم تنفيذ الأمر composer install من جديد. سيجد Composer هذه المرة أن لديك ملفّ composer.lock وبدلا من البحث عن إصدارات متوافقة مع تعليمات الملف composer.jsonفسيلجأ إلى الإصدارات الدقيقة المذكورة في الملف composer.lock ويثبّتها. يعني هذا أننا سنحصُل على نفس المكتبات التي حذفناها بحذف مجلّد الاعتماديّات. سؤال آخر.. هل يجب تضمين الملف composer.lock في مستودع Git؟ يجب أن تكون الإجابة الآن واضحة. إن أردت تسجيل الإصدارات الدقيقة للاعتماديّات التي استخدمتها في المشروع فالإجابة هي نعم؛ وهذا هو الواقع في أغلب المشاريع. إن كنت تعمل ضمن فريق مطوّرين فإن جعل الملف composer.lock في المستودع يضمن أن الجميع يستخدم نفس الإصدارات؛ الأمر الذي يمكن أن يكون مفيدا في تنقيح Debugging الأخطاء التي تظهر لدى مطوّر واحد فقط من الفريق. إن كنت توزّع تطبيقك عبر Git فإن تضمين الملف composer.lock في المستودع سيضمن أن إصدارات الاعتماديّات التي استخدمتها في التطوير وأجريت عليها الاختبارات هي نفسها المستخدمة في بيئة الإنتاج. لماذا من المهم استخدام نفس إصدارات الاعتماديّات؟ فلنفترض أن Git يتجاهل وجود الملف composer.lock. تنفّذ الأمر composer install، يبحث Composer عن آخر ترقيع للإصدار 1.1 من الحزمة templars/shay فيجد الإصدار 1.1.4 ويثبّته. تعمل على المشروع باستخدام الإصدار 1.1.4، وفي هذه الأثناء يقدّم فريق الحزمة templars/shay الإصدار 1.1.5 الذي - لسوء الحظ - يتضمّن علة برمجيّة Bug حرجة. عندما تنشُر مشروعك على بيئة الإنتاج يثبّت Composer - بالاعتماد على تعليمات الملف composer.json - الإصدار 1.1.5 من الحزمة الذي يحوي علّة تمنع تطبيقك من العمل على النحو الذي تريده. يمكنك استنتاج أنه لو كان الملف composer.json في المستودع لأدّى تنفيذ الأمر composer install في بيئة الإنتاج إلى تثبيت الإصدار 1.1.4 من الحزمة templars/shay الذي سبق لك اختبار التطبيق معه. باختصار: في الأخير.. متى يتغيّر الملف composer.lock ولأي سبب؟ أرى طوال الوقت مطورين ينفّذون الأمر composer update كلّما حدّثوا الملف composer.json، للحصول على الحزم الجديدة التي أضافوها إلى الملف. في الواقع هذا الأمر خاطئ! يجب أن تستخدم الأمر composer install بدلا من ذلك، إذ أنه يثبّت الحزم الجديدة دون تحديث إصدارات الحزم الأخرى؛ هذه الطريقة آمن كثيرا. في ما يلي لائحة بإجراءات تتسبّب في تحديث الملف composer.lock: تنفيذ الأمر composer install للمرة الأولى. يُنشَأ الملف composer.lock لتسجيل الإصدارات الدقيقة للاعتماديّات المثبّتة. تنفيذ الأمر composer install بعد إضافة حزم جديدة. يُضاف الإصدار الدقيق للحزمة إلى الملف composer.lock. تنفيذ الأمر composer update. تُحدَّث إصدارات جميع الحزم إلى الترقيع الأخير بما يتوافق مع تعليمات الملف composer.json، وهو ما ينتُج عنه تحديث الإصدارات الدقيقة في الملف composer.lock. تنفيذ الأمر composer update package/name لتحديث الحزمة المذكورة إلى آخر ترقيع، بما يتوافق مع تعليمات الملف composer.json، وبالتالي يُحدَّث الملف composer.lock ليعكس التغيير الحاصل في إصدار الحزمة. يعني ما سبق أن composer install أمر “آمن”، ولن ينتُج عنه سوى إضافة حزم جديدة إلى الملف composer.lock (وليس تحديث حزم موجودة مسبقا). في حين أن الأمر composer update أمر “خطِر”، إذ أنه يتسبّب في تغيير مباشر على الإصدارات الدقيقة الموجودة في الملف composer.lock . أرجو أن يكون الملف اللغز composer.lock قد اتّضح لك بعد قراءة هذا المقال. إن كنت تعلّمت شيئا أو اثنين من هذا المقال فأرجو أن تشاركه مع أصدقائك حتى يعرفوا هم أيضا سر الملف العظيم. ترجمة - بتصرّف - للمقال PHP: The Composer Lock File لصاحبه Dayle Rees. حقوق خلفية الصورة البارزة محفوظة لـ Freepik

نظام التحكم بالإصدارات Gitإن Git هو نظام تحكم بالإصدارات موزَّع (distributed) ومفتوح المصدر مطوَّر من لينوس تورفالدس لدعم تطوير نواة لينُكس؛ حيث يكون كل مجلد في Git عبارة عن مستودع مع تأريخ كامل وإمكانيات لتتبع الإصدارات، وليس متعمِدًا على الوصول على الشبكة أو على خادوم مركزي. التثبيتيمكن تثبيت نظام التحكم بالإصدارات git باستخدام الأمر الآتي: sudo apt-get install gitالضبطيجب لكل مستخدم git أن يعرِّف نفسه أولًا إلى git، وذلك بتنفيذ الأمرّين الآتيين: git config --global user.email "you@example.com" git config --global user.name "Your Name"الاستخدام الأساسيما سبق يكفي لاستخدام git في طريقة موزعة وآمنة، حيث يُفترَض أنَّ المستخدمين يستطيعون الوصول إلى الخادوم عبر SSH؛ حيث يمكن إنشاء مستودع جديد على الخادوم بالأمر: git init --bare /path/to/repositoryملاحظة: الأمر السابق يُنشِئ مستودعًا «فارغًا» (bare)، أي أنه ليس بالإمكان استخدامه للتعديل على الملفات مباشرةً. إذا أردت الحصول على نسخة من محتويات المستودع على الخادوم، فاحذف الخيار ‎--bare. يمكن لأي عميل يملك وصولًا عبر SSH إلى الخادوم أن ينسخ المستودع بالأمر: git clone username@hostname:/path/to/repositoryبعد نسخ الملفات إلى جهاز العميل، يمكنه تعديلها ثم إيداعها ومشاركتها بالأوامر: cd /path/to/repository # edit some files git commit -a # Commit all changes to the local version of the repository git push origin master # Push changes to the server's version of the repositoryتثبيت خادوم gitoliteعلى الرغم من أنّ ما سبق كافٍ لإنشاء ونسخ وتعديل المستودعات، لكن المستخدمين الذين يريدون تثبيت git على خادوم سيريدون عمومًا إنجاز المهام في git كنظام إدارة التحكم بالأكواد المصدرية تقليدي؛ وعند وجود عدِّة مستخدمين وامتيازات وصول لهم، فالحل الأمثل هو تثبيت gitolite كما يلي: sudo apt-get install gitoliteضبط Gitoliteضبط خادوم Gitolite مختلف قليلًا عن معظم الخواديم في الأنظمة الشبيهة بِيونكس؛ فبدلًا من ملفات الضبط التقليدية في ‎/etc/‎، فإن gitolite يُخزِّن الضبط في مستودع git؛ أول خطوة لضبط تثبيت جديد هي السماح بالوصول إلى مستودع الضبط. أولًا، علينا إنشاء مستخدم لأجل gitolite لكي نصل إليه عبره: sudo adduser --system --shell /bin/bash --group --disabled-password --home /home/git gitسنترك الآن gitolite لكي يعرف عن مفتاح SSH العمومي لمدير المستودع؛ هنا نفترض أن المستخدم الحالي هو مدير المستودع؛ إذا لم تضبط مفتاح SSH بعد، فراجع الدرس الخاص بخادوم OpenSSH لمزيدٍ من التفاصيل: cp ~/.ssh/id_rsa.pub /tmp/$(whoami).pubلنبدِّل إلى المستخدم git ونستورد مفتاح المدير إلى gitolite: sudo su - git gl-setup /tmp/*.pubسيسمح Gitolite لك بعمل تغيرات مبدئية لضبطه أثناء عملية الإعداد؛ يمكنك الآن نسخ وتعديل مستودع ضبط gitolite من المستخدم المدير (المستخدم الذي استوردت مفتاح SSH العمومي الخاص به)؛ عُد إلى ذاك المستخدم، ثم انسخ مستودع الضبط: exit git clone git@$IP_ADDRESS:gitolite-admin.git cd gitolite-adminالمجلد gitolite-admin فيه مجلدين فرعيين، المجلد «conf» و «keydir»؛ ملفات الضبط موجودة في مجلد conf، ويحتوي مجلد keydir على مفاتيح SSH العمومية للمستخدم. إدارة مستخدمي ومستودعات gitoliteإضافة مستخدمين جدد إلى gitolite هي عملية سهلة: احصل على مفتاح SSH العمومي لهم ثم أضفه إلى مجلد keydir بالاسم USERNAME.pub، لاحظ أن أسماء مستخدمي gitolite لا تطابق بالضرورة أسماء مستخدمي النظام، حيث تُستخدَم أسمائهم في ملف ضبط gitolite فقط، وذلك لإدارة التحكم بالوصول؛ وبشكل مشابه، يمكن حذف المستخدمين بحذف ملف المفتاح العمومي الخاص بهم؛ ولا تنسَ أن تودع التغييرات وتدفعها إلى خادوم git بعد كل تعديل: git commit -a git push origin masterتُدار المستودعات بتعديل الملف conf/gitolite.conf؛ الشكل العام له هو قيود مفصولة بفراغات تُحدِّد ببساطة قائمةً بالمستودعات ثم بعض قواعد الوصول؛ ما يلي هو المثال الافتراضي لهذا الملف: repo gitolite-admin RW+ = admin R = alice repo project1 RW+ = alice RW = bob R = deniseاستخدام خادومكلاستخدام الخادوم المُنشَأ حديثًا، يجب أن يستورد مدير gitolite مفاتيح المستخدمين العمومية إلى مستودع ضبط gitolite، ثم يمكنهم الوصول إلى أي مستودع لهم حق الوصول إليه عبر الأمر الآتي: git clone git@$SERVER_IP:$PROJECT_NAME.gitأو إضافة مشروع في الخادوم عن بعد: git remote add gitolite git@$SERVER_IP:$PROJECT_NAME.gitترجمة -وبتصرف- للمقال Ubuntu Server Guide: Git.

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

يعرض هذا المقال أساسيات التفريع والدمج في Git. نبدأ بمثال سهل لسيناريو يحدث كثيرا أثناء تطوير البرمجيات ونرى كيفية تطبيقه على التفريع والدمج. لنفترض حدوث الخطوات التالية: كنت تعمل على موقع ويب وأنجزت الجزء الأهم وهو الآن مفتوح للزوار. أنشأت تفريعا جديدا وبدأت العمل على ميزات ستضيفها لاحقا للموقع. عند هذه النقطة وردك اتصال يخبرك عن مشكل في الموقع. المشكل خطير ويحتاج حلا سريعا. تنتقل لنسخة الموقع الموجودة على بيئة الإنتاج (إصدار الموقع المفتوح للزوار). أي أنك انتقلت للتفريع الذي أطلقت منه الموقع (وليكن التفريع master). تنشئ تفريعا جديدا انطلاقا من تفريع الإنتاج بهدف إصلاح الخلل (الترقيع). تعمل على التفريع الجديد وتختبر التعديلات حتى تتأكد من جاهزيتك لإضافتها إلى بيئة الإنتاج. تدمج تفريع الترقيع مع تفريع الإنتاج وتدفع التغييرات إلى الموقع. أصلحت المشكل وبإمكانك الآن العودة إلى تفريع تحسين الميزات الذي كنت تعمل عليه قبل ورود الاتصال. المبادئ الأساسية للتفريع نفرض أنك تعمل على مشروع سبق أن أضفت إليه إيداعين. سجل إيداعات مستقيم قررت أنك ستعمل على إضافة الميزة رقم 53. تنشئ لهذا الغرض تفريعا جديدا. لإنشاء تفريع والانتقال للعمل عليه في نفس الوقت نستخدم الأمر git checkout مع الخيار b-: git checkout -b iss53 Switched to a new branch "iss53" هذا الأمر هو اختصار للأمرين: git branch iss53 git checkout iss53 إنشاء مؤشر تفريع جديد تنفيذ أمر git checkout يعني نقل المؤشر HEAD ليحيل إلى التفريع iss53. استمريت في العمل على موقعك، وتنفيذ إيداعات: vim index.html git commit -a -m 'added a new footer [issue 53]' وهو ما يجعل التفريع iss53 يتقدم بتتالي الإيداعات: تقدّم التفريع iss53 بتوالي الإيداعات يأتي الآن الاتصال الذي ينبئ بوجود مشكل في الموقع؛ ويجب التغلب على هذا المشكل في أقرب وقت. لا تحتاج مع Git لنشر الترقيع العاجل مع ترقيع الميزة 53؛ كما أنك لا تحتاج لبذل الكثير من الجهد للتراجع عن التعديلات التي أضفتها أثناء عملك على الميزة 53 حتى تعود إلى حالة الموقع الموجود الآن أمام الزوار. كل ما عليك فعله هو العودة إلى التفريع الرئيس master وترك التفريع iss53 لحين الفراغ من العمل العاجل. انتبه إلى أن Git لن يسمح لك بالانتقال إلى تفريع جديد إن كان مجلد العمل أو منطقة الإدراج يحوي تغييرات تتعارض مع التفريع الذي تريد الانتقال إليه. توجد طرق للالتفاف حول هذا الأمر، وهي ادّخار الإيداعات Stashing وتصحيحها Amending وهو ما سنتطرّق إليه لاحقا عند الحديث عن الادّخار والتنظيف Cleaning. سنفترض في الوقت الحالي أن جميع التعديلات أودعت وبإمكننا الانتقال إلى التفريع الرئيس: git checkout master Switched to branch 'master' يكون مجلد العمل في المشروع بالوصول إلى هذه النقطة مماثلا تماما لما كان عليه قبل بدء العمل على الميزة 53، ويمكنك الآن التركيز على العلة العاجلة. من المهم تذكر هذا الأمر: يعيد Git عند الانتقال إلى تفريع، مجلد العمل إلى ما كان عليه بعد آخر مرة نفّذت فيها إيداعا على هذا التفريع. فيضيف ملفات وينقل أخرى أو يغيرها تلقائيا للتأكد من أن نسخة مجلد العمل مطابقة لما كان عليه بعد آخر عملية إيداع على التفريع. لدينا ترقيع عاجل يجب إصداره. ننشئ تفريعا خاصا hotfix للعمل على إصدار ترقيع في أقرب وقت: git checkout -b hotfix Switched to a new branch 'hotfix' vim index.html git commit -a -m 'fixed the broken email address' [hotfix 1fb7853] fixed the broken email address 1 file changed, 2 insertions(+) إنشاء تفريع hotfix انطلاقا من التفريع master يمكن الآن اختبار التعديلات والتأكد من أن الترقيع يؤدي العمل المطلوب ثم بعد ذلك ندمج التفريع hotfix (باستخدام أمر git merge) مع التفريع الرئيس لنشره على بيئة الإنتاج. ننفذ الأوامر التالية لهذا الغرض: git checkout master git merge hotfix Updating f42c576..3a0874c Fast-forward index.html | 2 ++ 1 file changed, 2 insertions(+) لاحظ جملة fast-forward (تقدّم سريع) بعد تنفيذ أمر الدمج. يعود السبب في ذلك إلى أن الإيداع الذي يشير إليه التفريع الذي دمجت فيه يوجد ضمن سوابق الإيداع الذي دمجته. بعبارة أخرى؛ عندما تريد دمج إيداع “أ” مع إيداع “ب” يوجد من بين سوابق الإيداع المدموج ("أ") فإن Git يسهّل الأمر بتقديم مؤشر التفريع “ب” ليحيل إلى الإيداع “أ”؛ يفعل Git هذا الأمر بسبب عدم وجود إيداعات متنافرة بين التفريعين لدمجها. بمعنى أنه في حالتنا لم يطرأ أي إيداع على التفريع master منذ إنشاء التفريع hotfix. نقول في هذه الحالة إن Git أجرى تقدما سريعا fast-forward. توجد التعديلات الآن في اللقطة التي يشير إليها التفريع master ويمكن نشر الترقيع ليصبح متاحا للعموم. التقدم السريع للتفريع master إلى التفريع hotfix أنت جاهز بعد نشر الترقيع العاجل للعودة إلى العمل الذي انقطعت عنه. لكن يجب أولا حذفُ تفريع hotfix الذي لم تعد تحتاج إليه؛ تفريع master يشير الآن إلى نفس الإيداع. يمكن حذف التفريع hotfix باستخدام أمر git branch مع خيار d-: git branch -d hotfix Deleted branch hotfix (3a0874c). يمكن العودة إلى التفريع iss53 واستكمال العمل على الميزة 53: git checkout iss53 Switched to branch "iss53" vim index.html git commit -a -m 'finished the new footer [issue 53]' [iss53 ad82d7a] finished the new footer [issue 53] 1 file changed, 1 insertion(+) استكمال العمل على الميزة 53 يجب الانتباه هنا إلى أن العمل المضاف إلى التفريع hotfix غير موجود في ملفات التفريع iss53. يوجد لديك خياران لإضافة تعديلات hotfix؛ إما دمج التفريع الرئيس في تفريع iss53 أو الانتظار حتى تكمل العمل على التفريع iss53 ثم تدمجه في التفريع الرئيس. المبادئ الأساسية لدمج التفريعات أكملت العمل على الميزة 53 وأنت جاهز لدمجها في التفريع الرئيس. يجري دمج التفريع iss53 في التفريع الرئيس بنفس الطريقة التي دمجنا بها التفريع hotfix في التفريع الرئيس: الانتقال إلى التفريع الرئيس بالأمر git checkout ثم تنفيذ أمر الدمج: git checkout master Switched to branch 'master' git merge iss53 Merge made by the 'recursive' strategy. index.html | 1 + 1 file changed, 1 insertion(+) يوجد اختلاف بين الدمج في هذه الحالة ودمج التفريع hotfix السابق. مصدر الاختلاف هو حدوث إيداعات على كل من التفريعين بالتوازي؛ الإيداع الذي يشير إليه التفريع الرئيس الآن ليس هو الإيداع الذي كان يشير إليه عند إنشاء التفريع iss53. يعني هذا أن على Git اتخاذ طريقة مغايرة للتقدم السريع آنفة الذكر. ينفذ Git في هذه الحالة ما يعرف بالدمج الثلاثي Three-way merge فيستخدم اللقطتين المشار إليهما في الصورة أدناه والإيداع المشترك بين الفرعين. 3 لقطات مستخدمة في الدمج ينشئ Git، بدلا من تقديم المؤشر إلى آخر إيداع في التفريع iss53 مثل ما فعل مع التفريع hotfix، ينشئ لقطة جديدة ناتجة عن الدمج الثلاثي، وينشئ تلقائيا إيداعا جديدا يشير إلى اللقطة الجديدة. يُسمّى هذا الإيداع بإيداع الدمج Merge commit، ويتميز بكونه جزءا من متتاليتي إيداعات (أي أن له سابقين). إيداع دمج تجدر الإشارة هنا إلى أن Git يحدّد الإيداع الأفضل من بين الإيداعات السابقة لاستخدامه قاعدة للدمج. يختلف الأمر عن نظم إدارة نسخ أخرى مثل CVS وSubversion (قبل الإصدار 1.5) يُطلب فيها من المطور تحديد أفضل قاعدة إيداعات للدمج وفقا لها؛ وهو ما يجعل دمج التفريعات في Git أسهل كثيرا من النظم الأخرى. لم نعد نحتاج الآن، بعد دمج الميزة في التفريع الرئيس، للتفريعة 53. يمكن إغلاق التذكرة Ticket في نظام إدارة التذاكر لديك وحذف التفريع: git branch -d iss53 التعارض في عمليات الدمج لا تجري الأمور دائما بنفس السهولة المذكورة في الفقرة السابقة. إن غيّرت نفس الأجزاء من نفس الملف في فرعين تريد دمجهما فلن يكون بمقدور Git دمجهما بطريقة صحيحة. مثلا، إن عدّل العمل على الميزة 53 والترقيع في التفريع hotfix نفس الجزء من نفس الملف فسيظهر لديك تعارض Conflict في الدمج كما في المثال أدناه: git merge iss53 Auto-merging index.html CONFLICT (content): Merge conflict in index.html Automatic merge failed; fix conflicts and then commit the result. لم ينشئ Git في المثال أعلاه إيداعا للدمج؛ بل أوقف عملية الدمج إلى أن تحل مشكلة التعارض. إن أردت رؤية الملفات التي لم تطلها عملية الدمج بعد فيمكنك تنفيذ الأمر git status: git status On branch master You have unmerged paths. (fix conflicts and run "git commit") Unmerged paths: (use "git add <file>..." to mark resolution) both modified: index.html no changes added to commit (use "git add" and/or "git commit -a") تظهر جميع الملفات التي يوجد بها تعارض يمنع دمجها تحت بند Unmerged (غير مدموج). يضيف Git علامات قياسية لحل التعارض إلى الملفات المعنية ليمكن للمطور فتحها ومن ثم حلّ التعارضات. يحوي الملف فقرة تشبه ما يلي: <<<<<<< HEAD:index.html <div id="footer">contact : email.support@github.com</div> ======= <div id="footer"> please contact us at support@github.com </div> >>>>>>> iss53:index.html يعني هذا أن النسخة التي يحيل إليها المؤشر HEAD هي تلك الموجودة في الأعلى (كل ما يوجد فوق الخط ======)؛ بينما يظهر محتوى الملف الموجود في التفريع iss53 في الأسفل. للتذكير، يحيل المؤشر HEAD إلى التفريع الرئيس الآن، ويعود السبب في ذلك إلى أننا انتقلنا إليه بتنفيذ الأمر git checkout قبل محاولة الدمج. يجب اختيار محتوى أحد الملفين أو دمجهما يدويا. يمكن على سبيل المثال تغيير كامل الجزء المعلّم (يبدأ بـ<<<<<<< وينتهي بـ >>>>>>>) ووضع محتوى جديد مكانه: <div id="footer"> please contact us at email.support@github.com </div> يحوي هذا الحل جزءًا من كل فقرة، ويُلاحظ أن الأسطر >>>>>>>، <<<<<<< و ======= اختفت بالكامل. نفذ أمر git add على كل ملف بعد التخلص من التعارض. إضافة ملف به تعارض إلى منطقة الإدراج في Git يعني أن التعارض في الملف حُلّ. نفّذ أمر git mergetool إن أردت استخدام أداة رسومية لحل التعارضات. يُظهِر الأمر الأداة الرسومية المناسبة لحل التعارضات: git mergetool This message is displayed because 'merge.tool' is not configured. See 'git mergetool --tool-help' or 'git help config' for more details. 'git mergetool' will now attempt to use one of the following tools: opendiff kdiff3 tkdiff xxdiff meld tortoisemerge gvimdiff diffuse diffmerge ecmerge p4merge araxis bc3 codecompare vimdiff emerge Merging: index.html Normal merge conflict for 'index.html': {local}: modified file {remote}: modified file Hit return to start merge resolution tool (meld): اضغط زر Enter للبدء في استخدام الأداة الافتراضية (في المثال أعلاه يظهر اسم الأداة meld بين قوسين لأن المستخدم يشغّل نظام لينكس). إن أردت استخدام أداة مغايرة فيمكنك الاختيار بين الأدوات المدعومة التي يسردها أمر git mergetool مباشرة بعد جملة one of the following tools ثم كتابة اسم الأداة والضغط على زر Enter. يسألك Git بعد الخروج من الأداة ما إذا كان الدمج ناجحا. فإن أجبت بنعم (زر y على لوحة المفاتيح) فإنه يعلمّ الملفات للإشارة لتجاوز التعارض ويضيفها بالتالي إلى منطقة الإدراج. يمكن تنفيذ أمر git statusمرة أخرى للتأكد من أن جميع التعارضات حُلّت: git status On branch master All conflicts fixed but you are still merging. (use "git commit" to conclude merge) Changes to be committed: modified: index.html ثم تنفيذ أمر الإيداع git commit لاستكمال الدمج، بعد التأكد من أن جميع الملفات التي يوجد بها تعارض أضيفت إلى منطقة الإدراج. تبدو رسالة الإيداع المبدئية على النحو التالي (عند تنفيذ أمر git commit بعد دمج الملفات المتعارضة): Merge branch 'iss53' Conflicts: index.html # # It looks like you may be committing a merge. # If this is not correct, please remove the file # .git/MERGE_HEAD # and try again. # Please enter the commit message for your changes. Lines starting # with '#' will be ignored, and an empty message aborts the commit. # On branch master # All conflicts fixed but you are still merging. # # Changes to be committed: # modified: index.html # يمكنك تعديل الرسالة لإضافة تفصيلات عن كيفية حل التعارض إن كنت ترى أن ذلك سيفيد الآخرين عند النظر في هذا الدمج في المستقبل. لماذا فعلت ما فعلت، خصوصا إن لم يكن بديهيا. ترجمة -بتصرف- للفصل Git Branching - Basic Branching and Merging من كتاب Pro Git لصاحبه Scott Chacon.

في هذا الدرس، ستتعلم كيفية استخدام خُطّافات (Git (Git hooks لأتمتة نشر بيئة الإنتاج لتطبيقات Rails على خادم أوبونتو 14.04 عن بُعد. باستخدام خُطّافات Git ستتمكن من نشر التطبيقات عن طريق دفع التغييرات إلى خادم الإنتاج production server، وبدلًا من أن تقوم بكل شيء يدويًّا (مثل ترحيل قاعدة البيانات) فالاستعانة بأحد أشكال النشر الآلي، مثل خُطّافات Git، سيوفر عليك الكثير من الوقت على المدى الطويل. في هذا الدرس سنستخدم خُطّافGit من نوعpost-receive ، بالإضافة إلىPuma كخادم للتطبيق،Nginx كوكيل عكسي لـ Puma و PostgreSQL كقاعدة بيانات. المتطلبات الأساسية سوف تحتاج صلاحيات مستخدم غير جذري non-root والذي يملك امتيازات مستخدم أساسي superuser على خادم أوبونتو. في هذا المثال، سيكون اسم المستخدم deploy. يمكنك تعلم كيفية فعل ذلك في هذا الدرس: الإعداد الابتدائي لخادوم أوبنتو 14.04. إذا كنت ترغب في النشر دون الحاجة لإدخال كلمة المرور، فتأكد من إعداد مفاتيح SSH. سوف تحتاج إلى تثبيت Ruby على خادمك. إذا لم تكن قد فعلت ذلك سلفًا، يمكنك تثبيته جنبًا إلى جنب مع Rails باستخدام rbenv أو RVM. سوف تحتاج أيضًا إلى تطبيق Rails مُدار في مستودع git على جهازك. إذا لم يكن لديك تطبيق في git، فسوف نقدم لك تطبيقًا بسيطًا كمثال لتعمل عليه. لنبدأ على بركة الله. تثبيت PostgreSQL معظم بيئات Rails تستخدم PostgreSQL كقاعدة بيانات، لذلك عليك تثبيته على خادمك الآن. على خادم الإنتاج، قم بتحديث apt-get: sudo apt-get update ثم قم بتثبيت PostgreSQL بهذه التعليمات: sudo apt-get install postgresql postgresql-contrib libpq-dev إنشاء قاعدة بيانات الإنتاج الخاصة بالمستخدم لإبقاء الأمور بسيطةً، سنسمي قاعدة بيانات الإنتاج الخاصة بالمستخدم بنفس اسم التطبيق خاصتك. على سبيل المثال، إذا كان اسم تطبيقك “appname”، فيجب عليك إنشاء مستخدم PostgreSQL بهذه الطريقة: sudo -u postgres createuser -s appname لتعيين كلمة مرور لقاعدة بيانات المستخدم، ادخُل سطر أوامر PostgreSQL هكذا: sudo -u postgres psql بعد ذلك قم بتعيين كلمة المرور لقاعدة بيانات المستخدم “appname” هكذا: \password appname قم بإدخال كلمة المرور التي تريد ثم قم بتأكيدها. اخرج من سطر أوامر PostgreSQL بهذه التعليمة: \q الآن نحن على استعداد لتزويد تطبيقك بمعلومات الاتصال الخاصة بقاعدة البيانات. إعداد تطبيق Rails على جهاز التطوير خاصتك، ستقوم بإعداد تطبيقك لأجل النشر. اختياري: إنشاء تطبيق Rails إن كان لديك تطبيق Rails جاهز للنشر. فيمكنك تخطي هذا القسم والقيام بالتغييرات المناسبة لاحقًا. أمّا إن لم يكن لديك تطبيق جاهز، فإن الخطوة الأولى هي إنشاء تطبيق Rails جديدة. هذه التعليمات ستنشئ تطبيق Rails جديد تحت اسم “appname” في المجلد الرئيسي. لا تتردد في استبدال “appname” بالاسم الذي تريد: cd ~ rails new appname ثم تحوّل إلى مجلد التطبيق: cd appname لأجل تطبيقنا هذا، سوف نقوم بتوليد سقالة scaffold controller لكي يجد تطبيقنا شيءً ليعرضه: rails generate scaffold Task title:string note:text لنتأكدْ الآن من أن تطبيقنا موجود في مستودعgit . تهيئة Git Repo إن لم يكن تطبيقك موجودًا بالفعل في مستودع git لسبب ما، قم بتهيئته وإجراء إلزام أولي initial commit. قم بالتحوّل إلى مجلد التطبيق. في مثالنا، التطبيق يسمى " appname" وهو موضوع في المجلد الرئيسي home directory: cd ~/appname git init git add -A git commit -m 'initial commit' الآن دعونا نُجهّز تطبيقنا لربط الاتصال بقاعدة بيانات الإنتاج لـ PostgreSQL. تحديث إعدادات قاعدة البيانات تحوّل إلى مجلد تطبيقك إن لم تكن بالفعل هناك. في مثالنا، التطبيق يسمى “appname” وهو موضوع في المجلد الرئيسي home directory: cd ~/appname الآن افتح ملف إعداد قاعدة البيانات في محرر النصوص المفضل لديك: vi config/database.yml اعثر على مقطع الإنتاج production section في إعدادات قاعدة بيانات تطبيقك، وقم باستبداله بمعلومات الاتصال بقاعدة بيانات الإنتاج خاصتك. من المفروض أن يبدو كشيء من هذا القبيل (قم باستبدال القيم عند الاقتضاء): config/database.yml excerpt production: <<: *default host: localhost adapter: postgresql encoding: utf8 database: appname_production pool: 5 username: <%= ENV['APPNAME_DATABASE_USER'] %> password: <%= ENV['APPNAME_DATABASE_PASSWORD'] %> احفظ واخرج. هذا الملف يؤكد على أن بيئة الإنتاج الخاصة بالتطبيق ينبغي أن تستخدم قاعدة بيانات PostgreSQL تحت مُسمّى “appname_production” على المضيف المحلي localhost. لاحظ أنه تم إحالة اسم المستخدم وكلمة مرور قاعدة البيانات إلى متغيرات البيئة environment variables. سنقوم بتحديدها على الخادم في وقت لاحق. تحديث Gemfile إذا لم يكن لدى Gemfile خاصتك المكتبة pg (PostgreSQL adapter gem)، ولم تكن المكتبة Puma مُحددة، فيجب عليك إضافتهما الآن. افتح Gemfile الخاص بتطبيقك في المحرّر المفضل لديك: vi Gemfile أضف الأسطر التالية إلىGemfile : Gemfile excerpt group :production do gem 'pg' gem 'puma' end احفظ واخرج. سيحدد هذا النص البرمجي أن بيئة الإنتاج production environment يجب أن تستخدم المكتبات pgوpuma : إعداد Puma قبل إعداد Puma، يجب عليك أن تتحقق من عدد وحدات المعالجة المركزية التي يملكها خادمك. يمكنك بسهولة فعل ذلك على خادمك بهذه التعليمة: grep -c processor /proc/cpuinfo الآن، على جهاز التطوير خاصتك، قم بإضافة إعدادات Puma إلى الإعداد config/puma.rb . افتح الملف في محرر النصوص: vi config/puma.rb انسخ وألصق هذه الإعدادات في الملف: config/puma.rb # Change to match your CPU core count workers 2 # Min and Max threads per worker threads 1, 6 app_dir = File.expand_path("../..", __FILE__) shared_dir = "#{app_dir}/shared" # Default to production rails_env = ENV['RAILS_ENV'] || "production" environment rails_env # Set up socket location bind "unix://#{shared_dir}/sockets/puma.sock" # Logging stdout_redirect "#{shared_dir}/log/puma.stdout.log", "#{shared_dir}/log/puma.stderr.log", true # Set master PID and state locations pidfile "#{shared_dir}/pids/puma.pid" state_path "#{shared_dir}/pids/puma.state" activate_control_app on_worker_boot do require "active_record" ActiveRecord::Base.connection.disconnect! rescue Ac-tiveRecord::ConnectionNotEstablished Ac-tiveRecord::Base.establish_connection(YAML.load_file("#{app_dir}/config/database.yml")[rails_env]) end قم بتغيير العددworkers إلى عدد وحدات المعالجة المركزية لخادمك. يفترض المثال أن لديك اثنان. احفظ واخرج. الآن تم إعداد Puma بموضعlocation تطبيقك وموضع مقبسه socket والمذكرات logs ومعرّفات العمليات PIDS. لا تتردد في تعديل الملف، أو إضافة الخيارات التي تناسبك. ألزمCommit التغييرات الأخيرة: git add -A git commit -m 'added pg and puma' قبل الاستمرار، قم بتوليد المفتاح السري والذي سيتم استخدامه لبيئة الإنتاج الخاصة بتطبيقك: rake secret rake secret sample output: 29cc5419f6b0ee6b03b717392c28f5869eff0d136d8ae388c68424c6e5dbe52c1afea8fbec305b057f4b071db1646473c1f9a62f803ab8386456ad3b29b14b89 سوف تنسخ المُخرجات وتستخدمها لتحديد القيمة SECRET_KEY_BASE الخاصة بتطبيقك في الخطوة التالية. إنشاء النص البرمجي لإطلاق Puma سنقوم بإنشاء نص برمجي للإطلاق (Upstart init script). حتى نتمكن من تشغيل وإيقاف Puma بسهولة، وللتأكد من أنه سيبدأ عند بدء التشغيل. على خادم الإنتاج خاصتك، حمّل أداة Jungle Upstart من مستودع Puma على GitHub وضعها في المجلد الرئيسي: cd ~ wget https://raw.githubusercontent.com/puma/puma/master/tools/jungle/upstart/puma-manager.conf wget https://raw.githubusercontent.com/puma/puma/master/tools/jungle/upstart/puma.conf الآن افتح الملف puma.conf حتى تتمكن من تحرير إعدادات النشر الخاصة بمستخدمPuma : vi puma.conf ابحث عن السطرين الذين يحددان setuid و setgid، و قم باستبدال “apps” باسم النشر الخاص بالمستخدم أو المجموعة خاصتك. على سبيل المثال، إذا كان اسم مستخدم النشر “deploy”، فينبغي أن تكون الأسطر هكذا: puma.conf excerpt 1 of 2 setuid deploy setgid deploy الآن ابحث عن السطر الذي يحتوي:exec /bin/bash <<'EOT'. أضف الأسطر التالية تحته، وتأكد من استبدال اسم المستخدم وكلمة المرور الخاصة ب PostgreSQL، وأضف كذلك rake secret الذي قمت بإنشائه سابقًا: puma.conf excerpt 2 of 2 export APPNAME_DATABASE_USER='appname' export APPNAME_DATABASE_PASSWORD='appname_password' export SECRET_KEY_BASE='rake_secret_generated_above' احفظ واخرج. الآن انسخ النصوص في مجلد خدمات الإطلاق Upstart services: sudo cp puma.conf puma-manager.conf /etc/init النص البرمجي puma-manager.conf يُحدد /etc/puma.conf كمرجع لمعرفة التطبيقات التي يجب إدارتها. دعونا ننشئ ونحرّر هذا الملف الآن: sudo vi /etc/puma.conf كل أسطر هذا الملف يجب أن تتضمن مسارات التطبيقات التي تريد من Puma أن يُديرها. سنقوم بنشر تطبيقنا في مجلد يُسمى “appname” داخل المجلد الرئيسي. في هذا المثال، سيكون كما يلي (تأكد من تعديل المسار ليتناسب مع المكان الذي يتواجد فيه تطبيقك): /etc/puma.conf /home/deploy/appname احفظ واخرج الآن تمّ إعداد تطبيقك لينطلق عند بدء التشغيل بمساعدة Upstart, وهذا يعني أن تطبيقك سيبدأ حتى بعد إعادة إقلاع خادمك. لا تنسى أننا لم ننشر التطبيق حتى الآن، لذلك لسنا جاهزين لتشغيله بعد. تثبيت وإعداد Nginx لجعل التطبيق متاحًا على شبكة الإنترنت، يجب أن تستخدم Nginx كخادم. قم بتثبيت Nginx باستخدام apt-get: sudo apt-get install nginx الآن افتح كتلة الخادم الافتراضي default server block بمحرر النصوص: sudo vi /etc/nginx/sites-available/default استبدل محتويات الملف بالتعليمات البرمجية التالية. تأكد من استبدال الأجزاء الملوّنة باسم المستخدم واسم التطبيق المناسبين. /etc/nginx/sites-available/default upstream app { # Path to Puma SOCK file, as defined previously server unix:/home/deploy/appname/shared/sockets/puma.sock fail_timeout=0; } server { listen 80; server_name localhost; root /home/deploy/appname/public; try_files $uri/index.html $uri @app; location @app { proxy_pass http://app; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header Host $http_host; proxy_redirect off; } error_page 500 502 503 504 /500.html; client_max_body_size 4G; keepalive_timeout 10; } احفظ واخرج. سيقوم هذا النص البرمجي بإعداد Nginx كوكيل عكسي، لذلك طلبات HTTP ستُرسل إلى الخادم Puma عبر مقبس يونيكس Unix socket. لا تتردد في إجراء التغييرات التي تراها مناسبةً. لن نقوم بإعادة تشغيل Nginx, فالتطبيق غير موجود بعدُ على الخادم. سنقوم بإعداد التطبيق فيما يلي. إعداد مستودع الإنتاج (git (Prepare Production Git Remote على خادم الإنتاج، قم بتثبيت git بواسطة apt-get: sudo apt-get install git ثم قم بإنشاء مجلد للمستودع البعيد remote repository. سنقوم بإنشاء مجلد git أوّلي في المجلد الرئيسي وسنسميه “appname_production”. يمكنك تسمية المستودع البعيد كما تريد (ولكن لا تضعه في ~/appnameلأنه المكان الذي سننشر فيه التطبيق): mkdir ~/appname_production cd ~/appname_production git init –bare بما أن هذا المستودع أوّلي، فلا يوجد مجلّد عمل بعدُ وجميع الملفات الموجودة في .git موجودة في المجلد الرئيسي نفسه. نحن بحاجة إلى إنشاء خُطّاف git من نوعpost-receive ، والذي هو النص البرمجي الذي سيتم تشغيله عندما يتلقى خادم الإنتاج دفعةً من git(git push). افتح الملف hooks/post-receive في محرر النصوص: vi hooks/post-receive انسخ وألصق النص التالي في الملف post-receive: hooks/post-receive #!/bin/bash GIT_DIR=/home/deploy/appname_production WORK_TREE=/home/deploy/appname export APPNAME_DATABASE_USER='appname' export APPNAME_DATABASE_PASSWORD='appname_password' export RAILS_ENV=production . ~/.bash_profile while read oldrev newrev ref do if [[ $ref =~ .*/master$ ]]; then echo "Master ref received. Deploying master branch to produc-tion..." mkdir -p $WORK_TREE git --work-tree=$WORK_TREE --git-dir=$GIT_DIR checkout -f mkdir -p $WORK_TREE/shared/pids $WORK_TREE/shared/sockets $WORK_TREE/shared/log # start deploy tasks cd $WORK_TREE bundle install rake db:create rake db:migrate rake assets:precompile sudo restart puma-manager sudo service nginx restart # end deploy tasks echo "Git hooks deploy complete" else echo "Ref $ref successfully received. Doing nothing: only the mas-ter branch may be deployed on this server." fi done تأكد من تحديث القيم التالية: GIT_DIR :مجلد المستودع الأولي لـ (git (bare git repository الذي قمت بإنشائه في وقت سابق WORK_TREE : المجلد حيث تريد نشر تطبيقك (يجب أن يتطابق مع الموضع الذي قمت بتحديده في إعدادات Puma) APPNAME_DATABASE_USER :اسم مستخدم PostgreSQL (ضروري لمهام rake ) APPNAME_DATABASE_PASSWORD : كلمة مرور PostgreSQL (ضروري لمهام rake ) بعد ذلك، يجب عليك مراجعة التعليمات الموجودة بين التعليقين # start deploy tasks و # end deploy tasks. هذه هي التعليمات التي سيتم تشغيلها في كل مرة يتم دفع push الشعبة الرئيسية master branch إلى مستودع الإنتاج في(git (appname_production. إذا تركتها كما هي، فسيحاول الخادم القيام بما يلي بالنسبة لبيئة الإنتاج الخاصة بتطبيقك: تشغيل المُحزّم bundler إنشاء قاعدة بيانات ترحيل قاعدة البيانات الترجمة الأوليةPrecompile للأصول assets إعادة تشغيل Puma إعادة تشغيل Nginx إذا كنت ترغب في إجراء أية تغييرات أو أي إضافات للتحقق من الأخطاء، لا تتردد في القيام بذلك. بمجرد الانتهاء من مراجعة النص البرمجي احفظه واخرج. بعد ذلك، اجعل البرنامج النصي قابلًا للتنفيذ: chmod +x hooks/post-receive Sudo بلا كلمة مرور Passwordless Sudo لأن الخُطّاف post-receive يحتاج إلى تشغيل تعليماتsudo ، فسنسمح للمستخدم deploy باستخدام sudo بدون كلمة مرور(استبدل اسم المستخدمdeploy في حال اخترت اسمًا مختلفًا): sudo sh -c 'echo "deploy ALL=(ALL) NOPASSWD:ALL" > /etc/sudoers.d/90-deploy' هذا سيسمح للمستخدم deploy بتشغيل التعليمة sudo دون الحاجة لإعطاء كلمة المرور. ربما تريد أن تُقيّد التعليمات التي يمكن للمستخدمdeploy القيام بها. وكحد أدنى، عليك استخدام مفتاح المصادقة SSH كما عليك تعطيل المصادقة بكلمة المرور password authentication. إضافة Production Git Remote الآن بعد أن أعددنا كل شيء لخادم الإنتاج، دعونا نضيف production git remote لمستودع التطبيق خاصتنا. على جهاز التطوير خاصتك، تأكد من أنك في مجلد التطبيق: cd ~/appname ثم قم بإضافة مستودع git بعيد (git remote) جديد تحت اسم “production” والذي يشير إلى مستودع git الأولي appname_production الذي أنشأته على خادم الإنتاج. استبدل اسم المستخدم (deploy) وعنوان الـ IP الخاص بالخادم واسم المستودع البعيد (appname_production): git remote add production deploy@production_server_public_IP:appname_production لقد صار تطبيقك الآن جاهزًا للنشر بواسطة git push. النشر للإنتاج Deploy to Production بعد كل الإعدادات التي قمنا بها، يمكنك الآن نشر تطبيقك على الخادم خاصتك عن طريق تشغيل تعليمات git التالية: git push production master هذا سيدفع push شعبتك الرئيسية المحلية local master branch إلى مستودع الإنتاج البعيد production remote الذي قمت بإنشائه سابقًا. عندما يتلقى production remote أمر الدفع، فسينفّذ النصَّ البرمجي post-receive الذي أعددناه في وقت سابق. إذا قمت بكل شيء بشكل صحيح، فيجب أن يكون تطبيقك متاحًا الآن على عنوان الـ IP العام لخادم الإنتاج خاصتك. إذا كنت تستخدم التطبيق التعليمي لهذا الدرس، فمن المفروض أن تكون قادرًا على الوصول إلى http://production_server_IP/tasks من أيّ متصفح و من المفروض أن ترى شيئًا من هذا القبيل: الخلاصة في أي وقت تقوم بإجراء تغيير على تطبيقك، يمكنك تشغيل نفس التعليمة git push للنشر على خادم الإنتاج خاصتك. هذا لوحده من المفروض أن يوفر عليك الكثير من الوقت على مدى عمر المشروع. لقد شمل هذا الدرس فقط الخطّافات من نوع “post-receive”، ولكن هناك عدة أنواع أخرى من الخطّافات التي يمكن أن تساعدك على تحسين أتمتة عملية النشر. ترجمة -وبتصرّف- للمقال How To Deploy a Rails App with Git Hooks on Ubuntu 14.04 لصاحبه Mitchell Anicas

يأتي Git مُرفقا بأداة تُدعى git config والتي تسمح لك بقراءة إعدادات النظام وتغييرها والتحكم في كامل جوانب عمل Git. يتم حفظ هذه الإعدادات في الأماكن الثلاثة التالية: etc/gitconfig/: يحتوي هذا الملف على الإعدادات الخاصة بجميع المُستخدمين على نفس النظام/الجهاز أيّا كان المُستودع الذي يعملون عليه. في حال ما إذا قمت بتمرير خيار system-- إلى أمر git config فسيكون بإمكانك قراءة وتعديل الإعدادات الموجودة في هذا الملف.gitconfig./~: هذا الملف خاص بإعدادات المُستخدم الحالي فقط. بإمكانك قراءة الإعدادات من هذا الملف أو التعديل عليها عبر تمرير خيار global-- إلى الأمر git config.git/config.: هذا الملف المتواجد داخل كل مُستودع يحتوي الإعدادات الخاصة بالمستودع الذي يحتويه فقط. في حال ما إذا قمت بحفظ الإعدادات في مُستوى مُعين فإنه سيتم تجاهل إعدادات المُستوى الذي يعلوه. بعبارة أخرى، سيتم أخذ إعدادات ملف git/config. بالحسبان لو وُجدت وتجاهل إعدادات ملف etc/gitconfig/.على أنظمة Windows يقوم Git بالبحث عن ملف gitconfig. داخل مُجلد HOME$ أي داخل مُجلد C:\Documents and Settings\$USER أو C:\Users\$USER حسب إصدار نظام التشغيل المُستخدم. كما أنه يبحث أيضا عن ملف etc/gitconfig/ والذي يكون داخل المُجلد الذي قررت تنصيب Git فيه. هويتك على Gitمن بين الأمور التي يجب عليك القيام بها بمُجرد تنصيبك لنظام Git هو تحديد هويتك عليه ونقصد بذلك اسمك وعنوان بريدك الإلكتروني. هذه الخُطوة مُهمة لأن Git سيقوم بربط أي عملية تقوم بها بهذه الهوية، كما أن كل عملية إيداع ستقوم بها ستحمل هذه البيانات معها. يتم تحديد هوية المُستخدم عبر الأمرين التاليين: $ git config --global user.name "John Doe" $ git config --global user.email johndoe@example.comمن جديد، لن تحتاج إلى القيام بها الأمر سوى مرة واحد في حال ما إذا قمت بتمرير الخيار global-- للأمرين السابقين لأنه في هذه الحالة سيقوم Git باستخدام هذه الهوية مع جميع العمليات التي تتم على النظام/الجهاز الحالي. إذا رغبت في استخدام هوية مُختلفة مع مشاريع مُعينة فما عليك سوى تنفيذ الأمرين السابقين من دون تمرير الخيارglobal--. محرر النصوص الافتراضيالآن وبعد أن حددت هويتك على Git حان الأوان لاختيار مُحرر النصوص الذي ستستعمله لما يطلب منك Git كتابة رسالة أو تعليق على العمليات التي تقوم بها. في حال لم تقم باختيار مُحرر نصوص خاص فإن Git سيقوم باستخدام مُحرر النصوص الافتراضي لنظام التشغيل الخاص بك والذي عادة ما يكون Vi أو Vim. إن رغبت في استخدام مُحرر نصوص آخر وليكن Emacs فما عليك سوى تنفيذ الأمر التالي: $ git config --global core.editor emacsأداة Diff Toolخاصية أخرى تحتاج إلى إعداداها هي أداة diff tool والتي سيتم استخدامها لحل المشاكل المُتعلقة بعمليات الدمج. في حال ما إذا أردت استخدام vimdiff مثلا فما عليك سوى تنفيذ الأمر التالي: $ git config --global merge.tool vimdiffيستطيع Git التعامل مع جُملة من الأدوات بشكل قياسي وهي كالتالي: kdiff3tkdiffmeldxxdiffemergevimdiffgvimdiffecmergeopendiffالتحقق من الإعداداتإذا رغبت في التحقق من الإعدادات التي قمت بها فما عليك سوى تنفيذ الأمر: git config --list والذي يقوم بعرض النتائج على الشكل التالي: $ git config --list user.name=Scott Chacon user.email=schacon@gmail.com color.status=auto color.branch=auto color.interactive=auto color.diff=auto ...في حال ما إذا ظهرت قيم مُختلفة لنفس الخيار فهذا راجع إلى قراءة Git للإعدادات من أماكن مُختلفة ( /etc/gitconfigو ~/.gitconfig على سبيل المثال). في هذه الحالة فإن Git سيأخذ بالحسبان آخر قيمة في هذه القائمة. بإمكانك أيضا التحقق من الإعدادات بشكل فردي على باستخدام الأمر git config {key} مع استبدال ما يجب استبداله في الأمر: $ git config user.name Scott Chaconالحصول على المساعدةإن احتجت إلى أية مساعدة لدى استخدامك لنظام Git فيُمكنك الاستعانة بأحد الأوامر الثلاثة التالية للحصول على طريقة استخدام أي من أوامر Git: $ git help $ git --help $ man gitعلى النحو التالي (للحصول على شرح لأمر config): $ git help configهذه الأوامر مُفيدة جدا خاصة وأنها مُتوفرة دون الحاجة إلى اتصال إنترنت. إن كانت المصادر التي في حوزتك غير كافية وكنت تحتاج إلى مُساعدة شخصية ومباشرة فُيمكن زيارة قناتي git# و github# على خادوم Freenode IRC (على العنوان irc.freenode.net)، ستجد فيهما مجموعة كبيرة من خبراء Git والذين لديهم الرغبة في مساعدة من يطلبون المُساعدة. خلاصةبعد قراءتك لهذا المقال والمقالات السابقة التي نشرناها هنا فسيكون لديك فهم لأساسيات Git وفهم الاختلافات الموجودة بينه وبين باقي أنظمة إدارة النُسخ. سيكون لديك أيضا نظام Git جاهز للعمل على جهازك وإعدادات تضمن تضمين بياناتك الشخصية في كل عملية ستقوم بها. حان الآن الأوان للشروع في استخدام Git. ترجمة -وبتصرف- للفصل First-Time Git Setup من كتاب Pro Git لصاحبه Scott Chacon.

ما هو نظام التحكّم في النسخ Git، ولماذا حرّي بك أن توليه اهتماما؟ إن التحكّم في النّسخ، هو نظام يسجل التغيرات التي تحدث عبر الزمن على ملف أو مجموعة ملفات بحيث يمكنك الرجوع إلى مرحلة معينة (إصدار) لاحقًا. عمليا، يمكنك أن تقوم بهذا على جُل أنواع ملفات الحاسوب. إذا كنت تعمل كمصمم رسوميات أو ويب، مبرمج أو ما شابه وتريد طريقة لمتابعة جميع الإصدارات والتعديلات التي تجريها على صورة أو قالب ما (الأمر الذي سيعجبك بالتأكيد)، فإنه من الحكمة استعمال نظام إدارة الإصدارات VCS. حيث يمكّنك من إرجاع الملفات إلى حالٍ كانت عليه سابقًا، أو إرجاع مشروع بأكمله، يمكنك أيضًا مقارنة التغيرات الحاصلة مع مرور الزمن، أو معرفة من قام بآخر تعديل قد يكون سبب خطأ ما، من أشَارَ إلى خطْبٍ ما ومتى، وغيرهم المزيد. استخدامك لنظام إدارة الإصدارات يعني أيضًا أنه إذا قمت بعبث وتبعثرت أشياء، أو خسرت ملفات المشروع لسبب ما، يمكنك استرجاعها إلى حالها بسهولة. بل وبأدنى مشقة منك. أنظمة إدارة إصدارات المصدر المحلية الطريقة المثلى لدى كثير من الناس في التحكّم النسخ، هي نَسخ الملفات في مجلد مغاير (قد يكون مُعّلما بالزمن، في حالة كان الشخص حذِقا). هذا النهج منتشر بكثرة لبساطته، لكنه وبشكل مفرط، مَدعاة للغلط. فمن السهل نسيان أيٌ من المجلدات أنت فيها فتكتب عن غير قصد في الملف الخطأ، أو تنسخ فوق ملفات لم تكن تعنيها. للتعامل مع هذا المشكل، عمل المبرمجون قديما على تطوير VCSs مزودة بقاعدة بيانات بسيطة تحفظ جميع التغيرات التي تطرأ على الملفات التي هي تحت إدارة المراجعة (انظر الصورة). إحدى أدوات VCS الأكثر شعبية كان نظاما تدعى rcs والتي لا تزال تُوّزع مع العديد من حواسيب اليوم. حتى نظام OS X المشهور يحوي أمر rcs عند تنصيبك لأدوات المطور، تعمل هذه الأداة أساسا بحفظ مجموع الرقع (أي الاختلافات الحاصلة بين الملفات) بين كل عملية تغيير واحدة ومثيلتها في هيئة خاصة على القرص الصلب، يمكنها بهذا إعادة إنشاء أي ملف بنفس الهيئة التي كان عليها في نقطة ما من الزمن عن طريق دمج الرقع. أنظمة إدارة إصدارات المصدر المركزية المشكل الكبير التالي الذي واجه المستخدمين هو حاجتهم إلى التعاون مع مُبرمجين آخرين على أنظمة تشغيل أخرى. ولحل هذا المُشكل تم تطوير أنظمة لإدارة إصدارات المصدر مركزية (CVCSs). تستخدم هذه الأنظمة، مثل كل من CVS ،Subversion أو Perforce خادوما واحدا يحتوي كل الملفات التي نقوم بإدارة إصداراتها، إضافة إلى مجموعة من العملاء الذين يقومون باسترجاع الملفات من هذا الخادوم المركزي. ظلت هذه الأنظمة لسنوات عديدة المعيار القياسي لأنظمة إدارة إصدارات المصدر. توفر هذه الأنظمة مزايا عديدة خاصة إذا ما قارناها بأنظمة إدارة الإصدارات المحلية، فعلى سبيل المثال يُمكن للجميع –إلى حد مُعين من الدقة- معرفة ما الذي يقوم به الجميع على المشروع، كما أن للمدراء القدرة على التحكم بشكل دقيق فيما يُمكن لأي مشارك أن يقوم به. دون أن ننسى أنه من الأسهل التعامل مع نظام إدارة إصدارات مركزي مقارنة مع إدارة قواعد بيانات على جهاز كل مشارك. في المقابل، تأتي هذه الأنظمة مرفقة ببعض العيوب والتي قد يكون أخطرها هو اعتماد النظام على نقطة مركزية وحيدة، فإن تعطل الخادوم لساعة من الزمن، فإنه من غير المُمكن لأي كان أن يتشارك التحديثات التي تمت خلال تلك الفترة. أما لو تعرض القرص الصلب على الخادوم لعطب، فإنه -ما لم يتم أخذ نسخ احتياط قبل حصول ذلك- فإن احتمال فقدان المشروع بكامل تاريخه أمر وارد جدا، باستثناء النسخ المحلية المتواجدة على أجهزة المتعاونين في المشروع. أنظمة إدارة الإصدارات الموزعة ولمثل هذه الأوضاع ظهرت أنظمة إدارة الإصدارات المُوزعة (DVCSs). في مثل هذه الأنظمة كـ Git ،Mercurial ،Bazaar أو Darcs فإن ما يقوم به المستخدمون ليس مُجرد التحقق من آخر إصدار للملفات، لكن يقومون بإخذ نسخ كاملة عن المستودعات التي يعملون عليها. وعليه، فإن تعرض الخادوم لأي خلل فإنه يُمكن مواصلة العمل عبر نسخ المستودع الموجود على أي من أجهزة المستخدمين بحكم أن أي عملية تحقق يقوم بها المستخدم هي عبارة عن عملية نسخ احتياطي كامل لكامل بيانات المشروع (انظر الصورة التالية). وعلاوة على ذلك، فإن العديد من هذه الأنظمة المُوزعة تتعامل بشكل جيد مع المشاريع التي تملك عدة مستودعات تعمل عليها مجموعات مختلفة من المستخدمين بطرق مختلفة وضمن نفس المشروع. هذا الأمر يسمح باعتماد مهام لسير العمل لم يكن بالإمكان اعتمادها على الأنظمة المركزية مثل النماذج الهرمية. ترجمة -وبتصرف- لـ About Version Control من كتاب Pro Git لصاحبه Scott Chacon.

سنقوم في هذا الدرس بتغطية الأوامر الأساسية التي لا يُمكنك الاستغناء عنها إن أردت أن تستخدم Git بكفاءة عالية والتي ستقضي وقتك على Git في استخدامها. يُفترض بك بعد إنهاء قراءة هذا الدرس أن تصبح قادرًا على إعداد وتهيئة مُستودع، الشروع في وإيقاف تتبع التغييرات في ملفات مُعينة، إرسال التغييرات إلى منطقة الإدراج وإيداعها. سنشرح لك أيضا كيف ستقوم بتجاهل ملفات مُعينة أو التي تتبع أنماطا خاصة، فيما ستتحدث الدروس التي تلي هذا عن كيفية التراجع عن أخطاء قُمت بها بشكل سريع وسهل، كيفية تصفح تاريخ المشروع والاطلاع على كافة التعديلات التي حدثت ما بين كل إيداعين، وكيف تقوم بدفع التغييرات إلى مُستودع في خادوم بعيد أو سحب البيانات منه. الحصول على مستودع وحفظ التغييرات فيه يُمكنك الحصول على مُستودع Git بطريقتين مُختلفتين. تتمثل الأولى في إنشاء مُستودع لمشروع أو مُجلد مُعد سلفا، وتتم الثانية عبر استنساخ مُستودع موجود على خادوم بعيد. إنشاء مستودع جديد لمشروع موجود مسبقا إن أردت الشروع في تتبع إصدارات وتغييرات مشروع راهن فكل ما عليك القيام به هو الذهاب إلى مُجلد المشروع (بسطر الأوامر طبعا) ومن ثم تنفيذ الأمر التالي: $ git init سيقوم هذا الأمر بإنشاء مُجلد فرعي داخل مُجلد المشروع يحمل الاسم git. والذي سيحتوي جميع ملفات المُستودع الأساسية التي ستشكل هيكل المستودع. بطبيعة الحال لن يتم تتبع أية تغييرات بُمجرد تنفيذ هذا الأمر لوحده. إن أردت الشروع في إدارة نسخ الملفات الراهنة (يعني لن تبدأ بمُجلد فارغ) فإنه يجب عليك أولا الشروع في تتبع هذه الملفات والقيام بأول عملية إيداع. يُمكن القيام بذلك عبر تنفيذ بضعة أوامر git add التي ستحدد فيها أسماء هذه الملفات ثم تُتبعها بأمر للإيداع: $ git add README $ git commit -m "initial project version" بعد تنفيذك لهذه الأوامر (سنشرح ما تقوم به هذه الأوامر بعد قليل) سيكون لديك مُستودع Git يقوم بتتبع التغييرات التي ستطرأ على مجموعة ملفات، إضافة إلى إيداع أولي. نسخ مستودع موجود مسبقا إن أردت استنساخ مُستودع Git راهن -وليكن مُستودعا لمشروع ترغب في المُساهمة فيه- فإن الأمر الذي ستحتاجه للقيام بذلك هو git clone. إن كانت لديك دراية مُسبقة بباقي أنظمة إدارة النُسخ مثل Subversion فإنك ستلحظ بأن الأمر الذي نستعمله هنا هو clone وليس checkout، حيث أن ما سيستقبله Git هو نُسخة من جميع البيانات (أو تقريبا) الموجودة على الخادوم. يعني بأنك ستحصل على كل نسخة من كل الملفات منذ أن تم الشروع في تتبع المُستودع الموجود على الخادوم لدى تنفيذ الأمر git clone. بعبارة أخرى، لو تعرض القرص الصلب لخادومك لعطب ما فإنه بإمكانك استعادة المشروع الذي كنت تعمل عليه كما كان (أو تقريبا) بفضل النُسخ الموجودة في جميع الأجهزة التي تعمل على نفس المشروع. يتم استنساخ المُستودعات باستخدام الأمر التالي: git clone [url] حيث يتم استبدال بعُنوان المُستودع المُراد استنساخه. فعلى سبيل المثال لو أردت استنساخ مُستودع "الدليل البسيط لاستخدام Git" فسيكون الأمر على النحو التالي: git clone git://github.com/arabicgit/simple-guide.git سيتم إنشاء مُجلد يحمل الاسم simple-guide يتم إنشاء مُجلد git. بداخله، ومن ثم سيتم استنساخ جميع البيانات الموجودة في مستودع الدليل على Github التي يُمكن الشروع في العمل عليها. إن أردت أن يتم استنساخ المُستودع داخل مُجلد باسم مُخالف فيُمكن تحديد اسم المُجلد الذي ترغب فيه (وليكن MyGuide) في أمر الاستنساخ على النحو التالي: git clone git://github.com/arabicgit/simple-guide.git MyGuide يدعم Git عدة بروتوكولات للتحويل. استعملنا في المثال السابق بروتوكول git://، لكنه بإمكانك أيضا استخدام (http(s:// أو user@server:/path.git والتي تعتمد على بروتوكول SSH. تسجيل التغييرات الحاصلة في المستودع الآن وبعد أن حصلت على مُستودع يقبل تتبع التغييرات الحاصلة على ملفاته، إضافة إلى جُملة من الملفات التي ستعمل عليها، ستحتاج بطبيعة الحال إلى إحداث تغييرات عليها ومن ثم إيداع تلك التغييرات في كل مرة يصل فيها مشروعك إلى مرحلة ترغب في تسجيلها. تذكر بأن الملفات تكون في إحدى الحالتين التاليتين: مُتتبع tracked أو غير مُتتبع untracked. الملفات المُتتبعة هي التي سبق وأن سجلت حضورا في اللقطة snapshot السابقة. يُمكن لهذه الملفات أن تكون في حالات ثلاثة: مُعدّلة غير مُعدلة مُدرجة staged (أي موجودة في منطقة الإدراج). أما الملفات غير المُتتبعة فهي ما سوى ذلك، ويشمل ذلك أي ملف في مجلد العمل لم يكن موجودًا في اللقطة السابقة وغير موجود في منطقة الإدراج. لدى قيامك باستنساخ مُستودع فإن جميع ملفاته ستكون مُتتبّعة وغير مُعدّلة لأنه -وبكل بساطة- قمت لتوك بسحبها ولم تحدث أية تغييرات عليها. بمُجرد أن تدخل تغييرات على أحد الملفات فسيعتبره Git ملفا مُعدّلا، حيث أن هذه الملفات قد طرأت عليها تغييرات منذ آخر إيداع. ما هي الخُطوة القادمة في هذه الحالة؟ ستقوم أولا بإدراج هذه التغييرات stage (أي وضع الملفات المعنية بالأمر في منطقة الإدراج) ومن ثم تقوم بإيداع تلك التغييرات commit، وستكرر هذه العملية طيلة استخدامك لـ Git، مثلما هو مُوضح في الصورة التالية: التحقق من حالة ملفاتك للتحقق من حالة ملفات مستودعك ستحتاج إلى استخدام الأمر git status. إن قمت بتنفيذ هذا الأمر مُباشرة بعد قيامك باستنساخ مُستودع فإنه يُفترض بهذه النتيجة أن تظهر: $ git status On branch master nothing to commit, working directory clean وهو ما يعني بأنك أمام مُجلد عمل نظيف. بعبارة أخرى لم يتم إحداث تغييرات على أي ملف مُتتبَّع. في هذه الحالة أيضا لا يُظهر Git أي ملفات غير مُتتبعة، لأنه لو كان الأمر غير كذلك فسيقوم حتما بإعلامك بالأمر. يُخبرك هذا الأمر بالفرع branch الذي تتواجد فيه، ومثلما هو ظاهر من النتيجة السابقة فإننا حاليا في الفرع الرئيسي master وهو الفرع الذي يتم استعماله بشكل قياسي. لنفرض الآن بأنك قُمت بإضافة ملف جديد إلى مشروعك، ولنفرض بأنه ملف README. إذا لم يكن هذه الملف موجودا من قبل داخل هذا المُستودع ولدى قيامك بتنفيذ الأمر git status فإن اسم هذا الملف سيظهر في قسم الملفات غير المُتتبعة على النحو التالي: $ vim README $ git status On branch master Untracked files: (use "git add <file>..." to include in what will be committed) README nothing added to commit but untracked files present (use "git add" to track) عدم التتبع عنها يعني بأن git قد عرف بأن الملف لم يكن في اللقطة السابقة لمشروعك (أي آخر إيداع)، لكنه لن يشرع في تتبعه بشكل آلي ما لم تقم أنت بطلب ذلك بشكل صريح، وستجد بأن ذلك مُفيد جدا خاصة لما تعمل على مشروع يُنتج الكثير من الملفات المُوقتة التي لا ترغب في تتبعها. تتبع الملف الجديد الآن وللشروع في تتبع الملف الجديد فإننا سنحتاج إلى الأمر git add على النحو التالي: $ git add README وإذا قمت بتنفيذ الأمر git status من جديد فإن الملف سيظهر مُتتبعا ومُدرجا: $ git status On branch master Changes to be committed: (use "git reset HEAD <file>..." to unstage) new file: README بإمكانك معرفة أن الملف في منطقة الإدراج لأنه يظهر في قسم التغييرات التي سيتم إيداعها "Changes to be committed". إذا قمت بإدراج الملف في هذه المرحلة فإن حالة الملف لدى تنفيذك للأمر git add هي التي ستتم إضافتها إلى اللقطة. يُمكنك تحديد مسار ملف أو مُجلد لدى تنفيذك لأمر git add، ولدى تحديد مُجلد فإنه ستتم إضافة جميع مُحتوياته. إدراج الملفات المعدلة لنقم الآن بتعديل ملف سبق وأن شرعنا في تتبع التغيرات الطارئة عليه. لو أدخلنا تغييرات على الملف benchmark.rb ومن ثم نفذنا الأمر status من جديد لحصلنا على نتيجة مُماثلة لهذه النتيجة: $ git status On branch master Changes to be committed: (use "git reset HEAD <file>..." to unstage) new file: README Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git checkout -- <file>..." to discard changes in working directory) modified: benchmarks.rb أين يظهر ملف benchmark.db تحت قسم "Changes not staged for commit" (تعديلات لم يتم إدراجها لإيداعها).ومثلما هو ظاهر من هذا الوصف فأننا قمنا بإدخال تعديلات على ملف مُتتبع ولم يتم إدراج تلك التغييرات بعد. ولإدراج هذه التغييرات يكفي أن نُنفذ الأمر git add الذي لديه عدة استخدامات كالشروع في تتبع الملفات مثلما سبق وأن شاهدناه، إدراج الملفات وللقيام بأمور أخرى كتعليم ملفات الدمج المُتضاربة merge-conflicted files كمحلولة. $ git add benchmarks.rb $ git status On branch master Changes to be committed: > (use "git reset HEAD <file>..." to unstage) new file: README modified: benchmarks.rb مثلما نلاحظه الآن، تم إدراج كلا الملفين وسيتم أخذ التغييرات الطارئة عليهما في الحسبان في عملية الإيداع القادمة. لكن لنفرض بأنك تذكرت تغييرا آخرًا تود إدخاله على ملف قبل أن تقوم بعملية الإيداع، وعليه فإنك ستقوم بالتعديل عليه قبل إيداعه. لكن لو قمت الآن بتنفيذ أمر git status من جديد فستظهر هذه النتيجة: $ vim benchmarks.rb $ git status On branch master Changes to be committed: (use "git reset HEAD <file>..." to unstage) new file: README modified: benchmarks.rb Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git checkout -- <file>..." to discard changes in working directory) modified: benchmarks.rb غريب؟ أليس كذلك؟ يظهر ملف benchmark.rb على أساس أنه مُدرج وغير مُدرج في آن واحد. هل هذا ممكن؟ نعم هذا مُمكن حيث يقوم git بإدراج الملف في حالته التي كان عليها لدى تنفيذ الأمر git add وبالتالي لو قمت بالإيداع الآن فإنه سيتم إيداع ملف benchmark.rb في حالته التي كان عليها لدى تنفيذ الأمر git add وليس على الحال التي هو عليها الآن، وبالتالي فإنه يجب تنفيذ الأمر git add لإدراج تلك التغييرات في كل مرة تقوم بإدخال التعديلات على الملف: $ git add benchmarks.rb $ git status On branch master Changes to be committed: (use "git reset HEAD <file>..." to unstage) new file: README modified: benchmarks.rb تجاهل ملفات عادة ما تكون لديك في المشروع الذي تعمل عليه جُملة أو صنف من الملفات التي لا ترغب من Git أن يقوم بإضافتها بشكل آلي أو حتى في إظهارها كملفات غير مُتتبعة، وعادة ما تكون هذه الملفات تلك التي يتم توليدها بشكل آلي مثل ملفات log أو الملفات التي تنتج عن نظام البناء الخاص بك build system. في مثل هذه الحالات فإن الحل يكمن في استخدام ملف gitignore. الذي يحتوي أنماط أسماء هذه الملفات غير المرغوب فيها: $ cat .gitignore *.[oa] *~ يطلب السطر الأول في الملف (ولا أعني بذلك الأمر cat) من Git أن يتجاهل جميع الملفات التي تنتهي بـ o. أو a. (الكائنات وملفات الأرشيف التي يُحتمل أن تنتج عن عملية بناء شفرتك البرمجية). أما السطر الثاني فيطلب من Git أن يتجاهل جميع الملفات التي تنتهي أسماؤها بمحرف ~ والتي تستخدمها بعض محررات النصوص كمُحرر Emacs لحفظ الملفات المؤقتة. بإمكانك أيضا أن تُضمن في هذا الملف ملفات log ،tmp أو مجلد pid والتوثيق التي يتم توليده بشكل آلي وما إلى ذلك. الشروع في إعداد ملف gitignore. قبل الشروع في العمل على المشروع من شأنه أن يُجنبك إيداع ملفات لا ترغب أن تظهر في مستودعك لاحقا. القواعد العامة التي تتبعها أنماط أسماء الملفات المُضمنة في ملف gitignore. هي على النحو التالي: يتم تجاهل الأسطر الفارغة والأسطر التي تبدأ بمحرف # يتم أخذ الأنماط المبسطة للتعابير القياسية Standard glob patterns في الحسبان بإمكانك إنهاء النمط بـ / للدلالة على المجلدات. بإمكانك عكس النمط بتسبيقه بعلامة تعجب ! الأنماط المبسطة للتعابير القياسية Standard glob patterns هي نسخة مُبسطة من التعابير القياسية التي يُمكن استخدامها على سطر الأوامر. فـ * تدل على 0 أو أكثر من محرف، و [abc] تتوافق مع أي حرف ضمن هذه القائمة (في هذه الحالة: a ،b و c). أما علامة الاستفهام فتتوافق مع محرف واحد. أما لو استخدمنا هذه الصيغة [0-9] فإنها ستوافق أي محرف يقع ما بين 0 و 9. إليكم مثالا آخر عن ملف gitignore.: # a comment - this is ignored # no .a files *.a # but do track lib.a, even though you're ignoring .a files above !lib.a # only ignore the root TODO file, not subdir/TODO /TODO # ignore all files in the build/ directory build/ # ignore doc/notes.txt, but not doc/server/arch.txt doc/*.txt # ignore all .txt files in the doc/ directory doc/**/*.txt النمط **/ مُتوفر بداية من الإصدار 1.8.2 إظهار التغييرات المدرجة وغير المدرجة إذا كانت النتيجة التي يُظهرها الأمر git status غير دقيقة بالنسبة إليك أو إن كنت ترغب في معرفة التغييرات التي حصلت بدقة وليس مجرد معرفة قائمة الملفات التي تم تغييرها فإنه بإمكانك الاستعانة بالأمر git diff للقيام بذلك. لسنا هنا بصدد تفصيل الأمر git diff (سنقوم بذلك في مقال لاحق) لكنك ستحتاجه للإجابة على سؤالين مُحددين: ما الذي قُمت بالتعديل عليه ولم تقم بإدراجها بعد، وما الذي قمت بإدراجه لكن لم تقم بإيداعه بعد. بالرغم من أنه بإمكان git status الإجابة على هذين السؤالين، إلا أن الأمر git diff كفيل بالإجابة عنها بشكل أدق، حيث سيخبرك عن أي سطر تمت إضافته وعن أي سطر تمت إزالته. لنفرض بأنك قمت بتحرير وإيداع ملف README من جديد ومن ثم قمت بتحرير ملف benchmarks.rb من دون إدراجه. لو قمت بتنفيذ الأمر status فإنك ستحصل على نتيجة مُشابه للنتيجة التالية: $ git status On branch master Changes to be committed: (use "git reset HEAD <file>..." to unstage) new file: README Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git checkout -- <file>..." to discard changes in working directory) modified: benchmarks.rb لكن لو رغبت في معرفة التغييرات التي حصلت والتي لم يتم إدراجها فاستعن بالأمر git diff: $ git diff diff --git a/benchmarks.rb b/benchmarks.rb index 3cb747f..da65585 100644 --- a/benchmarks.rb +++ b/benchmarks.rb @@ -36,6 +36,10 @@ def main @commit.parents[0].parents[0].parents[0] end + run_code(x, 'commits 1') do + git.commits.size + end + run_code(x, 'commits 2') do log = git.commits('master', 15) log.size يقوم هذا الأمر بمقارنة مُحتوى مُجلد العمل بما هو موجود في منطقة الإدراج، وبالتالي فإن النتيجة ستُخبرك بالتغييرات التي قُمت بها والتي لم تقم بإدراجها بعد. أما إذا أردت رؤية التغييرات المُدرجة التي سيتم أخذها في الحسبان في الإيداع القادم فما عليك سوى استخدام الأمر git diff --cached (في الإصدار 1.6.1 والإصدارات التي تليه أصبح بالإمكان استخدام الأمر git diff --staged بدلا عنه، حيث يُعتبر هذا الأمر أسهل للتذكر من سابقه). يقوم هذا الأمر بمقارنة مُحتوى منطقة الإدراج بآخر إيداع قمت به: $ git diff --cached diff --git a/README b/README new file mode 100644 index 0000000..03902a1 --- /dev/null +++ b/README2 @@ -0,0 +1,5 @@ +grit + by Tom Preston-Werner, Chris Wanstrath + http://github.com/mojombo/grit + +Grit is a Ruby library for extracting information from a Git repository تجدر الإشارة إلى أن الأمر git diff بدون أية معاملات إضافية لا يقوم بإظهار كل التغييرات التي قُمت بها منذ آخر إيداع، حيث تكتفي بإظهار التغييرات التي لم يتم إدراجها. هذا الأمر قد يكون مُربكا بعض الشيء بحكم أنه لو قمت بإدراج جميع التغييرات التي قمت بها فإن أمر git diff لن يُظهر أية نتيجة. مثال آخر، لو قمت بإدراج الملف benchmarks.rb ومن ثم قمت بالتعديل عليه فإنه بإمكانك استخدام الأمر git diff لرؤية التغييرات التي تمت على الملف والتي تم إدراجها وتلك التغييرات التي لم يتم إدراجها أيضا: $ git add benchmarks.rb $ echo '# test line' >> benchmarks.rb $ git status On branch master Changes to be committed: (use "git reset HEAD <file>..." to unstage) modified: benchmarks.rb Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git checkout -- <file>..." to discard changes in working directory) modified: benchmarks.rb الآن يُمكنك استخدام الأمر git diff لمعرفة ما الذي لم يتم إدراجه بعد: $ git diff diff --git a/benchmarks.rb b/benchmarks.rb index e445e28..86b2f7c 100644 --- a/benchmarks.rb +++ b/benchmarks.rb @@ -127,3 +127,4 @@ end main() ##pp Grit::GitRuby.cache_client.stats +# test line والأمر git diff --cached لمعرفة ما الذي قُمت بإدراجه إلى حد الآن: $ git diff --cached diff --git a/benchmarks.rb b/benchmarks.rb index 3cb747f..e445e28 100644 --- a/benchmarks.rb +++ b/benchmarks.rb @@ -36,6 +36,10 @@ def main @commit.parents[0].parents[0].parents[0] end + run_code(x, 'commits 1') do + git.commits.size + end + run_code(x, 'commits 2') do log = git.commits('master', 15) log.size إيداع التغييرات الآن وبعد أن قمت بإعداد منطقة الإدراج على النحو الذي ترغب فيه، بإمكانك الآن القيام بإيداع التغييرات التي قمت بها. تذكر دائما بأن أي تغيير لم تم بإيداعه -أي ملف قمت بإنشائه أو التعديل عليه والذي لم تقم بإضافته بتنفيذ الأمر git add عليه منذ إنشائه أو منذ آخر تحديث عليه- لن يتم أخذه بالحسبان في الإيداع القادم، بل سينظر إليه النظام كملف تم تعديله. في هذه الحالة، ولدى تنفيذك للأمر git status آخر مرة فإنك لاحظت بأنه تم إدراج جميع التغييرات وبالتالي فإنك جاهز لإيداع التغييرات. يتم ذلك باستخدام الأمر git commit على النحو التالي: git commit تنفيذ هذا الأمر سيقوم بفتح مُحرر النصوص المُفضل لديك (والذي يتم تحديده عبر قيمة مُتغيرالنظام EDITOR$ والذي يُمكن أن يكون vim ،emacs أو أي مُحرر نصوص آخر، كما أنه يُمكنك تحديد عبر الأمر git config --global core.editor مثلما سبق وأن تطرقنا إليه في درس إعداد Git للمرة الأولى. سيقوم المُحرر بإظهار النص التالي (المثال التالي مأخوذ من مُحرر النصوص Vim): # Please enter the commit message for your changes. Lines starting # with '#' will be ignored, and an empty message aborts the commit. # On branch master # Changes to be committed: # new file: README # modified: benchmarks.rb # ~ ~ ~ ".git/COMMIT_EDITMSG" 10L, 283C مثلما نلاحظه هنا فإن نص/رسالة الإيداع القياسية تحتوي مُخرجة الأمر git status على هيئة تعليق، إضافة إلى سطر فارغ يسبق ذلك. بإمكانك حذف هذا التعليق وكتابة النص الذي ترغب فيه، كما أنه بإمكانك الإبقاء عنها لتتذكر الملفات التي تم تعديلها في هذا الإيداع ( للحصول على تذكير أدق يُمكنك تمرير المُعامل v- لأمر git commit سابق الذكر، وستحصل حينها على تفاصيل التغييرات التي حدثت على الملفات لما يتم فتح المُحرر المفضل لديك). لدى إغلاقك لمحرر النصوص سيقوم Git بإنشاء الإيداع ويقوم بإرفاق ذلك النص/الرسالة به مع التخلص من التعليقات وتفاصيل التغييرات التي أدخلت على الملفات. يُمكنك أيضا كتابة نص الإيداع مُباشرة مُرفقا بأمر الإيداع وذلك بتسبيقه بـ m- على النحو التالي: $ git commit -m "Story 182: Fix benchmarks for speed" [master 463dc4f] Story 182: Fix benchmarks for speed 2 files changed, 3 insertions(+) create mode 100644 README كما تلاحظ فإنك قمت بعمل أول عملية إيداع لك وحصلت على بعض المعلومات حوله، كاسم الفرع الذي ينتمي إليه (master) وما هي قيمة هاش SHA-1 الخاصة به 463dc4f، عدد الملفات التي تم تحديثها، إضافة إلى عدد الأسطر التي تمت إضافتها أو حذفها. يجب التذكير بأن عملية الإيداع تقوم بأخذ صورة عن البيانات التي تم إدراجها وأي تغييرات لم تقم بإرسالها إلى منطقة الإدراج لن يتم أخذها بالحسبان، وعليه يجب إضافتها من جديد إلى منطقة الإدراج قبل إيداعها من جديد. كل مرة تقوم فيها بعملية إيداع فإنك تأخذ صورة عن حالة مشروعك في اللحظة التي تم التقاط تلك الصورة فيها وبإمكانك الرجوع إلى تلك الحالة لاحقا إن رغبت في ذلك. تجاوز منطقة الإدراج بالرغم من أن منطقة الإدراج في غاية الأهمية لتمكيننا من "بناء" إيداعات على الشكل الذي نرغب فيه، إلا أنها تُعتبر في بعض المرات مرحلة إضافية لا نرغب فيها. إذا رغبت في تجاوز منطقة الإدراج ما بين الحين والآخر فإن Git يسمح لك بالقيام بذلك، حيث يكفي إضافة خيار a- إلى أمر git commit ليقوم git بإضافة جميع الملفات التي كنت تتبعها سابقا قبل عملية الإيداع الحالية (يعني يقوم باختصار أمر git add). $ git status On branch master Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git checkout -- <file>..." to discard changes in working directory) modified: benchmarks.rb no changes added to commit (use "git add" and/or "git commit -a") $ git commit -a -m 'added new benchmarks' [master 83e38c7] added new benchmarks 1 files changed, 5 insertions(+) لاحظ كيف أننا لم نحتج إلى تنفيذ الأمر git add على الملف benchmarks.rb في هذه الحالة قبل أن تقوم بعملية الإيداع. حذف الملفات لحذف ملف من مشروع Git فإنه يجب عليك أن تحذفه من قائمة الملفات المُتتبّعة (أو بالأحرى من قائمة الملفات المُدرجة) قبل أن تقوم بعملية إيداع. يُمكّن أمر git rm من القيام بذلك ويقوم بحذف الملف من مُجلد العمل مما سيُجنّب ظهوره في قائمة الملفات غير المُتتبعة. إذا قمت بحذف الملف يدويا من المشروع فإن اسمه سيظهر في قائمة التغييرات التي لم يتم إدراجها لما تقوم بتنفيذ الأمر git status: $ rm grit.gemspec $ git status On branch master Changes not staged for commit: (use "git add/rm <file>..." to update what will be committed) (use "git checkout -- <file>..." to discard changes in working directory) deleted: grit.gemspec no changes added to commit (use "git add" and/or "git commit -a") ومن ثم إذا قمت بتنفيذ الأمر git rm فإنه سيتم "إدراج" الملف للحذف: $ git rm grit.gemspec rm 'grit.gemspec' $ git status On branch master Changes to be committed: (use "git reset HEAD <file>..." to unstage) deleted: grit.gemspec وفي المرة القادمة التي تقوم فيها بالإيداع فإن الملف سيختفي كُليّة. إذا كنت قد عدّلت على الملف وقمت بإضافته إلى الفهرس index فإنه يجب فرض إزالته عبر تمرير الخيار -f. يتم الاستعانة بذلك لتجنب حذف بيانات لم يتم تسجيلها في سجلات Git عن طريق الخطأ (وبالتالي لن يُصبح بالإمكان استرجاعها). أمر آخر قد ترغب في القيام به والمُتعلق بحذف الملف من git مع إبقائه في مُجلد العمل الخاص بك. بعبارة أخرى قد تكون أضفت ملفا مُعينا عن طريق الخطأ ولكن لا ترغب في مواصلة تتبعه عبر git، وعادة ما يكون الأمر مُتعلقا بملفات نسيت إضافتها إلى gitignore. كملفات log كبيرة الحجم أو ملفات a. الناتجة عن ترجمة المشروع. كل ما تحتاج إلى القيام به هو إضافة خيار cached-- على الشكل التالي: $ git rm --cached readme.txt بإمكان تمرير أسماء ملفات، مُجلدات أو حتى أنماطا مُبسطة للتعابير القياسية file-glob patterns لأمر git rm. يعني يُمكن القيام مثلا بالتالي: $ git rm log/\*.log لاحظ وجود محرف \ الذي يسبق * والذي يُعتبر ضروريا لأن git يستعمل نظامه الخاص لتفسير هذه الأنماط إضافة إلى النظام الخاص بسطر الأوامر الذي تستخدمه. أما على نظام Windows فإنك لن تحتاج إلى إضافته. يقوم هذا الأمر بحذف جميع الملفات التي تملك المُلحق log. في مُجلد log/. بإمكانك أيضا تنفيذ الأمر التالي لحذف جميع الملفات التي تنتهي أسماؤها بـ ~: $ git rm \*~ نقل الملفات على عكس ما هو مُتداول عليه باقي أنظمة إدارة الإصدارات فإن Git لا يقوم بتتبع حركة الملفات بشكل مُباشر. إن قمت بتغيير اسم ملف مثلا فإن git لا يحتفظ بأية بيانات حول الأمر، إلا أن النظام يملك مقدارا مُعينا من "الذكاء" يسمح له باستنتاج ذلك لاحقا. سنقوم بالتطرق لتتبع حركة الملفات في مقال لاحق. قد يبدو الأمر غامضا نوعا ما خاصة وأن git يملك الأمر mv. إن أردت إعادة تسمية ملف فإنه يُمكن القيام بذلك على النحو التالي: $ git mv file_from file_to وسيتم ذلك على النحو المُتوقّع، حيث يظهر ذلك واضحا على النحو التالي: $ git mv README README.txt $ git status On branch master Changes to be committed: (use "git reset HEAD <file>..." to unstage) renamed: README -> README.txt في المقابل، الأمر السابق مُماثل في نتيجته للتالي: $ mv README README.txt $ git rm README $ git add README.txt حيث سيعرف git بأنك تقوم بإعادة تسمية الملف، وبالتالي لا يهم الآلية التي تتبعها للقيام بذلك. الاختلاف الوحيد ما بين الطريقتين هو أن mv عبارة عن أمر واحد بدل الأوامر الثلاثة في الطريقة الثانية. الأهم من ذلك يُمكن الاستعانة بأية طريقة ترغب فيها لإعادة تسمية الملفات، كل ما يهمك أن تقوم بتنفيذ أوامر add/rm اللازمة قبل أن تقوم بعملية الإيداع. ترجمة -وبتصرف- للفصلين: Git Basics – Getting a Git Repository و Git Basics – Recording Changes to the Repository من كتاب Pro Git لصاحبه Scott Chacon.

سنتناول في هذا المقال الأسئلة العشرة الأكثر تكرارًا حول Git والحلول المتعلقة بها. ستساعد هذه الحلول في تجاوز بعض العقبات عند استخدام Git. 1. كيف أقوم بتحرير رسالة إيداع commit خاطئة في Git؟ وهو سؤال يطرح بكثرة من طرف كل من بدأ لتوّه باستخدام Git. لتحرير رسالة إيداع commit خاطئة قمنا بكتابتها، نستخدم الأوامر التالية: git commit --amend سيقوم الأمر بفتح المحرّر الذي سيسمح بتغيير أحدث إيداع. إن أردنا تحرير رسالة الإيداع مباشرة عبر سطر الأوامر، يمكننا القيام بذلك باستخدام الأمر: git commit --amend -m "الرسالة الجديدة" 2. كيف أتراجع عن آخر إيداع commit كاملا؟ للتراجع عن إيداع بعض الملفّات نقوم في البداية بإلغاء آخر إيداع باستخدام الأمر: git reset --hard HEAD~1 سيقوم هذا الأمر بنقل مؤشر الرأس HEAD إلى الإيداع قبل الأخير. بعد ذلك، نقوم بعرض حالة جميع الملفات مرّة أخرى باستخدام الأمر: git status وأخيرًا، نضيف الملفات التي نودّ إضافتها إلى الإيداع باستخدام الأمر: git add ... 3. كيف أتراجع عن إضافة ملف git add؟ للتراجع عن إضافة بعض أو كل الملفّات إلى منطقة الإدراج بالأمر المذكور، نستخدم أحد الأوامر التالية: للتراجع عن ملف وحيد: git reset <FileName> للتراجع عن جميع الملفّات: git reset 4. كيف أحذف تفرع branch (محلي أو بعيد)؟ لحذف تفرّع محلّي، نستخدم الأمر: git branch -d yourLocalBranchName ولحذف تفرّع بعيد، نستخدم الأمر: git push origin --delete yourRemoteBranchName 5. كيف أحذف ملفات محلية من التفرع الحالي لحذف جميع الملفّات المحلّية التي لا نرغب بإيداعها أو الحفاظ عليها في مجلّد العمل، نستخدم الأمر: git clean -f أو: git reset --hard 6. كيف أعيد تسمية تفرع محلي؟ لإعادة تسمية تفرّع محلّي، لدينا حالتان: إعادة تسمية لتفرّع الحالي: git branch -m newBranchName إعادة تسمية تفرّع آخر ليس التفرّع النّشط الحالي: git branch -m oldBranchName newBranchName 7. كيف أنشئ تفرعا بعيدا remote Git branch؟ لإنشاء تفرّع بعيد، نقوم أوّلًا بإنشاء تفرّع محلّي: git checkout -b newBranchName ومن ثم نقوم بدفع التفرّع الذي أنشأناه إلى الخادم البعيد: git push origin newBranchName 8. كيف أغير الرابط الخاص بمستودع بعيد remote Git repository؟ لتغيير الرابط الخاص بمستودع بعيد (لنفترض أنه التفرّع origin) نستخدم الأمر التالي: git remote set-url origin newURL 9. كيف أغير اسم من قام بالإيداع؟ يمكن تغيير اسم من قام بالإيداع في سجلّ المُستودع باستخدام السكربت التالي المأخوذ من مقالات موقع github.com: git filter-branch --env-filter ' an="$GIT_AUTHOR_NAME" am="$GIT_AUTHOR_EMAIL" cn="$GIT_COMMITER_NAME" cm="$GIT_COMMITTER_EMAIL" if[ "$GIT_COMMITTER_EMAIL" = "your@email.to.match" ] then cn="New Committer Name" cm="New Committer Email" fi if[ "$GIT_AUTHOR_EMAIL" = "your@email.to.match" ] then an="New Author Name" am="New Author Email" fi export GIT_AUTHOR_NAME="$an" export GIT_AUTHOR_EMAIL="$am" export GIT_COMMITTER_NAME="$cn" export GIT_AUTHOR_EMAIL="$cm"' 10. كيف أستنسخ مستودعا في مجلد معين؟ لاستنساخ مستودع في مجلّد معيّن، نحتاج إمّا: الانتقال بمسار سطر الأوامر إلى داخل ذلك المجلّد وتنفيذ الأمر: git clone <URL> أو ننفّذ الأمر: git clone <URL> <yourFolderName> حيث أن yourFolderName هو اسم/مسار المُجلّد المعني بالأمر. ترجمة -وبتصرّف- للمقال Top 10 frequently asked questions on Git لصاحبه Hemant Joshi.

يتيح Git مثل الكثير من أنظمة إدارة النسخ VCS، إمكانية تعليم مواضع معينة خلال مرحلة التطوير على أنها مهمة باستخدام وسوم Tags. يستخدم المطورون كثيرا هذه الميزة لتحديد مواضع إطلاق الإصدارات (الإصدار 1.0؛ 1.1 وهكذا). سنرى في هذا المقال كيفية عرض الوسوم المستخدمة في المستودع، كيفية إنشاء وسوم جديدة وما هي أنواع الوسوم. عرض الوسوم يعرض الأمر التالي قائمة بالوسوم الموجودة في المستودع: git tag النتيجة: v0.1 v1.3 يعرض الأمر أعلاه الوسوم حسب الترتيب الأبجدي. يمكن أيضا البحث عن الوسوم التي تتبع نمطا معيّنا. يحوي مستودع الشفرة المصدرية لـGit على سبيل المثال أكثر من 500 وسم؛ إن كنت ترغب في إظهار الوسوم التي تتعلق بالإصدار 1.8.5 فقط دون غيره فالأمر التالي يؤدي المهمة: git tag -l "v1.8.5*" مثال على النتيجة: v1.8.5 v1.8.5-rc0 v1.8.5-rc1 v1.8.5-rc2 v1.8.5-rc3 v1.8.5.1 v1.8.5.2 v1.8.5.3 v1.8.5.4 v1.8.5.5 إنشاء الوسوم يستخدم Git نوعين من الوسوم: الخفيفة Lightweight والمشروحة Annotated. يشبه الوسم الخفيف فرعا لا تدخل عليه تغييرات، إذ أنه ليس إلا مؤشر على إيداع محدّد. الوسوم المشروحة على العكس من ذلك تخزّن بوصفها كائنات داخل قاعدة بيانات Git ويُنشأ لها مجموع تحقق، تحتوي على اسم من أضاف الوسم، بريده الإلكتروني والتاريخ. كما أن لديها رسالة وسم، ويمكن أن توثَّق ويُتحقَّق منها بواسطة GnuPG (برنامج تعمية تابع لمشروع GNU). يُنصَح باستخدام الوسوم المشروحة من أجل الحصول على كل هذه المعلومات، لكن إن كنت تريد وسما ظرفيا أو لا تريد لسبب ما حفظ البيانات المذكورة آنفا فإن الوسوم الخفيفة متاحة لهذا الغرض. الوسوم المشروحة كل ما عليك فعله لإنشاء وسم مشروح هو إضافة خيار a- إلى أمر git tag على النحو التالي: git tag -a v1.4 -m "my version 1.4" git tag v0.1 v1.3 v1.4 يحدّد الخيار m- رسالة الوسم التي تخزَّن معه. إن لم تحدّد رسالة فسيظهر محرّر بعد تنفيذ الأمر لإضافتها. يمكن عرض الوسم مع الإيداع الموسوم به باستخدام الأمر git show: git show v1.4 tag v1.4 Tagger: Ben Straub &lt;ben@straub.cc&gt; Date: Sat May 3 20:19:12 2014 -0700 my version 1.4 commit ca82a6dff817ec66f44342007202690a93763949 Author: Scott Chacon &lt;schacon@gee-mail.com&gt; Date: Mon Mar 17 21:52:11 2008 -0700 changed the version number يعرض الأمر بيانات الواسِم (صاحب الوسم)، تاريخ وسم الإيداع ورسالة الوسم قبل أن يظهر بيانات الإيداع. الوسوم الخفيفة الطريقة الأخرى لوسم الإيداعات هي استخدام الوسوم الخفيفة. لا تُخزّن أي معلومات إضافية بالنسبة لهذه الوسوم، ما عدا مجموع التحقق من الإيداع. استخدم أمر git tag دون ذكر خيار لإنشاء وسم خفيف: git tag v1.4-lw git tag v0.1 v1.3 v1.4 v1.4-lw v1.5 إن نفذت أمر git show على الوسم الخفيف فلن تظهر سوى بيانات الإيداع: git show v1.4-lw commit ca82a6dff817ec66f44342007202690a93763949 Author: Scott Chacon &lt;schacon@gee-mail.com&gt; Date: Mon Mar 17 21:52:11 2008 -0700 changed the version number الوسم المتأخر يوفّر Git إمكانية وسم الإيداعات حتى بعد أن تكون تجاوزتها. فلنفترض أن سجلّ الإيداعات لديك يبدو كالتالي: git log --pretty=oneline 15027957951b64cf874c3557a0f3547bd83b3ff6 Merge branch 'experiment' a6b4c97498bd301d84096da251c98a07c7723e65 beginning write support 0d52aaab4479697da7686c15f77a3d64d9165190 one more thing 6d52a271eda8725415634dd79daabbc4d9b6008e Merge branch 'experiment' 0b7434d86859cc7b8c3d5e1dddfed66ff742fcbc added a commit function 4682c3261057305bdd616e23b64b0857d832627b added a todo file 166ae0c4d3f420721acbb115cc33848dfcc2121a started write support 9fceb02d0ae598e95dc970b74767f19372d61af8 updated rakefile 964f16d36dfccde844893cac5b347e7b3d44abbc commit the todo 8a5cbc430f1a9c3d00faaeffd07798508422908a updated readme نفترض الآن أنك نسيت إضافة الوسم v1.2 على الإيداع ذي الرسالة updated rakefile. لا زال بإمكانك وسم الإيداع؛ لوسم هذا الإيداع حدّد مجموع التحقق منه (أو جزءًا من مجموع التحقق) في نهاية الأمر كالتالي: git tag -a v1.2 9fceb02 يمكنك التحقق من وسم الإيداع: git tag v0.1 v1.2 v1.3 v1.4 v1.4-lw v1.5 git show v1.2 tag v1.2 Tagger: Scott Chacon &lt;schacon@gee-mail.com&gt; Date: Mon Feb 9 15:32:16 2009 -0800 version 1.2 commit 9fceb02d0ae598e95dc970b74767f19372d61af8 Author: Magnus Chacon &lt;mchacon@gee-mail.com&gt; Date: Sun Apr 27 20:43:35 2008 -0700 updated rakefile ... مشاركة الوسوم لا ينقُل أمر git push مبدئيا الوسوم إلى الخواديم البعيدة. ستحتاج للتصريح بأنك تريد نقل الوسوم التي أنشأتها: git push origin v1.5 Counting objects: 14, done. Delta compression using up to 8 threads. Compressing objects: 100% (12/12), done. Writing objects: 100% (14/14), 2.05 KiB | 0 bytes/s, done. Total 14 (delta 3), reused 0 (delta 0) To git@github.com:schacon/simplegit.git * [new tag] v1.5 -&gt; v1.5 إن كانت لديك الكثير من الوسوم وتريد دفعها معا فخيار tags-- بدلا من اسم الوسم يؤدي المهمة: git push origin --tags Counting objects: 1, done. Writing objects: 100% (1/1), 160 bytes | 0 bytes/s, done. Total 1 (delta 0), reused 0 (delta 0) To git@github.com:schacon/simplegit.git * [new tag] v1.4 -&gt; v1.4 * [new tag] v1.4-lw -&gt; v1.4-lw سيحصُل المساهمون الآخرون بهذه الطريقة على الوسوم التي أضفتها عندما ينسخون المستودع أو يجلبون البيانات منه. نقل ملفات وسم إلى مجلد العمل إن كنت تريد وضع إصدار يستخدم وسما من المستودع في مجلد العمل فيمكنك إنشاء فرع جديد انطلاقا من الوسم باستخدام أمر git checkout كما يلي: git checkout -b version2 v2.0.0 Switched to a new branch 'version2' تحدّد الوسوم، على عكس الفروع، نقطة زمنية ثابتة من المستودع. من هذا المنطلق لا يتطور الوسم بتغير ملفاته لذا ينبغي الانتباه إلى أن الفرع version2 لن يكون موافقا للوسم v2.0.0 بعد إضافة إيداع إليه؛ إذ أن الفرع تقدم إلى الأمام بالتعديلات الجديدة التي أضافها الإيداع. ترجمة -وبتصرّف- للفصل Git Basics - Tagging من كتاب Pro Git لصاحبه Scott Chacon.

يجب أن تعرف كيف تدير المستودعات البعيدة لتكون قادرا على التعاون في مشروع يستخدم Git. المستودعات البعيدة هي نسخ من المشروع مضافة على خادوم غير جهازك المحلي. يمكن أن يكون لديك أكثر من مستودع بعيد، وهو إما أن يكون للقراءة فقط Read-only أو للقراءة والكتابة. يستدعي التعاون مع الآخرين إدارةَ المستودعات ودفع Push البيانات إليها أو جلبها منها Pull لمشاركة مساهماتك مع بقية الفريق. تتضمن إدارة المستودعات البعيدة معرفة كيفية إضافتها، حذفها عندما تصبح غير صالحة، إدارة الفروع Branches البعيدة ومتابعتها Tracking إضافةً لأمور أخرى. يعرِض هذا المقال لمهارات أساسية لإدارة المستودعات البعيدة. عرض المستودعات البعيدة يعرِض الأمر git remote الخواديم البعيدة المضبوطة لديك. ينتج عن تنفيذ الأمر إظهار لائحة بأسماء مختصرة لكل خادوم بعيد ضبطته. إن كنت نسخت مستودعا فسترى على الأقل الاسم المختصر origin، وهو الاسم المختصر الافتراضي الذي يعطيه Git للخادوم الذي نسخت منه المستودع. يستخدَم الاسم المختصر مرجعا للدلالة على المستودع بدلا من كتابة مساره كاملا. في المثال التالي ننسخ المستودع ticgit ثم نلج إلى مجلد المستودع وننفذ أمر git remote: git clone https://github.com/schacon/ticgit Cloning into 'ticgit'... remote: Reusing existing pack: 1857, done. remote: Total 1857 (delta 0), reused 0 (delta 0) Receiving objects: 100% (1857/1857), 374.35 KiB | 268.00 KiB/s, done. Resolving deltas: 100% (772/772), done. Checking connectivity... done. cd ticgit git remote origin لاحظ الاسم المختصر origin. يمكن أيضا استخدام الخيار v- الذي يُظهر مسارات URL التي خزنها Git للاستخدام عند القراءة من المستودع أو الكتابة فيه: git remote -v origin https://github.com/schacon/ticgit (fetch) origin https://github.com/schacon/ticgit (push) إن كان لديك أكثر من مستودع بعيد فسيسرُدها الأمر جميعا. على سبيل المثال، إن كان لمستودع واحد خواديم بعيدة متعدّدة للعمل مع متعاونين مختلفين فستكون نتيجة تنفيذ الأمر كالتالي: cd grit git remote -v bakkdoor https://github.com/bakkdoor/grit (fetch) bakkdoor https://github.com/bakkdoor/grit (push) cho45 https://github.com/cho45/grit (fetch) cho45 https://github.com/cho45/grit (push) defunkt https://github.com/defunkt/grit (fetch) defunkt https://github.com/defunkt/grit (push) koke git://github.com/koke/grit.git (fetch) koke git://github.com/koke/grit.git (push) origin git@github.com:mojombo/grit.git (fetch) origin git@github.com:mojombo/grit.git (push) يعني هذا أن بإمكاننا جلب مساهمات أي واحد من هؤلاء المتعاونين بسهولة. إضافة مستودعات بعيدة ذكرنا في الفقرات السابقة كيفية إضافة مستودعات بعيدة باختصار؛ في الفقرات التالية سنفصِّل في الكيفية. استخدم الأمر التالي لإضافة مستودع جديد باسم مختصر يمكنك جعله مرجعا للمستودع: git remote add [shortname] [url] مثلا: git remote origin git remote add pb https://github.com/paulboone/ticgit git remote -v origin https://github.com/schacon/ticgit (fetch) origin https://github.com/schacon/ticgit (push) pb https://github.com/paulboone/ticgit (fetch) pb https://github.com/paulboone/ticgit (push) يمكنك الآن استخدام الاسم pb بدلا من العنوان الكامل في سطر الأوامر. استخدم الأمر التالي لإحضار جميع البيانات الموجودة في المستودع البعيد الذي أضفته أعلاه والتي لا توجد لديك محليًّا: git fetch pb remote: Counting objects: 43, done. remote: Compressing objects: 100% (36/36), done. remote: Total 43 (delta 10), reused 31 (delta 5) Unpacking objects: 100% (43/43), done. From https://github.com/paulboone/ticgit * [new branch] master -&gt; pb/master * [new branch] ticgit -&gt; pb/ticgit يمكن الآن الوصول إلى الفرع الرئيس من المستودع عبر pb/master . جلب مستودعات بعيدة ودفع البيانات إليها يمكن جلب بيانات مستودع بعيد بتنفيذ الأمر: git fetch [remote-name] يذهب Git بعد تنفيذ الأمر أعلاه إلى المستودع البعيد وينزل جميع بياناته التي لا توجد لديك حتى الآن. تحصُل بعد تنفيذ الأمر على مراجع (أسماء مختصرة) لجميع الفروع يمكن بعد ذلك دمجها أو فحصها في أي وقت. يضيف أمر النسخ git clone الاسم المختصر origin للمستودع البعيد تلقائيا. يجلب أمر git fetch origin أي بيانات جديدة دُفِعت إلى الخادوم بعد نسخ المستودع (أو بعد آخر جلب منه). من المهم ملاحظة أن git fetch تضيف البيانات إلى المستودع المحلي، ولا تدمجها تلقائيا مع أي من أعمالك؛ كما أنها لا تعدل على ما تعمل عليه. يعني هذا أن عليك دمجها يدويا عندما تكون جاهزا. إن كان لديك فرع معدّ لتتبع مستودع بعيد فيمكنك استخدام git pull لجلب البيانات من المستودع البعيد ودمجها مع الفرع الحالي. يُعِد أمر git clone تلقائيا الفرع الرئيس المحلي لتتبع الفرع الرئيس على الخادوم البعيد الذي نُسخ المستودع منه. يجلب أمر git pull البيانات من الخادوم الذي نُسخ أصلا منه المستودع ويحاول تلقائيا دمجها إلى الشفرة البرمجية التي تعمل عليها حاليا. دفع البيانات إلى المستودع البعيد يجب دفع المشروع إلى الخادوم عندما يكون جاهزا لتشاركه مع الآخرين، بتنفيذ الأمر التالي: git push [remote-name] [branch-name] حيث [remote-name] يمثل الفرع على الخادوم البعيد و[branch-name] على الخادوم المحلي، مع التذكير أن نسخ المستودع يضبط الاسمين تلقائيا كما أشرنا أعلاه. عندما تريد دفع الفرع الرئيس إلى الخادوم الأصلي فيمكنك تنفيذ الأمر التالي لدفع الإيداعات التي أنجزتها إلى الخادوم: git push origin master يعمل الأمر السابق فقط إن كنت نسخت المستودع من خادوم لديك صلاحيات الكتابة عليه، مع شرط ألا يكون أي شخص آخر دفع بيانات جديدة للمستودع البعيد بعد آخر عملية جلب قمت بها. إذا نسخت المستودع أنت وشخص آخر في نفس الوقت ثم أضاف هو إيداعات جديدة بدفعها إلى المستودع ثم أتيت لدفع بياناتك فإن المستودع لن يقبلها. يجب عليك في هذه الحالة جلب إيداعات الشخص الآخر أولا إلى جهازك المحلي ثم تضمينها لديك في المشروع ثم دفعه من جديد. فحص مستودع بعيد إن أردت الحصول على معلومات أكثر تفصيلا عن مستودع بعيد فالأمر التالي يؤدي هذه المهمة: git remote show [remote-name] إن نفذت الأمر مع اسم مختصر مثل origin فستحصل على نتيجة شبيهة بالتالي: git remote show origin * remote origin Fetch URL: https://github.com/schacon/ticgit Push URL: https://github.com/schacon/ticgit HEAD branch: master Remote branches: master tracked dev-branch tracked Local branch configured for 'git pull': master merges with remote master Local ref configured for 'git push': master pushes to master (up to date) يظهر في نتيجة الأمر مسار المستودع البعيد إضافة إلى معلومات خاصة بفرع التتبع. يخبرك الأمر أيضا أنك إن نفذت الأمر git pull على الفرع الرئيس master فسيدمجه تلقائيا في الفرع الرئيس في المستودع البعيد بعد أن يجلب جميع المراجع البعيدة؛ كما أنه يسرد قائمة بجميع المراجع البعيدة التي جلبها. إن كنت تستخدم Git كثيرا فستظهر معلومات أكثر تفصيلا من المثال غير المعقد أعلاه: git remote show origin * remote origin URL: https://github.com/my-org/complex-project Fetch URL: https://github.com/my-org/complex-project Push URL: https://github.com/my-org/complex-project HEAD branch: master Remote branches: master tracked dev-branch tracked markdown-strip tracked issue-43 new (next fetch will store in remotes/origin) issue-45 new (next fetch will store in remotes/origin) refs/remotes/origin/issue-11 stale (use 'git remote prune' to remove) Local branches configured for 'git pull': dev-branch merges with remote dev-branch master merges with remote master Local refs configured for 'git push': dev-branch pushes to dev-branch (up to date) markdown-strip pushes to markdown-strip (up to date) master pushes to master (up to date) يعرض الأمر الفروع التي ستُدفَع إليها البيانات تلقائيا عند تنفيذ الأمر git push على فروع معيَّنة. كما يُظهر أيضا الفروع الموجودة على الخادوم التي لا توجد لديك حتى الآن، الفروع التي حذفت من الخادوم ولكنها لا زالت لديك محليًّا والفروع المختلفة التي دُمجت تلقائيا عند تنفيذ الأمر git pull. حذف المستودعات البعيدة وإعادة تسميتها يتيح الأمر git remote rename إمكانية تغيير الاسم المختصر الخاص بالمستودع البعيد. إن أردت مثلا تغيير pb إلى paul فيجب تنفيذ الأمر على النحو التالي: git remote rename pb paul git remote origin paul ينتج عن الأمر أيضا التعديل على أسماء الفروع أيضا، مثلا pb/master تصبح paul/master عند تعديل الاسم المختصر من pb إلى paul. استخدم الأمر git remote rm لحذف مستودع بعيد : git remote rm paul git remote origin ترجمة -وبتصرف- للفصل Git Basics - Working with Remotes من كتاب Pro Git لصاحبه Scott Chacon.

يتناول هذا المقال الأدوات الأساسية للتراجع عن التعديلات في Git. ينبغي دائما الحذر عند التعامل مع أوامر التراجع، إذ أن التراجع من الأمور القليلة في Git التي قد تجعلك تخسر العمل إن أجريتها بطريقة خاطئة. يكثر استخدام التراجع عند الإيداع قبل أن تكون جاهزا لذلك؛ مثلا بنسيان ملفات أو رسائل الإيداع. في هذه الحالة يمكنك إعادة الإيداع باستخدام الخيار amend--: git commit --amend يأخذ الأمر أعلاه محتويات منطقة الإدراج Staging area ويستخدمها في الإيداع. إن لم تحدث أية تغييرات منذ آخر عملية إيداع (عند تنفيذ الأمر مثلا مباشرة بعد تطبيق الإيداع السابق) فسيكون بإمكانك التعديل على رسالة الإيداع الأخيرة التي ستظهر في المحرّر. بهذه الطريقة تكون عدلت على رسالة الإيداع السابق دون أن تضيف إيداعا جديدا. بنفس الطريقة، تمكن إضافة ملف منسي إلى الإيداع. نفترض أنك مثلا بعد إرسال الإيداع فطنت إلى نسيان ملف باسم forgotten_file كان يجب أن يكون فيه؛ في هذه الحالة تستخدم نفس الأمر كما في المثال التالي: git commit -m 'initial commit' git add forgotten_file git commit --amend أرسلنا الإيداع في الأمر الأول، ثم أضفنا في الأمر الثاني ملفا جديدا إلى منطقة الإدراج واستخدمنا خيار amend-- مع git commit. نحصُل في النهاية على إيداع واحد يحل محل الأول ويوجد فيه الملف المنسي. التراجع عن إضافة الملفات إلى منطقة الإدراج سنتطرق في الفقرتين التاليتين إلى كيفية التراجع عن التعديلات على منطقة الإدراج ومجلد العمل. من الجميل أن الأمر الذي يريك حالة هاتين المنطقتين يذكرك بكيفية التراجع عن التعديلات عليهما. لنفترض مثلا أنك عدلت على ملفين وتريد إيداعهما منفصلين (إيداع لكل ملف)، ولكنك نفذت الأمر * git add بالخطأ، وأضفتهما في نفس الوقت إلى منطقة الإدراج. كيف يمكنك نزع الاثنين من منطقة الإدراج؟ أمر git status يذكرك بالكيفية: git add * git status On branch master Changes to be committed: (use "git reset HEAD &lt;file&gt;..." to unstage) renamed: README.md -&gt; README modified: CONTRIBUTING.md مباشرة تحت عبارة Changes to be committed (التعديلات المهيّأة للإيداع) يوجد التذكير الذي يقول "استخدام reset HEAD... للتراجع عن إضافة ملف إلى منطقة الإدراج". إن قررنا اتباع النصيحة والتراجع عن إضافة ملف (وليكن CONTRIBUTING.md) إلى منطقة الإدراج: git reset HEAD CONTRIBUTING.md نحصل على الرسالة التالية: Unstaged changes after reset: M CONTRIBUTING.md وعند التحقق الآن من الحالة: git status نحصل على النتيجة التالية: On branch master Changes to be committed: (use "git reset HEAD &lt;file&gt;..." to unstage) renamed: README.md -&gt; README Changes not staged for commit: (use "git add &lt;file&gt;..." to update what will be committed) (use "git checkout -- &lt;file&gt;..." to discard changes in working directory) modified: CONTRIBUTING.md عدلنا على الملف CONTRIBUTING.md إلا أنه الآن خارج منطقة الإدراج. ملحوظة: استخدام أمر git reset يمكن أن يكون خطرا عند استخدام الخيار hard-- إلا أنه ليس كذلك إن استخدم دون خيارات، في هذه الحالة يتعامل مع منطقة الإدراج فقط. التراجع عن تعديل ملفات ما ذا لو قررت أنك لا تريد الاحتفاظ بالتعديلات التي أجريتها على الملف CONTRIBUTING.md؟ كيف يمكن التراجع عن التعديلات بسهولة، إعادته إلى ما كان عليه قبل آخر إيداع مثلا؟ يخبرك أمر git status بكيفية ذلك، مثل ما فعل مع إضافة الملفات إلى منطقة الإدراج. في مخرجات المثال أعلاه تبدو منطقة الإدراج على النحو التالي: Changes not staged for commit: (use "git add &lt;file&gt;..." to update what will be committed) (use "git checkout -- &lt;file&gt;..." to discard changes in working directory) modified: CONTRIBUTING.md تخبرك الرسالة "..."use "git checkout" بكيفية إلغاء التعديلات على ملفات مجلد العمل. نطبق التعليمات: git checkout -- CONTRIBUTING.md ثم نتحقق من تأثير الأمر: git status On branch master Changes to be committed: (use "git reset HEAD &lt;file&gt;..." to unstage) renamed: README.md -&gt; README تمكن ملاحظة أن التعديلات ألغيت. هام: من المهم فهمُ أن أمر git checkout خطير جدا. يلغي الأمر أي تعديل أجريته بلا رجعة، ولن يمكنك إعادته. استخدم هذا الأمر فقط عندما تكون متأكدا من أنك لم تعد ترغب في التعديلات. تذكر أن كل ما أودِع Commited في Git يمكن غالبا إرجاعه؛ حتى الإيداعات الموجودة على فروع Branches محذوفة أو تلك التي عدل عليها باستخدام خيار amend--. إلا أن البيانات التي لم تودع تُفقَد -على الأرجح- بغير رجعة. ترجمة -وبتصرّف- للفصل Git Basics - Undoing Things من كتاب Pro Git لصاحبه Scott Chacon.

توجد طريقتان أساسيتان في Git لتضمين التعديلات من تفريع إلى آخر: merge و rebase. يشرح هذا المقال ماهية إعادة تأسيس التفريعات Rebasing، كيفيتها، الفائدة منها والحالات التي يجدر بك عدم استخدام إعادة التأسيس فيها. مبادئ إعادة التأسيس يمكن بالعودة إلى المثال في درس المبادئ الأساسية لدمج التفريعات رؤية تمايز أعمالك بإضافة إيداعات إلى كلٍّ من التفريعين. استخدام أمر git merge هو أسهل طريقة، مثل ما رأينا سابقا، لتضمين تفريع في آخر. ينفّذ الأمرُ الدمجَ الثلاثي بين آخر لقطتين في كلّ تفريع (C3 وC4) واللقطة المشتركة الأقرب (C2) منشئا بذلك لقطة (وإيداعا) جديدة. إلا أنه توجد طريقة أخرى: يمكنك أخذ الترقيع Patch الذي أضافه الإيداع C4 ثم تطبيقه على الإيداع C3. تسمى هذه العملية في Git بإعادة التأسيس. يتيح الأمر rebase أخذ جميع الإيداعات التي أضيفت إلى تفريع وتكرارها على تفريع آخر. يكون تطبيق هذا المبدأ على المثال في الصورة بتنفيذ الأمر على النحو التالي: git checkout experiment git rebase master First, rewinding head to replay your work on top of it... Applying: added staged command يعمل الأمر بالرجوع إلى الإيداع السابق المشترك بين التفريعين (التفريع الذي تعمل عليه الآن، والتفريع الذي تريد إعادة التأسيس عليه)، الحصول على التغييرات التي أدرجها كل إيداع على التفريع الحالي وتخزينها في ملف ظرفي، ضبط التفريع الحالي على آخر إيداع في التفريع الذي نريد إعادة التأسيس عليه ثم في الأخير تطبيق التعديلات بالترتيب. نستطيع بالوصول إلى هذه النقطة العودة إلى التفريع master وتنفيذ دمج بتقدم سريع: git checkout master git merge experiment يشير الإيداع 'C4 إلى نفس اللقطة التي يشير إليها الإيداع C5 في مثال الدمج الذي تحدثنا عنه في البداية. لا يوجد فرق في المنتوج النهائي بين الاثنين؛ إلا أن إعادة التأسيس تجعل سجل التعديلات أكثر وضوحا. يبدو سجل الإيداعات في تفريع أعيد تأسيسه خطيًّا: تظهر الأعمال كما لو أنها حدثت بالتتالي، حتى لو كان الواقع أنها كانت بالتوازي. يُلجَأ عادة لتأسيس التفريعات للتأكد من أن الإيداعات تُطبَّق دون مشاكل على تفريع بعيد؛ مثلا عند المشاركة في مشروع لا تتولى صيانته. تعمل في هذه الحالة على تفريع ثم تعيد تأسيس التفريع على origin/master عندما تكون جاهزا لإرسال الترقيع إلى المشروع الرئيس. لن يحتاج مسؤول المشروع في هذه الحالة إلا إلى دمج سريع. انتبه إلى أن اللقطة التي يشير إليها التفريع هي نفسها، سواء كانت الأخيرة من إيداعات بعد إعادة تأسيس التفريع أو إيداع دمج. وجه الاختلاف هو فقط سجل التغييرات. تكرّر إعادة التأسيس التغييرات من خط عمل على آخر بالترتيب الذي حدثت به في حين يأخذ الدمج نقطتي النهاية ويدمجهما معا. إعادات تأسيس متقدمة يتيح Git إمكانية تطبيق إعادة التأسيس على أمور أخرى غير التفريع المستهدف بإعادة التأسيس. نأخذ المثال الموضَّح في الصورة أدناه. أنشأت تفريعا جديدا باسم server (تفريع موضوع Topic branch) لإضافة ميزات من جهة الخادوم إلى مشروعك وأضفت إيداعا إلى هذا التفريع؛ ثم أنشأت بعدها تفريعا جديدا لميزات تعمل في جانب العميل client وأضفت عليه إيداعات متتابعة. عدت في الأخير إلى تفريع server وأضفت إليه إيداعات أخرى. نريد الآن دمج التغييرات في جانب العميل إلى التفريع الرئيس وفي نفس الوقت ترك التعديلات في جانب الخادوم لاختبارها أكثر. نستخدم خيار onto-- مع أمر git rebase لأخذ الإيداعات الموجودة على التفريع client دون أن تكون موجودة على server (أي الإيداعات C8 وC9): git rebase --onto master server client يمكن تفسير الأمر السابق بـ”افحص تفريع client، اعثر على الإيداعات التالية للإيداع المشترك بينه والتفريع server ثم طبقها على التفريع master“. يبدو الأمر معقّدا إلا أن النتيجة مذهلة. يمكن بعدها تطبيق دمج سريع على التفريع الرئيس: git checkout master git merge client نرغب الآن في تضمين التفريع server أيضا. تمكننا إعادة تأسيس التفريع server على التفريع master دون الحاجة لفحصه أولا بتنفيذ الأمر [git rebase [basebranch] [topicbranc. يفحص الأمر تفريع الموضوع (أي التفريع server في هذه الحالة) تلقائيا ثم يؤسسه على التفريع القاعدي (master): git rebase master server يُعيد الأمر تأسيس التفريع server على التفريع master على النحو الموضَّح في الصورة التالية. نطبق دمجا سريعا للتفريع القاعدي master: git checkout master git merge server يمكن الآن حذف التفريعين server وclient لأن جميع الأعمال فيهما أدمجت في التفريع الرئيس ولم تعد بحاجة إليها. git branch -d client git branch -d server يبدو سجل التعديلات كما يظهر في الصورة أدناه. مشاكل إعادة التأسيس يمكن إجمال مخاطر إعادة تأسيس التفريعات في النصيحة التالية: لا تُعِد تأسيس إيداعات موجودة خارج مستودعك. تهجُر عندما تعيد تأسيس تفريع، إيداعاتٍ موجودةً وتبدلها بأخرى جديدة مشابهة إلا أنها مختلفة. تصبح الأمور صعبة وغير مرتبة عند استخدام إعادة التأسيس بما يخالف النصيحة أعلاه، مثلا عندما تدفع إيداعات إلى مستودع مشترك ثم يجلبها آخرون ويعملون عليها، ثم تعيد كتابة الإيداعات باستخدام أمر git rebase وتدفعها إلى المستودع مرة أخرى. سيحتاج مشاركوك في هذه الحالة لإعادة دمج أعمالهم ويمكن أن تحدث مشاكل عندما يريدون دفع أعمالهم بعدك. فلنأخذ مثالا لحالة يمكن أن تؤدي فيها إيداعات - أعيد تأسيسها ووُفِّرت للعموم - إلى مشاكل. نفترض أنك نسخت مستودعا من خادوم مركزي ثم أجريت أعمالا عليه. يبدو سجل الإيداعات على النحو الموضَّح في الصورة التالية. يعمل أحدهم في هذه الأثناء على إضافة تعديلات إلى المستودع من ضمنها دمج تفريع ثم يدفع النتيجة إلى الخادوم المركزي، تأتي أنت وتفتش عن الجديد على المستودع البعيد وتدمج التفريع البعيد الجديد إلى عملك؛ يصبح سجل الإيداعات على النحو التالي. يقرّر الشخص الذي دفع التفريع المدموج التراجع وإعادة تأسيس التفريع بدلا من ذلك؛ ينفذ أمر: git push --force لتغيير سجل الإيداعات على الخادوم، ثم تأتي أنت للتفتيش عن جديد المستودع البعيد وتجلب الإيداعات الجديدة. أنتما الآن في ورطة: تنفيذك لأمر: git pull سينشئ إيداعَ دمج يتضمّن سجلي التعديلات وسيبدو المستودع لديك كالتالي: سيظهر عند تنفيذ أمر git log على سجل التعديلات أعلاه إيداعان لديهما نفس الكاتب، التاريخ والرسالة؛ أمر مربك. علاوة على ذلك، يؤدي دفع بيانات بسجل التغيير هذا إلى الخادوم إلى إدخال كل هذه الإيداعات المعاد تأسيسها إلى الخادوم وهو ما سيربك الآخرين أكثر. من الآمَن في هذه الحالة افتراضُ أن المطوّر الآخر لا يريد أن يَبقى الإيداعان C4 وC6 في سجل الإيداعات؛ ولهذا السبب أعاد التأسيس أصلا. إصلاح ما أفسدته إعادة التأسيس يوفر Git آليات إضافية لحالات مثل التي رأيناها في الفقرة السابقة. التحدي في المواقف التي يدفع فيها أحد أعضاء الفريق تعديلات تغير تلك التي أعدت تأسيس عملك عليها هو التفريق بين عملك وبين ما أعيدت كتابته. يحسب Git، إضافة إلى مجموع التحقق (دالة SHA-1) الخاص بالإيداع مجموع تحقق خاص بالترقيع Patch الذي أضيف مع الإيداع؛ يسمّى مجموع التحقق هذا بمعرّف الترقيع Patch id. يمكن لـGit، عندما تجلب بيانات أعيدت كتابتها ثم تعيد التأسيس لها على الإيداعات الجديدة من الشريك، أن يتعرّف على الإيداعات الخاصة بك ثم يطبقها على التفريع الجديد. بدلا من تنفيذ أمر git merge بعد أن نفّذ الشريك أمر git push --force في المثال السابق (الحالة الموضَّحة في الصورة قبل الأخيرة) نفّذ الأمر git rebase teamone/master وسيقوم Git بالتالي: تحديد الإيداعات الخاصة بتفريعك فقط (أي الإيداعات C6، C4، C3، C2 وC7). التعرف على الإيداعات التي ليست إيداعات دمج (C3، C2 وC4). تحديد الإيداعات التي لم تُعد كتابتها في التفريع الوجهة (التفريعان C2 وC3 فالإيداعان C4 و'C4 هما نفس الترقيع، أي أن تعديلاتهما هي نفسها). تطبيق هذه الإيداعات على التفريع teamone/master. ينتج عن الخطوات المتّبعة الوضعية التالية بدلا من تلك التي كنا سنجد فيها أنفسنا لو نفّذنا أمر git pull. تعمل الطريقة أعلاه فقط إن كان الإيداعان C4 و'C4 الذين أضافهما شريكك متطابقين تقريبا؛ وإلا فإن أمر rebase لن يكون قادرا على معرفة أيهما المكرَّر وسيضيف إيداعا جديدا مشابها لـ'C4 (يُحتمَل جدّا ألا يُطبَّق نظرا لأن التعديلات ستكون غالبا موجودة في مكان ما). يمكن تسهيل الأمر بتنفيذ git pull --rebase بدلا من git pull عادي؛ أو التأسيس يدويا بتنفيذ أمر git fetch تتبعه بـ git rebase teamone/master في هذه الحالة. توجد طريقة لجعل خيار rebase-- مبدئيا عند تنفيذ أمر git pull وهي إعداد المعطى pull.rebase في الإعدادات ليأخذ القيمة git config --global pull.rebase true. ستجري الأمور بخير ما دمت تستخدم إعادة التأسيس بوصفها طريقة لتنسيق الإيداعات والعمل عليها قبل دفعها وما ظللت ملتزما بإعادة تأسيس الإيداعات التي لم تتوفر أبدا للعموم دون غيرها. في الجانب الآخر، تتعرّض للكثير من المخاطر بإعادة التأسيس على إيداعات سبق دفعها إلى مستودعات عمومية ويمكن أن يكون بعض شركائك أسسوا عملهم عليها. تأكد من تنفيذ جميع أعضاء الفريق لأمر git pull --rebase لمحاولة التقليل من المشاكل بعد إعادة تأسيس أحدهم على إيداعات جلبها من المستودع العمومي. إعادة التأسيس أم الدمج؟ ربما تتساءل الآن بعد الخوض في كلّ من إعادة التأسيس والدمج، أيهما أنسب؟ سنعود إلى الوراء قليلا قبل الإجابة على التساؤل لندقّق في معنى سجل المستودع. يمكن رؤية الموضوع على أساس أن سجل المستودع هو تسجيل لما حدث فيه، بمعنى أنه وثيقة تاريخية قيّمة بذاتها، ولا يجوز التلاعب بها. يعدّ تغيير السجلّ من وجهة النظر هذه خطأ كبيرا؛ فذلك يعني تزوير الوقائع. ماذا لو حدثت فوضى في المستودع بعد متتالية من الإيداعات؟ هذه هي الوقائع ويجب أن تظل مسجّلة تقول وجهة النظر هذه. توجد رؤية مغايرة للموضوع، تقول إن سجل الإيداعات هو رواية لكيفية بناء المشروع. يحتاج دليل صيانة البرنامج لنفس الحذر الذي يتطلبه نشر كتاب، فلا يجوز أن تنشر كتابا مازال في طور المسودة. يتبنى وجهة النظر هذه من يستخدمون أدوات مثل git rebaseوgit filter-branch لسرد القصة بأفضل طريقة للقراء المستقبليين. يتضح الآن أن سؤال أيها أستخدم، إعادة التأسيس أم الدمج؟ ليس بتلك السهولة. Git أداة قوية تسمح بفعل الكثير من الأشياء للسجّل وبه؛ إلا أن كلّ فريق مختلف وكذلك المشاريع. يعود الأمر إليك، بعد فهم طريقة عمل الاثنين، لاختيار ما يناسب الفريق الذي تعمل معه والمشروع الذي تعمل عليه. المبدأ العام للحصول على أفضل ما في الطريقتين هو إعادة تأسيس التعديلات المحلية التي لم تشارَك بعد قبل أن تدفعها من أجل تقديم القصة؛ والابتعاد تماما عن إعادة تأسيس أي شيء سبق دفعه إلى مستودع عمومي. خاتمة غطينا في هذه السلسلة أساسيات التفريع والدمج في Git. يجدر بك أن تكون مرتاحا للعمل على إنشاء التفريعات الجديدة والانتقال للعمل عليها، التبديل بين التفريعات ودمجها ودمج التفريعات المحلية معا؛ بالإضافة إلى تشارك التفريعات بدفعها إلى خادوم مشترك، العمل مع آخرين على تفريعات مشتركة وإعادة تأسيس تفريعاتك فبل أن تشاركها. الخطوة الموالية هي معرفة ما تحتاجه لتشغيل خادوم Git خاص بك لتشارك المستودعات. ترجمة -بتصرف- للفصل Git Branching - Rebasing من كتاب Pro Git لصاحبه Scott Chacon.

يُستخدَم Hexo، وهو إطار عمل للتدوين الثابت (Static) مبنيّ على Node.js، لنشر تدوينات مكتوبة في مستندات Markdown. تُعالَج التدوينات ثم تُحوَّل إلى HTML/CSS انطلاقا من قوالب معدَّة لهذا الغرض (تماما كما تفعل بقية مُولّدات المحتوى الثابت مثل Jekyll و Ghost). يعمل Hexo على هيئة وِحدات (Modules) يمكن ثبيتها وإعدادها حسب الحاجة. سنعدّ في هذا المقال Hexo اعتمادا على خادوم ويب Nginx ومنصة GitHub. المتطلبات في ما يلي قائمة بما ستحتاجه لإنجاز هذا الدرس: خادوم أوبنتو 14.04 مع حساب ذي صلاحيات إدارية غير المستخدم الجذر. يمكنك إعداد حساب بالمواصفات المطلوبة باتباع خطوات درس الإعداد الابتدائي لخادوم أوبنتو. تثبيت Git على خادوم أوبنتو وإعداده. يشرح درس تنصيب وإعداد Git و gitolite للتحكم في الإصدارات على أوبنتو الكيفية. تثبيت Node.js على خادوم أوبنتو. تثبيت Nginx على خادوم أوبنتو. حساب على GitHub الذي هو مستودع Git. تأكد من أن المتطلبات مثبتة ومضبوطة ثم انتقل إلى خطوات تثبيت Hexo وإعداده. الخطوة الأولى: تثبيت Hexo وبدء تشغيله تتضمن هذه الفقرة كل ما عليك فعله لتثبيت Hexo وجعله يعمل على خادومك. ابدأ أولا بتحديث الحزم: sudo apt-get update && sudo apt-get upgrade يتكوّن Hexo من الكثير من العناصر والحزم البرمجية. سنجلب اثنتين من الحزم الأكثر أهمية في Hexo باستخدام مدير الاعتمادات npm. العنصر الأول والأهم هو hexo-cli، يوفر أوامر Hexo الأساسية : npm install hexo-cli -g ثم نأتي للعنصر الثاني hexo-server وهو خادوم مضمَّن يمكن استخدامه للعرض المسبق للتدوينات واختبارها قبل النشر: npm install hexo-server -g تتوفر الكثير من الحزم الأخرى لـHexo، إلا أن الحزمتين أعلاه هما الأساس الذي لا يُستغنى عنه لإطلاق مدونة باستخدام Hexo. يمكن أن تستعرض الحزم الأخرى المكونة لإطار عمل Hexo بخاصية البحث في npm. نحتاج الآن لقاعدة ملفات لبناء مدونتنا عليها. يُوفِّر Hexo أمر init لهذا الغرض، كل ما عليك فعله هو تمرير المسار أو المجلد الذي تريد استخدامه لملفات إعداد المدونة إلى الأمر: hexo init ~/hexo_blog يستغرق اﻷمر بضع ثوان حسب سرعة الاتصال لديك: INFO Copying data to ~/hexo_blog INFO You are almost done! Don't forget to run 'npm install' before you start blogging with Hexo! . . . ننتقل إلى المجلد المستخدَم في الأمر السابق: cd ~/hexo_blog ثم ننفذ أمر التثبيت التالي: npm install يمكنك تجاهل التحذيرات الاختيارية (WARN notsup). نحصُل بعد انتهاء تنفيذ الأمر على ملفات الإعداد الأساسية. الخطوة الثانية: ضبط ملف الإعداد الأساسي في Hexo نسرُد محتويات مجلد المشروع: ls -l تظهر مخرجات على النحو التالي: -rw-rw-r-- 1 zeine77 zeine77 1483 Feb 17 15:48 _config.yml drwxrwxr-x 201 zeine77 zeine77 36864 Feb 17 15:53 node_modules -rw-rw-r-- 1 zeine77 zeine77 442 Feb 17 15:48 package.json drwxrwxr-x 2 zeine77 zeine77 4096 Feb 17 15:45 scaffolds drwxrwxr-x 3 zeine77 zeine77 4096 Feb 17 15:45 source drwxrwxr-x 3 zeine77 zeine77 4096 Feb 17 15:45 themes يعدّ الملف config.yml_ أهم هذه الملفات إذ تخزَّن به إعدادات نواة Hexo. إن احتجت مستقبلا لإجراء تعديلات على المدونة فعلى الأرجح سيكون ذلك من خلال هذا الملف. نفتح الملف لإجراء تخصيصات على البرنامج: nano _config.yml توجد في أعلى الملف فقرة معنونة بـSite (الموقع): # Site title: Hexo subtitle: description: author: John Doe language: timezone: يوجد في الأسطر الأربعة الأولى اسم المدونة، عنوان فرعي لها، وصف واسم صاحب المدونة. لديك كامل الحرية في اختيار ما يناسب لهذه الأسطر. انتبه إلى أن بعض قوالب Hexo لا تعرض كامل هذه المعلومات. يمكن اعتباره هذه الفقرة بيانات وصفية للمدونة. الخياران المواليان يمثلان اللغة والمنطقة الزمنية. تأخذ اللغة قيمة عبارة عن حرفين يرمزان للغة وفق معيار ISO-639-1. يُضبط الوقت مبدئيا على المنطقة الزمنية للخادوم ويستخدم صيغة قاعدة بيانات tz. إن قررت التعديل على إحدى المعطيين فتأكد أن القيمة وفق الصيغة المطلوبة. في ما يلي مثال على ملف الإعداد: #Site title: مدونة أكاديمية حسوب subtitle: مدونة تقنية تستخدم Hexo description: مثال على استخدام Hexo لإنشاء مدونة author: أكاديمية حسوب language: ar timezone: Africa/Nouakchott تضبط الفقرة الموالية إعدادات الروابط. يمكن استخدام عنوان IP قيمةً لمعطى url إن لم يكن لديك نطاق خاص. # URL ## If your site is put in a subdirectory, set url as 'http://yoursite.com/child' and root as '/child/' url: http://127.0.0.1 root: / permalink: :year/:month/:day/:title/ permalink_defaults: خيار آخر نودّ تغييره في ملف الإعداد وهو default_layout ضمن فقرة Writing إلى الأسفل قليلا. نحدد القيمة draft للمعطى. يعني هذا أن المنشورات الجديدة تُنشأ على هيئة مسودات يجب نشرها حتى تكون مرئية على المدونة. # Writing new_post_name: :title.md # File name of new posts default_layout: draft titlecase: false # Transform title into titlecase احفظ الملف ثم أغلقه. سنعود إليه لاحقا عندما نبدأ بالنشر. الخطوة الثالثة: كتابة تدوينة جديدة ونشرها تبدأ عملية نشر تدوينة (أو مسودة كما أسميناها في الإعداد أعلاه) بتنفيذ الأمر التالي، حيث أول-تدوينة هو اسم التدوينة التي تريد إنشاءها: hexo new أول-تدوينة تظهر الرسالة التالي في سطر الأوامر: INFO Created: ~/hexo_blog/source/_drafts/أول-تدوينة.md نفتح الملف لتحرير أول تدويناتنا: nano ~/hexo_blog/source/_drafts/أول-تدوينة.md يجب أن تحوي كل تدوينة على جبهة أمامية Front-matter، وهي كتلة تعليمات قصيرة مكتوبة بـJSON أو YAML لضبط إعدادات مثل عنوان التدوينة، تاريخ النشر، الوسوم Tags ومعلومات من هذا القبيل. تُعلَّم نهاية الجبهة الأمامية بعلامة --- أو ;;;. تمكن كتابة منشور المدونة بعد الجبهة الأمامية باستخدام صيغة Markdown. أبدل المحتوى المبدئي لملف "md.أول-تدوينة" بالمحتوى التالي: title: أول تدوينة في مدونة أكاديمية حسوب tags: - حسوب - مدونة categories: - إعلانات comments: true date: 2016-02-18 09:30:00 --- ## هنا تكتب تعليمات ماركداون **هذه هي تدوينتنا الأولى!** نص التدوينة الأولى احفظ الملف ثم أغلقه. سيبقى ملف ماركداون الذي أنشأناه للتو في مجلد hexo_blog/source/_drafts/~ إلى أن ننشره. كل الملفات الموجودة في هذا الملف غير مرئية لزوار المدونة. ننشر التدوينة لتتاح للزوار hexo publish first-post تظهر الرسالة التالية: INFO Published: ~/hexo_blog/source/_posts/أول-تدوينة.md سيصبح بالإمكان رؤية المنشور فور نشر المدونة. الخطوة الرابعة: تشغيل خادوم الاختبار أكملنا في الخطوات السابقة إعداد الخادوم، ونشرنا أول تدوينة. سنشغّل خادوم الاختبار لرؤية النتيجة: hexo server يمكن الآن رؤية المدونة بزيارة http://your_server_ip:4000 حيث your_server_ip عنوان IP الموقع. سيظهر لديك منشور Hello World المعرَّف مسبقا، إضافة للمنشور الذي كتبناه للتو. اضغط على الزرين CTRL+C لإيقاف خادوم الاختبار. يُستخدم خادوم الاختبار لعرض التغييرات والإضافات إلى المدونة، ثم يأتي وقت نشر المدونة على الشبكة بعد أن تنتهي من التعديلات. الخطو الخامسة: إعداد Git لنشر المدونة توجد وسائل عدة لنشر ما أعدنناه على Hexo. المقاربة المختارة في هذا الدرس هي استخدام Git لتخزين الملفات الثابتة، الخطافات Hooks لتوجيهها وNginx لتقديمها. تتيح حزم في Hexo الدعم لـ Heroku ،Rsync ،OpenShift وغيرها. سنحتاج لمستودع Git نخزّن فيه ملفات HTML التي يولّدها Hexo. سنستخدم مستودعا عموميا على GitHub لتسهيل الأمور. أنشئ مستودعا جديدا على GitHub باسم hexo_static أو أي اسم آخر تراه مناسبا، مع التأكد من أن المستودع عمومي (خيار Public). حدّد مربع Initialize this repository with a README لإضافة ملف README تلقائيا إلى المستودع. افتح ملف الإعداد الرئيسي لـHexo من أجل تحريره: nano _config.yml توجد في أسفل الملف فقرة معنونة بـDeployment: # Deployment ## Docs: https://hexo.io/docs/deployment.html deploy: type: حدّد خيارات النشر كما في المثال أدناه. يحيل رابط URL إلى المستودع الذي أنشأته للتو؛ لذا تأكد من وضع اسم حسابك في GitHub مكان your_github_username. أبدل كذلك اسم المستودع إن كنت اخترت اسما مغايرا. deploy: type: git repo: https://github.com/your_github_username/hexo_static.git branch: master احفظ الملف ثم أغلقه. بما أننا اخترنا النشر عن طريق Git فسنحتاج لحزمة Hexo التي ترسل الملفات الثابتة التي يولدها إلى مستودع Git. استخدم npm لتثبيتها: npm install hexo-deployer-git --save يمكنك الآن تجربة إرسال الملفات إلى مستودع hexo_static وإضافة أول إيداع بواسطة Hexo: hexo generate && hexo deploy أدخل معلومات الاستيثاق في GitHub عندما تطلب منك لبدء نقل الملفات. تبدو نتيجة تنفيذ الأمرين السابقين بعد نجاحه على النحو التالي: To https://github.com/username/hexo_static.git. * [new branch] master -> master Branch master set up to track remote branch master from https://github.com/username/hexo_static.git. INFO Deploy done: git الخطوة السادسة: إعداد Nginx يتميّز خادوم ويب Nginx في تقديم الملفات الثابتة للزوار، وهو ما يجعله اختيارا مناسبا لمدونتنا. نبدأ بإعداد Nginx لتقديم المدونة للزوار. ننشئ أولا مجلدات النظام التي سنطلب من Nginx استخدامها: sudo mkdir -p /var/www/hexo ثم نعطي للحساب الذي نستخدمه على أوبنتو ملكيةَ المجلد: sudo chown -R $USER:$USER /var/www/hexo نعدّل أذون المجلد على النحو التالي: sudo chmod -R 755 /var/www/hexo نفتح ملف الإعداد المبدئي لـNginx لتحريره: sudo nano /etc/nginx/sites-available/default نعدّل كلتة server في ملف الإعداد بحيث يصبح جذر المستند Document root يشير إلى المجلد الذي أنشأناه للتو: server { listen 80 default_server; listen [::]:80 default_server ipv6only=on; root /var/www/hexo; index index.html index.htm; احفظ الملف ثم أغلقه. يمكنك عند الحصول على اسم نطاق للمدونة تحرير هذا الملف وتحديد قيمة server_name بحيث تصبح اسمَ نطاقك. نعيد تشغيل Nginx لاعتماد التعديلات: sudo service nginx restart الخطوة السابعة: إنشاء خطافات Hooks في Git سنربط في هذه الخطوة مستودع hexo_static بمستودع Git آخر لنرسل عبره ملفات HTML إلى مجلد خادوم الويب. نبدأ بإنشاء مستودع Git فارغ الهدف منه توجيه محتوى المستودع hexo_static إلى مجلد خادوم الويب: git init --bare ~/hexo_bare أنشئ ملف خطاف جديدا داخل مجلد خطافات Git: nano ~/hexo_bare/hooks/post-receive أضف السطرين التاليين إلى الملف. نحدّد في الملف شجرة عمل Git التي تحوي الشفرة المصدرية ومجلد Git الذي يحوي الإعدادات، السجل وأمورا أخرى: #!/bin/bash git --work-tree=/var/www/hexo --git-dir=/home/$USER/hexo_bare checkout -f احفظ الملف ثم أغلقه. اجعل الملف post-receive قابلا للتنفيذ: chmod +x ~/hexo_bare/hooks/post-receive سنحتاج الآن لنسخ مستودع النشر hexo_static الذي أنشأناه في الخطوة الخامسة إلى الخادوم. تأكد من إبدال username في الأمر أدناه باسم حسابك في GitHub. git clone https://github.com/username/hexo_static.git ~/hexo_static انتقل إلى المجلد hexo_static: cd ~/hexo_static نضيف مستودع hexo_bare السابق على أنه مستودع بعيد باسم live: git remote add live ~/hexo_bare الخطوة الثامنة: إنشاء سكربت النشر يمكن باستخدام سكربت Shell قصير بدء كامل عملية النشر السابقة بدلا من أدائها يدويا. يعني هذا أننا لن نحتاج إلى تنفيذ أوامر Hexo الواحدة تلو الأخرى أو تشغيل خطّاف Git بأوامر متعدّدة. نعود إلى مجلد مدونة Hexo وننشء فيه ملفا للسكربت: cd ~/hexo_blog nano hexo_git_deploy.sh ألصق الشفرة التالية في الملف: #!/bin/bash hexo clean hexo generate hexo deploy ( cd ~/hexo_static ; git pull ; git push live master ) احفظ الملف ثم أغلقه. ينفذ السكربت أوامر Hexo التالية: أمر clean الذي يحذف الملفات المولَّدة سابقا من مجلد public. أمر generate الذي يولّد ملفات HTML انطلاقا من ملفات ماركداون ويضعها في مجلد public. أمر deploy الذي يُرسِل الملفات الموجودة في المجلد public إلى مستودع Git الذي عرّفناه سابقا في ملف الإعداد config.yml_. يشغّل السطر الأخير (cd ~/hexo_static ; git pull ; git push live master) خطاف Git ويحدّث مجلد المدونة على خادوم الويب بوضع ملفات HTML فيه. نجعل سكربت النشر قابلا للتنفيذ: chmod +x hexo_git_deploy.sh الخطوة التاسعة: تنفيذ سكربت النشر نفذ سكربت النشر السابق لاختبار كامل العملية: ./hexo_git_deploy.sh ستُطلب منك معلومات الاستيثاق أثناء إيداع الملفات في مستودع GitHub. انتظر اكتمال العملية ثم ألق نظرة على الملفات في المجلد var/www/hexo/: ls /var/www/hexo النتيجة: 2016 archives categories css fancybox index.html js tags تُظهر نتيجة الأمر أعلاه أن الملفات التي أنشأها Hexo نُقلت إلى مجلد خادوم الويب، يعني هذا أن بإمكانك تصفح المدونة بالذهاب إلى عنوان الخادوم http://your_server_ip/. يكفي تنفيذ السكربت hexo_git_deploy.sh مستقبلا لنشر التعديلات أو الإضافات على المدونة. تذكر أن تختبر التغييرات على خادوم Hexo الاختباري قبل نشرها. الخطوة العاشرة: اكتشاف نظام ملفات Hexo (اختيارية) يعتمد Hexo على ملفات للعمل عليها. ليس من الضروري تعديل هذه الملفات إلا أنه سيكون من الجيد معرفة دور كل واحد منها في نظام الملفات التابع لـHexo، فربما تحتاج لاستخدامه. يبدو مخطَّط الملفات والمجلدات على النحو التالي: ├── _config.yml ├── node_modules ├── package.json ├── scaffolds ├── source | └── _posts └── themes مجلد node_modules يخزّن Hexo في هذا المجلّد الوحدات التي تنزّلها بـ npm لاستخدامها في المدونة. بنهاية هذا الدرس لن توجد في هذا المجلد سوى الحزم التي نزلناها في الخطوة الأولى أو الحزم التي تأتي مضمَّنة في Hexo. على العموم لن تحتاج للتعديل على هذا المجلد. مجلد package.json يحوي ملف JSON هذا الإعدادات والإصدارات التي يستخدمها Hexo. الجأ لهذا الملف إن احتجت لتحديث الحزم يدويا، إرجاعها إلى إصدار أقدم Downgrade أو حذفها. لن تحتاج لتعديل هذا الملف على الأرجح إلا إذا حدث تعارض بين حزم Hexo وهو أمر غير شائع. مجلد scaffolds يستخدم Hexo القوالب الموجودة في هذا المجلد ليصيغ التدوينات وفقا لها. تأتي ثلاثة قوالب مبدئيا في الملف وهي draft (مسودة)، post (منشور) و page (صفحة). إن أردت استخدام قالب جديد فيجب وضعه هنا قبل الاستخدام. مجلد source توجد التدوينات المنشورة في مجلد فرعي من مجلد source، نفس الشيء ينطبق على المسودات. يوجد أغلب محتوى المدونة المكتوب بماركداون في هذا المجلد أو مجلد متفرع عنه. مجلد themes توضع قوالب المظهر Themes في هذا المجلد. تحوي أغلب القوالب على ملف config.yml_ خاص بها للاحتفاظ بإعدادات مخصّصة مثل تلك التي يعرّفها ملف الإعداد العام. استخدمنا خلال هذا الدليل القالب المبدئي في Hexo. خاتمة لم نتطرق في هذا الدرس للكثير مما يمكن تعلمه، إلا أنه يضع قاعدة متينة لإنشاء مدونة باستخدام Hexo. راجع التوثيق الرسمي لإطار العمل والذي يحوي الكثير من المعلومات الدقيقة إن أردت التعمق أكثر في البرنامج. الخطوة الموالية هي تخصيص المظهر ليناسب رغباتك في تطوير مدونة خاصة بك. ترجمة -وبتصرف- لمقال How to Create a Blog with Hexo On Ubuntu 14.04 لصاحبه C.J. Scarlett.

المراجع البعيدة في Git هي مؤشرات Pointers إلى المستودعات البعيدة بما تتضمنه من تفريعات، وسوم وغيرها. يمكنك الحصول على لائحة كاملة بالمراجع البعيدة بتنفيذ الأمر: git ls-remote [remote] أو: git remote show [remote] لعرض التفريعات البعيدة إضافة لمعلومات متفرقة. إلا أنه توجد طريقة أخرى أكثر شيوعا وهي الاستفادة من تفريعات التتبع عن بعد Remote-tracking branches تفريعات التتبع عن بعد هي مراجع لحالة التفريعات البعيدة. توجد هذه التفريعات محليا إلا أنه ليس بالإمكان تحريكها فهي تتحرك تلقائيا عندما تتبادل بيانات مع الخادوم البعيد. تعمل تفريعات التتبع عن بعد كإشارة مرجعية لتذكيرك بموضع تفريعات المستودعات البعيدة في آخر مرة اتصلت فيها بالخادوم. تأخذ تفريعات التتبع عن بعد الهيئة (remote)/(branch). إن أردت مثلا رؤية الحالة التي كان عليها التفريع master على مستودع origin البعيد في آخر مرة اتصلت فيها به فستفحص Checkout التفريع origin/master. إن كنت تعمل عن بعد مع زملاء، ثم دفعوا Push تفريعا باسم iss53 فيمكن أن يكون لديك تفريع محلي بنفس الاسم بينما يشير تفريع التتبع عن بعد إلى الإيداع على origin/iss53. قد يبدو الأمر معقّدا قليلا لذا سنأخذ مثالا. فلنفترض أن لديك خادوم Git على العنوان git.ourcompany.com. إن نسخت Clone مستودعا من الخادوم فإن أمر git clone سيسميه تلقائيا origin، يجلب جميع البيانات إلى المستودع المحلي، ينشئ مؤشرا إلى آخر إيداع في التفريع master ويسميه محليا بـorigin/master. يوفر Git أيضا تفريع master محليا يبدأ من نفس مبدأ التفريع master الخاص بـorigin. ملحوظة: origin ليس مستودعا ذا خصوصية. لا يمثل origin مستودعا ذا خصوصية تماما كما أن master ليس تفريعا ذا دلالة خاصة في Git. يسمّي Git التفريع َالمبدئي بـmaster عند تنفيذ أمر git init كما يسمي أمر git clone المستودع البعيد مبدئيا بـ origin؛ لهذا السبب فقط يكثُر استخدام التسميتين. إن نفذت أمر git clone مع خيار o- مثل: git clone -o booyah فسيكون التفريع booyah/master هو التفريع المبدئي لديك. إن عملت على التفريع master المحلي وأثناء عملك دفع أحدهم تغييرات إلى git.ourcompany.com وحدّث التفريع master على الخادوم فسيختلف سجل الإيداعات المحلي عن البعيد. في تلك الأثناء لن يتغير تفريع origin/master ما لم تدخل في تبادل بيانات مع الخادوم. نفذ أمر: git fetch origin لمزامنة تفريع التتبع عن بعد. يبحث الأمر عن خادوم المستودع origin (أي git.ourcompany.com )، يفتش عن البيانات الموجودة على الخادوم التي لا توجد محليا ثم يحدّث البيانات المحلية محرّكا المؤشر origin/master إلى موضعه الجديد. نأخذ مثالا لتوضيح كيف تبدو تفريعات التتبع عن بعد لخواديم بعيدة متعدّدة. نفترض أن لديك خادوم Git داخلي تستخدمه إحدى فرق العمل لأغراض التطوير والاختبار. عنوان هذا الخادوم هو git.team1.ourcompany.com. تمكن إضافة مرجع للخادوم البعيد هذا إلى المشروع الذي تعمل عليه حاليا بتنفيذ الأمر: git remote add كما تطرقنا لذلك في درس العمل على المستودعات البعيدة في Git. نضيف المستودع مع استخدام الاختصار teamone. يمكنك الآن تنفيذ الأمر: git fetch teamone للبحث عن البيانات الموجودة على الخادوم الجديد دون أن تكون موجودة محليا. يوجد على الخادوم teamone جزء من العمل الموجود على الخادوم الأول؛ يعني هذا أن Git بعد تنفيذ الأمر السابق لن ينزل إيداعات جديدة لكنه سيكتفي بإنشاء تفريع تتبع عن بعد جديد ويسميه teamone/master يشير إلى آخر إيداع في التفريع master على الخادوم teamone. دفع البيانات عندما تريد مشاركة تفريع تعمل عليه مع آخرين فستحتاج لدفع البيانات إلى مستودع بعيد لديك صلاحية الكتابة عليه. لا يُزامن Git التفريعات المحلية تلقائيا مع التفريعات البعيدة، بل يجب أن تزامن التفريع الذي ترغب في مشاركته يدويا. تستخدم بهذه الطريقة تفريعات خاصة (محلية) للأعمال التي لا تريد مشاركتها بينما تدفع بيانات التفريعات التي تود مشاركتها إلى خادم مشترك. إن كان لديك تفريع باسم serverfix تريد التشارك بالعمل عليه مع آخرين فيمكنك دفع البيانات إليه بنفس طريقة دفع التفريع الأخرى بتنفيذ الأمر: git push <remote> <branch> كما في المثال التالي: git push origin serverfix Counting objects: 24, done. Delta compression using up to 8 threads. Compressing objects: 100% (15/15), done. Writing objects: 100% (24/24), 1.91 KiB | 0 bytes/s, done. Total 24 (delta 2), reused 0 (delta 0) To https://github.com/schacon/simplegit * [new branch] serverfix -> serverfix يأخذ Git تلقائيا محتوى التفريع serverfix إلى refs/heads/serverfix:refs/heads/serverfix وهو ما يعني أخذ بيانات التفريع المحلي serverfix ودفعها لتحديث بيانات التفريع البعيد serverfix. سنعرج للحديث عن refs/heads/ عندما نتحدث عن أمور داخلية في Git، يمكن الآن تجاوزها. يمكن أيضا تنفيذ الأمر: push origin serverfix:serverfix الذي يؤدي نفس المهمة. يُفسَّر الأمر بـ "خذ التفريع serverfix المحلي واجعله هو تفريع serverfix البعيد". يمكن استخدام هذه الطريقة لدفع بيانات تفريع محلي إلى تفريع بعيد يختلف عنه في الاسم. أما إن كنت ترغب في تغيير اسم التفريع في المستودع البعيد فيمكنك تنفيذ الأمر: git push origin serverfix:awesomebranch لدفع بيانات تفريع serverfix المحلي إلى التفريع awesomebranch على الخادوم البعيد. لا تعد كتابة كلمة السر في كل مرة! يطلُب Git عند دفع البيانات إلى مستودع يستخدم روابط مؤمنة بيانات الاستيثاق (اسم المستخدم وكلمة السر) ويظهر محثّ Prompt في سطر الأوامر لتلقي هذه البيانات. تستطيع استخدام تخبئة اعتمادات Credential cache لتفادي إدخال اسم المستخدم وكلمة السر في كل مرة تدفع فيها البيانات. الطريقة الأسهل لإعدادها هي تنفيذ أمر: git config --global credential.helper cache يحصُل مشاركوك في المستودع عند تنفيذ أمر git fetch مستقبلا على مرجع لمكان نسخة التفريع serverfix الموجودة على الخادوم: git fetch origin remote: Counting objects: 7, done. remote: Compressing objects: 100% (2/2), done. remote: Total 3 (delta 0), reused 3 (delta 0) Unpacking objects: 100% (3/3), done. From https://github.com/schacon/simplegit * [new branch] serverfix -> origin/serverfix من المهم الانتباه إلى أن تفريعات التتبع عن بعد التي تنتج عن تنفيذ أمر git fetch لا تعطيك تلقائيا نسخة يمكن تحريرها من هذه التفريعات. يعني هذا بعبارة أخرى أن الأمر أعلاه لا ينشئ تفريع serverfix جديدا بل مؤشرا باسم origin/serverfix لا يمكن تعديله. نفذ أمر: git merge origin/serverfix لدمج التفريع البعيد في التفريع الحالي لديك. إن كنت تريد تفريع serverfix خاصا بك للعمل عليه فيمكنك تأسيسه على تفريع التتبع عن بعد: git checkout -b serverfix origin/serverfix Branch serverfix set up to track remote branch serverfix from origin. Switched to a new branch 'serverfix' يعطيك الأمر أعلاه تفريعا محليا يبدأ من حيث يوجد origin/serverfix ويمكنك العمل عليه. تفريعات التتبع Tracking branches يؤدي فحصُ تفريع محلي من تفريع تتبع عن بعد تلقائيا إلى إنشاء ما يُسمّى تفريع تتبع. تفريعات التتبع هي تفريعات محلية ذات علاقة مباشرة مع مستودع بعيد (يُسمَّى التفريع البعيد بالتفريع العلوي Upstream branch). إذا كنت تعمل على تفريع تتبع ثم نفذت أمر git pull فإن Git سيعرف تلقائيا من أين سيجلب البيانات والتفريعَ الذي يجب دمجها فيه. ينتج عادة عن نسخ مستودع إنشاء تفريع master لتتبع origin/master. يمكنك إن أردت إعداد تفريعات تتبع أخرى؛ أو التخلي عن تتبع التفريع master الذي أُعدّ تلقائيا أثناء نسخ المستودع. أقرب مثال لإنشاء تفريعات تتبع هو تنفيذ الأمر: git checkout -b [branch] [remotename]/[branch] هذا الأمر شائع لدرجة أن Git لديه اختصار للأمر: git checkout --track origin/serverfix Branch serverfix set up to track remote branch serverfix from origin. Switched to a new branch 'serverfix' في الواقع، الأمر شائع لدرجة وجود اختصار للاختصار أعلاه! ينشئ Git عند تنفيذ أمر git checkout تفريع تتبع إذا توفر الشرطان: (أ) التفريع غير موجود سلفا، (ب) يوافق اسم التفريع بالضبط تفريعا بعيدا وحيدا: git checkout serverfix Branch serverfix set up to track remote branch serverfix from origin. Switched to a new branch 'serverfix' تتاح أيضا إمكانية إعداد تفريع محلي باسم مختلف عن التفريع البعيد باستخدام النسخة الأولى من الأمر مع ذكر اسم التفريع المحلي على النحو التالي: git checkout -b sf origin/serverfix Branch sf set up to track remote branch serverfix from origin. Switched to a new branch 'sf' بهذا يجلب تنفيذ الأمر git pull على التفريع sf البيانات تلقائيا من origin/serverfix. استخدم خيار u- أو set-upstream-- إذا كنت تريد إعداد تفريع محلي تعمل عليه لتتبع تفريع بعيد أو تغيير التفريع العلوي الذي يتتبّعه التفريع المحلي: git branch -u origin/serverfix Branch serverfix set up to track remote branch serverfix from origin. ملحوظة: اختصار التفريع العلوي. تستطيع بعد إعداد تفريع تتبع استخدام الاختصار {upstream}@ أو {u}@ للإشارة إلى التفريع العلوي المرتبط به. نفترض أنك تعمل على التفريع master الذي يتتبع التفريع origin/master؛ يمكنك في هذه الحالة تنفيذ الأمر المختصر {git merge @{u بدلا من git merge origin/master. استخدم خيار vv- مع أمر git branch لعرض تفريعات التتبع التي أعددتها. يسرد الأمر قائمة بالتفريعات المحلية مع معلومات أكثر عن كل تفريع بما فيها التفريعات العلوية وهل تفريع التتبع يتقدم على التفريع العلوي أم يتأخر عنه أم الاثنان معا. git branch -vv iss53 7e424c3 [origin/iss53: ahead 2] forgot the brackets master 1ae2a45 [origin/master] deploying index fix * serverfix f8674d9 [teamone/server-fix-good: ahead 3, behind 1] this should do it testing 5ea463a trying something new تشير نتيجة الأمر في المثال أعلاه إلى أن التفريع iss53 يتتبّع التفريع origin/iss53، وأنه يتقدم عليه بإيداعين (ahead 2)؛ بمعنى أنه يوجد إيداعان محليان لم يدفعا بعدُ إلى الخادوم. يظهر أن التفريع master يتتبّع التفريع origin/master وأنه محدَّث. نرى في السطر الموالي أن serverfix يتتبّع server-fix-good على الخادوم teamone وأنه يتقدم عليه بـ3 ويتأخر عنه ب1؛ أي أنه يوجد إيداع واحد على الخادوم لم يُدمج محليَّا بعد، كما توجد ثلاثة إيداعات محلية لم تُدفع إلى الخادوم. يظهر في السطر الأخير أن التفريع testing لا يتتبّع أي تفريع بعيد. يجب الانتباه إلى أن هذه الأعداد تحيل إلى البيانات المخبَّأة منذ آخر مرة بُحث فيها عن بيانات على كل خادوم؛ فالأمر أعلاه لا يدخل في اتصال مع الخواديم بل يخبرك فقط بالمعلومات الموجودة محليا. إن كنت تريد بيانات حديثة كليًّا فيجب البحث عنها أولا على الخواديم جميعا بتنفيذ الأمر git fetch عليها. يمكن مثلا تحديث البيانات من جميع الخواديم كالتالي: git fetch --all; git branch -vv جلب البيانات ينزّل أمر git fetch كل التغييرات الموجودة على الخادوم التي لا توجد عندك محليا؛ ولكنها لا تغير مجلد العمل بتاتا، بل تكتفي بتنزيل البيانات وترك مهمة دمجها لك. إلا أنه يوجد أمر git pull الذي ينزّل البيانات ويدمجها في مجلد العمل لديك؛ ينتج عن تنفيذ أمر git pull غالبا تنفيذ أمر git fetch متبوعا مباشرةً بأمر git merge. يؤدي تنفيذ git pull على تفريع تتبع مُعدّ مثل ما وضحنا في الفقرة السابقة، إما بإعداده صراحة أو عن طريق أمر git clone أو git checkout، يؤدي إلى البحث في المستودع العلوي المناسب عن البيانات الجديدة ثم دمجها فورا في تفريع التتبع المحلي. من الأفضل عموما استخدام أمري: git fetch و git merge بالتتابع إذ أن أمر git pull قد يكون مربكا. حذف التفريعات البعيدة لنفترض أنك أنهيت العمل على تفريع بعيد (أكملت أنت ومشاركوك العمل على ميزة وأُدمجت في التفريع الرئيس الذي توجد به الشفرة المستقرة مهما كان اسمه، master أو أي شيء آخر)؛ يمكنك حذف هذا التفريع باستخدام الخيار delete-- في أمر git push. نفذ الأمر التالي إذا أردت حذف التفريع serverfix من الخادوم: git push origin --delete serverfix To https://github.com/schacon/simplegit - [deleted] serverfix يتلخص عمل الأمر في حذف مؤشر التفريع من الخادوم. يحتفظ خادوم Git عادة ببقية البيانات لمدة إلى أن تتم عملية جمع النفايات Garbage collection؛ تتيح هذه الطرقة إمكانية إرجاع التفريع إن كان حذفه عرضيا. ترجمة -بتصرف- للفصل Git Branching - Remote Branches من كتاب Pro Git لصاحبه Scott Chacon.

تعرفنا في الدرسين السابقين على كيفية إنشاء التفريعات (Branches) في Git و كيفية دمجها وحذفها. سنرى في هذا الدرس أدوات لإدارة التفريعات وخططا لتسيير أعمال التطوير باستخدام التفريعات في Git. إدارة التفريعات لا ينحصر عمل أمر git branch على إنشاء التفريعات وحذفها، بل يتعدّى ذلك. إن نفّذت الأمر من دون خيارات فستحصُل على قائمة بالتفريعات الحالية: git branch iss53 * master testing لاحظ علامة * أمام تفريع master: تعني هذه العلامة أن التفريع master هو آخر تفريع انتقلت إليه، أي أن المؤشّر HEAD يشير الآن إلى هذا التفريع). يعني هذا أيضا أنك إن أضفت إيداعا الآن فإن تفريع master سيتقدّم إلى الأمام. استخدم خيار v- لعرض آخر إيداع على كل تفريع: git branch -v iss53 93b412c fix javascript issue * master 7a98805 Merge branch 'iss53' testing 782fd34 add scott to the author list in the readmes يمكن أيضا استخدام الخيارين merged-- و no-merged-- لترشيح نتيجة الأمر والإبقاء فقط على التفريعات التي دُمجت أم لا في التفريع الذي توجد عليه الآن: git branch --merged iss53 * master يظهر التفريع iss53 لأنك دمجته سابقا في التفريع الحالي master. في الحالة العامة يمكن حذف التفريعات التي لا تظهر أمامها علامة * في نتيجة الأمر أعلاه إذ يدل ذلك على أن محتواها دُمج سابقا في تفريع آخر (الحالي) وبالتالي فلن تخسر شيئا بحذفها. استخدم الخيار no-merged-- لعرض التفريعات التي تحوي أعمالا لم تُدمج بعد: git branch --no-merged testing تُظهر نتيجة الأمر السابق التفريع الآخر الذي يوجد به محتوى لم يُدمَج بعد. إن جربت حذف هذا التفريع بالأمر: git branch -d فلن ينجح: git branch -d testing error: The branch 'testing' is not fully merged. If you are sure you want to delete it, run 'git branch -D testing'. تظهر رسالة خطأ لتعلمك بوجود محتوى على التفريع testing لم يُدمج بعد. إن أردت رغم ذلك حذف التفريع وبالتالي فقدان المحتوى فيمكنك فرض الحذف باستخدام الخيار D- كما تشير بذلك رسالة المساعدة في نتيجة الأمر السابق. تسيير العمل باستخدام التفريعات تعرفنا على أساسيات التفريع والدمج ولكن كيف يمكننا استخدامها في تسيير عمليات التطوير؟ سنغطي في هذه الفقرة طريقتين يكثر استخدامهما لتسيير الأعمال بالاعتماد على مبادئ التفريع. التفريعات طويلة الأمد تسهّل قاعدة الدمج الثلاثي من إمكانية دمج تفريع في آخر أكثر من مرة في فترة زمنية طويلة. يعني هذا أنه بالإمكان الإبقاء دائما على تفريعات مفتوحة لاستخدامها في أطوار مختلفة من دورة تطوير البرنامج ودمج بعضها في أخرى من حين لآخر. يختار كثير من مستخدمي Git هذه المقاربة القائمة على الحفاظ على الشفرة البرمجية المستقرة - التي صُدّرت لبيئة الإنتاج أو في طريقها إلى ذلك - في التفريع الرئيس. يوجد بالتوازي مع التفريع الرئيس تفريع آخر باسم develop أو next للعمل عليه أو لاختبار الاستقرار. ليس بالضرورة أن يكون هذا التفريع مستقرا دائما، ولكنه حالما يصل إلى حالة استقرار يُدمج في التفريع الرئيس. يُستخدَم التفريع الموازي لتُدمج فيه التفريعات قصيرة الأمد (تفريع لميزة محدّدة) عندما تكون جاهزة والتأكد من استقرار العمل وخلوه من العلل بعد إضافة الميزة الجديدة قبل أن يُدمج في التفريع الرئيس. تُفهم هذه المقاربة بالنظر إلى موقع مؤشر التفريع على الخط الزمني للإيداعات. توجد الإيداعات المستقرة في نقطة أقدم على الخط الزمني، بينما توجد إيداعات التفريعات الجديدة في موقع أحدث. رؤية خطية للتفريع حسب تقدم الاستقرار طريقة أخرى لفهم المقاربة هي النظر إلى التفريعات على أنها مدرَّجات. تنتقل مجموعة إيداعات إلى درجة أعلى (أكثر استقرارا) بعد أن تُختبر. تدرج الإيداعات حسب درجة الاستقرار يمكن استخدام مستويات استقرار متعددة. يوجد في بعض المشاريع تفريع باسم proposed (مُقترَح) أو pu (اختصار لـproposed updates أي تحديثات مقترحة) لتضمين التفريعات التي لم تجهز بعد للدمج في تفريع next أو master. الفكرة هي أن تكون التفريعات على مستويات مختلفة من الاستقرار؛ وعندما تصل إلى مستوى استقرار أعلى تُدمج في التفريع الموالي. ليس من الضروري أن تكون لديك تفريعات متعدّدة ولكن ذلك يساعد غالبا خصوصا في المشروعات المعقّدة أو الكبيرة. تفريعات المواضيع تفيد تفريعات المواضيع، وهي تفريعات قصيرة الأمد تُنشأ لميزة أو عمل محدّد مرتبط بالمشروع، مهما كان حجمه. ليس شائعا استخدام هذه الطريقة في التفريع في نظم إدارة النسخ الأخرى لثقل آليات التفريع والدمج فيها؛ على العكس من Git الذي تُستخدم فيه هذه الطريقة كثيرا. رأينا مثالا على طريقة التفريع هذه عندما أنشأنا التفريعين iss53 و hotfix في درس أساسيات التفريع والدمج: أضفنا بضع إيداعات إلى التفريعين ثم حذفناهما مباشرة بعد دمجهما في التفريع الرئيس. تتيح هذه الطريقة سهولة تغيير السياق تماما وبسرعة؛ نظرا لكون العمل مقسَّمًا حسب مواضيع فإن كل تفريع يحتفظ فقط بالتغييرات المتعلقة بموضوعه. يمكن إبقاء التغييرات في التفريع لدقائق، أيام أو أشهر ثم دمجها عندما تكون جاهزة بغض النظر عن ترتيب إنشاء تفريعات المواضيع أو ترتيب العمل عليها. فلنفترض المثال التالي: كنت تعمل على التفريع الرئيس (master) ، أنشأت تفريعا جديدا لعلة اكتشفتها (iss91) واستمريت في العمل عليها لبعض الوقت ثم أنشأت تفريعا جديدا من التفريع iss91 لتجربة طريقة أخرى في حل العلة (iss91v2)؛ ثم عدت للعمل على التفريع الرئيس وعملت عليه لبعض الوقت ثم أنشأت تفريعا جديدا لتجربة فكرة لست متأكدا من نجاحها (التفريع dumbidea). يبدو سجل التفريع لهذا المثال على النحو التالي فلنفرض أن الحل الثاني للعلة (التفريع iss91v2) هو الأفضل، وأن الفكرة الجديدة نالت إعجاب زملائك في العمل. يمكن الآن التخلي عن التفريع iss91 (مما يعني خسارة الإيداعين C5 وC6) ثم دمج التفريعين المتبقيين في التفريع الرئيس. يصبح سجل الإيداعات على النحو التالي من المهم تذكر أن جميع هذه التفريعات محلية. كل التغييرات التي تفعلها عند إنشاء تفريعات جديدة أو دمج تفريعات موجودة تتم في مستودع Git دون حدوث أي تواصل مع خادوم بعيد. توجد خطط أخرى لتسيير العمل عند التعامل مع المستودعات البعيدة سنعرض لها في مقال لاحق. ترجمة -بتصرف- للفصل Git Branching - Branching Workflows من كتاب Pro Git لصاحبه Scott Chacon.

يدعم Git على غرار غالبية أنظمة إدارة النسخ التفريع Branching. يُقصَد بالتفريع الانتقال للعمل على خط تطوير مغاير لخط التطوير الرئيس والاستمرار في العمل على هذا الخط دون تداخل مع الخط الرئيس. يتطلّب التفريع في كثير من أنظمة إدارة النسخ إنشاء نسخة جديدة من مجلد الشفرة المصدرية، وهو أمر مكلّف ويأخذ الكثير من الوقت في المشاريع الكبيرة. أساسيات التفريع نحتاج لفهم آلية التفريع للعودة قليلا إلى الوراء ومراجعة الكيفية التي يخزّن بها Git بياناته. ذكرنا في درس مبادئ Git الأساسية أن البرنامج لا يخزّن البيانات على هيئة مجموعة فروق أو تغييرات؛ لكنه بدلا من ذلك يخزّن متتالية من اللقطات Snapshots. ما يحدُث عند إيداع البيانات هو أن Git يخزّن كائن إيداع Commit object يحوي مؤشرا على لقطة للمحتوى الذي أدرجته. يوجد بهذا الكائن أيضا اسمُ كاتب الإيداع Author وبريده الإلكتروني، الرسالة التي أضفتها مع الإيداع ومؤشرات Pointers على الإيداع أو الإيداعات التي تأتي مباشرة قبل الإيداع الذي يمثّله الكائن المذكور (الإيداع أو الإيداعات السابقة): لا سابق بالنسبة لأول إيداع، سابق واحد لإيداع عاديّ وإيداعات سابقة متعدّدة لإيداع ناتج عن دمج Merge تفريعين أو أكثر. سنفرض أن لدينا ثلاثة ملفات، أضفناها جميعا إلى منطقة الإدراج ثم نفّذنا أمر الإيداع. ينشئ الإدراج جمع تحقق Checksum لكلّ ملف، يخزّن نسخة الملف في مستودع Git (يسمّي Git هذه النسخ بالكتل Blobs) ثم يضيف جموع التحقق إلى منطقة الإدراج: git add README test.rb LICENSE git commit -m 'The initial commit of my project' ينشئ Git عند تنفيذ أمر commit جمع تحقق لكل مجلّد فرعي (المجلّد الجذر فقط في المثال الحالي) ويخزّن كائنات الشجرة في مستودع Git؛ ثم ينشئ بعد ذلك كائن إيداع لديه بيانات وصفية Metadata ومؤشرًا يحيل إلى شجرة جذر المشروع مما يسمح له بإنشاء لقطة من المجلد عند الحاجة. يحوي مستودع Git الآن خمسة كائنات: كتلة واحدة لمحتوى كلٍّ من الملفات الثلاثة، شجرة واحدة تسرُد لائحة بمحتوى المجلّد وتحدّد الكتل التي تخزِّن أسماء الملفات وكائن إيداع يوجد فيه مؤشر إلى جذر الشجرة إضافة لكلّ البيانات الوصفية الخاصة بالإيداع. شجرة البيانات الخاصة بالإيداع إن أجريت تعديلات ثم نفذت أمر commit من جديد فإن الإيداع الجديد سيخزّن مؤشرا على الإيداع الذي سبقه. إيداع والإيداعات السابقة عليه تفريع Git ليس سوى مؤشر على واحد من هذه الإيداعات؛ يتميز هذا المؤشر بكونه قابلا للنقل. يدعى التفريع المبدئي في Git بـmaster. ينشئ Git عند بدء الإيداعات تفريعا يؤشِّر على آخر إيداع؛ وفي كلّ مرة تضيف إيداعا جديدا ينتقل المؤشر تلقائيا إليه. ملحوظة: تفريع master ليس تفريعًا خاصًّا فهو مماثل لأي تفريع آخر في Git. يعود السبب في كون كلّ مستودعات Git تقريبا تحوي تفريعًا بهذا الاسم إلى أنّ أمر git init ينشئ مبدئيا تفريعا بهذا الاسم، والكثيرون لا يكلّفون أنفسهم عناء تغييره. تفريع وسجل الإيداعات الخاصة به إنشاء تفريع جديد في Git مالذي يحدث بالضبط عندما تنشئ تفريعا جديدا؟ يعني هذا أنك تنشئ مؤشرا جديدا للتنقل به. فلنفترض أننا أنشأنا تفريعا جديدا باسم testing باستخدام أمر git branch التالي: git branch testing ينشئ الأمر مؤشرا جديدا يحيل إلى نفس الإيداع الذي توجد عليه. أي أن لدينا مؤشرين يحيلان إلى نفس المتتالية من الإيداعات. تفريعان يشيران إلى نفس متتالية الإيداعات كيف يعرف Git التفريع الذي توجد عليه الآن؟ يحتفظ Git لهذا الغرض بمؤشر خاص يُسمّى HEAD (المقدّمة). ينبغي الانتباه إلى أن HEAD في Git مختلف تماما عنه في أنظمة إدارة نسخ أخرى مثل Subversion و CVS. يحيل HEAD إلى التفريع المحلي الذي تعمل عليه الآن. في المثال أعلاه فنحن لا زلنا على التفريع master حتى بعد إنشاء تفريع testing الجديد؛ فأمر git branch ينشئ تفريعا جديدا ولكنّه لا ينقُل إلى التفريع الجديد. مؤشر HEAD يشير إلى تفريع master تسهُل رؤية هذا الأمر بتنفيذ أمر git log الذي يعرض عند تحديد الخيار decorate-- الإيداعات التي تحيل إليها مؤشرات التفريعات: git log --oneline --decorate f30ab (HEAD -> master, testing) add feature #32 - ability to add new formats to the central interface 34ac2 Fixed bug #1328 - stack overflow under certain conditions 98ca9 The initial commit of my project يظهر اسما التفريعين master وtesting بجانب الإيداع f30ab. التبديل بين التفريعات يُستخدم أمر git checkout للانتقال إلى تفريع وبدء العمل عليه. ننفذ الأمر التالي للانتقال إلى التفريع testing الذي أنشأناه للتو: git checkout testing ينقل أمر git checkout أعلاه مؤشرَ HEAD إلى تفريع testing. يشير HEAD الآن إلى تفريع testing ما دلالة نقل مؤشّر HEAD؟ سنضيف إيداعا جديدا وسنرى: vim test.rb git commit -a -m 'made a change' يتقدم مؤشر HEAD إلى الإيداع الأخير في التفريع ينتقل مؤشر HEAD بتنفيذ الأمر commit. أي أن تفريع testing تقدم بإيداع بينما لا زال تفريع master على ما كان عليه عند تنفيذ أمر الانتقال git checkout. نعود إلى التفريع الرئيس master بتنفيذ الأمر التالي: git checkout master ينتقل مؤشر HEAD إلى التفريع الرئيس ينقل الأمر السابق مؤشر HEAD ليحيل إلى التفريع الرئيس ثم يرجع الملفات الموجودة في مجلد العمل إلى اللقطة التي يشير إليها التفريع master. يعني هذا أيضا أن التعديلات من الآن فصاعدا ستكون على نسخة قديمة من المشروع. يبدو الأمر كما لو أنك تراجعت عن التعديلات التي أجريتها بعد الانتقال إلى تفريع testing؛ وبدأت في تغييرات جديدة. ملحوظة: الانتقال إلى تفريع يغيّر ملفات مجلد العمل. ينبغي الانتباه إلى أن الانتقال إلى تفريع يؤدي إلى تغير الملفات الموجودة في مجلد العمل. إن انتقلت إلى تفريع قديم فسيعود محتوى مجلد العمل إلى ما كان عليه بعد آخر إيداع على هذا التفريع. إن لم يستطع Gitفعل ذلك فلن يسمح لك بتاتا بالانتقال إلى التفريع الجديد نعدّل على أحد الملفات ثم نضيف إيداعا جديدا: vim test.rb git commit -a -m 'made other changes' للتذكير نحن نعمل على التفريع master. بالإيداع أعلاه يبدأ سجلّ التفريعين بالتباعد كما هو موضح في الشكل أدناه. أنشأنا تفريعا جديدا وانتقلنا للعمل عليه، أجرينا بضعة تغييرات ثم عدنا من جديد للعمل على التفريع الرئيس. كل من هذه التغييرات معزول عن الآخر في تفريع مختلف: يمكن العمل على تفريع، ثم الانتقال إلى تفريع آخر والعمل عليه ثم العودة إلى التفريع الأول والعمل عليه أيضا؛ وعندما تكون جاهزا يمكن أن تدمج الاثنين. يؤدّى كل هذا العمل بسهولة بالأوامر checkout ،branch وcommit. تباعد التفريعات عن بعضها يمكن استخدام الأمر التالي لعرض سجل التغييرات على شكل مخطّط يوضّح إلى أين تحيل مؤشرات التفريعات وكيف تباعدت عن بعضها: git log --oneline --decorate --graph --all مثال على النتيجة: * c2b9e (HEAD, master) made other changes | * 87ab2 (testing) made a change |/ * f30ab add feature #32 - ability to add new formats to the * 34ac2 fixed bug #1328 - stack overflow under certain conditions * 98ca9 initial commit of my project يسهُل إنشاء تفريعات ومحوها في Git، إذ لا يتطلّب ذلك سوى إنشاء ملفّ من مجموع تحقق ذي 40 محرفا يمثّل الإيداع الذي يحيل إليه مؤشّر التفريع. يختلف Git عن نظم إدارة نسخ أخرى يتطلب التفريع فيها نسخ جميع ملفات المشروع إلى مجلد ثان ممّا يدوم ثواني عدّة وأحيانا دقائق حسب حجم المشروع؛ بينما يكاد يكون الأمر في Git لحظيا. زيادة على ذلك فإن تخزين سوابق الإيداع تجعل من العثور على قاعدة مناسبة لدمج تفريعين أسهل وفي كثير من الأحيان تلقائيا. تشجّع هذه الميزة التي سنتطرّق إليها في المقال التالي المطوّرين على إنشاء التفريعات واستخدامها أكثر. ترجمة -بتصرف- للفصل Git Branching - Branches in a Nutshell من كتاب Pro Git لصاحبه Scott Chacon.

قد تود بعد القيام بعمليات إيداع عدّة، أو بعد استنساخ Cloning مستودع Repository يحوي سجلا للإداعات، النظر إلى ماضي الإيداعات لرؤية مالذي كان يحصُل. أمر git log أيسر طريقة وأكثرها فعالية لهذا الغرض. تستخدم الأمثلة المقدّمة هنا مشروع simplegit-progit الذي يمكن الحصول عليه بتنفيذ الأمر التالي: git clone https://github.com/schacon/simplegit-progit نفذ أمر git log بعد الدخول إلى مجلد المشروع: git log ستحصل على مخرجات على النحو التالي: commit ca82a6dff817ec66f44342007202690a93763949 Author: Scott Chacon &lt;schacon@gee-mail.com&gt; Date: Mon Mar 17 21:52:11 2008 -0700 changed the version number commit 085bb3bcb608e1e8451d4b2432f8ecbe6306e7e7 Author: Scott Chacon &lt;schacon@gee-mail.com&gt; Date: Sat Mar 15 16:40:33 2008 -0700 removed unnecessary test commit a11bef06a3f659402fe7563abf99ad00de2209e6 Author: Scott Chacon &lt;schacon@gee-mail.com&gt; Date: Sat Mar 15 10:31:28 2008 -0700 first commit يسرُد أمر git log - إن استخدِم دون خيارات - الإيداعات التي حدثت حسب ترتيب زمني عكسي، أي الإيداع الأحدث أولا. تمكن ملاحظة أنه مع كل إيداع يظهر مجموع التدقيق Checksum الخاص به، اسم من كاتب الإيداع وعنوانها البريدي، تاريخ الإيداع ورسالة الإيداع. توجد الكثير من الخيارات للاستخدام مع أمر git log من أجل إظهار ما تريده بالضبط. سنعرِض هنا لأكثرها شعبية. يعرض خيار p- عند استخدامه مع أمر git log الفروقات ضمن كل إيداع. تمكن إضافة عدد لتحديد المخرجات. يعرض المثال التالي آخر إيداعيْن مع إظهار الفروق: git log -p -2 النتيجة: commit ca82a6dff817ec66f44342007202690a93763949 Author: Scott Chacon &lt;schacon@gee-mail.com&gt; Date: Mon Mar 17 21:52:11 2008 -0700 changed the version number diff --git a/Rakefile b/Rakefile index a874b73..8f94139 100644 --- a/Rakefile +++ b/Rakefile @@ -5,7 +5,7 @@ require 'rake/gempackagetask' spec = Gem::Specification.new do |s| s.platform = Gem::Platform::RUBY s.name = "simplegit" - s.version = "0.1.0" + s.version = "0.1.1" s.author = "Scott Chacon" s.email = "schacon@gee-mail.com" s.summary = "A simple gem for using Git in Ruby code." commit 085bb3bcb608e1e8451d4b2432f8ecbe6306e7e7 Author: Scott Chacon &lt;schacon@gee-mail.com&gt; Date: Sat Mar 15 16:40:33 2008 -0700 removed unnecessary test diff --git a/lib/simplegit.rb b/lib/simplegit.rb index a0a60ae..47c6340 100644 --- a/lib/simplegit.rb +++ b/lib/simplegit.rb @@ -18,8 +18,3 @@ class SimpleGit end end - -if $0 == __FILE__ - git = SimpleGit.new - puts git.show -end \ No newline at end of file يعرض الخيار p- نفس المعلومات التي يعرضها الأمر بدون خيارات، مع إضافة الفروق بالنسبة لكل مُخرَج (إيداع). يفيد هذا الأمر كثيرا عند مراجعة الشفرة البرمجية أو للتصفح السريع لما جرى خلال سلسلة من عمليات الإيداع التي أجراها أحد أعضاء الفريق مثلا. يمكن أيضا استخدام خيارات للتلخيص مع الأمر git log. إن أردت مثلا إحصاءات ملخَّصة لكلّ إيداع فيمكنك استخدام خيار stat--: git log --stat النتيجة: commit ca82a6dff817ec66f44342007202690a93763949 Author: Scott Chacon &lt;schacon@gee-mail.com&gt; Date: Mon Mar 17 21:52:11 2008 -0700 changed the version number Rakefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) commit 085bb3bcb608e1e8451d4b2432f8ecbe6306e7e7 Author: Scott Chacon &lt;schacon@gee-mail.com&gt; Date: Sat Mar 15 16:40:33 2008 -0700 removed unnecessary test lib/simplegit.rb | 5 ----- 1 file changed, 5 deletions(-) commit a11bef06a3f659402fe7563abf99ad00de2209e6 Author: Scott Chacon &lt;schacon@gee-mail.com&gt; Date: Sat Mar 15 10:31:28 2008 -0700 first commit README | 6 ++++++ Rakefile | 23 +++++++++++++++++++++++ lib/simplegit.rb | 25 +++++++++++++++++++++++++ 3 files changed, 54 insertions(+) يظهر خيار stat-- تحت كل إيداع قائمة بالملفات التي عُدلت في الإيداع، عددها وعدد الأسطر التي أُضيفت أو حُذفت. يضيف الخيار أيضا ملخصًا للتعديلات تحت كل إيداع. إن أردت تغيير الصيغة التي تظهر بها مخرجات السجل فيمكنك استخدام الخيار pretty--. توجد صيغ معدّة سلفا للاستخدام؛ عند إعطاء القيمة oneline لخيار pretty-- فإن كل إيداع يظهر في سطر واحد، وهو ما سيكون مفيدا إن كانت لديك الكثير من الإيداعات للنظر فيه. git log --pretty=oneline النتيجة: ca82a6dff817ec66f44342007202690a93763949 changed the version number 085bb3bcb608e1e8451d4b2432f8ecbe6306e7e7 removed unnecessary test a11bef06a3f659402fe7563abf99ad00de2209e6 first commit تعدّ قيمة format من أكثر قيم pretty-- أهمية. تعطي هذه القيمة عند استخدامها مع الخيار إمكانية تحديد صيغة مخصَّصة لمخرجات السجلات. يساعد هذا الأمر كثيرا إن كنت تريد تهيئة المخرجات لتحليلها آليا: git log --pretty=format:"%h - %an, %ar : %s" مثال على النتيجة: ca82a6d - Scott Chacon, 6 years ago : changed the version number 085bb3b - Scott Chacon, 6 years ago : removed unnecessary test a11bef0 - Scott Chacon, 6 years ago : first commit توجد في الجدول أدناه قائمة بالخيارات التي يمكن استخدامها لتهيئة مخرجات format. table{border: 1px solid black; border-collapse: collapse;} td, th{border: 1px solid black; padding: 5px 15px;} th{background-color: #ecf0f1;} الخيار الوصف H% مجموع التدقيق h% الصيغة المختصرة لمجموع التدقيق T% مجموع التدقيق لكامل الشجرة Tree t% مجموع التدقيق المختصَر للشجرة P% مجموعات التدقيق للعنصر الأب an% اسم كاتب الإيداع ae% البريد الإلكتروني لكاتب الإيداع ad% تاريخ إنشاء الإيداع (Author date) ar% التاريخ النسبي لإنشاء الإيداع (قبل كذا من الزمن) cn% اسم صاحب الإيداع Commiter ce% البريد الإلكتروني لصاحب الإيداع cd% تاريخ الإيداع cr% التاريخ النسبي للإيداع s% الموضوع ملحوظة: ربما تتساءل عن الفرق بين كاتب الإيداع وصاحب الإيداع؛ كاتب الإيداع هو الشخص الذي كتب العمل بينما صاحب الإيداع هو آخر شخص أضاف العمل إلى المستودع. نفرض مثلا أنك أرسلت ترقيعا لمشروع برمجي، ثم أضافه أحد مطوري المشروع إلى المستودع. يُعزَى لكل منكما في السجل؛ أنت بوصفك كاتب الترقيع وهو بوصفه صاحب الإيداع. يفيد خيارا oneline و format كثيرًا عند استخدامهما مع خيار graph-- الذي يعرض مخطط ASCII لسجل التفرع Branch والدمج Merge. git log --pretty=format:"%h %s" --graph مثال على النتيجة: * 2d3acf9 ignore errors from SIGCHLD on trap * 5e3ee11 Merge branch 'master' of git://github.com/dustin/grit |\ | * 420eac9 Added a method for getting the current branch. * | 30e367c timeout code and tests * | 5a09431 add timeout protection to grit * | e1193f8 support for heads with slashes in them |/ * d6016bc require time for xmlschema * 11d191e Merge branch 'defunkt' into local يفيد خيار graph-- كثيرا عند استخدام التفريع والدمج في مستودعات git. توجد الكثير من الخيارات الأخرى للعمل مع أمر git log. يسرد الجدول التالي قائمة بخيارات تعمل مع git log إضافة لخيارات تهيئة أخرى قد تجدها مفيدة. الخيار الوصف p- إظهار الترقيع المصاحب لكل إيداع stat-- إظهار إحصاءات الملفات المعدّل عليها في كل إيداع shortstat-- قصر النتائج الظاهر من نتيجة stat-- على الأسطر المعدّل عليها، المضافة أو المحذوفة name-only-- عرض قائمة بالملفات المعدّل عليها بعد معلومات الإيداع name-status-- عرض قائمة بالملفات التي أضيفت إليها معلومات، عدلت معلوماتها أو حذفت abbrev-commit-- عرض المحارف الأولى من مجموع التحقق من الإيداع، بدلا من كامل المجموع (40 محرفا) relative-date-- عرض التواريخ بصيغة نسبية ("قبل يومين" مثلا) بدلا من الصيغة الكاملة graph-- عرض مخطّط ASCII لسجل التفريع والدمج بجانب مخرجات أمر log pretty-- عرض الإيداعات بصيغة بديلة، يمكن للخيار أن يأخذ إحدى القيم oneline ،short ،fuller ،full، أو format تحديد مخرجات أمر git log يقبل أمر git log خيارات لتحديد المخرجات الظاهرة في نتيجة الأمر، فلا يُعرَض سوى عدد محدّد منها. رأينا أعلاه خيار 2- الذي يعرض فقط الإيداعين الأخيرين. يمكن استخدام الخيار n- حيث n عدد طبيعي لإظهار العدد الموافق من الإيداعات (آخر 5 أو 10 إيداعات مثلا). عمليا، قد لا تستخدم هذه الخيارات كثيرا؛ عكسَ خيارات التحديد المتعلقة بالزمن مثل since-- أو until-- التي يكثر استخدامها. مثلا يسرد الأمر التالي قائمة بالإيداعات التي أضيفت خلال الأسبوعين الأخيرين: git log --since=2.weeks يمكن استخدام since-- مع الكثير من الصيغ؛ تحديد التاريخ 15-01-2016 مثلا، أو تاريخ نسبي (قبل 3 سنوات ويوم و3 دقائق): 3 years 1 day 3 minutes ago يمكنك أيضا ترشيح المخرجات لتطابق معايير بحث تحدّدها. يسمح خيار author-- بالترشيح حسب كاتب الإيداع، في ما يتيح خيار grep-- البحث حسب كلمات مفتاحية ضمن رسائل الإيداع (إن كنت ترغب باستخدام خياري author-- وgrep-- معا فيجب أن تضيف all-match-- إلى الأمر). يعد خيار S- من الخيارات المفيدة كثيرا، حيث يسمح بالبحث عن الإيداعات التي أضافت أو حذفت سلسلة محارف معيّنة. إن أردت على سبيل المثال البحث عن آخر إيداع أضاف أو حذف دالة باسم function_name فيمكن استخدام الأمر التالي: git log -Sfunction_name توجد أيضا إمكانية قصر نتائج أمر git log على الإيداعات التي أجرت تغييرات على ملفات أو مجلدات معينة بذكر مسار الملفات أو المجلدات. يجب أن تكون المسارات هي آخر عنصر في أمر git log ويُنصح أن تسبقها شرطتان -- لفصلها عن بقية الخيارات. يعرض الجدول التالي أهم الخيارات المستخدمة في تحديد مخرجات الأمر git log. الخيار الوصف n- تحديد عدد الإيداعات المراد عرضها since, --after-- عرض الإيداعات التي أضيفت بعد التاريخ المحدد until, --before-- عرض الإيداعات التي أضيفت قبل التاريخ المحدد author-- عرض الإيداعات التي يوافق حقل الكاتب فيها سلسلة المحارف المعيّنة committer-- عرض الإيداعات التي يوافق حقل صاحب الإيداع فيها سلسلة المحارف المعيّنة grep-- عرض الإيداعات التي تحوي الرسائل المصاحبة لها سلسلة المحارف المذكورة S- عرض الإيداعات التي أضافت أو حذفت سلسلة المحارف المعيَّنة يعرض الأمر التالي الإيداعات التي كتبها gitster في الشفرة المصدرية لـGit والتي لم تُدمَج Merge في شهر أكتوبر 2008: git log --pretty="%h - %s" --author=gitster --since="2008-10-01" \ --before="2008-11-01" --no-merges -- t/ مثال على النتيجة: 5610e3b - Fix testcase failure when extended attributes are in use acd3b9e - Enhance hold_lock_file_for_{update,append}() API f563754 - demonstrate breakage of detached checkout with symbolic link HEAD d1a43f2 - reset --hard/read-tree --reset -u: remove unmerged new paths 51a94af - Fix "checkout --track -b newbranch" on detached HEAD b0ad11e - pull: allow "git pull origin $something:$current_branch" into an unborn branch من بين 40 ألف إيداع في سجل الشفرة المصدرية لـGit أظهر الأمر الإيداعات الستة التي توافق المعايير المذكورة أعلاه. ترجمة -وبتصرّف- للفصل Git Basics - Viewing the Commit History من كتاب Pro Git لصاحبه Scott Chacon.

يتيح Git طريقة سهلة لجعل كتابة الأوامر وتجربة استخدام Git عموما أيسر وأقرب للتعود عليها، وهي الاختصارات Aliases. لا يُكمِل Git تلقائيا الأوامر أثناء كتابتها؛ إن كنت ترغب في ألا تكتب الأوامر كاملة في كل مرة فيمكنك إعداد اختصار لكل أمر باستخدام git config؛ في ما يلي أمثلة على بعض هذه الأوامر: git config --global alias.co checkout git config --global alias.br branch git config --global alias.ci commit git config --global alias.st status يعني تنفيذُ الأوامر أعلاه أنك لن تحتاج لكتابة أمر git commit كاملا من أجل إيداع ملفاتك، بل تكتفي بالاختصار git ci. نفس الشيء ينطبق على git checkout التي أصبح ممكنا إبدالها بـgit co. ستلاحظ أثناء استخدامك لـGit أن أوامر محدّدة تتكرّر أكثر من غيرها؛ لا تتردد في إنشاء اختصارات لها على النحو المذكور أعلاه. يمكن أيضا استخدام الاختصارات لإنشاء أوامر ترى أنها يجب أن تكون موجودة. مثلا؛ لتسهيل نزع ملف من منطقة الإدراج يمكن إنشاء اختصار باسم unstage بدلا من الأمر الكامل -- reset HEAD: git config --global alias.unstage 'reset HEAD --' لدينا الآن تكافؤ في عمل الأمرين التاليين، مع سهولة أكثر في استخدام الأول منهما (الاختصار): git unstage fileA git reset HEAD -- fileA من الشائع بين مستخدمي Git إضافةُ اختصار باسم last لعرض آخر إيداع: git config --global alias.last 'log -1 HEAD' فيصبح عرض آخر إصدار أسهل: git last commit 66938dae3329c7aebe598c2246a8e6af90d04646 Author: Josh Goebel &lt;dreamer3@example.com&gt; Date: Tue Aug 26 19:48:51 2008 +0800 test for current head Signed-off-by: Scott Chacon &lt;schacon@example.com&gt; يبدِل Git الاختصار بالأمر الذي حددته أثناء إنشائها، الأمر بهذه السهولة. قد تودّ تنفيذ أمر خارجي بدلا من واحد من أوامر Git؛ يعرَّف الاختصار في هذه الحالة بوضع علامة تعجّب ! أمامه. يفيد استخدام الاختصارات بهذه الطريقة كثيرا إن كنت تطور أدوات خاصة للتعامل مع مستودعات Git. مثال على إنشاء اختصار لأداة gitk (متصفح مستودعات بواجهة رسومية): git config --global alias.visual '!gitk' ترجمة -بتصرف- للفصل Git Basics - Git Aliases من كتاب Pro Git لصاحبه Scott Chacon.

ما هو Git، ولماذا كل هذا الاهتمام المتزايد به؟ هل أحتاج فعلا إلى استعماله؟ هل سأصبح مُبرمجا من الدرجة الثانية لو لم تكن لدي أدنى فكرة حول ماهية Git؟ كيف لي أن أستعمله لأزيد مردوديتي البرمجية؟ هل سأصبح [ضع أي وصف هنا] لو استعملت Git؟ هذا المقال سيحاول الإجابة على بعض هذه الأسئلة، يُشوقك للبحث عن إجابات لأخرى، أو يدفعك لقراءة المقال إلى آخره لترى إن كانت هناك أية إجابة على السؤال الأخير. فلنبدأ ببساطة وبكلام يفهمه الجميع، … ما هو Git؟ هل هو لغة برمجة؟ – لاهل هو قاعدة بيانات؟ – لاهل هو نظام تشغيل؟ – لا(جميع هذه الأسئلة وردتني شخصيا) إذا ماهو Git؟ وما وظيفته بالتحديد؟ لفهم ماهيته، علينا أولا فهم المشكلة التي أدّت إلى وجوده، فخذ هذا كمثال بسيط، وأسقطه على نفسك لتفهم المشكلة. المشكلةأنت مبرمج أو مطور ويب، تعمل على مشروع ما، سهرت الليالي فرحًا، لقد حققت تقدما وإنجازا في مشروعك، مرّت بضعة أيام أو بضعة أسابيع، فإذ بك تجد نفسك في مشكلة، كتبت شفرة برمجية عاثت في مشروعك فسادًا، وليتك تستطيع الرجوع للوراء، أو وصلت إلى مرحلة أين يشتغل فيها المشروع بشكل جيد، لكنك تخاف أن تُفسد الخطوة التالية عليه، ﻷنك لست متأكدا أن الميزة القادمة التي ستبرمجها في المشروع ستتكامل معه ولن تقلبه رأسا على عقب، حسنا، أنت شخص ذكي (ربما أنت بلال؟)، لن تقع في فخ كهذا! تبدأ بإنشاء مجلد يحوي المشروع في حالته الحالية، وإن كنت حَذِقا زيادة، ستعطي المجلد اسما بتاريخ اليوم وتوقيته، وتعمل على نسخة أخرى منه في مجلد آخر، وهكذا تفعل في كل مرة يتكرر المشكل، وبهذا يسهل عليك الرجوع إلى حالة المشروع السابقة في حال سارت الأمور علي عكس ما كنت تُخطط له مستقبلا. مرّ مزيد من الوقت، كَبُر المشروع، أصبحتَ مرّة تتكاسل عن إنشاء مجلد جديد ﻷنه ليس لديك وقت لهذا، ومرّة تريد الرجوع إلى حالة سابقة للمشروع لاسترجاع جزء من الشفرة البرمجية في الملف الفلاني كانت تعمل بشكل أفضل، دقيقة، متى كان هذا؟ أين وضعت ذاك المجلد؟ ما كل هذه المجلدات الكثيرة! أيّها هي المجلد الذي أحتاجه؟ حسنا لقد وجدته، أين كانت تلك الشفرة البرمجية حينذاك وفي أي ملف؟! ضاعت الدقائق والساعات، وضاع الجهد والسّهر. مرّ مزيد من الوقت، لقد كبُر المشروع أكثر، بل وزادت أهميته ومسؤوليته، انضم إلى مشروعك أشخاص آخرون، أصدقاؤك المبرمجون يتعاونون معك لتطويره، أو زملاؤك في العمل يتشاركون فيه، أنتم فريق رائع وذكي، لقد وجدتم طريقة لتشارك الشفرة البرمجية، تتراسلونها عبر البريد، أو ترفعونها على خادوم شركتكم البعيد، أو تضعونها على خادومكم الخاص بكل تأكيد، أو ربما ترفعونها على إحدى خدمات التخزين مثل Dropbox. مهلا، فُلان أضاف شيئا في المشروع، في نفس الوقت أضفت أنت أيضا شيئا فيه، كيف أدمج نسخته مع النسخة التي لدي؟! مشكلة، لقد كتبنا شفرة في نفس الموضع، لتقوم بنفس العمل، فأي الشفرتين أفضل؟ قد تحرّيت الوضع وتبين أن لكلا الشفرتين مزايا وعيوب، فكيف أدمج مزايا الشفرتين في واحدة؟ في نفس الوقت أرسل زيد وسعيد شفرتيهما، أنت مدير المشروع وعلى مسؤوليتك دمج التغيرات التي يُرسلها الفريق، لقد أرفق زيد رسالة وقال يمكنك أن تبدل الملف الفلاني بالملف الذي أرسلته ولا تخف، وقال أنه أفضل من الملف الذي أرسله سعيد، صدّقت زيدًا وتخطيت سعيدا، وتسرعت في استبدال الملف وأنت سعيد، وإذا بالملف يُفسد عليك كامل المشروع، ولا تملك نسخة منه بالحالة التي كان عليها لا من قريب ولا من بعيد،… زيدٌ ذاك له منّي أشد وعيد! وضاعت دقائق وساعات أخرى. الحللست وحدك في هذا المشكل، فلقد عانى منه المبرمجون قديما، وعملوا على حلّه بتطوير أدوات تتولى أو تسهّل عليهم حفظ التغيرات التي يجرونها عبر الزمن على ملفات الشفرة البرمجية، وتسجيلها (أي التغيّرات) في قاعدة بيانات تحفظ الفروقات بين نُسَخ الشفرة البرمجية عبر الزمن، بحيث يمكن الرجوع إلى نسخة معينة، في مرحلة معينة من الشفرة البرمجية، تماما كما كانت عليه وقت حفظها. ليس هذا وحسب، حيث يمكن للأداة أن تدمج التغيرات التي أجراها أكثر من شخص بعضها ببعض، وتُعلمك بوجود تضاربات بين شفرة فلان وعلان في الملف الفلاني من سطر كذا إلى سطر كذا. بل وتطورت هذه الأدوات أكثر، وأصبحت تتولى مهمة رفع التغيرات التي أجريتها إلى خادوم بعيد (عبر إنشاء ما يُعرف بالمستودع أو Repository على الخادوم)، أو جلب التغيرات التي أجراها الآخرون من خادوم بعيد (من المستودع)، بل وحتى أكثر من خادوم في نفس الوقت، ثم مساعدتك في عرض الفروقات Diffs بين النُّسخ، ودمج أحدث التغيرات في نسخة واحدة. سمّوا هذه الأدوات بعدة مسمّيات تصب كلّها في نفس المعنى، من ذلك: نظام التحكم في النسخ، بالانجليزية: Version Control System أو اختصارًا: VCS، وهذا المُسمّى أشهرهم.نظام التحكم بالمصدر، بالانجليزية: Source Control.نظام التحكم بالمراجعات، بالانجليزية: Revision Control.إدارة الشفرة المصدرية، بالانجليزية: Source Code Management وتختصر إلى: SCM.كلها مسمّيات يُقصد بها الأداة التي تقوم بتسجيل التغيرات التي تحدث عبر الزمن على ملف أو مجموعة ملفات بحيث يمكن الرجوع إلى مرحلة معينة (نسخة، أو إصدار) لاحقًا. ماهي التغيرات التي حصلت، ما هي التعارضات الموجودة بين نسختين لنفس الملف، من قام بكتابة الشفرة الفلانية، ومن سبب مشكلا ما، ومن عمل على حل المشكل الفلاني. وغير ذلك المزيد. من بين تلك الأدوات، نعرض أشهرها عبر الزمن، وهي: rcs وقد كانت من بين أشهر الأدوات. حتى نظام OS X المشهور يحتوي على أمر rcs عند تنصيبك لأدوات المطور، تعمل هذه الأداة أساسا على حفظ مجموع الرُّقع (أي الاختلافات الحاصلة بين الملفات) بين كل عملية تغيير ومثيلتها في هيئة خاصة على القرص الصلب، يمكنها بهذا إعادة إنشاء أي ملف بنفس الهيئة التي كان عليها في نقطة ما من الزمن عن طريق دمج الرقع، لكنها أداة بدائية في حال كان يعمل على المشروع أكثر من شخص.أنظمة التحكم بالنُّسخ المركزية، أو Centralized Version Control Systems وتعرف اختصارا بـ CVCSs، جاءت لتحل المشكل الكبير التالي الذي واجه المستخدمين، وهو حاجتهم إلى التعاون مع مُبرمجين آخرين على أنظمة تشغيل أخرى. تستخدم هذه الأنظمة، مثل كل من CVS، Subversion أو Perforce خادوما واحدا يحتوي كل الملفات التي نقوم بالتحكّم في نُسَخها، إضافة إلى مجموعة من العملاء الذين يقومون باسترجاع الملفات من هذا الخادوم المركزي. ظلت هذه الأنظمة لسنوات عديدة المعيار القياسي لأنظمة التحكم في النّسخ VCS.أنظمة التحكم في النّسخ المُوزعة أو Distributed Version Control Systems و تعرف اختصارًا بـ DVCSs. في مثل هذه الأنظمة كـ Git، Mercurial، Bazaar أو Darcs فإن ما يقوم به المستخدمون ليس مُجرد التحقق من آخر نسخة من الملفات، لكن يقومون أيضا بأخذ نُسَخٍ كاملة عن المستودعات التي يعملون عليها. وعليه، فإن، وفي حال ما إذا تعرّض الخادوم لأي خلل، فإنه يُمكن مواصلة العمل عبر نَسْخ المستودع الموجود على أي من أجهزة المستخدمين بحكم أن أي عملية التحقق التي يقوم بها المستخدم هي عبارة عن عملية نسخ احتياطي لكامل بيانات المشروع.كل هذه تدخل تحت مسمّى VCS. أما Git، فيعتبر نقلة نوعية في عالم VCS بشكل عام، ﻷنه جاء بإدارة التفرعات (branches) المتوازية وإعادة دمجها مع بعض، وهو الأمر الذي كان يُعدّ كابوسا في الأدوات القديمة مثل CVS. وللأمانة، فإن Git ليس أول نظام جاء بهذه الفكرة، بل سبقه إليها bitkeeper لكنه لم يكن برنامجا مجانيا ولا حرّا، وبالتالي فإن Git أوّل نظام حر ومجاني يأتي بإدارة التفرعات المتوازية (mercurial أيضا جاء بها وهو حر مجاني، وقد تم تطويرهما أصلا ليكونا بديلا لـbitkeeper). إذا، إجابة على السؤال الأول، ماهو Git؟ باختصار هو: نظام التحكم في النسخ الموزّع غير المركزي، وهي جملة يُفترض أنه يمكنك فهمها الآن. أسئلة شائعة:هل تعلّم Git صعب؟ وهل يحتاج أن يكون لدي خلفية برمجية؟لا، ليس صعبا، وليس غاية في حد ذاته، فهو فقط أداةٌ وسيلة، تعلمّها يأتي بالتمرّس، فقط بضعة أوامر ستتعود عليها وتصبح بداهة مع مرور الزمن، ولن تحتاج إلى أي خلفية برمجية. عليك البدء في إدخاله في سير عملك، واعلم أنك ستربح الوقت به ولن تضيعه. قلت أوامر؟؟ أنا أخاف من الطرفية، هل له واجهات رسومية؟!نعم، له عدة واجهات رسومية على مختلف أنظمة التشغيل، لكنه من غير المحبذ للمبتدئ أن يبدأ بها، بل من المستحسن أن يصبر مع الطرفية ليفهم آلية عمله جيدا، ثم له أن ينتقل لما يصل لمرحلة متقدمة، ولو أن حتى المتقدمين لا يزالون يفضلون الطرفية. هل يعمل على Linux فقط؟ هل له نسخة Windows؟يعمل على جميع الأنظمة المعروفة، سواء Linux ،Mac أو Windows بل حتى على أنظمة أخرى، ويعمل بنفس الكيفية وبنفس الأوامر، الشي الوحيد الذي يختلف نوعا ما هو طريقة التنصيب. هل يمكن التحكم بنُسخ الملفات غير البرمجية؟ كأنواع الملفات الأخرى؟نعم، يمكن الإستفادة من Git في التحكم بنُسخ الملفات على اختلاف أنواعها، فإن كنت مثلا مصمما، أو كاتبا، أو مهندسا معماريا أو ما شابه، فإنه يمكن إدارة نسخ الملفات التي تعمل عليها بنفس الطريقة. لكن الملفات التنفيذية أو غير النصية يصعب معرفة ما تغير فيها عبر الزمن وعرض الفروقات فيها أو بينها، نظرًا لطبيعتها (binary). هل يجب وجود خادوم بعيد للعمل بـ Git؟لا، بتاتا، يمكن إنشاء المستودعات على حاسوبك، وإبقائه عندك ولن تحتاج ﻷي خادوم بعيد. كيف يُنطق Git؟ينطق چيت، بنفس الجيم التي ينطقون بها في مصر. متصفحك لا يدعم تشغيل ملفات الصوت.من طور Git؟نفسه من بدأ بتطوير نواة Linux، وهو Linus Torvalds. ما معنى كلمة Git؟تعني شخصا غبيا أو لنقل أحمقا، وهي كلمة عامية بريطانية، وهو ما قد يشعر به المرء لما يكتشف أنه ضيع سنوات دون استعماله. آمل أن أكون قد وُفقت في شرح ماهية Git بشكل خاص و VCS بشكل عام. إذا كان لديكم أية أسئلة إضافية أو اقتراحات، فاطرحوها بالتعليقات وسيتم تحديث الموضوع.

وأخيرا اقتنعت بفلسفة المصادر المفتوحة، أو أنك أخيرا وجدت الوقت للمُساهمة في أحدها، وربما ما دفعك إلى الأمر هو استفادتك من مشروع مفتوح المصدر وأردت أن ترد الجميل بالمساهمة فيه بدورك، لكن لا تدري كيف تقوم بذلك؟ الأمر بسيط، كل ما تحتاجه هو جهاز محلي يكون Git مُنصبا عليه، حساب على Github وبعض الوقت، ومن ثم اتباع بضع خُطوات بسيطة. تجدر الإشارة إلى أنك لا تحتاج إلى أن تكون مُبرمجا للمُساهمة في المشاريع مفتوحة المصدر، يُمكنك المُساهمة في إنشاء أو تحسين توثيق المشروع، حيث يُعتبر التوثيق الجيد أحد أهم عوامل نجاح المشاريع مفتوحة المصدر، وانتشار بعضها على حساب الآخر. لنفرض أن المشروع الذي تود المُساهمة فيه هو "git – الدّليل البسيط". 1. قم باستنساخ المشروع إلى حسابك الخاص وذلك بالنقر على زر Fork الموجود في الزاوية العُلوية اليُمنى لصفحة المشروع. هذه العملية من شأنها أن تُنشئ نُسخة مُطابقة للمُستودع الأصلي على حسابك على Github. 2. بعد ذلك قم باستنساخ هذا المُستودع الجديد على جهازك المحلي. ادخل إلى المجلد الذي تود استنساخ المُجلد فيه (cd path/to/folder) وقم بتنفيذ الأمر git clone متبوعا بعُنوان المُستودع. ستجد العُنوان أسفل القائمة اليُمنى في صفحة المُستودع. بالنسبة لي سيكون الأمر على النحو التالي: git clone https://github.com/djug/simple-guide.git 3. الآن وبعد أن حصلت على هذه النُسخة، قم بإدخال التعديلات التي ترغب فيها واحفظ تلك التعديلات. قبل أن نقوم بإيداع تلك التعديلات، يُنصح دائما التحقق من حالة المُستودع، وإن تم أخذ التعديلات بالحسبان أو إن قمنا بتعديل ملف لم نكن نرغب في تعديله، حيث يكفي أن ننفذ الأمر git status لمعرفة حالة المُستودع (النسخة المحلية): git status On branch master Your branch is up-to-date with 'origin/master'. Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git checkout -- <file>..." to discard changes in working directory) modified: index.ar.html4. تبدو الأمور طبيعية. لنقم بإرسال التغييرات إلى منطقة الإدراج: git add .ومن ثم إيداعها (commit): git commit -m "Your commit Message Here"بطبيعة الحال ستحتاج إلى وضع وصف مُناسب للتغييرات التي قمت بها. بإمكانك أيضا تنفيذ الأمر commit لوحده من دون أية رسائل: git commitوسيقوم git بفتح مُحرر النصوص المُفضل لديك لكتابة الوصف (في حال ما إذا قمت بتحديد اسم هذا المُحرر في إعدادات git). سنحتاج الآن إلى إرسال هذه التغييرات إلى المُستودع (الشخصي وليس مُستودع المشروع الذي نشارك فيه) على Github عبر تنفيذ الأمر: git push origin masterسيطلب منك Git اسم المُستخدم الخاص بك على Github وكلمة السر، وبمُجرد أن يتم التحقق منهما سيتم دفع التغييرات إلى مُستودعك الخاص. 5. الآن لو عدنا إلى صفحة المُستودع الشخصي على Github سيظهر لنا تاريخ آخر تحديث للملفات المُعدلة ووصف له. وكل ما نحتاج إلى فعله الآن هو إرسال "طلب سحب" pull request -أي سحب التغيرات- إلى المُستودع الأصلي للمشروع وذلك بالنقر على الزر الأخضر الذي يظهر في الزاوية العُلوية اليُمنى للمُستودع ستظهر لك صفحة لتلخص من جديد التغييرات التي تمت 6. الخطوة الأخيرة هي النقر على زر Create Pull request، إضافة أية تعليقات ترغب فيها على الطلب، ومن ثم النقر على زر Send pull request: ستصل صاحب المشروع رسالة بخصوص التغييرات التي قمت بها، وفي حال قبولها سيصلك إشعار بها وستظهر تغييراتك على المستودع الأصلي: هذا كل ما في الأمر. أنت الآن بطريق… أقصد مُشارك في مشاريع مفتوحة المصدر بشكل رسمي. نصائح عامة لدى المساهمة في المشاريعاجعل نص الإيداع commit معبّرا أو ملخصا للتغيرات التي قمت بها، لا تجعله مبهما أو عاما.افصل طلبات السحب "pull request" حسب الغرض، أو اجعل لكل تغير تقترحه في branch لوحده حسب الغرض، مثال: لا ترسل طلب سحب يحتوي تغيرات مرئية في الـ html و css وفيه أيضا ترجمة النصوص إلى العربية، هكذا تصعب المهمة على من يقوم بعملية الدمج في حال كان يريد قبول الترجمة لكنه غير راض عن التغيرات التي طرأت في الـ html/css. في هذه الحالة سيكون من الأنسب:طلب سحب للتغيرات المرئية لوحده.طلب سحب آخر للملفات الترجمة إلى العربية.في حال كانت مساهمتك تحل علة ما تم التبليغ عنها في قسم الـ issues في مستودع المشروع على github، أو لها علاقة به، فإنه يمكنك الإشارة إلى تلك العلة في نص الإيداع فقط بوضع رقم العلة مسبوقا بعلامة #، مثال:git commit -m "fix for some bug (issue #23)"ستلاحظ عند زيارة واجهة Github أن الرقم 23# في نص الإيداع، قد أصبح رابطا يحول مباشرة إلى صفحة تلك العلة. في حال قمت بعمل Fork وساهمت في المشروع، وأردت مرة أخرى أن تساهم في ذاك المشروع مجددا، فلا تنس أن تجعل مستودعك الشخصي من ذاك المشروع محدّثا، يعني اجلب التغيرات الجديدة التي طرأت على المستودع الأصلي، قبل المساهمة مجددا وعمل أي commit أو pull request، هذا يخفض من نسبة التعارض conflicts، ويسهّل عليك وعلى القائمين على المشروع عمليات الدمج، قد تكون التغيرات التي قمت بها، قد قام بها آخر، أو ربما تم حذف الملف الذي تعمل عليه أصلا من المشروع الأصلي، فيضيع جهدك هباءا منثورا.من المحبذ أيضا، استعمال صيغة الأمر في نص الإيداع، مثال، استعمل "add something to file x" عوض "adding|added something to file x".

إنّ أحد أهم الاعتبارات التي يجب أخذها بالحسبان عند تخزين عملنا وبياناتنا في بيئة رقميّة هو كيفيّة التّأكّد من أنّ المعلومات الخاصّة بنا ستكون متاحة في حال وجود مشكلة، قد يعني هذا أشياء مختلفة بالنظر إلى التطبيقات التي نستخدمها، مدى أهميّة الحصول على فشل فوري ونوعية المشاكل التي نتوقّعها. سنقوم في هذا الدّرس بمناقشة بعض الطرق المختلفة لتوفير النسخ الاحتياطي ووفرة البيانات data redundancy، ولأنّ حالات الاستخدام المختلفة تتطلّب حلولًا مختلفة فلن نكون قادرين على إعطاء إجابة تناسب جميع الحالات، ولكن سنتعلّم ما هو الشيء المهم في حالات مختلفة وما هو التّنفيذ implementation (أو التّنفيذات implementations) الأكثر مُلاءَمة لهذه العمليّة. سنناقش في هذا الدرس الحلول المختلفة التي يُمكننا استخدامها للنسخ الاحتياطي والمزايا النسبيّة لكلّ واحدة منها بحيث نستطيع اختيار الخطّة التي تناسب البيئة التي نعمل عليها. ما الفرق بين وفرة البيانات Redundancy والنسخ الاحتياطي Backing Up؟غالبًا ما نجد تداخل في معظم الحالات بين المصطلحين وفرة البيانات redundant والنسخ الاحتياطي backup، وهما مفهومان مميّزان مرتبطان ببعضهما ولكنّهما مختلفان، وبعض الحلول تُوفِّرهما معًا. 1. وفرة البيانات Redundancyتعني وفرة البيانات وجود تجاوز للفشل failover فوري في حال وجود مشكلة في النّظام، والمقصود من تجاوز الفشل أنّه في حال أصبحت مجموعة من البيانات غير متوفّرة فسيتمّ استبدالها فورًا بنسخة كاملة لتحلّ محلّها، وينتج عن هذا زمن إيقاف تشغيل down time غير مُلاحظ تقريبًا ويستطيع التطبيق أو الموقع مواصلة تخديم الطلبات وكأنّ شيئًا لم يكن، وفي هذه الأثناء يملك مدير النظام الفرصة لإصلاح المشكلة وإعادة النظام إلى الحالة التي يعمل فيها بشكل تام. وبينما يبدو هذا وكأنّه حل رائع لتخديم النسخ الاحتياطي فإنّ هذا في الحقيقة فكرة خاطئة خطيرة، فلا تُزوِّدنا وفرة البيانات بحماية ضدّ الفشل الذي يؤثر على كامل الآلة أو النّظام، على سبيل المثال إن كُنّا نملك mirrored RAID مضبوط (مثل RAID1) فستكون بياناتنا متوافرة فيه وفي حال فشل أحد الأقراص سيبقى الآخر متوافرًا، ولكن إن فشلت الآلة نفسها فقد نفقد جميع البيانات الخاصّة بنا. ومن مساوئ هذا النوع من الإعداد أنّ كل عمليّة يتمّ تنفيذها على كل نسخة من البيانات، ويتضمّن هذا العمليّات الخبيثة malicious أو التي تمّت بغير قصد، يُمكّننا حل النّسخ الاحتياطي الصحيح الاستعادة من نقطة سابقة حيث كانت البيانات معروفة بكونها بحالة جيّدة. 2. النسخ الاحتياطي Backupكما أشرنا سابقًا فإنّه من المُحتّم علينا الحفاظ على نُسَخ احتياطيّة تعمل بشكل جيّد لبياناتنا الهامّة، واعتمادًا على الموقف فقد يعني هذا النسخ الاحتياطي للتطبيق أو لمعلومات المستخدمين أو حتى لكامل الموقع أو الآلة، والفكرة من وراء النُسَخ الاحتياطيّة أنّه في حال حدوث فقدان في النّظام أو الآلة أو البيانات فإنّنا نستطيع استعادة restore، إعادة نشر redeploy، أو الوصول إلى بياناتنا، قد تتطلّب الاستعادة من نسخة احتياطيّة زمن إيقاف تشغيل، ولكن يوجد فرق بين البدء من نقطة في اليوم السابق والبدء من الصفر، أي شيء لا نستطيع تحمل خسارته -بالتعريف- يجب علينا عمل نسخة احتياطية له. ومن حيث الأساليب يوجد عدد قليل من المستويات المختلفة للنُسَخ الاحتياطيّة يُمكن تصنيفها إلى عدّة طبقات بحسب الحاجة إلى حساب أنواع مختلفة من المشاكل، على سبيل المثال ربّما نقوم بالنسخ الاحتياطي لملف الإعدادات configuration file قبل تعديله وذلك لكي نستطيع العودة بسهولة إلى الإعدادات القديمة قبل أن تنشأ المشكلة، يكون هذا مثالي للتغيرات الصغيرة التي نستطيع مراقبتها بشكل فعال، ولكن هذا الإعداد سيفشل على نحو بائس في حال فشل القرص أو أي شيء أكثر تعقيدًا، ينبغي علينا أيضًا الحصول على نُسَخ احتياطيّة بشكل منتظم وتلقائي إلى موقع بعيد remote location. النُّسَخ الاحتياطيّة بحد ذاتها لا تزوّدنا بتجاوز الفشل تلقائيًا، وهذا يعني أنّ الفشل لن يُكلّفنا خسارة أيّة معلومات (على اعتبار أنّ النُسَخ الاحتياطيّة التي نملكها حديثة 100%)، ولكن قد يُكلفنا زمن تشغيل Uptime، وهذا هو أحد الأسباب التي تجعلنا نستخدم وفرة البيانات والنَسخ الاحتياطي جنبًا إلى جنب بدلًا من أن تُلغي كلّ واحدة منهما الأخرى. النسخ الاحتياطي على مستوى الملف File-Level Backupإنّ النَسخ الاحتياطي على مستوى الملف هو واحد من أشيع أشكال النَسخ الاحتياطي، يستخدم هذا النّوع من النَّسخ الاحتياطي أدوات النسخ الاعتياديّة الموجودة مع النّظام لنقل الملفات إلى موقع أو جهاز آخر. 1. كيفية استخدام الأمر cpأبسط أشكال النَّسخ الاحتياطي لآلة تعمل بنظام لينِكس مثل الـ VPS هي عن طريق الأمر cp، ينسخ هذا الأمر ببساطة الملفات من موقع محلّي local إلى موقع آخر، ونستطيع على حاسوب محلّي وصْل mount قُرص قابل للإزالة وبعدها نسخ الملفات إليه: mount /dev/sdc /mnt/my-backup cp -a /etc/* /mnt/my-backup umount /dev/sdcيقوم هذا المثال بوصْل قرص قابل للإزالة ومن ثُمّ ينسخ الدّليل etc/ إلى القرص، وبعدها يقوم بإلغاء وصْل unmount القرص، والذي يُمكننا تخزينه في مكان آخر. 2. كيفية استخدام الأمر Rsyncإنّ الأمر rsync هو بديل أفضل للأمر cp، حيث يُمكّننا من إجراء نُسَخ احتياطيّة محليّة مع قَدْر أكبر من المرونة، نستطيع تنفيذ نفس العمليّات السابقة باستخدام rsync عن طريق الأوامر التالية: mount /dev/sdc /mnt/my-backup rsync -azvP /etc/* /mnt/my-backup umount /dev/sdcوفي حين أنّ هذا يبدو بسيطًا حتى هذه النقطة، إلّا أنّنا سندرك بسرعة أنّ النَّسخ الاحتياطي على نظام ملفّات محلّي مرهق ومُعقّد، حيث يجب علينا فيزيائيًا وصْل وفصْل قرص النَسخ الاحتياطي ونقله إلى مكان آخر إن أردنا الحفاظ على المعلومات في حال حدوث سرقة أو حريق، نستطيع تحقيق الكثير من نفس المزايا باستخدام النَسخ الاحتياطي عبر الشبكة. يستطيع الأمر Rsync تنفيذ نُسخ احتياطيّة عن بُعد remote بنفس السهولة التي يستطيع القيام بها بنُسخ احتياطيّة محليّة، يجب علينا فقط استخدام صيغة بديلة، سيعمل هذا الأمر على أي مُضيف host نستطيع الدخول إليه عن طريق SSH طالما أنّ rsync مُثبّت لدى الطرفين: rsync -azvP /etc/* username@remote_host:/backup/سيقوم هذا الأمر بالنسخ الاحتياطي للدليل etc/ الموجود على الجّهاز المحلّي إلى دليل على remote_host موجود في backup/. سينجح هذا الأمر إن كُنّا نملك صلاحيات للكتابة على هذا الدّليل وتوجد مساحة كافية. للمزيد من المعلومات حول كيفيّة استخدام rsync للنّسخ الاحتياطي اضغط هنا. 3. كيفية استخدام أدوات أخرى للنسخ الاحتياطيبالرغم من بساطة الأمرين cp و rsync وإمكانيّة استخدامهما بسهولة إلّا أنّهما ليسا دومًا الحل المثالي، لجعل النُسخ الاحتياطية مُؤتمتة نحتاج لوضع هاتين الأداتين ضمن Script وكتابة أي شيفرة ضرورية من أجل الدوران والجماليّات الأخرى. لحسن الحظ توجد بعض الأدوات المساعدة التي تقوم بتنفيذ إجراءات مُعقّدة أكثر للنسخ الاحتياطي ببساطة. Baculaإنّ أداة Bacula هي حل مُركّب ومرن يُعزّز نموذج خادوم عميل للنسخ الاحتياطي للمضيفين hosts، تفصل Bacula بين أفكار العملاء، أماكن النسخ الاحتياطي والإدارة directors (المُكوِّن الذي يُنسّق النسخ الاحتياطي الفعلي)، وتقوم أيضًا بضبط كل مهمّة نسخ احتياطي ضمن وحدة تدعى الوظيفة job. يسمح لنا هذا بتضبيط configuration مُحبّب ومرن بشدّة، نستطيع النسخ الاحتياطي للعديد من العملاء إلى جهاز تخزين وحيد، عميل واحد إلى عدّة أجهزة تخزين، وتعديل مُخطط النسخ الاحتياطي بسرعة وسهولة عن طريق إضافة عُقَد أو ضبط تفاصيلهم، تعمل هذه الأداة بشكل جيّد عبر بيئة تحتوي على شبكة، وهي قابلة للتوسيع وتقسيمها إلى وحدات، مما يجعلها رائعة للنسخ الاحتياطي لموقع أو تطبيق مُوزَّع عبر عدّة أجهزة. لكي تتعلّم المزيد حول كيفيّة تضبيط خادوم Bacula للنسخ الاحتياطي وكيفيّة النسخ الاحتياطي للأنظمة عن بعد باستخدام Bacula، قم بزيارة هذه الروابط. BackupPCمن الحلول الشائعة الأخرى هي أداة BackupPC، يُمكن استخدام هذه الأداة للنسخ الاحتياطي لأنظمة لينِكس وويندوز بسهولة، يتم تنصيبها على جهاز أو VPS والذي سيعمل كخادوم للنسخ الاحتياطي، وبعدها يسحب الخادوم البيانات من عملائه باستخدام طرق نقل الملفّات المُعتادة. يُقدّم هذا الإعداد ميزة تنصيب جميع الحِزَم packages المتعلّقة بذلك على جهاز مركزي واحد، والتضبيط الوحيد الذي نحتاجه هو السماح لخادوم النسخ الاحتياطي بالوصول عبر SSH، يُمكن بسهولة إعداد هذا، وباستخدام DigitalOcean نستطيع تضمين مفاتيح SSH لخادوم BackupPC إلى العملاء بينما نقوم بالنشر، يسمح لنا هذا بضبط النسخ الاحتياطيّة من خادوم النسخ الاحتياطي بسهولة ونشر بيئات الإنتاج الخاصّة بنا بشكل نظيف بدون أيّة برمجيّات إضافيّة. لكي تتعلّم كيفيّة تثبيت واستخدام BackupPC على خادوم، اضغط هنا. DuplicityDuplicity هي بديل رائع للأدوات التقليديّة، الميّزة الأساسيّة للتفاضل في Duplicity هي أنها تستخدم تعمية GPG encryption لنقل وتخزين البيانات، ولهذا بعض الفوائد الرائعة. إنّ الفائدة الواضحة من استخدام تشفير GPG للنسخ الاحتياطي للملفّات هي أنّه لا يتم تخزين البيانات بشكل نص مُجرَّد plain text. الشّخص الوحيد الذي يستطيع فكّ تعمية decrypt البيانات هو من يملك مفتاح GPG key، يُوفِّر هذا درجة من الحماية لتعويض تضخّم التدابير الأمنية اللازمة عندما يتم تخزين البيانات في مواقع مُتعدّدة. الفائدة الأخرى التي قد لا تكون واضحة بشكل فوري للأشخاص الذين لا يستخدمون GPG عادةً هي أنّه يتمّ التّحقّق من كل عمليّة نقل لتكون دقيقة تمامًا، تفرض GPG فحص تلبيد Hash صارم للتأكّد من عدم وجود ضياع في البيانات أثناء النقل، ويعني هذا أنّه عندما يحين الوقت لاستعادة البيانات من النُسخة الاحتياطيّة سنكون أقل عُرضة للوقوع في مشاكل تَلَف الملفات. لكي تتعلّم كيفيّة تمكين النُسخ المُشفّرة باستخدام GPG في Duplicity، اتبع هذا الرابط. النسخ الاحتياطي على مستوى الكتلة Block-Level Backupsإنّ النسخ الاحتياطي على مستوى الكُتلة هو أقل شيوعًا من النسخ الاحتياطي على مستوى الملف ولكنّه بديل هام له، يُعرف أيضًا هذا النمط من النسخ الاحتياطي بالتصوير imaging لأنّه من المُمكن استخدامه لاستنساخ duplicate واستعادة كامل الأجهزة. يسمح النسخ الاحتياطي على مستوى الكُتلة بالنسخ على مستوى أعمق من الملف، فبينما يقوم النسخ الاحتياطي على مستوى الملف بنسخ الملف1، الملف2، والملف3 إلى موقع نسخ احتياطي، يقوم النسخ الاحتياطي على مستوى الكُتلة بنسخ كامل الكُتلة Block التي تحتوي على هذه الملفات، ولتفسير المفهوم بطريقة أخرى يمُكننا القول أنّ النسخ الاحتياطي على مستوى الكتلة ينسخ المعلومات بِت bit تلو الآخر، فهو لا يهتم بالملفات المُجرّدة التي قد تُمثّلها هذه البتّات bits (ولكن سيتم نقل الملفّات بشكل كامل خلال هذه العمليّة). إنّ إحدى الفوائد من النسخ الاحتياطي على مستوى الكتلة أنّه عادة ما يكون أسرع، وبينما يقوم النسخ الاحتياطي على مستوى الملف بالبدء بعمليّة نقل جديدة لكل ملف مُنفصل، يقوم النسخ الاحتياطي على مستوى الكُتلة بنقل الكُتَل والتي عادةً ما تكون أكبر حجمًا، وهذا يعني الحاجة للبدء بعمليّات نقل أقل لإتمام النسخ. استخدام الأداة dd لتنفيذ عمليات النسخ الاحتياطي على مستوى الكتلةإنّ أبسط طريقة لتنفيذ عمليّات النسخ الاحتياطي على مستوى الكُتلة هي باستخدام الأداة dd، هذه البرمجيّة مرنة جدًا وتتيح لنا نسخ المعلومات بِت تلو الآخر إلى مكان جديد، ويعني هذا أنّنا نستطيع النسخ الاحتياطي لقسم partition أو قرص disk إلى ملف واحد أو إلى جهاز raw device بدون أي خطوات تمهيدية. أبسط طريقة للنسخ الاحتياطي لقسم أو قرص هي استخدام dd كما يلي: dd if=/path/of/original/device of=/path/to/place/backupفي هذه الحالة تُحدّد =if جهاز الدخل input أو موقع، تُشير =of إلى ملف الخرج output أو موقع، من الهام جدًا تذكّر هذا الفرق، لأنّه من البديهي مسح قرص كامل إن تمّ عكسهما. إن كُنّا نرغب بالنسخ الاحتياطي لقسم يحتوي على مُستنداتنا الموجودة في dev/sda3/ نستطيع إنشاء ملف صورة كما يلي: dd if=/dev/sda3 of=~/documents.imgتُوجد العديد من الحلول الأخرى للنسخ الاحتياطي على مستوى الكتلة متوفّرة على أجهزة لينِكس، ولكنّنا لن نناقشهم هنا. إصدارات النسخ الاحتياطيةإنّ أحد أهم الأسباب الرئيسيّة للنسخ الاحتياطي للبيانات هو القدرة على استعادة إصدار سابق من ملف أو مجموعة ملفّات في حال حدوث تغيير غير مرغوب أو حذف، وبينما تُزوّدنا جميع آليات النسخ الاحتياطي المذكورة حتى الآن بهذا إلى حدّ ما، نستطيع تنفيذ نظام أكثر قوّة باستخدام أدوات إضافيّة. الطريقة اليدويّة لإنجاز هذا هي إنشاء ملف نسخة احتياطية قبل التعديل كما يلي: cp file1 file1.bak nano file1نستطيع أيضًا أتمتة هذه العمليّة عن طريق إنشاء ملفّات مخفيّة ذات ختم زمني timestamped في كل مرّة نقوم فيها بتعديل ملف عن طريق المُحرّر، على سبيل المثال نستطيع وضع ما يلي في ملف bashrc./~ : nano() { cp $1 .${1}.`date +%y-%m-%d_%H.%M.%S`.bak; /usr/bin/nano $1; }عندما نستدعي الآن الأمر nano سيقوم تلقائيًا بإنشاء نُسَخ احتياطيّة. يُوفّر لنا هذا مستوى مُعيَّن من النسخ الاحتياطي، ولكنّها طريقة هشّة جدًّا وقد تملأ القرص بسرعة إن كُنّا نُعدِّل الملفّات كثيرًا، لذلك هي ليست حلًّا رائعًا وربما ينتهي بنا الأمر أسوأ من القيام بالنسخ اليدوي للملفات التي نريد تحريرها. ومن البدائل التي تقوم بحل العديد من المشاكل المُتأصّلة في هذا التصميم هو استخدام git، والتي هي تحديدًا نظام تحكّم بالإصدار، وبالرغم أنّ هذا قد يكون غير واضح نستطيع استخدام git للتحكّم بأي ملف تقريبًا. نستطيع إنشاء مستودع git repository في الدليل الرئيسي فورًا، ببساطة عن طريق كتابة ما يلي: cd ~ git initربّما نحتاج هنا إلى تطويع tweak الإعدادات لاستثناء بعض الملفات، ولكن بشكل عام يقوم بإنشاء إصدارات بشكل فوري، بإمكاننا بعدها إضافة محتويات الدليل الخاص بنا وتضمين الملفّات عن طريق ما يلي: git add . git commit -m "Initializing home directory"نستطيع ببساطة الانتقال إلى موقع بعيد remote location نظام git المُضمَّن أيضًا: git remote add backup_server git://backup_server/path/to/project git push backup_server masterإنّ هذا النظام ليس رائعًا للنسخ الاحتياطي من تلقاء نفسه، ولكن بجمعه مع نظام نسخ احتياطي آخر يتمكّن هذا النمط من التحكّم بالإصدار من تزويدنا بتحكّم جيّد ومُحبّب بشدّة بالتغيرات التي نقوم بها. للتعلّم أكثر حول كيفيّة استخدام git وكيف نستطيع استخدام git لإصدار الملفّات العاديّة، تحقّق من هذه الروابط. النسخ الاحتياطي على مستوى VPS، ومزود DigitalOcean كنموذجفي حين أنّه من المهم إدارة النُسخ الاحتياطيّة بأنفسنا، تُزوّدنا خدمة DigitalOcean مثلا ببعض الآليات لإكمال النسخ الاحتياطيّة الخاصّة بنا. نمتلك دالّة للنسخ الاحتياطي تقوم بانتظام بعمل نُسَخ احتياطيّة تلقائيّة من أجل droplets (مصطلح مقابل لـ VPS على DigitalOcean) التي تُمكّن هذه الخدمة، نستطيع تشغيلها خلال إنشاء droplet عن طريق اختيار صندوق التأشير "تمكين النُسَخ الاحتياطيّة" "Enable Backups": سيقوم هذا بأخذ نُسخة احتياطيّة لكامل صورة الـ VPS، وهذا يعني أنّنا نستطيع بسهولة إعادة النشر من النُسخة الاحتياطيّة أو استخدامها كأساس للـ droplets الجديدة. ولأخذ صورة لمرّة واحدة عن النظام لدينا نستطيع إنشاء لقطات snapshots، والتي تعمل بصورة مشابهة للنُسَخ الاحتياطيّة ولكنّها غير مؤتمتة، نستطيع إنشاءَها عن طريق الذهاب إلى droplet لدينا واختيار "Snapshots" من القائمة العلويّة: ترجمة -وبتصرّف- للمقال How To Choose an Effective Backup Strategy for your VPS لصاحبه Justin Ellingwood. حقوق الصورة البارزة: Designed by Freepik.

واحدة من الإمكانيات الأساسيّة التي يجب أن تتمتّع بها معظم خوادم الإنترنت؛ القدرة على استقبال وإرسال المعلومات إلى الأجهزة الأخرى المُتصلة بالشبكة، فعلى الرغم من أن الناس تنظر عمومًا إلى الخوادم باعتبارها منصات تزويد بالمحتوى، إلا أنها يجب أن تملك القدرة على استقبال المحتوى لأسبابٍ عديدة. وفي حين أنّ معظم حزم البرامج في غنو لينكس متوفرة ضمن المستودعات الرسمية لكل توزيعة ويمكن تحميلها وتركيبها باستخدام أدوات مدراء الحزم المعروفة، إلا أنّ باقي أنواع الملفات والمعلومات تستخدم آليات مختلفة. نناقش في درسنا هذا بعضًا من الطرق الشائعة لتحميل الملفات والمعلومات إلى خادوم لينكس الخاص بك. سوف نستخدم بشكل رئيسي خادوم يعمل بنظام Ubuntu 14.04 لتطبيق الأمثلة الواردة هنا، إلا أنه يمكنك المتابعة معنا بالتأكيد بغض النظر عن إصدار ونوع توزيعتك. الحصول على البيانات والتطبيقات من المستودعاتقد يكون استخدام المستودعات الرسميّة لجلب الحزم والتطبيقات إلى خادومك أكثر الطرق شيوعًا. تُشير المستودعات في سياقنا هنا إلى عدّة أشياء مختلفة، فقد تُعبّر مثلًا عن المجموعات الكبيرة من التطبيقات المتوفرة بصيغة مُترجمة compiled جاهزة للتثبيت، والتي تمّ اختبارها وضبطها بحيث تناسب التوزيعة التي تستخدمها. إضافةً لذلك لدينا المستودعات المصدرية، والتي تحتوي على كافة الملفات الضروريّة لبناء تطبيق ما انطلاقًا من المصدر. وسنتناول كلا النوعين من المستودعات فيما يلي. تركيب البرامج من المستودعات العاديّة لتوزيعتكالطريقة القياسيّة لتركيب البرامج في بيئة غنو لينكس هي استخدام مدير الحزم، والمُعدّ مسبقًا للاتصال مع مجموعة من الخوادم المُجهزّة بمستودعات تضم آلاف الحزم التي تمّ فحصها، تحزيمها، واختبار توافقها مع النظام. تستخدم توزيعات غنو لينكس أنواعًا مختلفة من صيغ التحزيم ومدراء الحزم لإنجاز ذلك. وتعتبر صيغة التحزيم deb. الأكثر شهرةً، وهي الصيغة المُستخدمة في توزيعة دبيان و Ubuntu وعدد آخر من مشتقاتهما، ولدينا أيضًا صيغة التحزيم rpm. والتي تُستخدم عادةً في توزيعة RedHat والتوزيعات المبنية عليها مثل CentOS و Fedora، أخيرًا هناك بعض التوزيعات التي تستخدم نظامًا ثالثًا أبسط مما سبق وهو صيغة التحزيم tar.xz. كتوزيعة Arch Linux. وفي العموم، فإن التوزيعات التي تستخدم التحزيم ذو اللاحقة deb. تعتمد على مدير الحزم apt، بينما تعتمد التوزيعات التي تستخدم تحزيم rpm. على مدير الحزم yam أو إصداره المُحدّث dnf. وباعتبار أن Arch Linux تُحزّم البرامج بصيغة ثالثة، فإنها تملك كذلك مدير حزمها الخاص والذي يدعى pacman لإدارة عمليات التثبيت والحذف وما إلى هنالك، يمكنك قراءة المزيد عن كيفيّة استخدام pacman من خلال صفحة الويكي الخاصّة به في موسوعة Arch. كيفيّة استخدام أرشيف الحزم الشخصيّ PPAواحدة من الطرق الإضافيّة للحصول على البرامج والتطبيقات في الأجهزة العاملة بنظام Ubuntu هي استخدام أراشيف الحزم الشخصية أو ما يعرف بـ PPA، والتي تُكسب توزيعة Ubuntu مرونة جيّدة. تشير الـ PPA بشكل أساسيّ إلى مستودع على الإنترنت، عادةً ما يشمل واحدة أو عددًا قليلًا من الحزم، و يدار بواسطة شخص أو فريق عمل مستقل عن قنوات Ubuntu الرسميّة، مما يزوّد المستخدمين بمصادر إضافيّة لمدير الحزم، بحيث تصبح التطبيقات المخزّنة ضمن هذه المستودعات متاحة للتركيب بشكل سلس إلى جانب الحزم الأخرى. تتمتع أراشيف الحزم الشخصيّة بعددٍ من المميزات إذ تُمكّنك من الحصول على أحدث نسخ التطبيقات بين إصدارات Ubuntu الرسميّة كلّ ستّة أشهر، حيث عادةً ما يترك فريق Ubuntu مهمة تحديث نسخ البرامج الجديدة حتى موعد الإصدار القادم من التوزيعة، إضافةً إلى إتاحة الوصول لمجموعة أوسع من التطبيقات التي لا يقوم فريق Ubuntu الرسمي بتحزيمها أصلًا، فيما لو توفر فريق من المتطوعين الذين يتخذون على عاتقهم مهمة توفير هذه الحزم. والميزة الأهم عن البناء من المصدر هي أن هذه الحزم تُدار بواسطة أدوات مدير الحزم التقليدي، وهذا يشمل إمكانية استقبالها للتحديثات بشكل دوري ودمجها مع نظام التحزيم العام، الأمر الذي يسهّل عليك عددًا من المهام كحل مشاكل الاعتماديات. وفي المقابل هناك بعض المساوئ التي تعتري هذا الأسلوب بطبيعة الحال، أحدها أنك ستضع الكثير من الثقة في مشرفي ومطوري مستودعات PPA. فبينما هناك أسباب وجيهة لمنح منتجي Ubuntu هذه الثقة، فإنه يتوجب عليك أن تسائل نفسك فيما إذا كانت مستودعات PPA تُقدَّم من قِبل جهة جديرة بالثقة. فحتى لو لم يملك المطورون أغراضًا خبيثة، فقد لا يدركون بالشكل المثالي المحاذير الأمنيّة مما قد يُسبّب مخاطر جديّة عن غير قصد. أمرٌ آخر يجب أن تحتفظ به في ذهنك، ألا وهو فترة حياة مستودعات PPA، إذ عليك أن تملك خطّة عمل فيما لو توقّف الدعم فجأةً عن هذه المستودعات من قبل المصدر، ثم هل تملك الوقت لمراقبة الحالات التي تُقرّر فيها توزيعتك أخيرًا إضافة الدعم رسميًا لهذه الحزم من خلال المستودعات الافتراضية؟ قبل أن نتابع، قد يتوجب عليك تركيب الحزمة التالية في Ubuntu لتسهيل إدارة مستودعات PPA، والتي يختلف اسمها تبعًا للإصدار الذي تستخدمه، إلا أنه يجب أن تكون قادرًا على استخدام أحد هذين الخيارين: sudo apt-get update sudo apt-get install python-software-properties # For Ubuntu 12.04 and lower sudo apt-get install software-properties-common # For Ubuntu versions > 12.04 بعد ذلك يمكنك إضافة مستودعات PPA بواسطة الصيغة العامة التالية: sudo add-apt-repository ppa:PPA_name ولتفعيل المستودع الجديد ينبغي تحديث فهرس الحزم للحصول على المعلومات الجديدة من PPA المُضاف، وأخيرًا يمكنك تركيب البرنامج الجديد الذي يُقدّمه المستودع كالعادة: sudo apt-get update sudo apt-get install new_packageمستودعات Gitتُعتبر Git نوعًا آخر من المستودعات والتي يُرجّح أنك سمعت بها من قبل، في الأصل فإن Git هو برنامج مُوزّع وغير مركزي لإدارة إصدارات البرامج وتسهيل المشاركة في تطويرها وإدارة نُسخها، فإذا كان البرنامج الذي تبحث عنه مُستضافًا على مستودع git أو بواسطة إحدى خدمات الوِب لاستضافة البرمجيات باستخدام git مثل GitHub، Bitbucket، private GitLab، فيمكنك حينها تنزيل نسخة من الملفات بسهولة عن طريق الأمر git. في البداية دعنا نتأكد من وجود الأداة git مُثبّتة على نظام التشغيل: sudo apt-get update sudo apt-get install git بعد ذلك يمكنك إنشاء مجلّد جديد والانتقال إليه لتحفظ المشروع وتستنسخ مستودعه باستخدام المعلومات التي يقدّمها موقع الاستضافة. فعلى سبيل المثال للحصول على رابط URL لمستودع مشروع في موقع GitHub انظر إلى الجانب الأيمن: يمكنك الآن نسخ عنوان الرابط URL وتمريره بعد ذلك إلى الطرفية باستخدام الأمر: git clone https://github.com/user/project.git ينسخ الأمر السابق المشروع بالكامل إلى الدليل النشط في الطرفيّة. موارد الويب العامّةفي حين أن استخدام المستودعات لإدارة البرامج أمرٌ سهل، ويوفّر طريقة رائعة لتتبّع الترقيعات والإصدارات الجديدة، إلا أنها قد لا تكون الطريقة المتاحة دومًا لأسباب عديدة؛ من ذلك أن عددًا آخر من التطبيقات غير موجودة لا يتوفر ضمن مستودعات، كما أنك قد تحتاج إلى أنواع أخرى من البيانات (غير حزم البرمجيات) على الخادوم الخاص بك. ولهذه الحالات نحن نحتاج إلى مجموعة أخرى من الأدوات التي يمكن أن تساعدنا. سنناقش فيما يلي عددًا من الطرق متفاوتة التعقيد، لهذا الغرض. تحميل ونقل البيانات عن بُعدقد تكون الطريقة الأكثر بداهةً لتحميل البيانات إلى الخادوم الخاص بك هي تنزيل هذه البيانات إلى حاسوبك المنزلي أولًا ومن ثم إعادة رفعها إلى الموقع. وعلى الأرجح أنك استخدمت هذه الطريقة بالفعل لرفع بعض المحتوى إلى موقعك، فرغم أنها قد لا تكون الأكثر أناقة إلا أنها سهلة بالتأكيد. أي نوع من المحتوى، كالملفات والحزم، والتي ترغب بتضمينها في موقعك، يمكن تنزيلها إلى حاسوبك باستخدام متصفحات الوبِ التقليديّة. تأكد عند تحميلك تطبيق ما من حصولك على الإصدار الصحيح المطابق للتوزيعة المُثبتة على خادومك، بما في ذلك نوع الحزمة، إصدارها، ومعماريتها (في حال كان المصدر يتيح ذلك). بعد ذلك، يمكنك نقل هذه الملفات بسهولة إلى خادومك، الطريقة التي أنصح باتباعها هي الاتصال عبر sftp، والتي ستؤّمن لك اتصالًا آمنًا ويسيرًا لنقل الملفات، يمكنك قراءة درسنا عن استخدام sftp من سطر الأوامر. الطريقة الأخرى هي استخدام عميل FTP مع إمكانية sftp، والتي شرحناها في درسنا هنا عن استخدام تطبيق FileZilla مع sftp. هذه غالبًا الطرق الأكثر مرونةً لتزويد خادومك بالمحتوى، حيث تتيح لك نقل الملفات الجديدة التي أنشأتها إضافةً إلى تلك الموجودة على الوِب. تصفح الوب من خلال الطرفيّةهناك طريقة أخرى أجدها ممتعة لتزويد موقعك بالمحتوى وهي استخدام متصفح الإنترنت ضمن الخادوم. وعلى الرغم من أنه يمكنك تثبيت واجهة رسومية على الخادوم الخاص بك ومن ثم استخدام أحد المتصفحات التقليدية إلا أنني أعتبر ذلك نوعًا من المبالغة المُسرفة غير الضرورية، طالما هناك بديل آخر، ألا وهو استخدام المتصفحات المُخصّصة للاستعمال ضمن الطرفيّة نفسها والتي تسمح لك بزيارة المواقع واستعراض محتواها النصيّ. لنستعرض الآن بعضًا من الخيارات المتوفرة لمتصفحات الوِب من خلال الطرفية. lynxيعتبر lynx أقدم متصفح وِب لا يزال تطويره واستخدامها نشطًا، كما أنه سهل الاستخدام، بشكل أساسي يتمّ التصفح باستخدام السهمين العلوي والسفلي للتنقل بين روابط الصفحة، وللضغط على رابط ما يتم تحديده بدايةً ثم الضغط على مفتاح الإدخال Enter أو السهم اليمني. قد لا يكون lynx متاحًا بشكل افتراضي على نظام التشغيل لديك، إلا أنه يمكنك تثبيته بسهولة من مدير الحزم: sudo apt-get update sudo apt-get install lynx يدعم متصفح lynx كلًا من ملفات تعريف الارتباط cookie والعلامات المرجعيّة bookmarks، كما يمكنه تلوين خرجه فيما لو دعمت الطرفية التي تستخدمها ذلك، وفي العموم يمكنك استخدامه لزيارة أي نوع من المواقع باستثناء تلك التي تعتمد على إضافات خارجية (كجافاسكربت أو فلاش) لتوفير وظائفها. هنا على سبيل المثال استعرضنا موقع أكاديمية حسوب باستخدام المتصفح lynx ضمن طرفية mlterm: linksيقدّم links أداةً أخرى رائعة لتصفح الوِب من خلال الطرفيّة، ويتميز عن سابقه بأنه يحتوي على شريط قوائم علوي مماثلًا للمتصفحات التقليديّة (يمكن تفعيل شريط القوائم بالضغط على زر ESC). لتثبيت links في حال لم يكن مُثبتا بالفعل؛ استخدم مدير الحزم كالعادة: sudo apt-get update sudo apt-get install links وفي حين أنه لا يدعم تلوين النصّ بشكل افتراضي، مما قد يجعل من الصعب إلى حدٍ ما التمييز بين النصوص الصرفة وعناوين الروابط، إلا أنه يستفيد من ميزات مكتبة ncurses البرمجيّة لتقديم واجهة مرتبة بشكل جيّد، حيث أن استعراض موقع رسومي من خلال متصفحٍ نصيّ سيسبب دومًا مشاكل في التنسيق، links يتولى المهمة على نحوٍ جيّد. ميزة أخرى مهمة قد تجعلك تُقرّر استخدام links وهو دعمه لاستخدام الفأرة، وهذا يعني إمكانية الدخول إلى الروابط واستعراضها عن طريق النقر على عناوينها باستخدام المؤشّر كما لو كنت تتعامل مع متصفحك التقليدي. elinksفي عام 2001 اشتق elinks من متصفح links وأضيفت إليه ميزة دعم الامتدادات extended مع الاستفادة من قوّة وآليات عمل البرنامج الأب. للحصول على elinks في Ubuntu عن طريق مدير الحزم apt نكتب: sudo apt-get update sudo apt-get install elinks يتفوقelinks على links بعددٍ من الميزات، كقدرته على التعامل مع كلمات المرور وإدارة النماذج forms، تعدّد الألسنة، ودعم الجافاسكربت جزئيًا، بالإضافة إلى دعم بروتوكولي التورنت وIPv6، ورغم أن هذه الميزات قد تأتي على حساب السرعة، إلا أنه فرق بسيط للغاية. w3mw3m متصفحٌ نصيٌّ آخر يمكن اعتباره الأسهل في الاستخدام وبشكلٍ مشابه للتعامل مع المتصفح الرسومي، كما يأتي مع العديد من الميزات الأخرى، فعلى سبيل المثال تسمح لك معظم المتصفحات النصيّة بالتنقل بين الروابط، لكن التنقل خلال الصفحة نفسها قد لا يكون متاحًا بسهولة، w3m يسهّل هذه العملية عن طريق استخدام TABs للتنقل بين الروابط واستخدام مفاتيح الأسهم لتحريك المؤشر بشكل مستقل لتمرير الصفحة. عادةً ما يأتي w3m مُثبت بشكل افتراضي مع العديد من الأنظمة، أما إذا لم يكن مضمنًا في خادومك فيمكنك إضافته عن طريق تنفيذ: sudo apt-get update sudo apt-get install w3m إحدى المزايا التي قد تهم البعض هي إمكانية استخدام الأوامر المستعملة في برنامج vi، على سبيل المثال يمكن تحريك مؤشر الفأرة بواسطة الأزرار ‘j’, ‘k’, ‘l’, و ‘h’. أدوات التنزيلسيكون من المفيد أحيانًا أن تكون قادرًا على تصفح الإنترنت من الخادوم نفسه باستخدام الأدوات السابقة، إلا أنك ستجد نفسك في نهاية المطاف ترغب بالعودة إلى حاسبك الخاص للتصفح من خلال متصفحات الوِب الرسوميّة باعتبار ذلك أمرًا أكثر كفاءة، كما ستشعر بالثقة بأنّ ما تشاهده هو تمامًا ما يُفترض أن تحصل عليه. لهذه الأسباب يلجأ معظم الناس إلى تصفح الوِب من خلال المستعرضات التقليدية ومن ثم نسخ ولصق الروابط إلى الطرفية لاستخدامها مع أحد أدوات التنزيل. wgetتُعتبر الأداة wget خيارًا ممتازًا للحصول على الصفحات أو الملفات من المواقع. إذا لم تكن تملك wget مسبقًا على خادومك، يمكنك الحصول عليها عن طريق تنفيذ: sudo apt-get update sudo apt-get install wget كلّ ما عليك فعله بعد ذلك لتنزيل الملفات من الإنترنت هو لصق عنوان الرابط URL في الطرفيّة بعد استدعاء الأداة: wget www.example.com إذا كان عنوان الرابط URL المُستخدم يُشير إلى موقع على شبكة الإنترنت فإنه سيجري تحميل الفهرس أو الصفحة الرئيسيّة له، وفي حال كان الرابط يعيد توجهيك إلى ملف فسيتم تحميل هذا الملف ضمن الدليل النشط. وهكذا فأثناء تصفحك الإنترنت من خلال جهاز الحاسوب الخاص بك في المنزل، وحالما ترغب في تحميل ملف ما من الشبكة، انقر بزر الفأرة الأيمن على الرابط ثم اختر شيئًا مشابهًا لـ "انسخ عنوان الموقع" أو "copy link location"، ثم قم بلصق العنوان في الطرفية مسبوقًا باستدعاء الأداة wget. إذا حصل وقوطعت عملية التحميل لأي سبب (مثل ضُعف الاتصال بالإنترنت)، فإنه يمكنك استخدام wget مع الخيار c- والذي يستأنف التحميل الجزئي في حال تمّ العثور على ملف غير مكتمل في الدليل النشط. wget -c www.example.com تدعم الأداة wget التعامل مع ملفات تعريف الارتباط Cookies مما يجعلها مرشحًا جيدًا للنصوص التنفيذية scripting إضافةً إلى قدرتها على تحميل موقع وِب بالكامل. curlتُعتبر الأداة curl خيارًا جيدًا كذلك لهذا النوع من العمليات، ففي حين تعمل wget بواسطة جلب الملفات، فإن curl تستخدم الخرج القياسي مما يجعلها أداة مثالية للاستخدام مع السكربتات والأنابيب scripts and pipes، بالإضافة إلى دعمها عددًا كبيرا من البروتوكولات، وتمكّنها من التعامل مع أساليب توثيق http بشكل أكفأ من wget. تأتي العديد من أنظمة التشغيل مجهزة مع curl بشكل افتراضي، إذا لم يكن نظام تشغيلك كذلك: sudo apt-get update sudo apt-get install curl وبينما تستخدم curl الأنابيب عادةً، إلا أنه يمكنك أيضًا حفظ خرجها بسهولة إلى ملف، وهذا ما تريده غالبًا إذا كنت ترغب بتحميل ملفات لرفعها إلى خادومك. لتنزيل ملف وحفظه بالإبقاء على اسمه الافتراضي نفّذ: curl -O www.example.com/index.html يتوجب علينا تحديد الملف لأن هذه هي الطريقة التي نُعلم بها curl بالاسم المحليّ للملف. أما إذا كنت تريد أن تختار اسم للملف المحلي، فنحن لسنا بحاجة للإشارة إلى ملف معيّن في عنوان الموقع إذا كان ما نريده هو فهرس دليل الموقع، بدلًا من ذلك يمكننا أن نشير اختياريًا إلى الموقع وأيا يكن ملف الفهرس فإنه سيُهيئ ليوضع في الملف الذي اخترناه: curl -o file.html www.example.com لا تقتصر فائدة هذه الطريقة على تنزيل فهارس الأدلة وإنما تعمل بشكل جيّد أيضًا لتنزيل ملف بالاسم الذي تختاره. الخاتمةكما ترى فإنه لدينا عدد غير قليل من الخيارات المختلفة للحصول على الملفات، التطبيقات، والمواد المختلفة من الإنترنت لتمريرها إلى الخادوم الخاص بك. وفي حين أن كلا منها لديه القدرة على جلب المحتوى من شبكة الإنترنت فلا يوجد أداة واحدة من بينها مناسبة لجميع أنواع التحميلات؛ لذا فمن المفيد أن نتعرف على الأدوات المتاحة أمامنا لنكون قادرين على الاستفادة من نقاط القوّة في كلّ منها والتي صُممت أساسًا من أجلها، وهذا ما سوف يساعدك على تجنب القيام بأعمال لا لزوم لها، ويعطيك المرونة في الطريقة التي تقارب بها مشاكلك. تُرجم وبتصرف من مقال How To Download Software and Content onto your Linux VPS لكاتبه Justin Ellingwood. ncurses: هي مكتبة برمجيّة تُزوّد التطبيقات بواجهة برمجيّة لتسهّل على المطورين كتابة واجهات نصيّة لبرامجهم تعمل ضمن الطرفية بطريقة أقرب للبرامج الرسوميّة. Pipes: الأنبوب، هي أداة يمكن أن تُشغّل عدّة أوامر في لينكس بشكل متعاقب بحيث تفصل بين كل أمرين؛ مُرسلةً خرج العملية السابقة ليكون دخل العملية اللاحقة.