محمد أحمد العيل

يعدّ أمر tar من بين الأدوات التي يشيع استخدامها في سطر أوامر لينكس، إلا أن جوانب مفيدة كثيرة في الأمر تبقى مجهولة. نعرض في هذا المقال بعض أشهر استخدامات الأمر tar إضافة إلى استخدامات رائعة أخرى يقل الانتباه إليها. أول ما تجب معرفته هو الغرض الأساسي من tar؛ إذ يعمل الأمر على جمع الكثير من الملفات في واحد. إذا نفذت أمر tar على مجلّد من 37 ملفّا فستحصُل على ملفّ واحد يضمّها جميعا وبالتي يسهُل مشاركتها مع الآخرين. كما أن الأمر يحافظ على بنية المجلّد ويمكن أن يحافظ على الأذونات ومعلومات الوقت والزمن كذلك. الخيارات في ما يلي قائمة بأهم الخيارات التي يمكن استخدامها مع tar. c: إنشاء ملف أرشيف. f: استخدام مُخرج الأمر لإنشاء ملف. تظهر مخرجات الأمر في الطرفية فقط إن لم يٍُستخدَم هذا الخيار. x: استخراج محتويات ملف أرشيف. j: استخدام خوارزمية bzip2 لضغط الملفات. z: استخدام خوارزمية gzip لضغط الملفات. p: الحفاظ على الأذونات عند استخراج الملفات. t: الحصول على قائمة بمحتويات ملف الأرشيف. v: عرض تقدّم عمل الأمر أثناء تنفيذه. d: عرض الفروق بين ملف الأرشيف ونظام الملفات. إنشاء ملف أرشيف إنشاء ملف أرشيف لمجلّد: tar cf directory.tar directory إنشاء ملفّ أرشيف انطلاقا من مجموعة ملفات: tar cf directory.tar file1 file2 file3 إنشاء ملف أرشيف مضغوط بخوارزمية bzip لملفات mp3 الموجودة في المجلّد الحالي: tar -cvf mp3collection.tar ./*.mp3 إنشاء ملف أرشيف من المجلد /home/academy/ مع الحفاظ على الأذونات: tar cvpf academy.tar /home/academy/ إنشاء أرشيف من المجلد etc/ مع استبعاد المجلد الفرعيّ apache2: tar cvf etc_without_apache.tar –exclude='/etc/apache2/' ضغط الملفات إنشاء ملف مضغوط بـbzip2 مع عرض تقدّم عمل الأمر في الطرفية: tar cjvf directory.tar.bz2 directory/ إنشاء ملف مضغوط بـgzip مع عرض تقدّم عمل الأمر في الطرفية: tar czvf directory.tar.gz directory/ عرض محتوى أرشيف عرض محتوى ملف الأرشيف directory: tar tvf directory.tar.bz2 ... bluewaters_1440x900.jpg cloudyday_1440x900.jpg fragile_1600x1200.jpg coolemoticon_1440x900.jpg cloudyday_1440x900.jpg ... الاستخراج من ملفات الأرشيف استخراج محتوى ملف أرشيف: tar xvf directory.tar.bz2 استخراج ملف passwd فقط من أرشيف etc: tar xvf etc.tar.bz2 passwd استخراج مجلد postfix فقط من أرشيف etc: tar xvf etc.tar.bz2 /etc/postfix/ استخراج ملفات php فقط من أرشيف htdocs: tar xvf htdocs.tar.bz2 –wildcards '*.php' الفروق الفرق بين ملف أرشيف ومجلّد (في حال عدم ذكر المجلد فالمقارنة تكون مع مجلد بنفس اسم الأرشيف في المجلد الحالي): tar df directory.tar.bz2 البحث عن ملف في الأرشيف: tar df directory.tar.bz2 directory/file1 ملحوظة: يجب في إصداراتٍ من tar تمرير خيار خوارزمية الضغط أثناء استخراج الملفات أو أثناء النظر في فروق ملفات أرشيف مضغوطة)؛ إلا أن الأمر اختياري في أغلب الإصدارات الأخيرة. مثلا: tar xjvf etc.tar.bz2 /etc/postfix/ بدلا من: tar xvf etc.tar.bz2 /etc/postfix/ ترجمة -وبتصرّف- لمقال A tar Primer لصاحبه Daniel Miessler.

يقدّم هذا الدرس كيفية إنشاء نموذج Model قاعدي في Laravel ومن ثم استخدامه. النماذج هي الجزء من بنية MVC الذي تُعالَج فيه البيانات وتُنفَّذ عليها قواعد التطبيق. يتطلّب الدرس تثبيت Laravel وإعداده مع قاعدة البيانات. نبدأ بإنشاء النموذج باستخدام أمر artisan على النحو التالي: php artisan make:model Widget -m سمّينا النموذج بـWidget وأضفنا خيار m- لإنشاء التهجير في نفس الوقت. يختزل الأمر بهذه الطريقة الكثير من الوقت ويجعلنا نركّز على الأهم: عمل النموذج. ستجد بعد اكتمال تنفيذ الأمر ملفا باسم Widget.php في مجلّد app المتفرّع عن مجلّد المشروع، وملفًّا للتهجير في المجلّد database/migrations. يظهر اسما الملفّيْن في مخرجات تنفيذ الأمر السّابق. نفتح ملفّ Widget.php للنظر في محتواه: <?php namespace App; use Illuminate\Database\Eloquent\Model; class Widget extends Model { // } هذا كلّ ما يوجد الملف! هيكل نموذج يمكننا الاستفادة منه لإنشاء ما نريد. بالانتقال إلى مجلّد database/migrations نجد ملفًّا يشبه التالي: 2016_03_19_163722_create_widgets_table.php يظهر في بداية اسم الملف ختم زمني بتاريخ إنشائه. يفترض Laravel أن اسم النموذج كلمة مفردة (Widget مثلا) تبدأ بحرف كبير Uppercase، في حين يتوقّع أن يكون اسم الجدول Table جمعًا (widgets) يبدأ بحرف صغير. يمكن تفسير الأمر بأن النموذج يُرجِع نظيرا واحدا لتسجيلات الجدول. إذا نظرنا إلى ملفّ التهجيرات فسنجد أن لدينا قاعدة يمكننا البناء عليها لأمور أكثر تقدّما: use Illuminate\Database\Schema\Blueprint; use Illuminate\Database\Migrations\Migration; class CreateWidgetsTable extends Migration { /** * Run the migrations. * * @return void */ public function up() { Schema::create('widgets', function (Blueprint $table) { $table->increments('id'); $table->timestamps(); }); } /** * Reverse the migrations. * * @return void */ public function down() { Schema::drop('widgets'); } } ينشئ Laravel تلقائيا حقل المعرّف في قاعدة البيانات id ويجعله يتقدّم تلقائيا فور إدراج تسجيلة جديدة في الجدول (autoincrement) وذلك باستخدام الدّالة increments. يضيف Laravel كذلك ختمين زمنيّين لتاريخَيْ إنشاء التسجيلة وتحديثها timestamps. سنضيف عمودا Column جديدا إلى قاعدة البيانات؛ لذا نضيف التعليمة التالية إلى دالّة up ضمن ملفّ التهجير: $table->string('widget_name')->unique(); يضيف السّطر أعلاه عمودا جديدا للجدول باسم widget_name من نوع string ويقيّده بـunique لكي لا توجد تسجيلتان في الجدول بنفس الاسم. تصبح دالّة up في ملف التهجير بعد إضافة العمود على النحو التالي: public function up() { Schema::create('widgets', function (Blueprint $table) { $table->increments('id'); $table->string('widget_name')->unique(); $table->timestamps(); }); } ثم ننفّذ التهجير: php artisan migrate ستلاحظ بعد تنفيذ الأمر إنشاءَ جدول جديد في قاعدة البيانات لديك. بما أننا نخطّط لإدراج تسجيلات إلى قاعدة البيانات بالتطبيق فيجب أن نضيف الخاصيّة التالية إلى النموذج Widget: /** * The attributes that are mass assignable. * * @var array */ protected $fillable = ['widget_name']; تخبر هذه التعليمة Laravel أن العمود widget_name يدعم الإسناد الشّامل Mass assignment (تحديد قيم معطياتٍ عدّةٍ مرة واحدة). إن لم نضف هذه التعليمة فلن يمكننا باستخدام التطبيق إدراجُ تسجيلات جديدة في الجدول. سنستخدم في الدرس التالي النموذج الذي أنشأناه أعلاه مع معمل النماذج Model factory في Laravel لملْء تسجيلات في جدول widgets. ترجمة -وبتصرّف- للمقال How to Make a Model in Laravel 5.1 لصاحبه Bill Keck.

يحظى أمر ping بشعبية كبيرة لدى مديري الشبكات وممتهني التقنية لما يقدمه من خدمات في سبيل فحص الاتصال بين مضيفين Host. يقدّم هذا المقال تفاصيل أكثر عن هذا الأمر شائع الاستخدام. ماهو أمر ping وكيف يعمل؟ يعمل أمر ping على فحص إمكانية الوصول إلى عنوان IP، مضيف أو خادوم انطلاقا من شبكتك. يكثُر استخدام الأمر للتدقيق في أخطاء الشبكة وتحديد مشاكلها. يقوم الأمر على مبدأ عمل سهل ولكنه مفيد؛ إذ يُرسِل حزم بيانات تحوي الرسالة PING إلى عنوان IP (أو المضيف) وينتظر الرد ثم يحسب الفترة الزمنية اللازمة لورود الجواب؛ يُشار لهذه المدّة بـRTT، وهي اختصار Round Trip Time أي زمن الذهاب والإياب؛ تُعرَف هذه المدة أيضا بزمن الوصول Latency. يعني هذا أن بإمكانك معرفة ما إذا كان يمكن الوصول إلى مضيف من شبكتك وسرعة تلقي الرد منه باستخدام ping. يشير العمل السريع لأمر ping (زمن وصول قصير) إلى أن الاتصال متجاوب أكثر وهي مسألة مهمة في تطبيقات مثل الألعاب على الشبكة. يُقاس زمن الوصول عادة بجزء على ألف من الثانية (ثانية = 1000ms)؛ أزمان وصول أعلى تعني وجود مشاكل في الشبكة. يتغيّر زمن الوصول حسب عوامل من بينها التوجيه Routing والموقع الجغرافي. ينتج عن تنفيذ أمر ping لتجربة الوصول إلى مضيف في نفس البلد زمن أدنى من مضيف في بلد بقارة أخرى نظرا للموقع الجغرافي والقفزات Hops التي يتضمنها التوجيه. تأتي أداة ping مثبتة مسبقا على جميع أنظمة التشغيل الحديثة تقريبا ويمكن تنفيذها من سطر الأوامر (الطرفية على الأنظمة الشبيهة بيونكس أو محثّ وندوز Windows prompt). ملحوظة: يمكن إعداد الخواديم أو المضيفات على حظر (عدم الرد) طلبات ping لأسباب أمنية. خيارات ping الأساسية معرفة إصدار ping يتيح الخيار V- معرفة إصدار ping المثبَّت في النظام: ping -V مثال على المخرجات: ping utility, iputils-s20121221 استخدام أمر ping المعطى الضروري الوحيد لأمر ping هو اسم المضيف أو عنوان IP المراد فحصُه. ping example.com اسم المضيف في المثال أعلاه هو example.com. في ما يلي مثال على مخرجات الأمر: PING example.com (93.184.216.34) 56(84) bytes of data. 64 bytes from example.com (93.184.216.34): icmp_seq=1 ttl=42 time=116 ms 64 bytes from example.com (93.184.216.34): icmp_seq=2 ttl=42 time=154 ms 64 bytes from example.com (93.184.216.34): icmp_seq=3 ttl=42 time=163 ms 64 bytes from example.com (93.184.216.34): icmp_seq=4 ttl=42 time=1028 ms 64 bytes from example.com (93.184.216.34): icmp_seq=5 ttl=42 time=768 ms 64 bytes from example.com (93.184.216.34): icmp_seq=6 ttl=42 time=128 ms ستحتاج لتوقيف تنفيذ الأمر بالضغط على الزرين CTRL و C وإلا فإن الأمر سيستمر في إرسال الحزم. ملحوظة: توجد اختلافات يسيرة في الأمر بين لينكس ووندوز، يتوقف تنفيذ الأمر في وندوز بعد إرسال أربع حزم مبدئيا. يظهر ملخّص بالإحصاءات بعد توقف الأمر: ^X^C --- example.com ping statistics --- 24 packets transmitted, 23 received, 4% packet loss, time 23041ms rtt min/avg/max/mdev = 114.323/307.465/1057.499/296.627 ms, pipe 2 يتضمن الملخّص: عدد الحزم المُرسَلة Transmitted عدد الحزم المستلمة Received نسبة فقدان الحزم Packet loss الحد الأدنى للمدة الزمنية لوصول الإجابة min. متوسط وصول الإجابة avg. الحد الأقصى للمدة الزمنية لوصول الإجابة max. تظهر في كل سطر مدة الإجابة وقيمة أخرى باسم ttl. تحدّد القيمة الأخيرة عمر الحزمة (Time To Live). إن انقضت هذه القيمة دون أن يتمكن ping من الاتصال بالوجهة فسيقرّر أنه لا يمكن الوصول إليها. لا يقتصر استخدام هذا المعطى على ping بل مجالات أخرى مثل بروتوكول HTTP و نظام أسماء النطاقات. لا يختلف فحص الاتصال بجهاز على الشبكة الداخلية عن فعل نفس الشيء بالنسبة لمضيف على الإنترنت. الأمر التالي مثلا يفحص الاتصال بجهاز على الشبكة الداخلية عبر عنوان IP الخاص به: ping 192.168.1.5 عدد مرات تنفيذ الأمر السلوك المبدئي لأمر ping إن استخدم بدون خيارات هو الاستمرار في إرسال الحزم إلى أن يتدخل أحد لإيقافه؛ إلا أنه توجد طريقة لتحديد عدد مرات إرسال الحزم. استخدم الخيار c- متبوعا بعدد على النحو التالي: ping -c 10 example.com تظهر المخرجات كالتالي: PING example.com (93.184.216.34) 56(84) bytes of data. 64 bytes from example.com (93.184.216.34): icmp_seq=1 ttl=43 time=129 ms 64 bytes from example.com (93.184.216.34): icmp_seq=2 ttl=43 time=127 ms 64 bytes from example.com (93.184.216.34): icmp_seq=3 ttl=43 time=126 ms 64 bytes from example.com (93.184.216.34): icmp_seq=4 ttl=43 time=125 ms 64 bytes from example.com (93.184.216.34): icmp_seq=5 ttl=43 time=284 ms 64 bytes from example.com (93.184.216.34): icmp_seq=6 ttl=43 time=132 ms 64 bytes from example.com (93.184.216.34): icmp_seq=7 ttl=43 time=131 ms 64 bytes from example.com (93.184.216.34): icmp_seq=8 ttl=43 time=130 ms 64 bytes from example.com (93.184.216.34): icmp_seq=9 ttl=43 time=178 ms 64 bytes from example.com (93.184.216.34): icmp_seq=10 ttl=43 time=128 ms --- example.com ping statistics --- 10 packets transmitted, 10 received, % packet loss, time 9011ms rtt min/avg/max/mdev = 125.003/149.335/284.433/47.508 ms ينفَّذ الأمر - كما يظهر - عشر مرات ثم يتوقف ويعطي إحصائيات. لفعل نفس الشيء على وندوز نضيف الخيار n- بدلا من c-: ping -n 10 example.com تعديل حجم حزمة البيانات يُرسِل أمر ping مبدئيا حزمة بحجم 64 بايت على لينكس، و32 بايت على وندوز. إن أردت تغيير الحجم المبدئي للحزمة على لينكس فيمكنك ذلك باستخدام الخيار s- : ping -s 100 -c 6 example.com النتيجة: PING example.com (93.184.216.34) 100(128) bytes of data. 108 bytes from example.com (93.184.216.34): icmp_seq=2 ttl=51 time=1113 ms 108 bytes from example.com (93.184.216.34): icmp_seq=3 ttl=51 time=253 ms 108 bytes from example.com (93.184.216.34): icmp_seq=4 ttl=51 time=263 ms 108 bytes from example.com (93.184.216.34): icmp_seq=5 ttl=51 time=253 ms 108 bytes from example.com (93.184.216.34): icmp_seq=6 ttl=51 time=1068 ms --- example.com ping statistics --- 6 packets transmitted, 5 received, 16% packet loss, time 4999ms rtt min/avg/max/mdev = 253.093/590.201/1113.044/408.995 ms, pipe 2 بالنسبة لوندوز فالخيار المستخدم هو l-: ping -l 100 -n 6 example.com زيادة المدة الزمنية أو تقليصها ينتظر أمر ping مبدئيا ثانية واحدة قبل إرسال الحزمة الموالية إلى الوِجهة. يمكِّن استخدام الخيار i- من زيادة هذا المجال أو تقليصه. يحدّد الأمر التالي 3 ثوان مجالا بين إرسال حزمتين: ping -i 3 example.com يمكننا بنفس الطريقة التسريع من إرسال الحزم بدل انتظار ثانية في كل مرة: ping -i 0.2 example.com إغراق الوجهة بحزم ping تُستخدم هذه الطريقة لاختبار أداء الشبكة. لا ينتظر أمر ping بين إرسال حزمتين إن استخدم الخيار f- بشرط تنفيذه بصلاحيات إدارية: sudo ping -f example.com ستلاحظ - حسب جودة الشبكة لديك - نقاطا تتحرك بسرعة. يطبع الأمر نقطة في الطرفية في كل مرة تُرسَل حزمة، وفي كل مرة يرد فيها جواب يُطبع رجوع إلى الخلف (تُحذَف نقطة) وهو ما يعطي فكرة عن عدد الحزم التي لم ترد عنها إجابات؛ وهو ما تمثله النقاط المتبقية. اضغط زرّي CTRL و C لإيقاف الأمر. عرض إحصاءات ping فقط يمكن باستخدام الخيار q- الإبقاء على إحصاءات الأمر فقط دون إظهار معلومات الحزم: ping -c 5 -q example.com النتيجة: PING example.com (93.184.216.34) 56(84) bytes of data. --- example.com ping statistics --- 5 packets transmitted, 4 received, 20% packet loss, time 6221ms rtt min/avg/max/mdev = 259.175/723.504/1219.311/460.540 ms, pipe 2 يظهر التقرير فقط في مخرجات الأمر أعلاه. تحديد مهلة لتنفيذ ping إذا أردت تحديد مهلة زمنية تظهر بانقضائها إحصاءات أمر ping فيمكنك ذلك بإضافة الخيار w-: ping -w 6 example.com يعيّن الخيار w-المدة الزمنية التي يقضيها الأمر في إرسال الحزم. حددنا في المثال أعلاه 6 ثوان سيتوقف بعدها تنفيذ الأمر وتظهر الإحصاءات. رسائل الخطأ في أمر ping تظهر عدة رسائل - حسب الحالة - في مخرجات ping، في ما يلي شرح مدلولاتها. Destination Host Unreachable تشير الرسالة Destination Host Unreachable (لا يمكن الوصول إلى المضيف الوِجهة) إلى أنه لا توجد طريق من الشبكة المحلية إلى المضيف الذي أرسلت إليه الحزم. يعني هذا عادة أنه يوجد خطأ في الاتصال. إن نفذت أمر ping دون أن تكون متصلا فستظهر هذه الرسالة. Request timed out تعني هذه الرسالة Request timed oud (انتهاء مهلة انتظار الرد) أن الأداة لم تحصُل على أجوبة على الحزم التي أرسلتها ضمن المهلة المحدّدة (1 ثانية مبدئيا). توجد عدّة أسباب ممكنة من أبرزها احتقان Congestion في الشبكة، حجب بعض الحزم في الجدار الناري firewall، مشكل في الموجِّه Router وغيرها. Unknown host / Ping Request Could Not Find Host تدلّ رسالة الخطأ Unknown host (مضيف غير معروف) أو شبيهتها Ping Request Could Not Find Host (لم يستطع طلب Ping العثور على مضيف) إلى خطأ في اسم المضيف؛ إما لكون اسم المضيف غير موجود أو أنه غير متاح لديك في الشبكة. عند تنفيذ الأمر التالي مثلا (لاحظ الخطأ في كتابة hsoubs): ping hsoubs.com تظهر الرسالة: ping: unknown host hsoubs.com خاتمة يختلف زمن الوصول باختلاف نوعية الشبكة وطريقة الاتصال (ألياف ضوئية، شبكة لا سلكية، … إلخ). إذا كانت الشبكة لديك جيدة فستكون نسبة الحزم المفقودة %0 وستحصُل على زمن وصول ببضعة أجزاء من الثانية. ترجمة -وبتصرّف- لمقال All About PING Command لصاحبه Mohammad Forhad Iftekher.

يجد كثير من مستخدمي لينكس والأنظمة الشبيهة بيونكس عموما مشاكل في فهم أذونات Permissions الملفات والمجلّدات. يتعلق الأمر أحيانا بترتيب أوضاع بتات القراءة، الكتابة أو التنفيذ؛ بينما تكمن الصعوبة أحيانا أخرى بفهم رموز العدّ الثمانيّ Octal أو ربما كيفية حل لغز بت setuid والبت اللاّصق Sticky bit. يتوجّه هذا المقال إلى من لم يفهم قطّ هذه الأذونات بالدرجة الأولى وإلى من يجد خلطا من حين لآخر في تفاصيلها. راجع أيضا مقال مقدّمة إلى أذونات لينكس Linux Permissions. الأساسيات نبدأ أولا بالنظر إلى مخرجات أمر ls: ls -lah -rwxr-xr-- 1 daniel consultants 5K Mar 10 06:55 scanner.rb -rwxr-xr-x 1 sarah teachers 18M Jul 30 10:07 papers.tar.bz2 ثلاث مجموعات من ثلاثة أحرف: بما أن الأمر يتعلّق هنا بملفات فستظهر عارضة - في أول كل مُخرَج (سطر) . تلي العارضة مجموعة محارف (9 بالضبط، تدخُل العوارض - في الحساب) سنصطلح على تقسيمها إلى ثلاث مجموعات فرعية متساوية (3x3). المستخدِم-المجموعة-الآخرون: نسمي المجموعات الثلاث على الترتيب المستخدِم User, U، مجموعة المستخدم Group, G والآخرين Other, O. يعني هذا أن أول مجموعة محارف (rwx في السطريْن) تتعلق بالمستخدِم مالك الملفّ، الثانية (r-x في السطريْن) تتعلّق بمجموعة المستخدمين مالكة الملفّ والثالثة (--r في السطر الأول وr-x في السطر الثاني) تعني الآخرين أي بقية المستخدمين. صاحب (مالك) الملف: يظهر في نتيجة الأمر المستخدم مالك الملف ومجموعة المستخدمين مالكة الملف كذلك، لكنك لن ترى الآخرين. يعود السبب في ذلك إلى أن أذونات الآخرين (مجموعة المحارف الأخيرة ضمن المجموعات الثلاث أعلاه) تنطبق على كل من ليس مالكَ الملف وليس ضمن مجموعة المستخدمين صاحبة الملف. الأعداد الثلاثة يرتبك بعضهم عندما يرى الأذونات مذكورة بصيغة مجموعة من ثلاثة أعداد، لكنّ الأمر ليس بهذا التعقيد. تذكّر فقط أن هذه الأعداد هي أماكن تحوي الرقم الموافق للإذن حسب الترتيب (من اليسار إلى اليمين): r (القراءة)، w (الكتابة) وx (التنفيذ). لاحظ الصورة. بالنسبة لكلّ رمز، نضربه في 1 إذا كان مذكورا في الأذونات وفي 0 إن لم يكن (تظهر عارضة مكانه)، ثم نجمع نتيجة كل ثلاثي. الأذونات على المجلدات يجب الانتباه إلى أن الأذونات على المجلدات تختلف عنها على الملفات. توحي أسماء الأذونات على الملفات بعملها: قراءة الملف (r)، الكتابة فيه أو حذفه (w) وتنفيذه (x)؛ بينما الدلالة مختلفة قليلا في المجلدات: يعني إذن القراءة على مجلد أن بإمكانك عرض المجلّد. يدلّّ إذن الكتابة أن لديك القدرة على إنشاء محتوى في المجلد أو حذفه منه. يشير إذن التنفيذ إلى أنه بالإمكان الدخول إلى المجلّد، تنفيذ أمر cd عليه مثلا. البت اللاصق، معرف المستخدم ومعرف المجموعة تمثّل هذه الخيارات الثلاثة الجزئية الأكثر تعقيدا لدى الكثيرين في أذونات لينكس. معرف المستخدم صُمِّم خيار معرّف المستخدم setuid (اختصار لـ Set user ID upon execution "اضبط معرّف المستخدم أثناء التنفيذ") لحلّ مشكل أساسي: غياب الإذن الكافي لتنفيذ بعض البرامج. كان حلّ هذا المشكل بإضافة خيار إلى الملف يقول “نفّذ هذا البرنامج وفق أذونات المستخدم الذي يملكه بغضّ النظر عن المستخدم الذي ينفّذ الملف”. ينبغي الحذر من استخدام هذا الخيار - الذي أصبح متجاوزا - إذ قد يؤدي لأخطار أمنية. إن حدث ومررت بإذن على النحو التالي فأنت أمام خيار setuid: -rwsr-xr-- 1 daniel consultants 5K Mar 10 06:55 scanner.rb لاحظ حرف s في أذونات المستخدم مالك الملف مكان إذن التنفيذ x. يشير حرف s إلى أن إذن setuid مضبوط. يظهر حرف s في المثال أعلاه صغيرا Lowercase وهو ما يعني أن خيار التنفيذ متاح أيضا لمالك الملف. إن كان خيار setuid فقط مضبوطا (بمعنى أنه لا يُتاح لمالك الملف إذن تنفيذه) فسيظهر الحرف كبيرا Uppercase هكذا S. ملحوظة: ينطبق التنبيه أعلاه بخصوص هيئة الحرف (صغير أو كبير) على جميع خيارات الأذونات الخاصة. المبدأ العام هو: إذا كان الحرف الذي يشير للإذن الخاص صغيرا فهذا يعني أن الإذن لدى المالك أيضا، أما إذا كان كبيرا فهذا يعني أنه ليس لدى المالك هذا الإذن. معرف المجموعة setguid يشبه الخيّار السابق في عمله مع فرق أنه يُطبَّق على مجموعة المستخدمين المالكة للملف بدلا من المستخدم المالك: -rwxr-Sr-x 1 bjones principals 101K Aug 16 04:01 grades.xml الفرق هنا بالمقارنة مع المثال في الفقرة السابقة هو أن حرف S يوجد ضمن أذونات المجموعة بدلا من المستخدِم. لاحِظ أيضا أن الحرف S في هذا المثال كبير وهو ما يعني أنّه ليس لدى المجموعة المالكة (principals في هذه الحالة) إذن التنفيذ ولكن عند تنفيذ المستخدِم bjones (المالك) أو مستخدم آخر ليس ضمن مجموعة principals للملف فإنّ التنفيذ سيكون بصلاحيات المجموعة المالكة. البت اللاصق يُستخدم هذا البت من أجل منع مستخدمين من التعديل على أو حذف ملفات مستخدِم أو مجموعة مستخدمين. يمكن تطبيق البت اللّاصق على ملفات عادية ولكنّه يُطبَّق أكثر على المجلّدات. نفرض مثلا أنك وضعت مجلدا تحت تصرّف مجموعة من التلاميذ ثم منحت لكل طالب مجلدا خاصا به. يمكن باستخدام البتّ اللاصق التأكد من أنه لن يكون بإمكان طالب حذفُ محتوى مجلد خاصّ بطالب آخر. يبدو البت اللاّصق كما يلي (لاحظ حرف t): drwxr-xr-t 1 alice alice 4.4K 2007-01-01 09:21 Alice التعديل على الأذونات استخدم أمر chmod لتعديل أذونات ملفّ بذكر الأذونات الجديدة التي تريد تطبيقها. يغيّر الأمر التالي أذونات مجلد الويب لتصبح 755: chmod 755 web_directory يغيّر الأمر أدناه أذونات ملف لتصبح 644: chmod 644 grocery_list.txt تعيين معرف المستخدم، معرف المجموعة والبت اللاصق يمكن استخدام أمر chmod أيضا لتعيين الأذونات الخاصّة. لتعيين معرّف المستخدم (نضيف 4 أمام الأذونات الاعتيادية): chmod 4644 script.rb يمكن أيضا استخدام طريقة إضافة الأذونات الأخرى: chmod u+s script.rb لتعيين معرّف المجموعة (نضيف 2 أمام الأذونات الاعتيادية): chmod 2644 script.rb أو: chmod g+s script.rb لتعريف البت اللّاصق (نضيف 1 أمام الأذونات الاعتيادية): chmod 1644 myfiles أو: chmod o+t myfiles ترجمة -وبتصرّف- للمقال A Unix and Linux Permissions Primer لصاحبه Daniel Miessler.

يجد الكثير من المبتدئين استخدام PHPUnit لاختبار Test الشيفرة المصدرية التي يكتبونها أمرا معقّدا للغاية؛ بدءًا من تثبيت مكتبات الاختبار وليس انتهاء بتشخيص أخطاء عملها. يسهّل Laravel 5 الكثير من هذه التعقيدات إذ يأتي مضمّنا مبدئيّا بمكتبة PHPUnit جاهزة للعمل. يمكنك التأكّد من ذلك بالدخول إلى مجلّد المشروع ثم تنفيذ الأمر التالي: vendor/bin/phpunit --version قد تظهر لك مشكلة في اعتمادات Composer إلا أنه يمكن تجاوزها بتنفيذ الأمر على النحو التالي: vendor/phpunit/phpunit/phpunit --version تظهر بعد تنفيذ الأمر المناسب النتيجة التالية (قد يختلف رقم الإصدار لديك): PHPUnit 4.8.24 by Sebastian Bergmann and contributors. استخدم الأمر الصحيح من بين الأمريْن أعلاه في بقية هذا الدرس. يأتي Laravel مبدئيّا بمثال لاختبار؛ سننظر في هذا المثال لنرى كيف تعمل اختبارات PHPUnit. افتح الملف ExampleTest.php الموجود في المجلّد tests المتفرّع عن مجلّد المشروع: <?php use Illuminate\Foundation\Testing\WithoutMiddleware; use Illuminate\Foundation\Testing\DatabaseMigrations; use Illuminate\Foundation\Testing\DatabaseTransactions; class ExampleTest extends TestCase { /** * A basic functional test example. * * @return void */ public function testBasicExample() { $this->visit('/') ->see('Laravel 5'); } } يمكننا تجربة الاختبار بتنفيذ الأمر التالي الذي ينفّذ جميع الاختبارات الموجودة في الملف tests المذكور أعلاه: vendor/bin/phpunit يبحث الاختبار أعلاه عن سلسلة المحارف Laravel 5 في الصفحة الرئيسية للمشروع التي يشير إليها المسار /. إن كان مشروع Laravel الذي تعمل عليه جديدا فسيظهر سطران كالتالي: Time: 118 ms, Memory: 12.00Mb OK (1 test, 1 assertion) يخبر السطر الأول بالوقت الذي استغرقه الاختبار وحجم الذاكرة المستخدمة لتنفيذه. أما السطر الثاني فيُظهر عدد الاختبارات وعدد التأكيدات Assertions ونتيجتها. لدينا اختبار واحد (ExampleTest) وتأكيد واحد (الصفحة الرئيسية تحوي سلسلة المحارف Laravel 5). بما أن نتيجة الاختبار إيجابية فإن السطر الأخير يظهر باللّون الأخضر. فلنجرّب إخفاق الاختبار. نستبدل Laravel 6 بـ Laravel 5 في ملف الاختبار ثم نعيد تنفيذ الأمر: vendor/bin/phpunit ستظهر الكثير من المُخرجات تحوي الرسائل التالية إضافة لشفرة الصفحة الرئيسية التي نختبرها: Time: 115 ms, Memory: 12.00Mb There was 1 failure: Couldn't find [Laravel 6] on the page. Check content above. FAILURES! Tests: 1, Assertions: 1, Failures: 1. يخبر السطر الأول بالمدة التي استغرقها الاختبار والحجم الذي أخذه في الذاكرة، بينما يشرح السّطر الثالث سبب الإخفاق وهو عدم القدرة على إيجاد سلسلة المحارف Laravel 6 في الصفحة. يلخّص السّطر الأخير نتيجة الأمر التي تظهر باللون الأحمر دلالة على إخفاق الاختبارات. إن حصل خطأ في الشفرة المصدرية للاختبار نفسه (نسيت مثلا ; في نهاية تعليمة) فلن يُنفَّذ الاختبار وستظهر رسالة بما حدث. اختبار استمارة Form تسجيل مستخدم يقضي المطوّرون المبتدئون الكثير من الوقت لاختبار الاستمارات على تطبيقاتهم، إلا أن Laravel يجعل الأمر في منتهى السهولة. سنجرّب في هذه الفقرة اختبار استمارة لتسجيل مستخدم جديد في التطبيق. سنستعين بأداة Artisan لإنشاء أساسيات الاستيثاق (عروض Views التسجيل، الدخول وإعادة تعيين كلمة السر بالإضافة إلى المتحكّمات Controllers والمسارات Routes الضرورية): php artisan make:auth ينشئ الأمر السابق عرضا على المسار register/ به استمارة لتسجيل مستخدم جديد. سنستخدم PHPUnit لاختبار هذه الاستمارة. نستعين بأداة Artisan من جديد لإنشاء ملف للاختبار: php artisan make:test RegistrationTest ملحوظة: تأكّد من إعداد قاعدة البيانات في مشروعك. ينشئ الأمر ملفا باسم RegistrationTest.php في المجلّد tests. نفتح الملف ونعدّله على النحو التالي: <?php use Illuminate\Foundation\Testing\WithoutMiddleware; use Illuminate\Foundation\Testing\DatabaseMigrations; use Illuminate\Foundation\Testing\DatabaseTransactions; class RegistrationTest extends TestCase { use DatabaseTransactions; public function testNewUserRegistration() { $this->visit('/register') ->type('bob', 'name') ->type('hello1@in.com', 'email') ->type('hello1', 'password') ->type('hello1', 'password_confirmation') ->press('Register') ->seePageIs('/'); } } لاحظ أن الشفرة تطلُب زيارة المسار register/، إدخال المعطيات المذكورة في الاستمارة باستخدام الدالة type، الضغط على الزّر Register ثم النظر في النتيجة هل هي المسار /. تأخذ الدالة type معطيين، الأول قيمة حقل الاستمارة والثاني اسم الحقل. يجب أن تكون أسماء المعطيات في الدالة موافقة لحقول الاستمارة. في حالتنا توجد أربعة حقول في الاستمارة. نستخدم الطّابع DatabaseTransactions Trait في الاختبار. يمكّننا هذا الطّابع من إلغاء إدراج تسجيلات جديدة في قاعدة البيانات حتى لا نملأها من غير جدوى. كما نستخدم الطّابع DatabaseMigrations للتراجع عن التهجيرات Migrations وبالتالي حذف الجدول من قاعدة البيانات. الطابع الثالث المستخدم في الاختبار هو طابع WithoutMiddleware الذي يسمح بتخطّي بعض إجراءات الحماية لأغراض الاختبار. يمكننا الآن تنفيذ الاختبار كما يلي: vendor/bin/phpunit tests/RegistrationTest.php النتيجة: Time: 401 ms, Memory: 16.50Mb OK (1 test, 5 assertions) يمكنك قراءة المزيد عن الاختبارات على موقع PHPUnit؛ فقط تذكّر أن الصنف الذي نمدّده في Laravel هو TestCase بدلا من PHPUnit_Framework_TestCase في تطبيقات PHP أخرى. ترجمة -وبتصرّف- لمقال How Use PHPUnit Test in Laravel 5.1 لصاحبه Bill Keck.

تتوفّر على توزيعات لينكس برامج تحظُر إنشاء كلمات سر يسهُل تخمينها؛ فالوصول إلى الكثير من بيانات المستخدم وبرامجه يتطلّب تجاوز مرحلة إدخال كلمة السرّ ، الأمر الذي يجعل من كلمات السر نقطة حرجة في سبيل تأمين النظام والمستخدم على حدّ السواء ويجب بالتالي الحرص دائما على أن تكون محدَّثة. توجد الكثير من طرق تعمية البيانات ولكلّ منها خصوصيّاته. تستخدم أغلب توزيعات لينكس خوارزميّة تعمية تُسمّى معيار تعميّة البيانات Data Encryption Standard, DES لتعميّة كلمات السّر. تُخزّن كلمات السرّ المعمّاة في ملف etc/passwd/ أو etc/shadow/. عندما يحاول المستخدم الولوج إلى النظام فإن كلمة السّر التي يُدخِلها تُعمَّى ثم تقارن بحقل كلمة السّر المعمّاة في الملف، فإن حصل تطابق فهذا يعني أنها نفس كلمة السّر وبالتالي يُسمح له بالولوج. تستخدم أغلب توزيعات لينكس نسخة من DES لا تعمل إلا في اتجاه واحد؛ بمعنى أنه يمكن استخدامها لتعميّة كلمة سر ولكن لا يمكن استخدامها لفك تعميّة كلمات السر في ملفّي etc/passwd/ وetc/shadow/. يمكن لبرامج هجمات القوة العمياء Brute force attacks مثل John the Ripper وCrack تخمين كلمات السر التي لا تحترم حدًّا أدنى من العشوائية؛ وبإمكان مديري النّظم استخدامها لصالحهم في طريقة استباقية بتنفيذها على كلمات سرّ مستخدميهم للعثور على كلمات السّر غير الآمنة ثم الطلب من هؤلاء تغييرها إلى أخرى آمَن. التعمية بالمفاتيح العمومية تستخدم التعمية بالمفاتيح العمومية Public-Key Cryptography مفتاحا (سلسلة محارف) للتعمية وآخر لفكّها، على عكس طرق تعمية أخرى تستخدم نفس المفتاح للمهمتيْن. يهدف استخدام مفتاح خاصّ للتعميّة (المفتاح العموميّ) وآخر لفكّها (المفتاح الخصوصيّ) إلى تجاوز ضرورة تأمين نقل المفتاح الوحيد أثناء تبادل الرسائل المعمّاة. يتوفّر المفتاح العمومي لكلّ شخص للجميع دون استثناء بينما يقى المفتاح الخصوصي سرًّا خاصًّا به. مثلا، عندما يريد محمّد إرسال بريد معمّى إلى عمر فإنه يستخدم المفتاح العموميّ لعمر لتعمية البريد، عند وصول البريد إلى عمر فإنه يستخدم مفتاحه الخصوصي الذي لا يعرفه غيره لفك تعميّة الرسالة والاطّلاع عليها. بهذه الطريقة لن يعرف فحوى الرسالة غيرهما، محمّد لأنه كتب الأصل غير المعمَّى، وعمر لأنه الوحيد الذي يمكنه فك تعميتها. برنامج PGP يتبنّى برنامج PGP (اختصار لـ Pretty Good Privacy) مبدأ التعمية بالمفاتيح العمومية ويمكن استخدامه لتوقيع البيانات وتعميّتها: التوقيع للتأكد من المصدر والحؤول دون انتحال الشخصيّة، والتعمية للحفاظ على خصوصية البيانات. يجب الانتباه قبل استخدام البرنامج إلى التقييدات القانونية في استخدامه. يُحظَر في بعض الدوّل توجيه رسائل بتعميّة قويّة إلى خارج البلد. بروتوكول TLS يُستخدَم بروتوكول TLS (والإصدار السابق منه SSL) كثيرا لتأمين الاتصالات في شبكة حواسيب. يهدف البروتوكول إلى الحفاظ على خصوصية البيانات المنقولة عبر الاتصال بتعميتها، الاستيثاق من هويّات المتخاطبين باستخدام تعمية بالمفاتيح العمومية والتأكد من سلامة البيانات عن طريق جمع تحقق Checksum لكلّ حزمة بيانات. التنفيذ الأكثر شهرة على أنظمة لينكس لهذا المعيار هو مكتبة OpenSSL التي تدعم خوارزميات تعمية من بينها DES، Blowfish وIDEA. بروتوكول HTTPS وهو تطوير لبروتوكول HTTP بتضمينه داخل اتّصال يؤمّنه بروتوكول TLS (أو SSL). الأغراض الأساسية من استخدام HTTPS على مواقع الويب هي الاستيثاق، حماية الخصوصية والتحقق من سلامة البيانات المتبادلة. بروتوكول S/MIME يأتي الاسم اختصارا لـ Secure Multipurpose Internet Mail Extension (امتداد البريد الإلكتروني الآمن متعدّد الأغراض)، وهو معيار مفتوح يعتمد على التعميّة بالمفاتيح العمومية لتأمين البريد الإلكتروني وغيره من أنواع المراسلات على الشبكة. الشبكات الخاصة الافتراضية Virtual Private Network توجد تنفيذات عدّة لمعيار بروتوكول الإنترنت الآمن على لينكس. معيار IPSEC (اختصار لـ Internet Protocol Security؛ أمان بروتوكول الإنترنت) هو مجهود تقف خلفه قوة مهمات هندسة الإنتنرت IETF ويهدف إلى إنشاء اتصالات معمّاة على مستوى الشبكة (الطبقة الثالثة) وتوفير سبُل للتحقق من سلامة البيانات، التحكم في الوصول، الاستيثاق والسريّة. من الأمثلة على تطبيقات هذا البروتوكول في لينكس LibreSwan الذي يسمح للمستخدم ببناء نفق اتصالات آمن عبر شبكات غير موثوقة. يُعمَّى كل ما يمر إلى الشبكة غير الموثوقة قبل إرساله ليعمل الطرف الآخر عند استلامه على فك التعمية، تنتُج عن هذه العملية شبكة خاصّة افتراضية Virtual Private Network, VPN والتي هي شبكة اتصالات خاصّة على الرغم من أن الأجهزة فيها تتصل عن طريق شبكة غير موثوقة. لا تقتصر طُرُق إنشاء شبكات خاصة افتراضية في لينكس على IPSEC، بل توجد برامج خاصّة لهذا الغرض مثل OpenVPN التي تستخدم كثيرا مكتبات OpenSSL. بروتوكول SSH توجد عدّة حزم برمجية على لينكس لاستخدام SSH أبرزها OpenSSH. صُمِّم بروتوكول SSH ليحلّ مكان بروتوكولات الاتصال عن بعد غير الآمنة مثل rlogin، rsh وrexecالتي كانت ترسل البيانات دون احتياطات أمنية تُذكر. تعتمد حزمة برامج OpenSSH على التعمية بالمفاتيح العمومية لتعميّة الاتصالات بين مضيفين Hosts، وللاستيثاق من المستخدمين. كما يمكن استخدامها للولوج إلى خادوم بعيد أو لنسخ البيانات بين مضيفين مع الحماية من هجمات رجل في الوسط Man in the middle وهجمات أخرى. وحدات الاستيثاق سريعة التفعيل Pluggable Authentication Modules تأتي الإصدارات الحديثة من توزيعات لينكس محمّلة بآلية استيثاق موحدة تُسمّى Pluggable Authentication Modules, PAM تسمح للتطبيقات التي تعمل في فضاء المستخدم بتغيير متطلبات الاستيثاق الخاصّة بها وطريقته حسب الحاجة. يمكن باستخدام هذه الآلية من بين أمور أخرى: تحديد أمكنة وأوقات معيّنة لمستخدمين لا يمكنهم الولوج خارجها إلى النظام. تعيين سقف لاستخدام الموارد لكل مستخدِم. استعمال خوارزميات تعميّة أخرى غير DES لجعل فك التعمية بهجمات القوة العمياء أصعب. تفعيل كلمات السّر في ملف shadow حسب الحاجة. ملف Shadow لتأمين كلمات سر المستخدمين تستخدم الإصدارات الحديثة من توزيعات لينكس ملف etc/shadow/ لجعل كلمات سر المستخدم المعمّاة في مأمن من بقية المستخدمين على نفس النظام. كانت كلمات السر المعمّاة تخزّن في الإصدارات القديمة داخل ملف etc/passwd/ مبدئيا، ويمكن لجميع المستخدمين رؤيتها وبالتالي تنفيذ هجمات القوة العمياء عليها لمحاولة فك تعميتها. يعني اللجوء إلى ملف etc/shadow/ أن المستخدمين الإداريين فقط هم من يمكنهم رؤية كلمات السّر المعمّاة. التأكد من أمان كلمات مرور المستخدمين يحتاج مدير النظام أحيانا إلى التأكد من أن كلمات مرور المستخدمين جيّدة كفاية، لكي لا تكون بابا قد يؤدي فتحه إلى مشاكل أمنية أخرى، تُستخدم برامج مثل Jone the Ripper وCrack لهذا الغرض. تقوم فكرة هذه البرامج على توليد كلمات مرور معمّاة إما حسب نمط معرَّف مسبقا أو بالاعتماد على قاموس ألفاظ ثم مقارنتها بكلمات المرور المعمّاة الخاصّة بالمستخدمين، فإن وُجد تطابق عُرِفت كلمة السر. الجدير بالذكر أن مثل هذه البرامج تأخذ الكثير من الوقت وموارد الجهاز للعمل؛ وكلما كانت كلمات السّر معقدة كل ما كانت المهمة أصعب. في سيناريو هجمة حقيقية سيحتاج المخترق أولا إلى الحصول على ملف كلمات سر المستخدمين وهو أمر يحتاج لثغرات أمنية قد لا تكون موجودة؛ إلا أن الحيطة واجبة على الدوام. ترجمة - وبتصرّف - لمقال Encryption Methods in Linux لصاحبه M.el Khamlichi. حقوق الصورة البارزة: Designed by Freepik.

يوجد لدى كثيرين خلط بين مصطلحات متقاربة هي التعميّة Encryption، الترميز Encoding، التجزئة Hashing والتشويش Obfuscation. سيتناول هذا المقال ماهية كلّ واحد من هذه المصطلحات. الترميز يهدف الترميز إلى تحويل بياناتٍ ليصبح بإمكان أنظمة مختلفة التعامل معها بطريقة صحيحة وآمنة. على سبيل المثال: إرسال ملفات تنفيذية في بريد إلكتروني أو عرض محارف Characters خاصّة على صفحة ويب. ليس الغرض هنا إبقاءَ المعلومة سريّة بل التأكد من أن التعامل معها سيكون على النحو الأمثل. يحوّل الترميز البيانات من صيغة إلى أخرى بآلية متاحة للعموم ويمكن بالتالي عكسُ التحويل بسهولة. لا تحتاج البيانات بعد ترميزها لمفتاح سري حتى يمكن التعامل معها، إذ أن المطلوب الوحيد ليمكنَ فك الترميز هو الخوارزمية Algorithm المستخدمة فيه. أمثلة: ASCII ،Unicode، ترميز روابط URL و Base64. التعمية تُستخدَم التعميّة لتحويل صيغة البيانات بغرض إبقائها مجهولة للآخرين؛ مثلا عند إرسال رسالة إلى شخص لا تريد أن يتمكن غيره من قراءتها أو لإيصال كلمة مرور بسريّة على الإنترنت. تهدف التعمية، بدلا من التركيز على قابلية استخدام المعلومة، إلى التأكد من أنه لا يمكن لغير المصرّح لهم الاستفادة من البيانات. تحوّل التعميّة البيانات إلى صيغة أخرى لا يمكن سوى لأشخاص محدّدين فهمُها. يُستخدَم لتنفيذ التعمية مفتاح تعمية إضافة إلى خوارزمية والنص المراد تحويله. يتطلب نزعُ التعمية الحصولَ على النص المعمَّى، خوارزمية التعميّة والمفتاح السري (نفس مفتاح التعمية أو مفتاح سري آخر). أمثلة: AES ،Blowfish و RSA. التجزئة تعمل التجزئة على التأكد من سلامة البيانات Integrity، بمعنى إن حدث تعديل عليها فستستطيع معرفة ذلك. تأخذ عمليّة التجزئة مُدخَلا عشوائيا وتُنتِج سلسلة محارف ثابتة الطول لديها الخصائص التالية: نحصُل دائما على نفس النتيجة بتنفيذ العمليّة على نفس المُدخَل. لا يجوز أن تُنتج العملية نفس المُخرَج لمُدخلات متعدّدة. يجب ألا يكون بالإمكان استنتاج المُدخَل من المُخرَج. يؤدي أي تعديل على مُدخَل مّا إلى تغييرات كبيرة في نتيجة تطبيق العملية عليه. تُستخدَم التجزئة مع الاستيثاق Authentication للحصول على دليل قوي أن رسالة مّا لم يُعدَّل عليها. تتم العملية بأخذ مُدخَل معيَّن، تعميّته بمفتاح محدَّد، تجزئته بنفس المفتاح، ثم تعميّة المفتاح بالمفتاح العمومي Public key الخاص بالمرسَل إليه ثم توقيع التجزئة بالمفتاح السريّ الخاص بالمرسِل. يفتح المرسَل إليه الرسالة ثم يفكّ تعمية المفتاح المستخدَم لتعميّة الرسالة باستخدام مفتاحه السّري مما يمكّنه من الحصول على النص الأصلي للرسالة. يمكنها بعدها تجزئة الرسالة ومقارنة نتيجة التجزئة بالتجزئة الموقَّعة من المرسِل فإن حصل تطابق فهذا يعني أن الرسالة لم يُعدَّل عليها وأنها أرسلت من الشخص المُنتظَر. أمثلة: SHA-3 و MD5 (أصبح قديما) التشويش يهدف التشويش إلى جعل المعلومة أصعب فهما، لتصعُب مهاجمتها أو نسخها. من الاستخدامات الشائعة له تشويش الشفرة المصدرية لجعل تكرار منتَج معيَّن أصعب عند تطبيق الهندسة العكسية Reverse engineering عليه. من المهم ملاحظة أن التشويش ليس تحكما قويا مثل التعميّة بل مجرّد عرقلة. يمكن غالبا عكسُه، مثل ما يحدُث مع الترميز، بنفس الطريقة التي يتمّ بها. يقتصر التشويش في حالات أخرى على عمليات يدوية تأخذ الكثير من الوقت لإجرائها. يجب الانتباه أيضا إلى أنه يوجد حدّ للتشويش حسب المحتوى. عند تشويش شفرة برمجية مثلا فالحدّ هو أن نتيجة التشويش يجب أن تبقى في حدود ما يمكن للحاسوب التعامل معه وإلا فإن البرنامج سيتوقّف عن العمل. أمثلة: مشوِّش JavaScript و ProGuard. ملحوظة: ربما تتساءل متى يُستحسن استخدام التشويش بدلا من التعمية؛ والجواب هو أن التشويش يُستخدَم لجعل البيانات أصعب فهما على مستغِلّ محدَّد (شخص مّا) مع إبقائها في متناول مستغِلّ آخر (حاسوب). بالنسبة للتعميّة فيصعُب في جميع الأحوال الاستفادة من البيانات دون الحصول على المفتاح السّري. خلاصة يهدف الترميز إلى الإبقاء على قابلية استخدام البيانات، ويمكن عكسُه بنفس خوارزمية الترميز؛ أي أنه لا يحتاج لمفاتيح سرية. تُستخدَم التعمية للحفاظ على خصوصية البيانات وتتطلّب إزالةُ التعمية استخدامَ مفتاح سري. تُستخدَم التجزئة لغرض التحقق من سلامة البيانات باكتشاف وجود تعديلات تدلّ عليها مُخرجات التجزئة. يُستخدم التشويش لمنع الأشخاص من فهم معنى بيانات خصوصا شفرات برمجية للحد من إمكانية تطبيق الهندسة العكسية على برنامج أو سرقة وظائفه. ترجمة -وبتصرّف- لمقال Encoding vs. Encryption vs. Hashing vs. Obfuscation لصاحبه Daniel Miessler.

جمعنا في هذا المقال 10 أدوات تساعد مستخدمي لينكس في مهامّ متنوعة مثل مراقبة الشبكة، فحص النظام وأوامر أخرى للرفع من الإنتاجية. الأداة w يُظهر أمر w المستخدمين مسجلي الدخول إلى النظام والعمليات التي ينفذونها: w أضف الخيار h- للحصول على المساعدة: w -h nmon وهي أداة تعرض معلومات عن أداء النظام، يمكن تثبيتها على أوبنتو بالأمر: sudo apt-get install nmon ثم بعد التثبيت ننفذ الأمر: nmon يمكن للأداة تحصيل معلومات عن استخدام الشبكة، المعالج والذاكرة. اضغط على حرف c لمعلومات عن استخدام المعالج: وحرف n لمعلومات عن الشبكة: تعطي الأداة بالضغط على حرف d معلومات عن استخدام القرص الصلب: ncdu وهي أداة تُستعمَل لتحليل استخدام مساحة القرص الصلب. للتثبيت على أوبنتو نفذ الأمر: sudo apt-get install ncdu وللاستخدام: ncdu / تأخذ الأداة معطى يمثّل المجلد الذي نريد معرفة مساحته على القرص الصلب. في المثال أعلاه حدّدنا المجلّد الجذر. قد يأخذ تحليل القرص بعض الوقت حسب حجمه، ثم تظهر النتيجة: استخدم الأسهم للانتقال بين قائمة المجلدات، وزر Enter لاختيار مجلد، n لترتيبها حسب الاسم و s لترتيبها حسب الحجم (تُرتّب المجلدات مبدئيا حسب الحجم). slurm تُستخدَم هذه الأداة لمراقبة تدفق البيانات عبر الشبكة حيث تظهرها في شكل منحنيات بيانية. sudo apt-get install slurm استخدم الخيار i- لمراقبة واجهة شبكة محددة: slurm -i eth1 اضغط زر l و c للانتقال بين طريقتي العرض، r لتحديث الشاشة و q للخروج. findmnt يُُستخدَم أمر findmnt للعثور على نظم الملفات المركّبة Mounted. كما يُستخدَم لتركيب أو نزع تركيب أجهزة طرفية عند الحاجة. findmnt نستخدم خيار l- للعرض على هيئة لائحة. findmnt -l عرض نظم الملفات المركّبة في ملف fstab: findmnt -s يمكن أيضا البحث عن نظم الملفات حسب النوع: findmnt -t ext4 dstat هي أداة مجمَّعة لمراقبة استخدام الذاكرة، عمليات النظام وأداء القرص الصلب. تُعدّ dstat بديلا جيدا لكل من ifstat ،iostat و dmstat. للتثبيت: sudo apt-get install dstat نفذ أمر dstat للحصول على معلومات مفصّلة عن استخدام المعالج، القرص الصلب والشبكة. يتيح الخيار c- تركيز المعلومات المعروضة على المعالج: dstat -c كما يمكن استخدام الخيار l- مع c- لمعرفة متوسّط استخدام المعالج لدقيقة، 3 دقائق أو 15 دقيقة. يوجد خيار D-الذي يمكن من متابعة أداء تجزئة قرص صلب بدلا من كامل القرص (d- لعرض أداء القرص فقط دون بقية الإحصاءات): dstat -dD sda7 saidar أداة أخرى تعمل في سطر الأوامر لمراقبة إحصاءات النظام مثل استخدام القرص الصلب، الشبكة، الذاكرة، مساحة الإبدال Swap وغيرها. للتثبيت: sudo apt-get install saidar ثم ننفذ أمر saidar للحصول على إحصاءات عن مختلف موارد النظام. يمكن استخدام الخيار c- لتلوين المخرجات. saider -c ss تأتي ss (اختصار لـSocket statistics) بديلا لأداة netstat لتجميع معلومات من فضاء النواة Kernel، تتميّز بالسرعة مقارنة مع netstat. لعرض جميع الاتصالات (نستخدم less لتسهيل تصفح المخرجات، اضغط على زر المسافة للانتقال للشاشة الموالية): ss |less يمكن استخدام الخيار A- لحصر النتائج حسب النوع: ss -A tcp كما توجد إمكانية عرض أسماء ومعرّفات العمليات pid: ss -ltp ccze تتيح هذه الأداة عرض السجلات Logs بهيئة أكثر جاذبية، للتثبيت نفذ الأمر: sudo apt-get install ccze مثال على الاستخدام: tailf /var/log/syslog | ccze تمكّن الأداة أيضا من حفظ السجلات بنفس طريقة العرض في ملف HTML: tailf /var/log/syslog | ccze -h > /path_to_file.html يعرض الأمر عند استخدام الخيار l- وحدات الأداة (أنواع السجلات التي تتعامل معها). ranwhen.py وهو سكربت python يعمل في الطرفية لعرض نشاطات النظام بيانيا، ينشئ السكربت منحنيات بيانية ملوّنة لعرض تفاصيل الأنشطة. للتثبيت على أوبنتو أضف المستودع التالي: sudo apt-add-repository ppa:fkrull/deadsnakes ثم حدّث النظام: sudo apt-get update وثبّت الإصدار 3.2 من python: sudo apt-get install python3.2 نزّل السكربت: wget -c https://github.com/p-e-w/ranwhen/archive/master.zip ثم فك ضغطه: unzip master.zip && cd ranwhen-master بإمكاننا الآن تنفيذ الأداة: python3.2 ranwhen.py ترجمة - وبتصرّف - لمقال Ten 10 Useful Utilities For Linux Users لصاحبه Rajneesh Upadhyay.

لم تعد الكثير من التطبيقات التي تعمل على الأجهزة المحمولة، مع تقدم تقنيات مثل التخزين المحلّي Local storage على المتصفحات، تحتاج إلى الاستخدام الكثيف لقواعد البيانات؛ مع بقاء الحاجة للاتصال بخادوم بعيد يخزّن ويحدّث بيانات ضرورية مثل معلومات المستخدم، نتائج مسابقة أو غيرها من البيانات التي لا يمكن تخزينها على العميل. تأتي منصات خدمات النهاية الخلفية للأجهزة المحمولة Mobile Backend as a Service لحل هذا الإشكال: تخزين بيانات على الخادوم لتوفيرها للأجهزة العميلة بأقل تكلفة. Parse التي تمتلكها فيس بوك هي إحدى هذه المنصات. أعلنت فيس بوك في شهر يناير 2016 عن إغلاق المنصة مع فتح مصدر النهاية الخلفية ونشرها باسم Parse server ليستمر تطويرها ويمكن تثبيتها في أي بيئة تشغّل Node.js و MongoDB دون الاعتماد على منصة الشركة؛ على أن تتوقف المنصة التابعة للشركة في شهر يناير 2017. يقدّم هذا الدليل تفاصيل تثبيت Parse server على خادوم أوبنتو 14.04؛ ويتوجّه ليكون مدخلا لتهجير التطبيقات من Parse أو لاستخدام النهاية الخلفية التي يوفرها في تطبيقات جديدة. المتطلبات سنفترض أن لديك خادوم أوبنتو 14.04 وحساب مستخدم بصلاحيات إدارية، غير المستخدم الجذر root. تمكن مراجعة درس الإعداد الابتدائي لخادوم أوبنتو 14.04 لإعدادات نظام التشغيل. يتطلّب الدرس كذلك تثبيت MongoDB. تأكد من إعداد المتطلبات ثم عد لهذا الدليل واتّبع الخطوات التالية. الخطوة الأولى: تثبيت Node.js وأدوات التطوير ابدأ بالانتقال إلى مجلد المستخدم الشخصي: cd ~ سنستخدم مستودع Apt الذي توفره NodeSource عن طريق سكربت تثبيت النسخة المستقرة الأخيرة من Node.js (الإصدار 5.5.0 أثناء كتابة هذا الدليل). نزّل السكربت بالأمر التالي: curl -sL https://deb.nodesource.com/setup_5.x -o nodesource_setup.sh يمكنك، إن أردت، رؤية محتوى السكربت باستخدام nanoأو أي محرّر نصوص آخر: nano ./nodesource_setup.sh نفذ السكربت بصلاحيات إدارية مع استخدام خيار E- لإخبار sudo بالحفاظ على متغيرات النظام Environment variables الخاصّة بالمستخدم: sudo -E bash ./nodesource_setup.sh تُضاف مستودعات NodeSource إلى النظام بعد انتهاء السكربت، ويمكننا بالتالي استخدام apt-get لتثبيت حزمة nodejs. سنثبت حزمة التعريف build-essential التي تتيح مجموعة من أدوات التطوير التي يمكن أن تكون مفيدة لنا في ما بعد، إضافة إلى نظام التحكّم في النسخ Git لنستخدمه في تنزيل المشروعات من GitHub: sudo apt-get install -y nodejs build-essential git الخطوة الثانية: تثبيت تطبيق Parse Server تجريبي صُمّم Parse Server للعمل بالتزامن مع Express، وهو إطار عمل Node.js شائع الاستخدام لتطبيقات الويب، يسمح بتركيب عناصر البرمجيات الوسيطة Middleware المستجيبة لتعريف واجهة تطبيقات برمجية API على مسار محدَّد. يحوي مستودع parse-server-example على GitHub مثالا لتطبيق يتبع هذا النمط في تصميم البرامج. انسخ المستودع باستخدام git على النحو التالي: git clone https://github.com/ParsePlatform/parse-server-example.git ادخل إلى مجلد parse-server-example الذي نسخته للتو: cd ~/parse-server-example ثم استخدم npm لتثبيت الاعتماديات بما فيها parse-server في المجلد الحالي: npm install سيعثُر npm على جميع الوحدات Modules المطلوبة لـ parse-server ثم يخزّنها على المسار parse-server-example/node_modules/~. الخطوة الثالثة: اختبار التطبيق التجريبي استخدم أمر npm لبدء تشغيل الخدمة. يُنفَّذ الأمر المعرَّف في خاصية start من ملف package.json؛ أي في هذه الحالة node index.js: npm start مخرجات الأمر: > parse-server-example@1.0.0 start /home/sammy/parse-server-example > node index.js DATABASE_URI not specified, falling back to localhost. parse-server-example running on port 1337. يمكن إنهاء تشغيل التطبيق في أي وقت بالضغط على الزرين Ctrl وC. يمرّر تطبيق Express المعرَّف في index.js طلبات HTTP إلى وحدة parse-server التي تتواصل مع قاعدة بيانات MongoDB وتطلُب تنفيذ الدوال المعرَّفة في الملف parse-server-example/cloud/main.js/~. نقطة النهاية Endpoint المبدئية لواجهة تطبيقات Parse Server في هذا المثال هي: http://your_server_IP/parse يمكن استخدام أمر curl في سطر أوامر آخر، أثناء عمل التطبيق، لتجربة نقطة النهاية. تأكد أولا من تسجيل دخولك إلى الخادوم إذ أن هذه الأوامر تستدعي المضيف المحلّي localhost بدلا من عنوان IP آخر. أنشئ تسجيلة Record بإرسال طلب POST مع ترويسة X-Parse-Application-Id لتحديد التطبيق، إضافة لبيانات أخرى بصيغة JSON: curl -X POST \ -H "X-Parse-Application-Id: myAppId" \ -H "Content-Type: application/json" \ -d '{"score":1337,"playerName":"Sammy","cheatMode":false}' \ http://localhost:1337/parse/classes/GameScore مخرجات الأمر: {"objectId":"fu7t4oWLuW","createdAt":"2016-02-02T18:43:00.659Z"} تُخزَّن البيانات المرسَلة في قاعدة بيانات MongoDB ويمكن إيجادها بإرسال طلب GET باستخدام curl مرة أخرى: curl -H "X-Parse-Application-Id: myAppId" http://localhost:1337/parse/classes/GameScore مخرجات الأمر: {"results":[{"objectId":"GWuEydYCcd","score":1337,"playerName":"Sammy","cheatMode":false,"updatedAt":"2016-02-02T04:04:29.497Z","createdAt":"2016-02-02T04:04:29.497Z"}]} استدع الدالة hello المعرَّفة في الملف parse-server-example/cloud/main.js/~ باستخدام واجهة التطبيقات البرمجية: curl -X POST \ -H "X-Parse-Application-Id: myAppId" \ -H "Content-Type: application/json" \ -d '{}' \ http://localhost:1337/parse/functions/hello مخرجات الأمر: {"result":"Hi"} الخطوة الرابعة: إعدادات التطبيق التجريبي اضغط على Ctrl وC في نافذة سطر الأوامر الأولى لإيقاف تطبيق Parse Server. يمكن إعداد التطبيق باستخدام ستة متغيرات نظام يبينها الجدول التالي. المتغير الوصف DATABASE_URI مسار الاتصال بقاعدة بيانات MongoDB، مثلاmongodb://localhost:27017/dev CLOUD_CODE_MAIN مسار إلى ملف يحوي الشفرة المصدرية لدوال Cloud Code الخاصّة بـParse APP_ID سلسلة محارف لتعريف التطبيق، مثلا myAppId. MASTER_KEY مفتاح سري رئيس يمكّن من تجاوز جميع آليات الأمان في التطبيق. PARSE_MOUNT المسار الذي توجد عليه واجهة تطبيقات Parse Server PORT المنفذ الذي ينصت عليه التطبيق، مثلا 1337 ننفذ أمر export قبل تشغيل التطبيق لإعداد متغيرات النظام، مثلا: export APP_ID=fooApp يمكننا إنشاء نسخة أسهل من التطبيق لأخذ صورة عن آلية العمل. أنشئ ملف سكربت جديدا: nano my_app.js ثم ألصق الشفرة التالية مع تغيير القيم بما يناسب: var express = require('express'); var ParseServer = require('parse-server').ParseServer; // إعداد واجهة التطبيقات البرمجية var api = new ParseServer({ databaseURI: 'mongodb://localhost:27017/dev', cloud: __dirname + '/cloud/main.js', appId: 'myOtherAppId', masterKey: 'myMasterKey' }); var app = express(); // ضبط مسار التطبيق app.use('/myparseapp', api); // الإنصات للاتصالات القادمة على المنفذ 9999 var port = 9999; app.listen(port, function() { console.log('parse-server-example running on port ' + port + '.'); }); احفظ الملف ثم نفذ الأمر التالي بعد إغلاقه: node my_app.js مخرجات الأمر: parse-server-example running on port 9999. يمكنك في أي وقت إيقاف التطبيق بالضغط على Ctrl وC. يعمل my_app.js بنفس الطريقة التي يعمل بها index.js تقريبا، مع فرق أنه ينصت على المنفذ 9999 مع تركيب Parse Server على المسار myparseapp/ بحيث يصبح مسار نقطة النهاية كما يلي: http://yourserverIP:9999/myparseapp يمكن تجربتها بـاستخدام curl على النحو التالي: curl -H "X-Parse-Application-Id: myOtherAppId" http://localhost:9999/myparseapp/classes/GameScore خاتمة قدّمنا في هذا الدرس أساسيات تشغيل تطبيق Node.js مثل Parse Server على أوبنتو. يتطلّب تهجير تطبيق من Parse حذرا أكبر وربما تعديلات على الشفرة البرمجية ويجب أن يُستعدّ له جيدا من ناحية تهيئة البنية التحتية. ترجمة -وبتصرّف- للمقال How To Run Parse Server on Ubuntu 14.04 لصاحبه Brennen Bearnes.

يحتاج لينكس، مثل غيره من أنظمة التشغيل متعدّدة المستخدمين Multi-user system إلى طريقة للتحكّم في وصول المستخدمين إلى مختلف الملفات. ليس من المحبّذ مثلا أن يعدّل مستخدم آخر على ملفات الإعداد التي أخذ ضبطها كثيرا من وقتك. يُطبَّق مبدأُ الفصلِ هذا على نظام تشغيل لينكس بآلية الأذونات Permissions. كيف تعمل الأذونات يُخزَّن كلّ ملف على النظام بأذوناته الخاصّة. كيف تُمثَّل؟ من الراجح أنك صادفتها أثناء عملك على نظام لينكس: drwxr-xr-x -r-w-rwrw- -rwxr--r-- تظهر الأذونات عند تنفيذ أوامر مثل ls -l. تخبر سلسلة المحارف Charcters بمعلومات الملف؛ يمكن تقسيم سلسلة المحارف الخاصّة بمعلومات الملف إلى أربعة أقسام: القسم الأول: هو المِحرف الأول الذي يدلّ على نوع الملفّ. القسم الثاني: يحوي المحارف من 2 إلى 4؛ وهي أذونات المستخدِم مالك الملف؛ أي ما يحقّ لهذا المستخدم فعله على الملف. القسم الثالث: المحارف من 5 إلى 7؛ وهي أذونات المجموعة مالكة الملف. القسم الرابع: المحارف من 8 إلى 10؛ وهي أذونات بقية المستخدمين (ليسوا مالك الملف ولا ينتمون للمجموعة مالكة الملف). يمكن للمحرف الأول أن يكون أحد المحارف التالية: - للملفات العادية. d: للمجلّدات. l: للوصلات الرمزية Symbolic link. s: لمقابس Socket يونكس. p: لأنابيب الاتّصال. c: للأجهزة الطرفيّة المحرفيّة Character device file. b: للأجهزة الطرفيّة الكتليّة Block device file. توضّح المحارف التسعة التالية لنوع الملف الأذونات في ثلاثة أقسام من ثلاثة محارف (القسم الثاني، الثالث والرابع المذكورة أعلاه): تعرض المحارف الثلاثة الأولى أذونات القراءة، الكتابة والتنفيذ بالنسبة لمالك الملف. تعرض المحارف الثلاثة الموالية نفس الأذونات ولكن بالنسبة للمجموعة مالكة الملف؛ والمحارف الثلاثة الأخيرة الأذونات بالنسبة لبقية المستخدمين. يعني المحرف الأول من كل قسم من إذن القراءة (r)، المحرف الثاني إذن الكتابة (w) والمحرف الثالث إذن التنفيذ (x). يدلّ ذكر المحرف (w، r وx) على وجود الإذن أما غياب الإذن فيُشار إليه بعارضة -. يعني وجود عارضة مكان إذن القراءة (أو الكتابة أو التنفيذ) أن المعني (المالك، المجموعة أو الآخرين) ليس لديه هذا الإذن. بالعودة إلى المثال: drwxr-xr-x يعني هذا السطر أننا أمام مجلّد (المحرف الأول d)، لدى مالك الملف (المحارف من 2 إلى 4) جميع الأذونات (rwx)، لدى المجموعة المالكة (المحارف من 5 إلى 7) إذنا القراءة والتنفيذ ولكن ليس لديها إذن الكتابة (r-x)، ونفس الشيء بالنسبة لبقية المستخدمين. تعديل الأذونات يُستخدَم أمر chmod لتعديل الأذونات. توجد طريقتان لذلك: الأولى باستخدام الأحرف المذكورة أعلاه (w، r وx)، والثانية باستخدام أرقام. سنشرح الطريقة الأخيرة هنا لأنها أسرع كثيرا. chmod 775 ~/my/file نلقي نظرة على القائمة التالية لفهم معنى الأرقام: 4 = r 2 = w 1 = w = إذن غير موجود نجمع الأرقام للحصول على الأذونات. بالنسبة لإذن rwx فيجب أن يكون 4+2+1=7؛ إذن r-x يجب أن يكون 4+0+1=5 وهكذا. بما أن لدينا ثلاثة أقسام من الأذونات (المستخدِم المالك، المجموعة المالكة وبقية المستخدمين) فسنحتاج إلى ثلاثة أرقام، رقم لكلّ قسم. أي أننا نجمع الأرقام المقابلة لأذونات كل قسم ونضعها جنبا إلى جنب في عدد من ثلاثة أرقام: الرّقم على اليسار لأذونات المستخدم المالك، الرقم في الوسط للمجموعة المالكة والرقم على اليمين لبقية المستخدمين. نعرف، بتنفيذ المبدأ أعلاه ، أن الأمر السابق يعدّل أذونات الملف /my/file/~ لتصبح كالتالي (طبقنا الأمر على ملف عادي، وبالتالي تظهر - في معلومات الملف تليها الأذونات): -rwxrwxr-x تعديل ملكية ملف يوجد أمران لتعديل ملكية الملف، الأول وهو chown يغيّر المستخدم المالك والثاني chgrp ويغيّر المجموعة المالكة. تغيير المستخدم المالك (المالك الجديد للملف /my/file/~ هو user): chown user ~/my/file تغيير المجموعة المالكة (المجموعة الجديدة هي group): chgrp group ~/my/file إن لم تكن مالكَ الملف أو تنفذ الأمرين أعلاه بصلاحيات المستخدم الأعلى root فلن ينجح تنفيذ الأمر. ترجمة -وبتصرّف- للمقال Linux File Permissions Explained لصاحبه Radek Pazdera.

تعدّ توزيعتا دبيان وأوبنتو من أكثر توزيعات لينكس تأثيرا، فمن بين حوالي 285 توزيعة نشطة، تُشتقّ 132 من دبيان بما فيها أوبنتو نفسها، إضافة إلى 67 أخرى مشتقة مباشرة من أوبنتو. على الرغم من ذلك تختلف تجربة استخدام الاثنتين في جميع الجوانب تقريبا؛ الأمر الذي يجعل الاختيار، الذي يجب أن يُبنى على التفضيلات في نواح أساسية مثل الدّعم، مستوى تحكّم المستخدِم، سهولة الاستخدام؛ أمرا غير يسير بتاتا. يميل الكثيرون عند وصف الاختلاف بين التوزيعتين إلى أن أوبنتو "توزيعة للمبتدئين"، بينما دبيان هي "خيار الخبراء". رغم أن هذا التوصيف صحيح جزئيا إلا أنه يميل في نفس الوقت إلى المبالغة. لم تتغيّر النظرة إلى دبيان كثيرا في السنوات العشر الأخيرة رغم أنها أصبحت تتيح تسهيلات أكثر للمستخدم الذي يرغب في ذلك. على نحو مشابه؛ يظهر أن استخدام أوبنتو سهل جدا إذا نظرنا للأمر من ناحية مبادئ التصميم إلا أن العادات قد تجعل المستخدِم يختلف في هذا التوصيف. تظهر الفروقات بين التوزيعتين جليةً رغم التشابه؛ بدءًا من التثبيت وسطح المكتب، إلى إدارة الحزم Packages والمجتمع Community، وهي أمور تجعل اختيار المناسب لخطّة عمل مؤسستك غير بديهي. الاختلافات في التثبيت يعتمد اختيار التوزيعة بدرجة مهمّة على نوعية العتاد Hardware لديك. تعمل دبيان حاليا على 13 معمارية عتاد تشمل معماريات 32bit و 64bit المعيارية من Intel، معمارية ARM و PowerPC. بينما تدعم أوبنتو رسميا معماريتي 32bit و 64bit، وتعمل على تطوير دعم معماريات ARM. يجب أيضا أخذ مثبّت Installer كل توزيعة في الحسبان. صُمِّم مثبِّت أوبنتو لكي لا يحتاج إلا إلى الحد الأدنى من المُدخلات من المستخدِم من أجل تسهيل التثبيت وجعله أسرع ما يمكن. يمكنك إن واجهت صعوبة تجربة وضع الخبير في المثبِّت والذي هو في الأساس إعادة تصميم لمثبّت دبيان. مثبِّت دبيان لديه، على الجانب الآخر، أولوياته الخاصة. مثلا، لا يختلف المثبّت الرسومي عن المثبّت على سطر الأوامر سوى في الواجهة. يمكن، على عكس الشائع عن دبيان، تثبيت التوزيعة بسهولة بقبول الخيارات المبدئية في كل مرحلة من مراحل التثبيت. أما إذا كنت تفضّل التخصيص فيمكنك الاختيار من بين الاختيارات المتاحة في كلّ خطوة، مما يزيد بدرجة ملحوظة مدّة التثبيت. يختار مثبِّت دبيان مخاطبة جميع مستويات المستخدمين بدلا من التوجّه إلى المبتدئين. لن تجد، على الأرجح، مثبّتا على نفس المستوى من المرونة. الفروق في إدارة النظام والحزم تنقسم المستودعات في دبيان إلى ثلاثة أساسية: المستودع المستقر Stable، المستودع الاختباري Testing والمستودع غير المستقر Unstable. يمثّل المستودع المستقرّ الإصدار المنصوح به من حزم البرمجيات لبيئات الإنتاج نظرًا لمرورها بالكثير من الاختبارات لتأكيد صلاحيتها، أما المستودع الاختباري فهو نسخة تخضع للاختبار وتتهيأ للمرور إلى المستوى الأعلى (المستودع المستقر)، في حين لا تزال النسخة في المستودع غير المستقر في مرحلة التطوير. أضيفت في السنوات الأخيرة مستودعات أخرى (رسمية وغير رسمية) مثل الحمل العكسي Backports، التجريبي Experimental، الأمان Security وغيرها. إلا أن تلك التي يجب على المستخدمين الانتباه إليها هي الثلاثة الأساسية. يختار مستخدمو دبيان بين الاستقرار منقطع النظير على حساب حداثة الحزم من جهة، والجدّة على حساب استقرار الحزم وتغييرات قد تكون كارثية وتشلّ النظام من جهة أخرى. يختلف تأثير خيار المستودعات أكثر على نوعية الحزم، هل هي حزم أساسية للنظام مثل النواة أو أخرى أقل أهمية مثل أدوات مساعِدة. يمكن مثلا اختيار مستودعات مستقرة للحزم الأساسية ومستودعات اختبارية لأدوات غير أساسية. تأخذ أوبنتو حزمها من مستودعات دبيان الاختبارية أو غير المستقرة وبدلا من تنظيمها حسب مستوى الاستقرار ترتّبها في أربع مستودعات أساسية: Main وتوجد به البرامج المدعومة من Canonical، مستودع Universe وتوجد به برامج حرّة يشرف عليها المجتمع، Restricted ويحوي برامج غير حرّة مُصنَّفة على أنها مهمّة و Multiverse الذي توجد به برامج غير حرة لا تدخل ضمن برامج المستودع السابق. تُضاف بضعة مستودعات أخرى، إلا أن هذه الأربعة هي الأساسية. يوجد فرق مهمّ آخر بين دبيان وأوبنتو وهو في طريقة التعامل مع البرامج غير الحرة؛ فدبيان لا تثبّت مبدئيا سوى الحزم الحرّة ونفس المبدأ يطبّقه المثبِّت الخاصّ بها والذي لا يثبّت الوِحدات غير الحرة في النواة. إنْ احتجت إلى برامج غير حرة فسيلزمك إضافة مقاطع Nonfree و Contrib لكلّ مستودع. لا تظهر التفرقة بين البرامج الحرّة وغير الحرّة بنفس الوضوح في أوبنتو. فرغم أن دبيان تتيح استخدام برامج غير حرّة إلا أنها لا تشجّع على ذلك وتجعلك تدرك أنّ استخدام هذه البرامج مخالف للمبادئ التي تشجّعها دبيان؛ في حين تشجّع أوبنتو على استخدام برامج غير حرّة من أجل توفير تجربة استخدام مشابهة لأنظمة التشغيل التجارية. من فروق إدارة النظام التي يجدر ذكرها هو أن أوبنتو تعطّل مبدئيا إمكانية الدخول المباشر إلى حساب المستخدِم الجذر، مشجّعةً استخدام sudo ما أمكن لتنفيذ المهامّ الإدارية. الفروق في بيئة سطح المكتب تختلف التوزيعتان في بيئة سطح المكتب المبدئيّة لكلّ منهما. تستخدم أوبنتو بيئة يونيتي Unity من تطوير شركة Canonical التي تقف خلف التوزيعة. إن نجحت Canonical في تسويق جوالاتها وأجهزتها اللوحية فسيمكنك في المستقبل الحصول على بيئة سطح المكتب نفسها على جميع أجهزتك (حاسوب، هاتف، حاسوب لوحيّ). تدعم كلّ من دبيان وأوبنتو أكثر من بيئة سطح مكتب. تقدّم أوبنتو أسطح مكتب في ما يشبه توزيعات مستقلة: على سبيل المثال Xubuntu لبيئة سطح المكتب Xfce و Kubuntu لبيئة سطح المكتب KDE. تشبه أسطُح المكتب المتوفّرة في دبيان تلك الموجودة في أوبنتو؛ إلا أن فِرَق التطوير التي تعدّها أقرب إلى توزيعة دبيان المعيارية. تختلف تواريخ إصدارات سطح المكتب لدبيان، فقد تتأخر بعضها قليلا بعد وقت الإصدار الرسمي لدبيان حتى تكون جاهزة (نفس الشيء يحدُث مع أوبنتو). تتوفّر أغلب حزم أوبنتو باستثناء Unity لدبيان؛ كما أن حزم دبيان تتوفّر غالبا لأوبنتو إذ أن الأخيرة تعتمد على حزم من مستودعات دبيان. تكون حزم أوبنتو عادةً أحدث من نظيراتها في دبيان التي تمر بدورة اختبار وتنقيح أطول مما يجعل حزم دبيان أكثر استقرارا. تحذير: لا تفترض أن الأصل المشترك بين الحزم يجعلها متوافقة بين التوزيعتين. يُقدَّر أن حوالي 20 بالمائة من حزم أوبنتو غير متوافقة مع دبيان للاختلافات في التسمية وأماكن الملفات. الفروق في مجتمع التوزيعة يمكن لمجتمعَيْ التوزيعتين أن يكونا معيارا ضمن معايير الاختيار. يشتهر مجتمع دبيان بمناقشته لكلّ قرار بالتفصيل. خصوصا في المسائل ذات الأهمية. تتحوّل النقاشات أحيانا عن مسارها وتصبح أقرب للشحناء. يصوّت جميع مطوّري الحزم الرسميين لاختيار قائد لمشروع دبيان، ومسؤولين آخرين. تسير الأمور على العموم حسب اقتراحات أعضاء المجتمع وإن كان للمسؤولسن المنتخبين سلطة لحدٍّ ما. يختلف مجتمع أوبنتو عن مجتمع دبيان في أن لديه مدونة سلوك Code of Conduct تحكُم التفاعلات في المجتمع. يقود Jono Bacon مجتمع أوبنتو لحدّ الساعة ويبذل مجهودا في حلّ النزاعات بين الأعضاء. يُضاف إلى ذلك مجلس إداري فني للمجتمع يُنتخب سنويا. رغم ذلك يبقى Mark Shuttleworth مؤسّس أوبنتو صاحب القرار الأخير. يملك المؤسس وممثلو Canonical السلطة في تقرير مستقبل التوزيعة وتنتُج عن قراراتهم أحيانا انتفاضات في أوساط المساهمين فيها. خاتمة توجد الكثير من المعايير لأخذها في الحسبان عند الاختيار بين دبيان وأوبنتو: مستخدم مبتدئ أم خبير؟ برنامج حرّ أم خاص؟ سهولة الاستخدام أم التحكم؟ برامج محدَّثة في مقابل برامج مستقرّة، مجتمع مفتوح أو مغلق؟ كلها أمور يجب أن تُراعى وتُدرَس قبل أن تأخذ قرارا قد يؤثّر على مستقبل مؤسستك. ربّما تجد من بين تلك المعايير ما لا يمثّل قيمة كبيرة لك، على عكس أخرى توليها أهمية شديدة. الأساسي أن تحدّد أولوياتك. ترجمة -وبتصرّف- لمقال How Ubuntu is different from Debian لصاحبه M.el Khamlichi.

توجد طريقتان أساسيتان في 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.

يتناول هذا المقال كيفية تثبيت الإصدار 1.3 من برنامج Graylog (يُشار إليه أحيانا بـ Graylog2) وإعداده لتجميع سجلات نظام التشغيل Syslog في موضِع مركزي. Graylog هو أداة فعّالة لإدارة السجلات وتحليلها تُستخدم في حالات كثيرة من مراقبة Monitoring الدخول عبر SSH والأنشطة غير المعتادة إلى تنقيح Debugging التطبيقات. تعتمد الأداة على Elasticsearch، جافا وقاعدة بيانات MongoDB. يمكن استخدام Graylog لتجميع أنواع مختلفة من السجلات ومراقبتها، إلا أننا سنقتصر في هذا الدرس على تجميع سجلات النظام. مكونات Graylog توجد أربعة عناصر أساسية في Graylog: عُقد خادوم Graylog: تشتغل عاملا لاستقبال الرسائل ومعالجتها، كما أنها تتواصل مع بقية العناصر (غير عقد الخادوم). يعتمد أداء هذه العقد على قدرات معالج Processor الخادوم المضيف. عُقد Elasticsearch: تخزّن الرسائل والسجلات. يعتمد أداءها على الذاكرة الحية RAM وقدرة الأقراص على الإدخال/الإخراج. قاعدة بيانات MongoDB: تخزّن البيانات الوصفية Metadata؛ لا تُستحث كثيرا. واجهة المستخدم (صفحات ويب). إعداد Graylog القاعدي سننفذ في هذا الدرس إعدادا قاعديا لـGraylog توجد جميع العناصر فيه على نفس الخادوم. يُستحسن في بيئات الإنتاج الكبيرة أن يُضبط كل مكوِّن على خادوم منفصل لتحسين الأداء. المتطلبات ستحتاج من أجل تنفيذ الخطوات المشروحة في هذا الدرس إلى حساب إداري على خادوم أوبنتو 14.04 ذي ذاكرة عشوائية لا تقلّ عن 2GB. طريقة إعداد الحساب مشروحة في درس الإعداد الابتدائي لخادوم أوبنتو 14.04. إن كانت ذاكرة الوصول العشوائي لديك أقل من 2GB فلن تستطيع تشغيل جميع مكونات Graylog. نبدأ بتثبيت MongoDB. تثبيت MongoDB تثبيت MongoDB سهل وسريع. نفّذ الأمر التالي لاستيراد مفتاح GPG الخاص بـ MongoDB إلى apt: sudo apt-key adv --keyserver keyserver.ubuntu.com --recv 7F0CEB10 ثم أنشئ قائمة مصادر MongoDB بتنفيذ الأمر: echo "deb http://repo.mongodb.org/apt/ubuntu trusty/mongodb-org/3.0 multiverse" | sudo tee /etc/apt/sources.list.d/mongodb-org-3.0.list حدّث أرشيف الحزم: sudo apt-get update ثم نثبّت الإصدار المستقر Stable من MongoDB بتنفيذ الأمر: sudo apt-get install mongodb-org يجب أن تكون قاعدة بيانات MongoDB الآن جاهزة وتعمل على الخادوم. يمكنك التأكد من ذلك بتنفيذ الأمر: sudo service mongod status لتشغيل قاعدة البيانات (إن لم تشتغل لسبب ما): sudo service mongod start تثبيت Java يحتاج Elasticsearch لجافا حتى يعمل، لذا سنثبته. ينصح Elasticsearch بتثبيت Oracle Java 8، وهو ما سنفعله (على الرغم من ذلك، إلا أن Elasticsearch ينبغي أن يعمل دون مشاكل مع OpenJDK). أضف مستودع PPA الخاص بـ ـOracle Java إلى apt: sudo add-apt-repository ppa:webupd8team/java ثم حدّث قاعدة بيانات الحزم: sudo apt-get update نفذ أمر تثبيت Oracle Java 8 التالي (واقبل شروط الرخصة في النافذة المنبثقة): sudo apt-get install oracle-java8-installer بعد اكتمال تثبيت جافا يأتي دور Elasticsearch. تثبيت Elasticsearch نحتاج لإصدار من Elasticsearch سابق للإصدار 2.0 ليعمل معه Graylog، لذا سنثبّت الإصدار 1.7 من Elasticsearch. نستورد مفتاح GPG العمومي الخاص بـ ـElasticsearch إلى apt كما يلي: wget -qO - https://packages.elastic.co/GPG-KEY-elasticsearch | sudo apt-key add - قد تحتاج لإدخال كلمة السر الخاصة بالمستخدم الجذر. ثم أنشئ قائمة مورد لـ Elasticsearch: echo "deb http://packages.elastic.co/elasticsearch/1.7/debian stable main" | sudo tee -a /etc/apt/sources.list.d/elasticsearch-1.7.x.list نحدّث بيانات الحزم: sudo apt-get update ثم نثبت Elasticsearch: sudo apt-get -y install elasticsearch الخطوة الموالية هي إعداد Elasticsearch؛ افتح ملف التعديل: sudo vi /etc/elasticsearch/elasticsearch.yml ابحث عن فقرة cluster.name ثم انزع عنها علامة التعليق # وأبدل القيمة المبدئية بـ graylog-development (الاسم الذي اخترناه للعنقود Cluster. لا يمكن أن يكون لعنقودين في نفس الشبكة نفس الاسم): cluster.name: graylog-development يستعمل Elasticsearch المنفذ Port رقم 9200. سنمنع المتصلين من خارج الشبكة المحلية من الوصول إليه. اعثر على السطر الذي يحدّد المضيف على الشبكة network.host، أزل علامة التعليق وضع مكانها localhost (المضيف المحلي) كالتالي: network.host: localhost احفظ ملف elasticsearch.yml ثم أغلقه. أعد تشغيل Elasticsearch: sudo service elasticsearch restart نفذ الأمر التالي لتشغيل Elasticsearch مع بدء تشغيل النظام: sudo update-rc.d elasticsearch defaults 95 10 انتظر بضع لحظات ثم نفذ الأمر التالي للتأكد من أن Elasticsearch يعمل كما يرام: curl -XGET 'http://localhost:9200/_cluster/health?pretty=true' تظهر نتيجة الأمر كالتالي: { "cluster_name" : "graylog-development", "status" : "green", "timed_out" : false, "number_of_nodes" : 1, "number_of_data_nodes" : 1, "active_primary_shards" : 1, "active_shards" : 1, "relocating_shards" : 0, "initializing_shards" : 0, "unassigned_shards" : 0, "delayed_unassigned_shards" : 0, "number_of_pending_tasks" : 0, "number_of_in_flight_fetch" : 0 } تثبيت خادوم Graylog يمكننا الآن بعد تجهيز المتطلبات تثبيتُ برنامج Graylog. نبدأ بتثبيت خادوم Graylog. ننزل حزمة مستودع Graylog في المجلد الشخصي للمستخدم: cd ~ wget https://packages.graylog2.org/repo/packages/graylog-1.3-repository-ubuntu14.04_latest.deb ونثبتها: sudo dpkg -i graylog-1.3-repository-ubuntu14.04_latest.deb تضيف هذه الحزمة عند تثبيتها مستودع Graylog إلى قائمة المستودعات لدى النظام. قبل تثبيت حزمة خادوم Graylog نتأكد من أن apt-transport-https التي تمكّن من تنزيل حزم apt باتصال آمن مثبتة: sudo apt-get update sudo apt-get install apt-transport-https sudo apt-get install graylog-server سنستخدم حزمة pwgen لتوليد مفاتيح سرية لذا سنثبتها: sudo apt-get install pwgen سنحتاج لضبط كلمة سر مدير خادوم Graylog ومفتاحه الخاص. يُضبط المفتاح الخاص في ملف server.conf بتحديد قيمة معطى password_secret. يمكن توليد مفتاح عشوائي وإدراجه في إعداد Graylog عبر الأمرين التاليين: SECRET=$(pwgen -s 96 1) sudo -E sed -i -e 's/password_secret =.*/password_secret = '$SECRET'/' /etc/graylog/server/server.conf تُعيَّن كلمة سر المدير بإنشاء مجموع تحقق Checksum لكلمة السر المرغوبة ثم تحديد قيمة المعطى root_password_sha2 في ملف إعداد Graylog بمجموع التحقق المُنشأ. أنشئ مجموع التحقق الخاص بكلمة السر بتنفيذ الأمر أدناه مع إبدال password بكلمة السر التي ترغب فيها. يدرج أمر sed في السطر الثاني مجموع التحقق في ملف إعداد Graylog (يمكنك تنفيذ أمر shasum ثم إدراج النتيجة يدويا في الملف server.conf): PASSWORD=$(echo -n password | shasum -a 256 | awk '{print $1}') sudo -E sed -i -e 's/root_password_sha2 =.*/root_password_sha2 = '$PASSWORD'/' /etc/graylog/server/server.conf نفتح ملف server.conf لتحريره: sudo vi /etc/graylog/server/server.conf ستجد أن قيمتي المعطيين password_secret وroot_password_sha2 عبارة عن سلسلة محارف Strings عشوائية هي ناتج الأوامر أعلاه. نعيد تعيين قيمة المعطى rest_transport_uri التي هي وسيلة اتصال واجهة ويب Graylog بخادومه. بما أننا نثبت جميع العناصر على نفس الخادوم فسنحدّد القيمة 127.0.0.1 أو localhost. اعثُر على المعطى rest_transport_uri وعدّل قيمته لتصبح على النحو التالي (مع إزالة علامة التعليق أمام السطر #): rest_transport_uri = http://127.0.0.1:12900/ نغيّر قيمة معطى elasticsearch_shards إلى 1 نظرا لأن لدينا عامل Elasticsearch وحيدا وهو الخادوم: elasticsearch_shards = 1 ثم نغير قيمة المعطى elasticsearch_cluster_name إلى graylog-development (نفس الاسم الذي حددناه أعلاه لمعطى cluster.name): elasticsearch_cluster_name = graylog-development نزيل علامة التعليق من أمام السطرين التاليين لاستخدام اتصال من نوع unicast بدلا من multicast: elasticsearch_discovery_zen_ping_multicast_enabled = false elasticsearch_discovery_zen_ping_unicast_hosts = 127.0.0.1:9300 احفظ الملف ثم أغلقه. خادوم Graylog الآن مضبوط وجاهز للعمل. نشغّل خادوم Graylog بتنفيذ الأمر التالي: sudo java -jar /usr/share/graylog-server/graylog.jar server تظهر في مخرجات الأمر العبارتان التاليتان دلالة على نجاح تشغيل خادوم Graylog: Started REST API at <http://127.0.0.1:12900/> Graylog server up and running الخطوة الموالية هي تثبيت واجهة ويب Graylog. تثبيت واجهة ويب Graylog ننفذ أمر التثبيت التالي للحصول على واجهة ويب Graylog: sudo apt-get install graylog-web الخطوة التالية هي إعداد المفتاح السري لواجهة الويب الذي يمثله معطى application.secret في ملف الإعداد web.conf. نطبق نفس الطريقة السابقة لتوليد مفتاح سري وإدراجه: SECRET=$(pwgen -s 96 1) sudo -E sed -i -e 's/application\.secret=""/application\.secret="'$SECRET'"/' /etc/graylog/web/web.conf افتح ملف إعداد واجهة الويب لتحريره: sudo vi /etc/graylog/web/web.conf نحتاج لتحديث ملف الإعداد لتحديد قيمة المعطى graylog2-server.uris التي هي قائمة من مسارات URI خاصة بخواديم Graylog. بما أن لدينا عقدة خادوم واحدة فيجب أن تطابق قيمة graylog2-server.uris قيمةَ المعطى rest_listen_uri في إعداد الخادوم (أي http://127.0.0.1:12900/): graylog2-server.uris="http://127.0.0.1:12900/" احفظ الملف ثم أغلقه. يجب نسخ ملف الإعداد إلى المسار /usr/share/graylog-web/conf/web.conf كالتالي: sudo cp /etc/graylog/web/web.conf /usr/share/graylog-web/conf/web.conf ننفذ الأمر التالي لتشغيل واجهة ويب Graylog: sudo /usr/share/graylog-web/bin/graylog-web-interface نستطيع الآن استخدام واجهة الويب، وهو ما سنفعله في الفقرات التالية. إعداد Graylog لاستقبال رسائل النظام Syslog أدخل عنوان الويب التالي إلى شريط العناوين في متصفحك المفضل: http://graylog_public_IP:9000/ يمثّل graylog_public_IP عنوان IP العمومي لخادومك. ستظهر لديك واجهة تطلب اسم المستخدم وكلمة السر. أدخل admin وكلمة السر التي اخترتها أثناء إعداد خادوم Graylog. ثم بعد الدخول الواجهة التالية: يوجد في أعلى الواجهة عدد يمثل إشعارا تظهر بعد النقر عليه رسالة تقول إن لديك عقدة نشطة لا تصلها أية مُدخَلات Inputs. فلنضف مدخلا لاستقبال رسائل سجل النظام عبر UDP. إنشاء مدخل لسجلات النظام عبر ميثاق UDP انقر على القائمة المنسدلة System (النظام) الموجودة في شريط القوائم العلوي واختر Inputs (مُدخلات) لإضافة مُدخَل يستقبل رسائل سجل النظام. اختر Syslog UDP من القائمة المنسدلة في الصفحة الجديدة ثم انقر على زر Launch new input (ابدأ المُدخَل الجديد). ستظهر نافذة منبثقة جديدة. أدخل البيانات التالية (أبدِل graylog_private_IP بعنوان IP الداخلي لخادومك): Title: syslog Port: 8514 Bind address: graylog_private_IP ثم انقر على زرّ Launch أسفل النافذة. ستجد أن مُدخلا جديدا باسم syslog يظهر في فقرة Local inputs؛ تظهر أولا لصيقة starting (في طور التشغيل) ثم بعد قليل تتحول إلى اللون الأخضر وعبارة running (يعمل)، قد تحتاج لإعادة تحميل الصفحة لتحديث الحالة. جهزنا خادوم Graylog لاستقبال رسائل من سجل النظام، بقي لنا ضبط الخادوم لإرسال سجلات النظام إلى Graylog. إعداد الخواديم لإرسال سجلات النظام إلى Graylog ينبغي تطبيق الخطوات التالية على الخواديم التي نريد مراقبتها. نبدأ بإنشاء ملف إعداد rsyslog في المجلد etc/rsyslog/، سنسميه 90-graylog.conf: sudo vi /etc/rsyslog.d/90-graylog.conf نضيف الأسطر التالية إلى الملف كي يبعث برسائل سجلات النظام إلى خادوم Graylog (أبدل graylog_private_IP بعنوان IP المحلي لخادوم Graylog): $template GRAYLOGRFC5424,"<%pri%>%protocol-version% %timestamp:::date-rfc3339% %HOSTNAME% %app-name% %procid% %msg%\n" *.* @graylog_private_IP:8514;GRAYLOGRFC5424 احفظ الملف ثم أغلقه. سيُحمَّل هذا الملف مع تحميل إعداد rsyslog، تجب إعادة تحميل rsyslog من أجل اعتماده: sudo service rsyslog restart نعود، بعد إكمال إعداد rsyslog على جميع الخواديم التي نريد مراقبة سجلاتها إلى واجهة Graylog. عرض مصادر Graylog بالعودة إلى واجهة الويب، انقر قائمة Sources في الشريط العلوي. ستظهر أسفل الصفحة لائحة بجميع الخواديم التي أعددت عليها rsyslog لإرسال السجلات إلى Graylog، مع عدد الرسائل الواردة منها في المدة المحددة ضمن القائمة المنسدلة (ساعة مبدئيا). البحث في بيانات Graylog توفر واجهة Graylog إمكانية البحث في بيانات السجلات. تختلف البيانات المتوصَّل إليها حسب نشاط الخادوم، لذا امنح Graylog دقائق لجمع البيانات خصوصا إذا كان النشاط على الخادوم ضعيفا. في الصورة التوضيحية أدناه مثال للبحث عن DNS في البيانات التي جُمعت في آخر 15 دقيقة. تظهر الرسائل في أسفل الصفحة، ويمكن استخدامها للبحث عن مشاكل في الإعدادات ومن ثم إصلاحها. يتيح Graylog إمكانية حصْر البحث في الرسائل القادمة على خادوم واحد فقط في حالة إعداد Graylog لتجميع البيانات من أكثر من مصدر. يمكن أيضا حصر البحث في نطاق زمني محدّد. يفيد البحث قي بيانات Graylog كثيرا حيث يمكّنك مثلا من مراجعة سجلات خادوم أو خواديم بعد حدوث مشكل. تساعد السجلات المركزية في تشخيص الحوادث المترابطة، فأنت لا تحتاج لتسجيل الدخول إلى جميع الخواديم لعرض بيانات الأحداث. خاتمة لا تنحصر إمكانيات Graylog في تجميع بيانات سجل النظام بل يمكن استخدامه لمركزة سجلات مختلفة ومراقبة التطبيقات أو الأنظمة التي ترسلها. كما تمكن أيضا إعادة تهيئة السجلات المرسلة لاستخراج بيانات محدّدة منها. لا تتردد في استكشاف إمكانيات البرنامج. يُستحسن في بيئات العمل الكبيرة تثبيت عناصر Graylog وإعدادها على خوادم منفصلة لأداء أعلى. ترجمة -وبتصرف- لمقال How To Install Graylog 1.x on Ubuntu 14.04 لصاحبه Mitchell Anicas.

يُستخدَم 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. نبدأ بمثال سهل لسيناريو يحدث كثيرا أثناء تطوير البرمجيات ونرى كيفية تطبيقه على التفريع والدمج. لنفترض حدوث الخطوات التالية: كنت تعمل على موقع ويب وأنجزت الجزء الأهم وهو الآن مفتوح للزوار. أنشأت تفريعا جديدا وبدأت العمل على ميزات ستضيفها لاحقا للموقع. عند هذه النقطة وردك اتصال يخبرك عن مشكل في الموقع. المشكل خطير ويحتاج حلا سريعا. تنتقل لنسخة الموقع الموجودة على بيئة الإنتاج (إصدار الموقع المفتوح للزوار). أي أنك انتقلت للتفريع الذي أطلقت منه الموقع (وليكن التفريع 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 على غرار غالبية أنظمة إدارة النسخ التفريع 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.

يتيح 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 مثل الكثير من أنظمة إدارة النسخ 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.

قد تود بعد القيام بعمليات إيداع عدّة، أو بعد استنساخ 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 التي قد تجعلك تخسر العمل إن أجريتها بطريقة خاطئة. يكثر استخدام التراجع عند الإيداع قبل أن تكون جاهزا لذلك؛ مثلا بنسيان ملفات أو رسائل الإيداع. في هذه الحالة يمكنك إعادة الإيداع باستخدام الخيار 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.

يُعدّ بذر قواعد البيانات إحدى الميزات الجميلة التي يقدمها Laravel؛ إلا أن إضافة تسجيلات بيانات كثيرة، الواحدة تلو الأخرى أمر مملّ ويأخذ الكثير من الوقت الثمين. تأتي مكتبة Faker لتدارك هذا الأمر. هذا الدرس جزء من سلسلة تعلم Laravel والتي تنتهج مبدأ "أفضل وسيلة للتعلم هي الممارسة"، حيث ستكون ممارستنا عبارة عن إنشاء تطبيق ويب للتسوق مع ميزة سلة المشتريات. يتكون فهرس السلسلة من التالي: مدخل إلى Laravel 5.تثبيت Laravel وإعداده على كلّ من Windows وUbuntu.أساسيات بناء تطبيق باستخدام Laravel.إنشاء روابط محسنة لمحركات البحث (SEO) في إطار عمل Laravel.نظام Blade للقوالب.تهجير قواعد البيانات في Laravel.استخدام Eloquent ORM لإدخال البيانات في قاعدة البيانات، تحديثها أو حذفها.إنشاء سلة مشتريات في Laravel.الاستيثاق في Laravel.إنشاء واجهة لبرمجة التطبيقات API في Laravel.إنشاء مدوّنة باستخدام Laravel.استخدام AngularJS واجهةً أمامية Front end لتطبيق Laravel. الدوّال المساعدة المخصّصة في Laravel.استخدام مكتبة Faker في تطبيق Laravel لتوليد بيانات وهمية قصد الاختبار. (هذا الدرس) تُستخدَم Faker، وهي مكتبة PHP، لتوليد بيانات وهمية لأغراض اختبار التطبيقات. ويمكنها توليد بيانات من أنواع متعدّدة. يغطي هذا الدرس المواضيع التالية: كيفية تثبيت Faker في Laravel.أساسيات استخدام Faker في Laravel.بذر قواعد البيانات باستخدام Faker.كيفية تثبيت Faker في Laravelيأتي Laravel مضمّنا بمكتبة Faker مبدئيا ولا تحتاج لتثبيتها يدويّا. المكتبة تصبح جاهزة للاستخدام فور تثبيت Laravel. يمكن استخدام Faker لتوليد بيانات من الأنواع التالية: الأعداد.نصوص Lorem (نصوص لمَلء الفراغ في الصفحات).بيانات الأشخاص مثل الألقاب، الأسماء، الجنس وغيرها.العناوين.أرقام الهواتف.الشركات.النصوص.الوقت والزمن.أسماء النطاقات، روابط URL، عناوين البريد الإلكتروني، … إلخ.وكيل مستخدم User agent.بطاقات الدفع الإلكتروني.الألوان.الملفات.الصور.الرموز الشريطية Barcodes.وأنواع متفرقة أخرى. أساسيات استخدام Fakerنستخدم في هذا الدرس مشروع Laravel الذي أنشأناه في درس استخدام AngularJS واجهةً أمامية Frontend لتطبيق Laravel 5 لتجربة عمل مكتبة Faker. يمكنك إن أردت إنشاء مشروع خاص للتجربة عبره، درس تثبيت Laravel 5 وإعداده على Windows وUbuntu يشرح الكيفية. نفتح ملف المسارات routes.php ونضيف الشفرة التالية: Route::get('/customers',function(){ $faker = Faker\Factory::create(); $limit = 10; for ($i = 0; $i < $limit; $i++) { echo $faker->name . ', Email Address: ' . $faker->unique()->email . ', Contact No' . $faker->phoneNumber . '<br>'; } });ننشئ كائنا من صنف Faker بالتعليمة $faker = Faker\Factory::create();ثم نضع حدّا لعدد التسجيلات التي نريد إنشاءها limit$، يُستخدَم هذا الحد في الحلقة التكرارية for لإنشاء عدد التسجيلات التي نريد (عشرة في حالتنا). نستخدم كائن faker$ داخل الحلقة التكرارية لتوليد بيانات أشخاص (الاسم name، البريد الإلكتروني email ورقم الهاتف phoneNumber). بالنسبة للبريد الإلكتروني فقد اخترنا أن يكون فريدا لكل شخص (لا يوجد اثنان في الجدول لديهما نفس العنوان البريدي). ثم نعرض هذه البيانات في المتصفّح. افتح الرابط customers/ في المتصفح ولاحظ النتيجة. Prof. Aiden Ebert, Email Address: Katharina69@hotmail.com, Contact No398-903-1148x26227 Candido Franecki, Email Address: Carlos.Dach@Gleichner.com, Contact No1-892-092-4346x13604 Isaiah Hand, Email Address: Bode.Claudie@Dickinson.biz, Contact No1-622-989-4414x2096 Faustino Hammes, Email Address: Emmerich.Anika@Hickle.net, Contact No(466)750-0869 Mrs. Deborah Weissnat Jr., Email Address: qHoppe@gmail.com, Contact No+39(0)3577406367 Ms. Harmony Homenick I, Email Address: Crist.Makenna@Monahan.com, Contact No04666426522 Delmer Hackett DDS, Email Address: hHilpert@Buckridge.info, Contact No210.397.7833x719 Hayley Hegmann PhD, Email Address: Genoveva14@hotmail.com, Contact No(780)054-8492x5869 Jarvis Tremblay, Email Address: pLakin@gmail.com, Contact No037.786.6464 Cecelia Rice, Email Address: Willms.Darrell@gmail.com, Contact No587-993-1770رأينا كيف تعمل Faker؛ سنرى الآن كيف نزاوج بينها وبذر قاعدة البيانات. بذر قاعدة البيانات باستخدام Fakerننشئ الآن جدول قاعدة بيانات عبر التهجيرات ثم نملأها ببيانات تولّدها مكتبة Faker. ننشئ ملف التهجيرات: php artisan make:migration customersافتح ملف التهجيرات الذي أنشأناه للتو وعدّله ليصبح على النحو التالي: <?php use Illuminate\Database\Schema\Blueprint; use Illuminate\Database\Migrations\Migration; class Customers extends Migration { /** * Run the migrations. * * @return void */ public function up() { Schema::create('customers', function (Blueprint $table) { $table->increments('id'); $table->string('name'); $table->string('email')->unique(); $table->string('contact_number'); $table->timestamps(); }); } /** * Reverse the migrations. * * @return void */ public function down() { Schema::drop('customers'); } }ثم ننفذ التهجير: php artisan migrateإن فحصت قاعدة البيانات فستجد أن جدولا جديدا باسم customers قد أضيف إلى القاعدة. ننتقل إلى الخطوة التالية وهي إنشاء ملف للبذر: php artisan make:seeder CustomersTableSeederثم نفتح ملف البذر CustomersTableSeeder.php الذي أنشأناه للتو ونعدّل عليه ليصبح كالتالي: <?php use Illuminate\Database\Seeder; class CustomersTableSeeder extends Seeder { /** * Run the database seeds. * * @return void */ public function run() { $faker = Faker\Factory::create(); $limit = 33; for ($i = 0; $i < $limit; $i++) { DB::table('customers')->insert([ //, 'name' => $faker->name, 'email' => $faker->unique()->email, 'contact_number' => $faker->phoneNumber, ]); } } }تُدرج الشفرة أعلاه 33 تسجيلة جديدة في جدول البيانات customers باستخدام البيانات التي ولّدتها مكتبة Faker. ثم ننفذ أمر البذر: php artisan db:seed --class=CustomersTableSeederيدل عدم ظهور رسائل في سطر الأوامر أن الأمر نُفّذ دون مشاكل. إن تحققت من قاعدة البيانات فستجد أن الجدول customers يحوي الآن 33 تسجيلة. لاحظ الحقول المولّدة؛ مثلا في حقل البريد الإلكتروني توجد عناوين بريدية صالحة من حيث الصيغة. ترجمة -وبتصرّف- لمقال Laravel 5 Faker Tutorial لصاحبه Rodrick Kazembe.

يأتي Laravel مضمّنا مبدئيًّا بالكثير من المهام الشائعة في تطوير تطبيقات الويب؛ إلا أن المطوّر يحتاج لإضافة ميزات خاصّة لإطار العمل لاستخدامها في مشروعه، وهو ما يمكن فعله في Laravel عبر الدوّال المساعِدة المخصّصة. هذا الدرس جزء من سلسلة تعلم Laravel والتي تنتهج مبدأ "أفضل وسيلة للتعلم هي الممارسة"، حيث ستكون ممارستنا عبارة عن إنشاء تطبيق ويب للتسوق مع ميزة سلة المشتريات. يتكون فهرس السلسلة من التالي: مدخل إلى Laravel 5.تثبيت Laravel وإعداده على كلّ من Windows وUbuntu.أساسيات بناء تطبيق باستخدام Laravel.إنشاء روابط محسنة لمحركات البحث (SEO) في إطار عمل Laravel.نظام Blade للقوالب.تهجير قواعد البيانات في Laravel.استخدام Eloquent ORM لإدخال البيانات في قاعدة البيانات، تحديثها أو حذفها.إنشاء سلة مشتريات في Laravel.الاستيثاق في Laravel.إنشاء واجهة لبرمجة التطبيقات API في Laravel.إنشاء مدوّنة باستخدام Laravel.استخدام AngularJS واجهةً أمامية Front end لتطبيق Laravel. الدوّال المساعدة المخصّصة في Laravel. (هذا الدرس)استخدام مكتبة Faker في تطبيق Laravel لتوليد بيانات وهمية قصدَ الاختبار. عند استخدام الدالة asset في قالب Blade فأنت تستدعي دالة مساعِدة مضمّنة في Laravel. الدوال المساعدة هي دوال مبنية لتأدية أعمال اعتيادية ويمكن غالبا استخدامها في أي ملف من إطار العمل أو التطبيق. سنشرح في هذا الدرس كيفية بناء دوال مساعدة مخصّصة. يغطي الدرس المواضيع التالية: مجلّد الدوال المساعِدة.تعريف صنف مساعِد.مزود الخدمة الخاص بالصنف المساعِد.كنية الصنف المساعد.سنستخدم نفس المشروع الذي أنشأناه في الدرس السابق لإيضاح المفاهيم الواردة في هذا الدرس. مجلد الدوال المساعدةسننشئ مجلّدا خاصّا بالأصناف التي ستعرّف الدوال المساعدة داخل مجلد التطبيق app، نعطيه اسم Helpers. داخل مجلد الدوال المساعدة app/Helpers ننشئ ملفا باسم MyFuncs.php لتعريف الصنف MyFuncs ونضيف إليه الشفرة المصدرية التالية: <?php namespace App\Helpers; class MyFuncs { public static function full_name($first_name,$last_name) { return $first_name . ', '. $last_name; } }تنشئ الشفرة أعلاه صنفا لتعريف الدالة المساعدة full_name. نبدأ بتعريف فضاء أسماء لأصناف المساعدات داخل فضاء أسماء التطبيق: namespace App\Helpers;ثم نعرّف الصنف MyFuncs الذي توجد داخله الدالة المساعدة full_name. الدالة المساعدة full_name هي دالة ثابتة static تقبل سلسلتي محارف Strings ثم تلمّهما Concatenate. صنف مزود الخدمة الخاص بالمساعِداتتستخدَم مزودات الخدمة للتحميل التلقائي للأصناف كما أشرنا في درس إنشاء سلة مشتريات في Laravel 5؛ سنعرّف مزود خدمة لتحميل جميع الأصناف الموجودة في المجلّد app/Helpers. سنستخدم Artisan لإنشاء مزود خدمة كما فعلنا مع النماذج و التهجيرات، نفذ الأمر التالي: php artisan make:provider HelperServiceProviderينشئ الأمر السابق ملفا باسم HelperServiceProvider على المسار /app/Providers؛ نفتحه لتحريره. عدّل الملف ليصبح كالتالي: <?php namespace App\Providers; use Illuminate\Support\ServiceProvider; class HelperServiceProvider extends ServiceProvider { /** * Bootstrap the application services. * * @return void */ public function boot() { // } /** * Register the application services. * * @return void */ public function register() { foreach (glob(app_path().'/Helpers/*.php') as $filename){ require_once($filename); } } }نعرّف فضاء الأسماء الذي ينتمي إليه الصنف App\Providers ثم نستدعي صنف مزود الخدمة Illuminate\Support\ServiceProvider وهو صنف يمدده مزود الخدمة الذي نحن بصدد تعريفه. تمهّد الدالة boot خدمات التطبيق Bootstrapping، أي تحميل الأصناف التي تعرّف الخدمات أثناء بدء التطبيق العمل. ثم يأتي دور الدالة register التي تحمّل محتويات المجلد Helpers بسبر ملفاته وتحميلها الواحد تلو الآخر. إعداد مزود خدمة المساعدات وكنية صنف المساعداتنحتاج لإعلام إطار العمل Laravel بوجود مزوّد الخدمة الذي أنشأناه. لذا سنفتح ملف إعداد التطبيق config/app.php ونضيف عنصرا جديدا إلى مصفوفة providers على النحو التالي: App\Providers\HelperServiceProvider::class,ثم ننتقل إلى مصفوفة الكنى aliases لإضافة كنية لصنف MyFuncs: 'MyFuncs' => App\Helpers\MyFuncs::class,احفظ التعديلات. استخدام المساعِدات المخصصةننشئ في ملف المسارات routes.php مسارا خاصّا لتجربة الدالة المساعدة: Route::get('/func', function () { return MyFuncs::full_name("Hsoub","Academy"); });نستدعي الدالة MyFuncs::full_name مع تمرير المعطيين الضروريين إليها. افتح المسار http://angulara.dev/func لتجربة عمل الدالة المساعدة. ستحصل على النتيجة التالية: Hsoub, Academyخاتمةتستخدَم الدوال المساعدة لتنفيذ مهام يكثُر استعمالها في تطبيقات الويب. يمكنك إنشاء دوال مساعدة مخصّصة وإضافتها إلى التطبيق. تفيد الدوال المساعدة كثيرا في تهيئة المخرجات وصياغتها ضمن قوالب Blade والاستغناء بالتالي عن معالجة البيانات داخل القوالب. ترجمة -وبتصرّف- لمقال Laravel 5 Custom Helper لصاحبه Rodrick Kazembe.