احترف Git

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

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

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

المشكلة الكبرى الأخرى التي واجهت الناس هي احتياجهم إلى التعاون مع مطوِّرين على أجهزة أخرى. فحلوها بإنشاء «الأنظمة المركزية لإدارة النسخ» (CVCS). لهذه الأنظمة (مثل CVS و Subversion و Perforce) خادوم وحيد به جميع الملفات المراقَبة، وعملاء يسحبون الملفات من ذلك المركز الوحيد. كان هذا هو المعيار المتبع لإدارة النسخ لأعوام عديدة.

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

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

الآن تتدخل الأنظمة المتوزِّعة لإدارة النسخ (DVCS). في نظام متوزِّع (مثل جت و Mercurial و Darcs)، لا يستنسخ العملاء اللقطة الأخيرة فقط من الملفات، بل يستنسخون المستودع برُمّته، بتاريخه بالكامل. لذا فإن انهار أحد الخواديم فجأة، وكانت هذه الأنظمة تتعاون عبر هذا الخادوم، فيمكن نسخ مستودع أي عميل إلى الخادوم مجددًا لإعادته للعمل. كل نسخة هي في الحقيقة نسخة احتياطية كاملة لجميع البيانات.

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

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

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

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

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

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

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

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

الآلية التي يستخدمها جت لحساب البصمة معروفة باسم بصمة SHA-1. وهي تنتج سلسلة نصية من أربعين رقْما ستعشريا (0–9 و a–f) محسوبين من محتوى الملف أو بِنية المجلد في جت. تشبه بصمة SHA-1 هذا:

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

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

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

انتبه الآن وركّز؛ هذا أهم شيء عليك تذكره دوما عن جت إذا أردت أن تمضي رحلة تعلمك بسلاسة. في جت ثلاث مراحل يمكن أن تكون ملفاتك فيها: معدّل، ومؤهل، ومُودَع.

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

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

منطقة التأهيل هي ملف يخزن معلومات عما سيكون في إيداعك التالي، وعادةً يكون ملف منطقة التأهيل في مجلد جت لمشروعك. المصطلح التقني في لغة جت هو «الفهرس» (index)، لكن العبارة «منطقة التأهيل» (staging area) مناسبة ومستخدمة أيضا.

مجلد جت هو المكان الذي يخزن فيه جت البيانات الوصفية وقاعدة بيانات الكائنات لمشروعك. هذا هو أهم جزء في جت، وهم الذي يُنسخ عندما تستنسخ (clone) مستودعا من حاسوب آخر.

يبدو أسلوب التطوير الأساسي في جت مثل هذا:

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

إذا أردت تثبيت أدوات جت الأساسية على لينكس عبر مثبت برمجيات مبنية، فيمكنك غالبا فعل ذلك عبر أداة إدارة الحزم التي في توزيعتك. فإذا كنت على فيدورا (أو أي توزيعة قريبة منها تستخدم حزم RPM، مثل ردهات (RHEL) أو CentOS)، فيمكنك استخدام dnf:

وإذا كنت على توزيعة دبيانية مثل أوبنتو، جرب apt:

لخيارات أخرى، توجد على موقع جت تعليمات لتثبيته على توزيعات لينكسية ويونكسية عديدة، في https://git-scm.com/download/linux.

توجد طرائق عديدة لتثبيت جت على ماك. ربما أسهلها هو تثبيت أدوات سطر أوامر إكس‌كود (Xcode Command Line Tools). وعلى ماك مافريكس (Mavericks, 10.9) أو أحدث، يمكنك فعل هذا بمجرد محاولة تنفيذ git في الطرفية أول مرة إطلاقًا.

فإذا لم يكن مثبتًا لديك بالفعل، فسيحثك على تثبيته.

أما إذا أردت نسخة أحدث، فيمكنك أيضا تثبيته عبر مثبت برمجيات مبنية. يوجد مثبت جت لماك على موقع جت، في https://git-scm.com/download/mac.

لتثبيت جت على ويندوز عدة طرائق أيضا. النسخة المبنية الأكثر رسميةً متاحة على موقع جت. عليك فقط الذهاب إلى https://git-scm.com/download/win وسيبدأ التنزيل تلقائيا. لاحظ أن هذا مشروع يسمى «جت لويندوز» (Git for Windows)، وهو منفصل عن جت نفسه؛ للمزيد من المعلومات عنه، اذهب إلى https://gitforwindows.org.

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

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

إذا أردت تثبيت جت من المصدر البرمجي، فستحتاج إلى المكتبات التالية التي يعتمد عليها جت: autotools و curl و zlib و openssl و expat و libiconv. مثلا، إذا كنت على نظام يستخدم dnf (مثل فيدورا) أو apt-get (مثل الأنظمة الدبيانية)، فيمكنك استخدام أحد هذين الأمرين لتثبيت أقل اعتماديات مطلوبة لبناء جت وتثبيته:

وتحتاج هذه الاعتماديات حتى تضيف التوثيق بصيغه المختلفة (doc و html و info):

إذا كنت تستخدم توزيعة دبيانية (دبيان أو أوبنتو أو إحدى مشتقاتهما)، فتحتاج أيضا حزمة install-info:

إذا كنت تستخدم توزيعة تستخدم RPM (فيدورا أو ردهات أو إحدى مشتقاتهما)، فتحتاج أيضا حزمة getopt (المثبتة مبدئيا في التوزيعات الدبيانية):

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

بسبب اختلافات في أسماء الأوامر.

عندما يكون لديك جميع الاعتماديات المطلوبة، يمكنك تنزيل أحدث ملف مضغوط موسوم برقم إصدار، من عدة أماكن. يمكنك تنزيله من موقع نواة لينكس، من https://www.kernel.org/pub/software/scm/git، أو من النسخة المقابلة على موقع جت‌هب، من https://github.com/git/git/tags. غالبا يكون أوضح قليلا على جت‌هب ما هي النسخة الأحدث، ولكن في صفحة موقع نواة لينكس ستجد بصمات الإصدارات، إذا أحببت تفقّد صحة الملفات التي نزّلتها.

بعدئذٍ يمكنك البناء والتثبيت:

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

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

نكرر: لن تحتاج إلى فعل هذا إلا مرة واحدة إذا استخدمت الخيار --global («عام»)، لأن جت عندئذٍ يستعمل هاتين المعلومتين لما تفعله مستخدمًا حسابك على هذا النظام. وإن احتجت إلى تجاوز إحدى هاتين القيمتين في مشروعات محددة، يمكنك تنفيذ الأمر في ذلك المشروع بغير الخيار --global.

تساعدك الكثير من الواجهات الرسومية في فعل هذا عند تشغيلها أول مرة.

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

إذا أردت محررًا آخر، مثل Emacs، فافعل الآتي:

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

في حالة Notepad++‎، وهو محرر برمجيات مشهور، ستريد غالبا أن تستخدم نسخة ٣٢-بت منه، لأن حتى وقت كتابة هذا، لا تدعم نسخة ٦٤-بت جميع الإضافات. إذا كنت على ويندوز ٣٢-بت أو تستخدم محرر ٦٤-بت على ويندوز ٦٤-بت، فإنك ستنفذ شيئا مثل هذا:

عندما تنشئ مستودعًا جديدًا بالأمر git init، فإن جت سيُنشئ فيه فرعًا، ويسميه مبدئيًّا master. يمكنك تعيين اسم آخر للفرع المبدئي، بَدءًا من النسخة 2.28 من جت.

لجعل اسم الفرع المبدئي هو main، نفّذ:

إذا أردت تفقّد إعدادات تهيئتك، نفّذ أمر التهيئة مع خيار السرد — git config --list — ليسرد لك جميع الإعدادات التي يراها جت وقتئذٍ:

ربما ترى بعض الأسماء مكررة، هذا لأن جت قد وجد الاسم نفسه في أكثر من ملف ([path]/etc/gitconfig و ~/.gitconfig مثلا). في مثل هذه الحالة يعتمد جت القيمة الأخيرة لكل اسم يراه.

يمكنك أيضا سؤال جت عن القيمة التي يراها لاسم معين، بالأمر git config «اسم»:

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

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

إذا أردت أن تبدأ في إدارة نسخ ملفات موجودة (وليس مجلدًا فارغًا)، فعليك بَدء تعقُّب هذه الملفات وصنع إيداع أوّلي. يمكنك فعل هذا ببعض أوامر الإضافة git add، التي تحدد الملفات التي تريد تعقبها، ثم بأم‍ر الإيداع git commit:

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

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

استنسخ مستودعًا بالأمر git clone «رابط». مثلا إذا أردت استنساخ مكتبة جت القابلة للربط المسماة libgit2، يمكنك فعل ذلك هكذا:

هذا ينشئ مجلدًا اسمه libgit2، ويبتدئ مجلد .git فيه، ويجذب جميع بيانات هذا المستودع، ويسحب لك من النسخة الأخيرة منه نسخةً للعمل. فإذا دخلت مجلد libgit2 الجديد الذي أُنشئ آنفًا، فستجد فيه ملفات المشروع تنتظرك للعمل عليها أو استعمالها.

وإذا أردت استنساخ المستودع إلى مجلد باسم غير libgit2، يمكنك تعيين هذا الاسم الجديد بإضافته إلى معاملات الأمر:

هذا الأمر يفعل الشيء نفسه الذي يفعله الأم‍ر السابق، لكن اختلف المجلد الهدف فصار mylibgit.

يستطيع جت التعامل مع عدد من موافيق (بروتوكولات) النقل المختلفة. استخدم المثال السابق ميفاق https://، ولكنك قد ترى أيضا git://، أو user@server:path/to/repo.git الذي يستخدم ميفاق SSH. يخبرك فصل تثبيت جت على خادوم بجميع الخيارات التي يستطيع الخادوم إعدادها حتى يمكنك الوصول إلى مستودع جت الخاص بك، ومزايا وعيوب كلٍ منها.

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

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

لنقُل إنك أضفت ملفًا جديدًا إلى مشروعك، مثلا ملف README («اقرأني») صغير. إذا لم يكن هذا الملف موجودًا من قبل، ونفّذت أمر الحالة git status، فسترى ملفك غير المتعقب هكذا:

نرى أن ملفك الجديد غير متعقب، لأنه تحت عنوان ‪“Untracked files”‬ («ملفات غير متعقبة») في ناتج الحالة. «غير متعقب» لا يعني إلا أن جت يرى ملفًا لم يكن في اللقطة السابقة (الإيداع الأخير)، ولم تؤهله بعد. ولن يبدأ جت في ضمه إلى لقطات الإيداعات إلا بعد أن تخبره بذلك بأمر صريح. إنه لا يفعل ذلك لكيلا تضم بالخطأ ملفات رقْمية مولدة أو ملفات أخرى لم تشأ ضمها أصلا. ولكنك تريد ضم README، فهيا نبدأ تعقب هذا الملف.

لبدء تعقب ملف جديد، استخدم أمر الإضافة git add. فمثلا لبدء تعقب ملف README، نفّذ هذا:

إذا كررت أمر الحالة، فسترى ملف README قد صار متعقبًا ومؤهلًا للإيداع:

نعرف أنه مؤهلٌ لأنه تحت عنوان ‪“Changes to be committed”‬ («تعديلات ستُودَع»). إذا أودعت الآن، فإن نسخة الملف وقت تنفيذ أمر الإضافة git add هي التي ستكون في اللقطة التاريخية التالية. تذكر أنك عندما نفذت أمر الابتداء git init سابقًا، أتبعته بأم‍ر الإضافة git add «ملفات» لبدأ تعقب ملفات مستودعك. أمر الإضافة git add يُعطى مسار ملف أو مجلد. فإذا كان مجلدًا فإنه يضيف جميع الملفات التي فيه وفي أي مجلد فرعي فيه.

لنعدّل ملفًا قد جعلناه متعقبًا. إذا عدّلت الملف المتعقب CONTRIBUTING.md وكررت أمر الحالة، فسترى ما يشبه هذا:

يظهر اسم الملف CONTRIBUTING.md تحت عنوان ‪“Changes not staged for commit”‬ («تعديلات غير مؤهلة للإيداع») — الذي يعني أن ملفًا متعقبًا قد تغيّر في مجلد العمل، ولكنه لم يؤهل بعد. لتأهيله، نفذ أمر الإضافة git add. يُستعمل أمر الإضافة لأغراض عديدة: لبدء تعقب ملفات جديدة، ولتأهيل الملفات المعدلة، ولأفعال أخرى مثل إعلان حل نزاع دمج في ملف. ربما من المفيد أن تعتبره بمعنى «أضف تحديدًا هذا المحتوى إلى الإيداع التالي» بدلا من «أضف هذا الملف إلى المستودع». لننفذ git add الآن لتأهيل ملف CONTRIBUTING.md ثم نكرر git status:

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

يا للهول! لقد صار CONTRIBUTING.md مسرودًا أنه مؤهل وكذلك غير مؤهل. كيف يُعقل هذا؟ يتضح أن جت يؤهل الملف تماما كما هو عندما تنفذ git add. فإذا أودعت الآن، فإن ما سيودع هو نسخة CONTRIBUTING.md التي كانت موجودة عندما نفذت أمر الإضافة git add آخر م‍رة، وليس نسخة الملف الظاهرة لديك في مجلد العمل عندما تنفذ أم‍ر الإيداع git commit. فإن عدّلت ملفًا بعد إضافته، فعليك إضافته مرة أخرى لتأهيل النسخة الأخيرة منه:

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

أمام الملفات الجديدة التي لم تُتعقب علامتا ??. والملفات الجديدة المؤهلة أمامها A (اختصار «أضيف»). والملفات المعدّلة أمامها M (اختصار «معدّل»). وهكذا. ويوجد عمودان في الناتج أمام أسماء الملفات: العمود الأيسر يوضّح حالته في منطقة التأهيل، والأيمن يوضّح حالته في شجرة العمل. لذا ففي ناتج مثالنا هذا، ملف README معدّل في مجلد العمل ولكنه ليس مؤهلا بعد، ولكن ملف lib/simplegit.rb معدّل ومؤهل. وملف Rakefile معدّل ومؤهل ثم معدّل مرة أخرى، ففيه تعديلات مؤهلة وتعديلات غير مؤهلة.

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

يطلب السطر الأول من جت أن يتجاهل أي ملفات ينتهي اسمها بـ ‪“.o”‬ أو ‪“.a”‬ — ملفات الكائنات وملفات المكتبات المضغوطة التي قد تُنتج أثناء بناء مصدرك البرمجي. ويطلب السطر الثاني من جت أن يتجاهل جميع الملفات التي ينتهي اسمها بعلامة التلدة (~)، التي تستعملها محررات نصوص عديدة مثل Emacs لتمييز الملفات المؤقتة. يمكنك كذلك إضافة مجلد log أو tmp أو pid، أو الوثائق المولدة آليًا، إلخ. إعداد ملف التجاهل .gitignore لمستودعك الجديد قبل الانطلاق في المشروع هو تفكير حسن عمومًا، لكيلا تودع بالخطأ ملفات يقينًا لا تريدها في مستودعك.

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

تشبه أنماط glob نسخة مُيسَّرة من «التعابير النمطية»، وتستعملها الصدفات. فتُطابق النجمة (*) صفر أو أكثر من المحارف؛ ويُطابق [abc] أي حرف داخل القوسين المربعين (أي a أو b أو c في هذه الحالة)؛ وتُطابق علامة الاستفهام الغربية (?) مِحرَفًا واحدًا؛ ولمطابقة مدًى من المحارف، نكتب أول مِحرف وآخر مِحرف (بترتيبهما في Unicode) داخل قوسين مربعين وبينهما شرطة، فمثلا لمطابقة رقمًا من الأرقام المغربية (من 0 إلى 9) نكتب [0-9]. كذلك النجمتان يطابقان أي عدد من المجلدات الفرعية، فمثلا يطابق النمط a/**/z كلًا من a/z و a/b/z و a/b/c/z وهكذا.

إليك مثال آخر على ملف .gitignore :

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

لنقُل إنك عدّلت ملف README مجددا وأهّلته، ثم عدّلت ملف CONTRIBUTING.md من غير تأهيله. إذا نفذت أمر الحالة، سترى من جديد شيئًا مثل هذا:

لرؤية ما الذي عدّلته ولم تؤهله بعد، اكتب git diff من غير أي معاملات أخرى:

يقارن هذا الأمر بين محتويات مجلد العمل ومنطقة التأهيل، ويُخبرك بما عدّلته ولم تؤهله بعد.

إذا أردت رؤية ما الذي أهّلته ليكون في الإيداع التالي، يمكنك استخدام git diff --staged. يقارن هذا الأمر بين تعديلاتك المؤهلة وإيداعك الأخير:

مهمٌ ملاحظة أن git diff وحده لا يُظهر جميع التعديلات التي تمت بعد الإيداع الأخير؛ إنما يُظهر التعديلات غير المؤهلة فقط. فإذا أهّلت جميع تعديلاتك، فلن ترَ من git diff أي ناتج.

مثالٌ آخر: إذا أهّلت ملف CONTRIBUTING.md ثم عدّلته، يمكنك بأمر الفرق معرفة تعديلات الملف التي أُهّلِت والتعديلات التي لم تؤهل. فإذا كانت بيئتنا تبدو هكذا:

يمكننا إذًا بأمر الفرق git diff أن نرى ما لم يؤهل بعد:

ومع خيار «المؤهَّل»: git diff --cached، نرى ما الذي أهّلته حتى الآن (الخياران --staged و --cached مترادفان):

الآن وقد هيّأت منطقة تأهيلك كما تحب، يمكنك أن تودع تعديلاتك. تذكر أنه لن يُحفظ في هذا الإيداع أي شي ما زال غير مؤهل — أيْ أيّ ملفات أنشأتها أو عدّلتها ولم تنفذ git add عليها بعدما عدلتها؛ بل ستبقى ملفات معدلة على القرص. لنقُل إنك عندما نفذت أمر git status رأيت أن كل شيء مؤهل، لذا فأنت الآن مستعد لإيداع تعديلاتك. أسهل طريقة للإيداع هي كتابة git commit:

فعل هذا يفتح محررك المختار.

يُظهر المحرر النصَ التالي (المثال من Vim):

ويترجم أولها إلى: «أدخل رسالة الإيداع لتعديلاتك. الأسطر البادئة بعلامة # ستُهمل، ورسالة فارغة ستلغي الإيداع.»

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

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

يمكنك عوضًا عن ذلك كتابة رسالة إيداعك في أم‍ر الإيداع نفسه، بالخيار -m، مثل هذا:

الآن قد صنعت إيداعك الأول! نرى أن الإيداع قد أخبرك شيئًا عن نفسه، مثل الفرع الذي أودعت فيه (master)، وبصمة الإيداع (463dc4f)، وعدد الملفات المعدّلة (2 files changed)، وإحصاءات عن السطور المضافة والمزالة في هذا الإيداع (2 insertion(+)).

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

مع أن منطقة التأهيل مفيدة لدرجة مدهشة في صياغة الإيداعات كما تشاء بالضبط، إلا أنها أحيانًا أعقد مما تحتاج في عملك. يتيح لك جت اختصارًا سهلًا متى أردت تخطي منطقة التأهيل: إضافة الخيار -a إلى أمر git commit تجعل جت يؤهل من نفسه كل ملف متعقب قبل هذا الإيداع، لتتخطى م‍رحلة الإضافة:

لاحظ أنك لم تحتجْ إلى تنفيذ git add على ملف CONTRIBUTING.md في هذه الحالة قبل الإيداع، لأن خيار -a يضم جميع الملفات المعدلة. هذا مريح، لكن احذر: قد يضم هذا الخيار تعديلات غير م‍رغوب فيها.

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

إذا أزلت الملف من مجلد عملك فقط، سيظهر تحت عنوان ‪“Changes not staged for commit”‬ («تعديلات غير مؤهلة للإيداع») في ناتج أمر الحالة:

عندئذٍ تنفيذك أمر git rm يؤهل إزالة الملف:

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

شيءٌ آخر مفيد قد تود فعله هو إبقاء الملف في شجرة عملك لكن إزالته من منطقة تأهيلك. بلفظ آخر، تريد أن ينسى جت وجوده ولا يتعقبه ولكن يبقيه لك على قرصك. هذا مفيد خصوصًا إن نسيت إضافة شيء إلى ملف التجاهل .gitignore ثم أهّلته بالخطأ، مثل ملف سجل كبير أو مجموعة من الملفات المبنية. استعمل خيار --cached («مؤهَّل») مع أمر الإزالة لفعل هذا (الخياران --staged و --cached مترادفان):

يمكنك إعطاءه أسماء ملفات أو مجلدات أو أنماط توسيع المسارات (glob). يعني هذا أن بإمكانك فعل أشياء مثل:

لاحظ الشرطة المائلة الخلفية (\) قبل النجمة *؛ هذا ضروري، لأن جت يوسّع بنفسه أسماء الملفات بعد أن توسّعها صدفتك. فبغير الشرطة المائلة الخلفية، ستوسع الصدفة أسماء الملفات قبل أن يراها جت. يحذف هذا الأمر جميع الملفات ذات الامتداد .log في مجلد log/. أو يمكنك فعل شيء مثل هذا:

يحذف هذا الأمر جميع الملفات المنتهي اسمها بعلامة التلدة (~).

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

لذا فقد تجد أنه من المحيّر وجود أمر «نقل» (mv) في جت. فإذا أردت تغيير اسم ملف في جت، يمكنك طلبه هكذا:

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

ولكن هذا مكافئ لتنفيذ شيء مثل هذا:

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

إضافةً إلى خيارات صياغة الناتج، يتيح أمر السجل عددًا من خيارات تقييد الناتج؛ أيْ إظهار جزء من الإيداعات فقط. لقد رأيت أحد هذه الخيارات بالفعل: خيار -2 الذي يُظهر آخر إيداعين فقط. الحقيقة أن استخدام -«ن»، حيث ن هو أي عدد صحيح موجب، يُظهر لك آخر ن إيداعًا. لن تحتاج هذا كثيرًا في الواقع، لأن جت بطبيعته يمرر الناتج كله إلى برنامج عرض (‪“pager”‬ مثل less) حتى ترى ناتج السجل صفحةً صفحة.

لكن خيارات التقييد بالزمن مثل --since («منذ») و --until («حتى») مفيدة جدا. مثلا، هذا الأمر يسرد الإيداعات التي تمت خلال الأسبوعين السابقين:

يعمل هذا الأمر مع العديد من الصيغ؛ يمكنك تحديد تاريخ محدد مثل "2008-01-15" أو تاريخ نسبي مثل "2 years 1 day 3 minutes ago".

يمكنك كذلك سرد الإيداعات المطابقة لمعايير بحث معينة. مثلا خيار --author يتيح لك سرد إيداعات مؤلف معين فقط، و --grep يتيح لك البحث عن كلمات معينة في رسائل الإيداعات.

مصفاة مفيدة جدا أخرى هي خيار -S (المعروف بالاسم الدارج: خيار «فأس» جت)، الذي يُعطى سلسلة نصية ولا يظهر إلا الإيداعات التي عدّلت عدد مرات وجودها. فمثلًا إذا أردت إظهار آخر إيداع أضاف أو أزال إشارة إلى دالة معينة، يمكنك تنفيذ:

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

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

مثلا، إذا أردت رؤية أيِّ الإيداعات التي عدّلت ملفات الاختبارات في مصدر جت، وقد أودعها Junio Hamano في شهر أكتوبر عام ٢٠٠٨، وليست إيداعات دمج، يمكنك فعل شيء مثل هذا:

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

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

مباشرةً تحت ‪“Changes to be committed”‬ («تعديلات ستُودَع») تجده يقول «استخدم git reset HEAD «ملفات» لإلغاء التأهيل». فلنعمل بهذه النصيحة إذًا، لإلغاء تأهيل ملف CONTRIBUTING.md:

هذا الأمر غريب قليلًا، لكنه يعمل كما توقعنا. ملف CONTRIBUTING.md معدّل لكنه عاد من جديد غير مؤهل.

هذا الأمر السحري هو كل ما تحتاج معرفته الآن عن أم‍ر الإرجاع git reset. سنغوص في فصل تبديد الغموض عن أمر الإرجاع reset في تفاصيل أعمق كثيرا عن أمر الإرجاع وماذا يفعل وكيف تتقنه لتفعل أفعالا شيقة وممتعة جدا.

ماذا لو أدركت أنك لم تعد تريد تعديل ملف CONTRIBUTING.md من الأساس؟ كيف يمكنك إرجاعه إلى حالته عند الإيداع الأخير (أو الاستنساخ الأول، أو كيفما حصلت عليه في مجلد عملك)؟ لحسن الحظ، يخبرك أمر الحالة بهذا أيضا. في ناتج المثال الأخير، كان جزء التعديلات غير المؤهلة هكذا:

فيخبرك أن تستخدم الأمر git checkout -- «ملفات» لتجاهل التعديلات التي في مجلد عملك. لنفعل ما يخبرنا به:

كما ترى، أُلغيت التعديلات.

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

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

أضافت النسخة 2.23.0 من جت أمرًا جديدًا: git restore. هذا في الأصل بديل لأمر الإرجاع git reset الذي ناقشناه للتو. بَدءًا من النسخة 2.23.0 من جت، سيستخدم جت أمر الاستعادة git restore بدلا من أم‍ر الإرجاع git reset في الكثير من عمليات التراجع.

لنرتد على آثارنا قَصصًا ونعيد الكرّة ونتراجع بأمر الاستعادة git restore بدلًا من أم‍ر الإرجاع git reset.

لسرد المستودعات البعيدة التي هيأتها، استعمل أمر البعداء git remote. فإنه يُظهر لك الاسم المختصر لكل بعيد في مستودعك. وإذا استنسخت مستودعًا، فإنك على الأقل سترى origin («الأصل»)، وهو الاسم الذي يعطيه جت للمستودع الذي استنسخت منه:

يمكنك أيضا استعمال الخيار -v («إطناب»)، ليُظهر لك الروابط التي خزنها جت للأسماء المختصرة للمستودعات البعيدة ليستعملها لقراءة ذلك المستودع البعيد ولتحريره:

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

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

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

ذكرنا أن أمر الاستنساخ git clone يضيف لك الأصلَ البعيد origin آليًّا، ورأيت مثالين على ذلك. لنعرف الآن كيف نضيف مستودعًا بعيدًا بأمر صريح. لإضافة مستودع جت بعيد جديد وتسميته باسم مختصر للإشارة إليه به بسهولة فيما بعد، نفذ git remote add <shortname> <url>، أي الاسم المختصر ثم الرابط:

يمكنك الآن استعمال الاسم pb في سطر الأوامر، بدلًا من الرابط بكامله. مثلا إذا أردت استحضار جميع المعلومات التي لدي پول ولكن ليست لديك في مستودعك بعد، استعمل أمر الاستحضار معه، أي git fetch pb:

الآن صار فرع master من مستودع پول متاحًا محليًّا (في مستودعك على جهازك) بالاسم pb/master؛ يمكنك دمجه في أحد فروعك، أو سحب إيداعه الأخير إلى فرع محلي إذا أردت تفقّده. سنشرح بالتفصيل ما هي الفروع وكيف نستعملها في باب التفريع في جت.

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

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

إذا استنسخت مستودعًا، فإن أمر الاستنساخ يضيف آليًّا هذا المستودع البعيد بالاسم ‪“origin”‬. لذا فإن git fetch origin يستحضر أي عمل قد دُفع إلى هذا المستودع بعدما استنسخته (أو استحضرت منه) آخر مرة. مهمٌ ملاحظة أن أمر الاستحضار ينزّل فقط البيانات إلى مستودعك المحلي؛ لكنه لا يدمجها مع عملك ولا يغير في أي شيء تعمل عليه. عليك دمجها يدويًا مع عملك عندما تكون مستعدًا لذلك.

إذا كان الفرع الحالي مُعَدًّا ليتعقّب فرعًا بعيدًا (انظر الفصل الفرعي التالي وباب التفريع في جت للمزيد من المعلومات)، فأمر الجذب git pull يستحضر آليًّا هذا الفرع البعيد ثم يدمجه في الفرع الحالي. هذا قد يكون أسهل أو أريح لك. وأمر الاستنساخ بطبيعته يجعل لك الفرع المبدئي المحلي يتعقب الفرع المبدئي البعيد (master أو main أو أيًّا كان اسمه) في المستودع الذي استنسخت منه. يستحضر أمر الجذب البيانات من المستودع الذي استنسخت منه في الأصل عادةً ثم يحاول دمجها آليًّا في الفرع الذي تعمل فيه حاليًّا.

عندما يكون مشروعك في مرحلة تود مشاركتها، عليك دفعه إلى المنبع. الأمر الذي يفعل هذا يسير: git push <remote> <branch>، أي اسم المستودع البعيد ثم الفرع: فإذا أردت دفع فرع master الخاص بك إلى المستودع الأصل origin (غالبا يعيّن لك الاستنساخ هذين الاسمين آليًّا)، فتنفيذ هذا الأمر يدفع أي إيداعات صنعتها إلى الخادوم:

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

إذا أردت رؤية معلومات أكثر عن بعيد معين، فعليك بالأمر git remote show «البعيد». إذا نفذت هذا الأمر مع اسم مختصر معين، مثل origin، فسترى شيئًا مثل هذا:

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

هذا مثال صغير غالبًا ستقابله. ولكن عندما تستخدم جت بكثرة، فسيعطيك git remote show معلومات أكثر كثيرًا:

يُظهر لك هذا الأمر ما الفرع الذي يجذب جت إليه تلقائيًّا عندما تنفذ git push وأنت في فرع معين. ويُظهر لك كذلك ما فروع المستودع البعيد التي ليست لديك بعد، وما الفروع البعيدة التي لديك وأُزيلت من البعيد، وما الفروع المحلية التي تقبل الدمج التلقائي من فروعها المتعقِبة للبعيد عندما تنفذ git pull.

يمكنك استعمال git remote rename لتغيير الاسم المختصر لمستودع بعيد. مثلا، لتغيير اسم pb إلى paul، نفّذ:

مهم ملاحظة أن هذا يغيّر أسماء فروعك المتعقِبة للبعيد أيضا. فالذي كان يسمى pb/master صار paul/master.

وإذا أردت إزالة إشارة لمستودعٍ بعيد لسبب ما — نقلت المستودع، أو لم تعد تستخدم خادوم مرآة معين، أو مساهم لم يعد يساهم — استعمل أم‍ر إزالة البعيد git remote remove أو اختصاره git remote rm:

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

سرد الوسوم الموجودة في مستودع جت سهل ومباشر؛ فقط اكتب git tag (اختياريًا مع -l أو --list):

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

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

يتيح جت نوعين من الوسوم: خفيفة، ومعنونة.

الوسم الخفيف كأنه فرع لا يتغيّر: مجرد إشارة إلى إيداع معين.

لكن على النقيض، الوسوم المعنونة هي كائنات كاملة في قاعدة بيانات جت؛ يحسب جت بصمتها، ويسجل معها اسم الواسم، وبريده، وتاريخ الوسم، ورسالته، ويمكن توقيعها وتوثيقها باستعمال GNU Privacy Guard‎ (GPG). من الأفضل في العموم إنشاء وسوم معنونة حتى تنتفع بكل هذه المعلومات، لكن إذا أردت وسمًا مؤقتًا أو لسببٍ ما لم تشأ الاحتفاظ بكل هذه المعلومات، فالوسوم الخفيفة متاحة.

إنشاء الوسوم المعنونة في جت سهل. الطريقة الأيسر هي إضافة -a (اختصار --annotate «عنونة») إلى أمر الوسم:

والخيار -m (اختصار --message=) يعيّن رسالة الوسم التي تخزّن معه. وإذا لم تعيّنها لوسم معنون، فسيفتح لك جت محررك حتى تكتبها فيه.

يمكنك أيضا رؤية تاريخ الوسم مع الإيداع الموسوم بأمر الإظهار git show:

يُظهر لك هذا معلومات الواسم وتاريخ وسم الإيداع ورسالة الوسم، ثم معلومات الإيداع نفسه.

طريقة أخرى لوسم الإيداعات هي بالوسوم الخفيفة. هذا لا يعني إلا تخزين بصمة الإيداع في ملف؛ فلا معلومات أخرى تُخزّن. لإنشاء وسم خفيف، لا تعطِ أمر الوسم أيًّا من الخيارات -a أو -s أو -m (اختصارات --annotate و --sign و --message= على الترتيب)؛ أعطه فقط اسم الوسم:

تنفيذ git show على مثل هذا الوسم لن يعطيك معلومات الوسم الإضافية، بل يُظهر فقط معلومات الإيداع:

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

لنفترض الآن أنك نسيت وسم المشروع عند v1.2، التي كانت عند إيداع ‪“Update rakefile”‬. يمكنك فعل هذا بعدما حدث ما حدث. لوسم ذلك الإيداع، اكتب في نهاية أمر الوسم بصمةَ الإيداع (أو جزءًا من أولها):

والآن ستجد أنك قد وسمت الإيداع:

أمر الدفع لا ينقل آليًّا الوسومَ إلى المستودعات البعيدة. فعليك دفعها بأمر صريح بعد إنشائها. هذه العملية كبيرة الشبه بمشاركة الفروع البعيدة: نفّذ git push origin «اسم-الوسم».

وإذا كانت لديك العديد من الوسوم التي تريد دفعها جملةً واحدة، فيمكنك إضافة خيار الوسوم --tags إلى أمر الدفع git push، لينقل إلى المستودع البعيد جميع وسومك التي ليست هناك بالفعل.

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

لحذف وسم من مستودعك المحلي، نفذ git tag -d «اسم-الوسم». مثلا، يمكننا حذف الوسم الخفيف الذي أنشأناه سابقًا هكذا:

لاحظ أن هذا لا يحذف الوسم من أي مستودع بعيد. توجد طريقتان شائعتان لحذف وسمٍ ما من مستودع بعيد:

الطريقة الأولى هي git push «البعيد» :refs/tags/«اسم-الوسم»:

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

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

إذا أردت رؤية نُسخ الملفات التي يشير إليها وسمٌ ما، يمكنك سحب هذا الوسم بأمر git checkout، مع أن هذا يضع مستودعك في حالة ‪“detached HEAD”‬، التي لها بعض الآثار الجانبية السيئة:

في حالة ‪“detached HEAD”‬، إذا عدّلت شيئًا وأودعت، فإن الوسم سيبقى كما هو، وإيداعك الجديد لن ينتمي إلى أي فرع ولن يمكن الوصول إليه أبدا، إلا ببصمته. لذا، فإن احتجت إجراء تعديلات — مثلا لإصلاح علة في نسخة قديمة — فغالبا ستحتاج إلى إنشاء فرع:

إذا فعلت هذا ثم أودعت، فإن فرع version2 سيكون مختلفًا عن وسم v2.0.0 لأنه سيكون متقدمًا عنه بتعديلاتك، لذا كن حذرًا.

ماذا يحدث عندما تنشئ فرعًا جديدًا؟ الإجابة: ينشئ جت إشارة جديدة لك لتحركها كما تشاء. لنقُل إنك أردت إنشاء فرع جديد اسمه testing. تفعل هذا بأمر الفروع git branch:

ينشئ هذا إشارةً إلى الإيداع الذي تقف عنده الآن.

كيف يعرف جت في أيّ فرع أنت الآن؟ إنه يحتفظ بإشارة مخصوصة تسمى «إشارة الرأس» (HEAD). لاحظ أن هذه مختلفة كثيرًا عن مفهوم HEAD في الأنظمة الأخرى مثل Subversion و CVS. في جت، هذه إشارة إلى الفرع المحلي الذي تقف فيه الآن. في حالتنا هذه، ما زلتَ واقفًا في فرع master. فما على أمر git branch إلا إنشاء فرع جديد؛ ليس عليه الانتقال إليه.

يمكنك رؤية هذا بسهولة بأمر السجل، الذي يُظهر لك ما تشير إليه إشارات الفروع، وذلك بالخيار --decorate («تسميات»، أي إظهار أسماء الإشارات؛ وهو مفترض مبدئيا منذ النسخة 2.13 من جت).

يمكنك رؤية فرعَي master و testing عند إيداع f30ab.

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

يحرك هذا الأمر إشارة الرأس لتشير إلى فرع testing.

ما دلالة هذا؟ لنصنع إيداعًا آخر إذًا.

هذا يدعو للتفكر، لأن الآن فرع testing قد تقدم، بينما قعد فرع master في مكانه مشيرًا إلى الإيداع القديم نفسه عندما انتقلنا إلى الفرع الجديد بأمر السحب. لنعد إلى فرع master:

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

لنُجري بعض التعديلات ونودع مجددًا:

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

يمكنك أيضا رؤية هذا بسهولة بأمر السجل، فإذا نفّذت git log --oneline --decorate --graph --all فسيُظهر لك تاريخ إيداعاتك ومواضع إشارات فروعك وكيف افترق تاريخك.

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

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

لنرَ لماذا عليك فعل هذا.

أولا، لنقُل إنك تعمل على مشروعك، ولديك بضعة إيداعات بالفعل في فرع master.

ثم رأيت أن تعمل على المسألة رقم ٥٣ في نظام متابعة المسائل الذي تستخدمه شركتك. فتنفّذ أمر git checkout مع الخيار -b، لإنشاء فرعٍ جديدٍ والانتقال إليه في الوقت نفسه:

وهذا اختصار للأمرين:

يمكنك العمل على موقعك وصنع بعض الإيداعات. فعل هذا يحرك فرع iss53 إلى الأمام، لأنه الفرع المسحوب (أي أنه الفرع الذي تشير إليه إشارة الرأس HEAD لديك):

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

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

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

عليك الآن العمل على الإصلاح العاجل. لننشئ فرع hotfix لتعمل عليه حتى تنتهي:

يمكنك الآن إجراء الاختبارات والتأكد من أن الإصلاح الذي صنعته هو المراد. ثم دمج فرع الإصلاح العاجل في الفرع الرئيس حتى تدفعه إلى الإنتاج. يمكنك فعل هذا بأمر الدمج git merge:

ستلاحظ عبارة ‪“fast-forward”‬ («تسريع») في ناتج الدمج. هذا لأن الإيداع C4 الذي يشير إليه فرع الإصلاح العاجل كان مباشرةً أمام الإيداع C2 الذي تقف فيه، فلم يفعل جت سوى تحريك الإشارة إلى الأمام. بلفظ آخر: عندما تريد دمج إيداع في إيداع آخر يمكن الوصول إليه بتتبع تاريخه، فإن جت لا يعقد الأمور بل يحرك الإشارة إلى الأمام، فلا أعمال مفترقة ليحاول دمجها — يسمى هذا «تسريعًا» (‪“fast-forward”‬).

تعديلاتك الآن موجودة في لقطة الإيداع التي يشير إليها الفرع الرئيس، فيمكنك الآن نشرها.

بعد نشر إصلاحك الشديد الأهمية، تكون جاهزا للعودة إلى عملك الذي كنت فيه قبل هذه المقاطعة. ولكن عليك أولا حذف فرع hotfix لأنك لم تعد تحتاج إليه؛ فالفرع الرئيس يشير إلى الشيء نفسه. يمكنك حذفه بالخيار -d مع أمر التفريع git branch:

يمكنك الآن العودة إلى فرع العمل الحالي الخاص بالمسألة رقم ٥٣، وإكمال العمل عليها.

من الواجب ملاحظة أن مِلفات فرع iss53 لا تحتوى على عملك في فرع hotfix. فإذا احتجت إلى جذبه إليها، ادمج فرع master في فرع iss53 بالأمر git merge master، أو أجّله حتى تقرر جذب فرع iss53 إلى master فيما بعد.

إذا رأيت أن عملك على المسألة رقم ٥٣ قد اكتمل وصار جاهزا لدمجه في الفرع الرئيس، فستدمج فرع iss53 في فرع master، تماما مثلما دمجت فرع hotfix سابقا: ليس عليك سوى سحب الفرع الذي تريد الدمج فيه ثم تنفيذ أمر الدمج:

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

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

الآن قد دُمِج عملك، ولم تعد في حاجة إلى فرع iss53. فيمكنك غلق هذه المسألة في نظام متابعة المسائل، وحذف الفرع:

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

لم ينشئ جت آليًّا إيداعَ دمجٍ جديدًا، بل أوقف العملية حتى تحل النزاع. فإذا أردت رؤية الملفات غير المدموجة في أي وقت بعد نزاع الدمج، نفّذ أمر الحالة git status:

ستظهر الملفات المتنازع عليها ولم تُدمج بعد أنها غير مدموجة ‪“unmerged”‬. ويضيف جت علامات معيارية لحل النزاعات إلى الملفات المتنازع عليها، حتى تتمكن من تحريرها يدويا وحل تلك النزاعات. فستجد أن في ملفك جزءًا يشبه هذا:

تجد نسخة HEAD (فرع master، لأنه الفرع الذي سحبته قبل أمر الدمج) في النصف الأعلى من هذه الك‍تلة (كل ما هو فوق سطر =======)، ونسخة iss53 في النصف الأسفل منها. وحتى تحل هذا النزاع، عليك اختيار أحد الجزأين أو دمج محتواهما بنفسك. فمثلا قد تحله بتغيير الكتلة كلها إلى:

يحمل هذا الحل شيئا من كلا الجزأين. أما الأسطر <<<<<<< و ======= و >>>>>>> فقد أزلناها بالكامل. وبعد حل كل نزاع مثل هذا في كل ملف متنازع عليه، نفّذ أمر الإضافة git add على كل ملف لإعلام جت أنه قد حُلّ. فتأهيل الملف في جت يعلن نزاعه محلولا.

وإذا أردت استعمال أداة رسومية لحل هذه المشاكل، فأمر أداة الدمج git mergetool يشغّل أداة دمج رسومية مناسبة ويسير معك خلال النزاعات:

إذا أردت استعمال أداة دمج أخرى غير الأداة المبدئية (اختار جت في هذه الحالة أداة opendiff لأننا نفّذاه على نظام ماك)، فيمكنك رؤية قائمة بجميع الأدوات المدعومة في الأعلى بعد جملة ‪“one of the following tools”‬. ليس عليك سوى كتابة اسم الأداة التي تريدها.

بعد إغلاق أداة الدمج، فسيسألك جت عما إذا كان الدمج ناجحًا. إذا أجبت بنعم، فسيؤهل الملف لك لإعلان أنه قد حُل. ويمكنك عندئذٍ استعراض الحالة مجددًا للتحقق أن جميع النزاعات قد حُلت:

فإذا كنت راضيا عن هذا، وتأكدت من أن كل شيء كان عليه نزاع قد أُهِّل، نفّذ git commit لاختتام إيداع الدمج. ورسالة الإيداع المبدئية تشبه هذا:

فيها يمكنك شرح حلك للنزاع وتعليل تعديلاتك إن لم تكن واضحة، إذا ظننت أن هذا يفيد من يرى هذا الإيداع فيما بعد.

هَبْ فرعًا لديك اسمه bad-branch-name وتريد جعله corrected-branch-name مع الإبقاء على تاريخه بالكامل. وتريد أيضا تغيير اسمه على الخادوم البعيد (جت‌هب GitHub أو جت‌لاب GitLab أو غيرهما). كيف تفعل هذا؟

غيّر اسم الفرع على جهازك بالأمر git branch --move :

هذا يغيّر bad-branch-name إلى corrected-branch-name، ولكن هذا التغيير محليٌّ فقط حتى الآن. فلجعل الآخرين يرون الفرع الصحيح في المستودع البعيد، عليك دفعه:

لنلقِ نظرةً على حالنا الآن:

لاحظ أنك في فرع corrected-branch-name وأنه متاح في المستودع البعيد. ولكنّ الفرع ذا الاسم الخطأ متاح كذلك هناك، لكن يمكنك حذفه بالأمر التالي:

الآن قد حلّ اسم الفرع الصحيح محل اسم الفرع الخطأ في كل مكان.

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

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

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

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

يمكنك فعل هذا بعدة مستويات من الاستقرار. فلدى بعض المشروعات الكبيرة فرع proposed أو pu («تحديثات مقترحة») ويدمجوا فيه فروعًا قد لا تكون جاهزة لأن تكون في فرع next أو master. فالأمر أن فروعك في مستويات مختلفة من الاستقرار، فعندما يصل أحدها إلى مستوى استقرار أعلى، فإنه يُدمج في الفرع الأعلى. ونكرر: ليس ضروريا استعمال عدد من الفروع طويلة العمر، ولكنه كثيرا ما يفيد، خصوصا عندما تتعامل مع مشروعات معقدة أو كبيرة جدا.

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

وقد رأيت هذا في الفصل السابق في فرعَي iss53 و hotfix اللذين أنشأتهما، فقد صنعت بضعة إيداعات فيهما ثم حذفتهما فور دمجهما في فرعك الرئيس. يسمح لك هذا الأسلوب بـ«تبديل السياق» سريعا وبالكامل، لأنك قسّمت عملك إلى صومعات، وكل صومعة (فرع) ليس فيها إلا التعديلات التي تخص موضوعًا واحدًا، فيسهّل ذلك رؤيتها عند المراجعة (code review) وغير ذلك. ويمكنك إبقاء التعديلات هناك دقائق أو أيامًا أو شهورًا، ثم دمجها عندما تكون جاهزة، بغض النظر عن ترتيب إنشائها أو العمل عليها.

لنقُل مثلا إنك عملت (في master)، ثم تفرّعت لإصلاح علة (iss91)، وعملت عليها قليلا، ثم تفرّعت مجددا (من الفرع الثاني) لتجرب طريقة أخرى لإصلاح العلة نفسها (iss91v2)، ثم عدت إلى فرعك الرئيس (master) وعملت فيه قليلا، ثم تفرّعت منه لتجربة شيء لست واثقا أنه جيد (فرع dumbidea). سيبدو تاريخ إيداعك الآن مثل هذا:

لنقُل إنك الآن وجدت إصلاحك الثاني للعلة (iss91v2) أفضل، وأنك أريت زملاءك فرع dumbidea فأخبروك أنه عبقري. فيمكنك إذًا إلقاء فرع iss91 الأول (وفقد الإيداعين C5 و C6)، ودمج الفرعين الآخرين في الفرع الرئيس. سيبدو تاريخك الآن كهذا:

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

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

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

مثلا إذا كان لديك فرعًا اسمه serverfix وتريد العمل عليه مع الآخرين، يمكنك دفعه بالطريقة نفسها التي دفعت بها فرعك الأول؛ نفّذ git push <remote> <branch> (أي اسم المستودع البعيد ثم الفرع):

هذا اختصار، لأن جت يفك اسم الفرع serverfix إلى refs/heads/serverfix:refs/heads/serverfix، الذي يعني «ادفع فرعي المحلي serverfix إلى المستودع البعيد origin لتحدّث فرع serverfix عليه». سنفصّل شرح جزء refs/heads/ في باب دواخل جت، ولكن عامةً يمكنك تركه. كذلك يمكنك تنفيذ git push origin serverfix:serverfix الذي يفعل الشيء نفسه؛ إنه يقول: «خذ فرعي المسمى serverfix واجعله فرع serverfix في المستودع البعيد». هذه الصياغة مفيدة لدفع فرع محلي إلى فرع بعيد باسم مختلف. فمثلا إن لم تُرِده أن يسمى serverfix في المستودع البعيد، فنفّذ git push origin serverfix:awesomebranch، فهذا يدفع فرعك المحلي serverfix إلى فرع awesomebranch في المستودع البعيد.

وفي المرة التالية التي يستحضر أحد زملائك من الخادوم، سيحصل على إشارة إلى حيث يشير فرع serverfix على الخادوم؛ سيجدها عنده في الفرع البعيد origin/serverfix:

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

لدمج هذا العمل في فرعك الحالي، يمكنك تنفيذ git merge origin/serverfix. وإذا أردت فرع serverfix خاصًا بك تستطيع العمل فيه، يمكنك تفريعه من الفرع المتعقب للبعيد:

يعطيك هذا فرعًا محليًا يمكنك العمل فيه، ويبدأ من حيث يقف origin/serverfix.

إن سحب فرع محلي من فرع متعقب للبعيد ينشئ آليًّا ما يسمى «فرع متعقِّب» (والفرع الذي يتعقبه يسمى «الفرع المنبع»). الفروع المتعقبة هي فروع محلية ذات علاقة مباشرة بفرع بعيد. فإذا كنت في فرع متعقب وكتبت git pull، فسيعرف جت تلقائيا أي مستودع بعيد يستحضر منه وأي فرع يدمج فيه.

عندما تستنسخ مستودعًا، ينشئ جت فرعًا باسم الفرع المبدئي فيه (مثل master) ويجعله يتعقب الفرع المبدئي في المستودع الأصل (origin/master). ولكن يمكنك إعداد فروع متعقبة أخرى إذا أردت، لتعقب مستودعات بعيدة أخرى، أو لتعقب فرع غير الرئيس. أيسر حالة مثلما رأيتَ آنفًا، عند اتحاد اسم الفرع المحلي والبعيد، أيْ git checkout -b <branch> <remote>/<branch>. وهذه العملية شائعة بما يكفي أن جت يتيح اختصارها بالخيار --track:

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

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

الآن، فرعك المحلي sf سيجذب من origin/serverfix تلقائيا.

إن كان لديك بالفعل فرعًا محليًّا وتريده أن يجذب من فرع بعيد جذبته للتو، أو تريد تغيير الفرع المنبع الذي تتعقبه، عليك بخيار «تعيين المنبع» --set-upstream-to أو اختصاره -u، مع أمر الفروع git branch لتغييره بأم‍ر صريح وقتما شئت.

لرؤية الفروع المتعقِّبة التي أعددتها، يقبل أمر الفروع خيارَ الإطناب م‍رتين -vv ليسرد لك فروعك المحلية مع معلومات مزيدة فيها ما يتعقبه كل فرع وإذا كان فرعك متقدمًا عنه (ahead) أو متأخرًا (behind) أو كليهما.

فنرى هنا أن فرع iss53 يتعقب origin/iss53 وأنه «متقدم» (ahead) باثنين، أي أن لدينا إيداعين محليين ولم ندفعهما إلى الخادوم بعد. ونرى كذلك أن فرع master يتعقب origin/master وأنه متزامن معه. ثم نرى بعدهما أن فرع serverfix يتعقب فرع server-fix-good على خادوم teamone وأنه متقدم عنه بثلاثة ومتأخر بواحد، أي أن لدى الخادوم إيداعًا لم ندمجه في فرعنا بعد، وأن لدينا ثلاثة إيداعات محلية لم ندفعها إليه. ثم نرى في النهاية أن فرع testing لا يتعقب أي فرع بعيد.

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

نعلم أن أمر الاستحضار git fetch يستحضر الإيداعات التي في المستودع البعيد وليست لديك، لكنه لا يغيّر شيئًا في مجلد عملك قَط؛ إنما يجلب البيانات لك ويتركك تدمجها بنفسك. لكن في جت أمر يسمى أم‍ر الجذب git pull، وهذا الأم‍ر عمليًّا يكافئ استحضارًا git fetch متبوعًا مباشرةً بدمج git merge، في معظم الحالات. فإذا كان لديك فرع متعقِّب مُعَدّ كما في الفصل السابق، إما بإعداده صراحةً وإما بأن يعدّه لك أمر الاستنساخ git clone أو أم‍ر السحب git checkout، فإن أم‍ر الجذب git pull سينظر أيّ مستودع وأيّ فرع يتعقبهما فرعك الحالي، ويستحضر ما في المستودع البعيد ويحاول دمجه في فرعك.

لنقُل إنك قضيت ما تريد من فرع بعيد، مثلا انتهيت أنت وزملاؤك من إضافة ميزة جديدة ودمجتموها في الفرع الرئيس. يمكنك حذف فرع بعيد بالخيار --delete مع أمر الدفع git push. فإذا أردت حذف فرع serverfix من الخادوم، يمكنك تنفيذ الأمر التالي:

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

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

أسهل طريقة لضم الفرعين، كما ناقشنا بالفعل، هي أمر الدمج merge، الذي يقوم بدمج ثلاثي بين آخر لقطتين في الفرعين (C3 و C4) وآخر سلف مشترك لهما (C2)، وينشئ لقطة جديدة (وإيداعًا).

لكن توجد طريقة أخرى: يمكنك أخذ رُقعة التعديلات (‪“patch”‬) التي صنعتها في هذا الإيداع (C4) وإعادة تطبيقها على الإيداع الآخر (C3). هذه ما نسميها «إعادة التأسيس» (‪“rebasing”‬) في جت. فبأمر إعادة التأسيس rebase يمكنك أخذ جميع التعديلات التي أودعتها في فرعٍ ما، وإعادة صنعها في فرع آخر.

في هذا المثال سنسحب فرع experiment، ثم نعيد تأسيسه على الفرع الرئيس master.

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

يمكنك الآن العودة إلى الفرع الرئيس وعمل دمج تسريع (‪“fast-forward”‬).

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

غالبا ستفعل هذا لضمان أن إيداعاتك ستُطبّـق بنظافة على فرعٍ بعيد؛ مثلا في مشروع تريد المساهمة فيه لكنك لست من المطورين القائمين عليه. فستعمل عندئذٍ في فرع، ثم تعيد تأسيسه على origin/master عندما تكون جاهزًا لتسليم رُقعتك إليهم. فهكذا لن يُجهِد المطورين ضمُ عملك، فما الأمر إلا تسريعًا، أو تطبيقًا نظيفًا للرقعة.

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

يمكنك كذلك جعل إعادة التأسيس تطبّـق التعديلات على فرع غير «الفرع المستهدف». لنرَ مثلا تاريخًا مثل شكل تاريخ فيه فرع موضوع متفرع من فرع موضوع آخر. لقد أنشأت فرع موضوع (server) لإضافة ميزات في جزء الخادوم في مشروعك، وصنعت إيداعًا. بعدئذٍ أنشأت فرعًا من هذا الفرع للعمل في جزء العميل (client) وصنعت بضعة إيداعات. ثم في آخر الأمر عدت إلى فرع server وصنعت بضعة إيداعات أخرى.

لنقُل إن إيداعاتك التي في جزء العميل، رأيت أن تدمجها في الفرع الرئيس لكي تصْدرها، مع الإبقاء على إيداعات جزء الخادوم حتى تختبرها أكثر. إن الإيداعات التي في client وليست في server (وهي C8 و C9) تستطيع إعادة تطبيقها على فرع master بالخيار --onto مع أمر git rebase:

إنما يقول هذا: «احسب فروقات فرع client (التعديلات التي سُجّلت فيه) منذ أن افترق عن فرع server، ثم أعد تطبيقها في فرع client كأنه قد تفرّع من فرع master وليس من server.» صعبة قليلا، لكن النتيجة عظيمة.

عندئذٍ يمكنك تسريع الفرع الرئيس master (انظر شكل تسريع الفرع الرئيس لضم تعديلات فرع client):

لنقُل إنك قررت جذب فرع server كذلك. يمكنك إعادة تأسيس فرع server على الفرع الرئيس بلا حاجة إلى سحبه أولًا، بالأمر git rebase <basebranch> <topicbranch> (أي الفرع الأساس ثم فرع الموضوع)، وهذا يسحب لك فرع الموضوع (server في حالتنا) ويعيد تطبيق إيداعاته على الفرع الأساس (master):

هذا يُعيد تطبيق إيداعات فرع الخادوم server على الفرع الرئيس master، كما يظهر في شكل إعادة تأسيس فرع server على الفرع الرئيس.

عندئذٍ يمكنك تسريع الفرع الأساس (master):

ثم تستطيع حذف الفرعين client و server لأن كل ما فيهما قد ضُمَّ بالفعل ولم تعد بحاجة إليهما، فيصير تاريخك في نهاية هذا كما في شكل تاريخ الإيداعات في النهاية:

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

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

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

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

لنرَ كيف يمكن لإعادة تأسيس عملٍ منشور أن تسبب مشاكل. لنقُل إنك استنسخت من الخادوم المركز، ثم بنيت عليه عملا. سيبدو تاريخ إيداعك مثل هذا:

ثم جاء شخصٌ آخر وصنع المزيد من الإيداعات، التي شملت دمجًا، ثم دفعها إلى الخادوم المركز. فاستحضرت (fetch) الفرع البعيد الجديد ودمجته في عملك، فصار تاريخك كالآتي:

بعدئذ، قرر الذي دفع العمل المدموج أن يتراجع ويعيد تأسيس عمله بدل دمجه، فدفع عَنوةً (git push --force) لتحرير التاريخ على الخادوم. ثم استحضرت (fetch) من هذا الخادوم، جالبًا الإيداعات الجديدة.

كلاكما الآن في مأزق. فإذا جذبت، ستصنع إيداع دمج يضم كلا التاريخين، وسيبدو مستودعك مثل هذا:

فإذا نظرت في السجل git log عندما يصير تاريخك كهذا، فسترى إيداعين متطابقين في اسم المؤلف وتاريخ الإيداع ورسالته، فيسبب اللَبس. وأضف إلى ذلك أنك إذا دفعت هذا التاريخ إلى الخادوم، فستعيد تقديم كل هذه الإيداعات المعاد تأسيسها إلى الخادوم المركز من جديد، فتسبّب المزيد من اللَبس لأكثر للناس. يمكننا افتراض أن المطور الآخر لا يريد الإيداعين C4 و C6 في التاريخ، ولذا أعاد تأسيسهما.

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

الخبر الجميل أن جت لا يحسب للإيداع وحده بصمة SHA-1، ولكن يحسبها أيضا للرُقعة (الفروقات) التي صنعها ذلك الإيداع. وهذه البصمة تسمى «معرِّف الرقعة» (‪“patch-id”‬).

فإذا جذبت إيداعات قد غُيِّرت وأعدت تأسيسها على الإيداعات الجديدة من زميلك، فغالبا سينجح جت في تمييز ما هي تعديلاتك الفريدة ويطبّـقها على الفرع الجديد.

فمثلا في الموقف الافتراضي السابق، لو أننا أعدنا التأسيس (بالأمر git rebase teamone/master)، بدل الدمج عندما كنا في خطوة «شخصٌ يدفع إيداعات معاد تأسيسها، هاجرًا بذلك الإيداعات التي بنيت عليها عملك»، فإن جت سوف:

فبدلا مما رأينا في «عندما تدمج العمل نفسه مجددا في إيداع دمج جديد»، سنحصل على نتيجة مثل «أعد التأسيس على عمل معاد تأسيسه ومدفوع عنوة».

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

ويمكنك أن تختصر هذا باستعمال خيار إعادة التأسيس --rebase مع أمر الجذب، أي تنفيذ git pull --rebase بدلا من git pull المجرد. أو يمكنك فعل ذلك يدويا بالاستحضار git fetch ثم إعادة التأسيس، أي تنفيذ git rebase teamone/master في هذه الحالة.

وإذا كنت تستخدم git pull وتريد جعل خيار --rebase خيارًا مفترضًا دومًا، يمكنك تفعيل قيمة التهيئة pull.rebase، مثلا بالأمر git config --global pull.rebase true.

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

إن وجدت أنت أو زميلٌ لك أن ذلك ضروري يومًا ما، تأكد أن الجميع يعرفون استخدام git pull --rebase، لكي تحاول جعل معاناة ما بعد الحادثة أقل سوءًا ولو قليلا.

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

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

وجهة النظر المقابلة هي أن تاريخ الإيداعات هو قصة صناعة مشروعك. ولأنك لا تنشر المسوّدة الأولى من كتاب، فلمَ إذًا تنشر عملًا أشعث أغبر؟ ففي أثناء عملك على مشروع، قد تحتاج سجلًا لجميع عثراتك وطرقك المسدودة. ولكن عندما يحين وقت إظهار عملك إلى العالم، فقد تود أن تحكي قصةً متماسكة عن كيفية الوصول من «أ» إلى «ب». ولذلك يستخدم أصحاب هذا المذهب أدوات مثل إعادة التأسيس ومعالجة الفروع لتحرير إيداعاتهم قبل دمجها في الفرع الرئيس، يستخدمون rebase و filter-branch ليحكون القصة بالطريقة الأقرب للقراء في المستقبل.

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

ويمكنك الجمع بين ميزات كليهما: أعد تأسيس التعديلات المحلية قبل دفعها حتى تنظف عملك، ولكن لا تعد أبدًا تأسيس أي شيء دفعته إلى مستودعٍ ما.

الأكثر بدائية هو الميفاق المحلي (‪“Local protocol”‬)، الذي يكون المستودع البعيد فيه هو مجلد آخر على الحاسوب نفسه. ويُستعمل غالبا إذا كان كل مَن في فريقك لديه وصول إلى نظام ملفات مشترك مثل NFS مضموم (mounted)، أو في الحالة الأندر أن يكون كل شخص مستخدما لحاسوب واحد. ولكن تلك الأخيرة ليست حالة مثالية لأن وقتئذٍ ستبيت كل مشروعاتك البرمجية على جهاز واحد، وهذا يُزيد احتمال فقد البيانات فقدا كارثيا.

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

أو مثل هذا:

ولكن تصرف جت يختلف قليلا إذا بدأت العنوان بالميفاق file:// صريحا. فإذا كتبت المسار فقط، فإن جت يحاول صنع روابط صلبة (hardlinks) أو نسخ الملفات التي يحتاجها مباشرةً. أما إذا كتبت file://، فإن جت ينفّذ العمليات التي يستعملها في المعتاد لنقل الملفات عبر الشبكة، ويكون هذا في الغالب أقل كثيرا في الكفاءة. السبب الأساسي لكتابة البادئة file:// هي إذا كنت تريد نسخة نظيفة من المستودع بغير الإشارات أو الكائنات الإضافية؛ غالبا ما يكون ذلك بعد الاستيراد من نظام إدارة نسخ آخر أو أم‍ر شبيه (انظر باب دواخل جت لعمليات الصيانة). سنستعمل المسار العادي هنا لأنه أسرع في أغلب الأحيان.

لإضافة مستودع محلي إلى مشروع جت موجود، نفّذ أمرًا مثل هذا:

عندئذٍ يمكنك الدفع إلى ذلك البعيد والجذب منه بالاسم المختصر الجديد local_proj كما كنت تفعل تمامًا عبر الشبكة.

يستطيع جت التواصل عبر HTTP بطريقتين مختلفتين. لم يعرف جت قبل النسخة 1.6.6 منه إلا واحدة منهما، وكانت ساذجة جدا وعموما للقراءة فقط. ولكن في نسخة 1.6.6، جاء ميفاق جديد جعل جت يتفاوض بذكاء في شأن نقل البيانات، بطريقة تشبه ما كان يفعله عبر SSH. وصار ميفاق HTTP الجديد هذا في الأعوام الأخيرة أشهر كثيرا لأنه أيسر للمستخدم وأذكي في تواصله. فانتشرت تسمية النسخة الجديدة «ميفاق HTTP الذكي» (Smart HTTP)، والقديمة «ميفاق HTTP البليد» (Dumb HTTP). وسنتناول الميثاق الذكي أولا.

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

لاستنساخ مستودع جت عبر SSH، استعمل رابط ssh:// مثل:

أو استعمل الصيغة المختصرة شبيهة scp لميفاق SSH:

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

أخيرا، لدينا ميفاق Git. هذا عفريت (daemon) مخصوص مرفق مع جت، ويستمع على منفذ مخصص (9418) ليتيح خدمة شبيهة بميفاق SSH، لكن بغير استيثاق أو تعمية. وعليك إنشاء ملف اسمه git-daemon-export-ok في مستودعك لتجعل جت يقدّمه عبر ميفاق Git؛ فالعفريت لن يقدّم مستودعًا ليس فيه هذا الملف، ولكن غير ذلك لا يوجد أمان. إما أن يكون المستودع متاحا للجميع لاستنساخه، وإما لا يكون. هذا يعني أنه عموما لا يمكن الدفع عبر هذا الميفاق. يمكنك تفعيل إذن الدفع، ولكن لانعدام الاستيثاق، فكل من يجد رابط مشروعك على الشابكة (الإنترنت)، يستطيع الدفع إليه. يكفي أن نقول أن هذا نادر.

الآن وقد صار لديك نسخة مجردة من مستودعك، فلا تحتاج سوى وضعه على الخادوم وضبط الموافيق (البروتوكولات). لنقُل إنك أعددت خادومًا يسمى git.example.com، ولديك وصول SSH له، وتريد تخزين كل مستودعات جت الخاصة بك في مجلد /srv/git فيه. إذا كان مجلد /srv/git موجودًا على هذا الخادوم، فيمكنك إعداد مستودعك الجديد بنسخ مستودعك المجرد إليه:

يستطيع الآن المستخدمين الذين لديهم إذن قراءة مجلد /srv/git عبر SSH أن يستنسخوا مستودعك بالأمر:

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

وسيضيف جت إذن التحرير للمجموعة إلى المستودع بطريقة صحيحة إذا استخدمت خيار --shared («مشترك») مع أمر الابتداء git init. لاحظ أن هذا لن يُتلف أي إيداعات أو إشارات أو أي شيء آخر.

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

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

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

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

جت‌لاب هو تطبيق وب بقاعدة بيانات، لذا فتثبيته أعقد من بعض خواديم جت الأخرى. لكن لحسن الحظ هذه العملية موثقة بالكامل ومدعومة جيدا. جت‌لاب يشدد التوصية بتثبيته على خادومك عبر الحزمة الرسمية الحافلة، المسماة حزمة ‪“Omnibus GitLab”‬.

خيارات التثبيت الأخرى هي:

للمزيد من المعلومات (بالإنجليزية) انظر GitLab Community Edition (CE) readme.

واجهة إدارة جت‌لاب هي واجهة وب. ليس عليك إلا توجيه متصفحك إلى اسم المُضيف (‪“hostname”‬) أو عنوان IP الذي ثبتَّ عليه جت‌لاب، ثم لُج بحساب المدير root. كلمة المرور المبدئية تختلف حسب خيار التثبيت، لكن الحزمة الرسمية الحافلة، بطبيعتها تولّد لك كلمة مرور وتخزنها في ملف /etc/gitlab/initial_root_password حتى أربعٍ وعشرين ساعة على الأقل. انظر التوثيق لتفاصيل أزيد. بعد الولوج، اضغط على رمز ‪“Admin area”‬ (منطقة الإدارة) في القائمة التي على اليمين بالأعلى.

أول ما قد تود عمله على جت‌لاب هو إنشاء مشروع، وذلك بالضغط على رمز ‪“+”‬ على شريط الأدوات. ستُسأل عن اسم المشروع، ومساحة الأسماء التي ينتمي إليها، ومستوى ظهوره. معظم ما تحدده هنا ليس مستديمًا، فتستطيع تغييره فيما بعد من واجهة الإعدادات. اضغط على ‪“Create Project”‬ («إنشاء المشروع») لإتمام العملية.

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

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

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

أسهل طريقة للتعاون على مشروع على جت‌لاب هي إعطاء كل مستخدم إذن الدفع مباشرةً إلى المستودع. يمكنك ضم المستخدمين إلى المشروع بالذهاب إلى قسم الأعضاء (‪“Members”‬) في إعدادات هذا المشروع، وربط المستخدمين الجدد بمستويات الوصول المناسبة. (مررنا على مستويات الوصول في فصل المجموعات). إذا كان للمستخدم مستوى الوصول «مطور» (‪“Developer”‬) فيستطيع دفع الإيداعات والفروع مباشرةً إلى المستودع.

لكن طريقة أخرى للتعاون بغير ضم المطورين إلى المستودع هي طلبات الدمج (‪“merge request”‬)، التي تتيح المساهمة بطريقة محكومة لكل مستخدم يستطيع رؤية المشروع. فالمستخدمون ذوو الوصول المباشر يمكنهم إنشاء فرع ودفع إيداعاتهم إليه ثم إنشاء طلب لدمج فرعهم في الفرع الرئيس أو أي فرع آخر. أما المستخدمون الذين ليس لديهم إذن الدفع للمستودع، فيمكنهم «اشتقاق» (‪“fork”‬) المستودع لإنشاء نسختهم الخاصة منه، ودفع إيداعاتهم إلى نسختهم الخاصة بهم، ثم إنشاء طلب دمج من اشتقاقهم إلى المشروع الأصل. يسمح هذا الأسلوب للمالك بالتحكم الكامل في كل ما يدخل المستودع ومتى يدخل، وفي الوقت نفسه يسمح بمساهمات المستخدمين غير الموثوق فيهم.

طلبات الدمج، والمسائل (‪“issues”‬)، هما أهم أدوات النقاشات الطويلة في جت‌لاب. فكل طلب دمج يسمح بنقاش على كل سطر من سطور التعديل المقترح (ويدعم نوعًا خفيفًا من مراجعة التعديلات (code review))، إضافةً إلى نقاش عام. يمكن تكليف مستخدم بإتمام طلب دمج أو مسألة، أو جعل ذلك ضمن هدف من الأهداف (‪“milestone”‬).

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

في الأنظمة المركزية، يكاد ألا يوجد إلا أسلوب تعاون واحد: الأسلوب المركزي. مركز التقاء واحد، أيْ مستودع، هو الذي يقبل التعديلات، ويُزامن كل المساهمين مستودعاتهم معه. المطورون هم نقاط فرعية («عملاء» لنقطة الالتقاء المركزية)، ويتزامنون مع المركز.

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

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

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

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

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

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

هذا شكل من أشكال أسلوب «المستودعات العديدة». تتّبعه غالبًا المشروعات العملاقة ذات المئات من المساهمين. من أشهرها نواة لينكس. وفيه نجد عددًا من مديري الدمج، كلٌ منهم مسؤول عن جزء معين من المستودع، ويسمون المساعدين (lieutenants). ولجميع المساعدين مدير دمج واحد يسمى الزعيم أو الدكتاتور الخيّر (benevolent dictator). ويدفع الزعيم إلى المستودع المرجِع، الذي يجذب منه جميع المساهمين. تجري هذه العملية هكذا (انظر شكل أسلوب الزعيم والمساعدين):

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

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

عندما تنوي دمج عمل جديد، من الحسن أن تجربه أولًا في فرع موضوع: فرع مؤقت تُنشئه خصيصًا لتجربة هذا العمل الجديد. فإنك هكذا تستطيع بسهولة تعديل كل رقعة على حدة، أو تركها إن لم تكن صالحة، حتى تعود إليها فيما بعد. إذا كنت تسمي فروعك بأسماء سهلة وذات صلة بالعمل التي تنويه فيها، مثل ruby_client أو شيء واضح مثله، فإنك تتذكره بسهولة عندما تعود إليه إن اضطررت لتركه وقتًا. بل إن القائمين على مشروع جت يميلون إلى استعمال «مساحات الأسماء» في أسماء الفروع، مثل sc/ruby_client، حيث sc اختصار اسم المساهم. كما تتذكر، تستطيع إنشاء فرعًا من فرعك الرئيس هكذا:

وإذا أردت الانتقال إليه بمجرد إنشائه، فنفذ أمر السحب مع خيار الفرع checkout -b:

أنت الآن جاهز لدمج المساهمات في فرع الموضوع هذا، ثم تحديد ما إذا كنت تريد دمجها في أحد الفروع الطويلة العمر في مشروعك.

إذا وصلتك رقعة ناتجة من برنامج git diff أو إحدى نسخ برنامج diff اليونكسي (وهذا ليس مستحَبًّا؛ انظر الفصل التالي)، فيمكنك تطبيقها بأمر git apply. بفرض أنك حفظها في ملف /tmp/patch-ruby-client.patch، يمكنك تطبيقها هكذا:

هذا يعدّل ملفات مجلدك الحالي. يكاد هذا يطابق تنفيذ أمر patch -p1 لتطبيقها، لكن أمر جت شكاك وصارم فيقبل تطابقات جزئية أقل مما يقبل أمر patch. وإنه يتعامل مع إضافة الملفات وحذفها ونقلها، إذا كانت موصوفة بصيغة فروقات جت (git diff). وهذا لا يفعله patch. وآخر فرق هو أن أمر جت git apply إما يطبق الرقعة كلها وإما يتراجع عنها كلها. لكن patch يستطيع تطبيق الرقع جزئيا، فيترك ملفاتك في حالة غريبة. فعموما أمر جت حريص ومحافظ أكثر من أمر patch.

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

يمكنك كذلك أن تستعمله للتحقق أن الرقعة ستطبق بنظافة قبل تطبيقها فعلًا؛ نفّذ git apply --check على ملف الرقعة:

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

إذا كان المساهم يستخدم جت وكان لطيفًا واستعمل أمر تنسيق الرقع git format-patch لإنشاء رقعته، فإن مهمتك أيسر لأن الرقعة تحوي لك معلومات المؤلف ورسالة الإيداع. فإذا استطعت أن تحُثّ مساهميك على استعمال أمر تنسيق الرقع من جت بدلًا من أمر الفروق (git diff، أو diff اليونكسي)، فافعل. فلا تستعمل أمر تطبيق الرقع المجردة git apply إلا للرقع الأثرية وأشباهها.

لتطبيق رقعة أنشأها أمر تنسيق الرقع format-patch، استعمل أمر تطبيق الرقع البريدية git am. (اسمه am لأنه لتطبيق (‪“apply”‬) سلسلة من الرقع من صندوق بريد شابكي (‪“mailbox”‬).) ونظريا، git am صُمِّم ليقرأ ملف mbox، وهو صيغة نصية ميسورة لتسجيل رسالة أو عدة رسائل بريدية في ملف نصي واحد. وتشبه هذا:

هذا أول ناتج أمر تنسيق الرقع الذي رأيته في فصل المساهمة السابق. وهو أيضا موافق لصيغة mbox. فإذا أرسل إليك أحدٌ رقعةً كما ينبغي: بأمر إرسال البريد git send-email، ونزّلتَ هذه الرسالة بصيغة mbox، فيمكنك إذًا أن تنفذ git am على هذا الملف، وسيبدأ في تطبيق جميع الرقع التي يجدها فيه. وإذا كان تطبيق عميل بريدك يستطيع حفظ عدة رسائل بصيغة mbox، فتستطيع حفظ سلسلة كاملة من الرقع في ملف واحد ثم تنفيذ أمر تطبيق الرقع البريدية git am عليه لتطبيقها واحدةً واحدة.

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

نرى أن الرقعة طبّـقت بنظافة وأنشئ لك إيداعًا جديدًا. أخذ جت معلومات المؤلف من خانة المرسِل (From:) وخانة التاريخ (Date:) اللذين في ترويسة البريد، وأنشأ رسالة الإيداع من عنوان البريد (Subject:) ومن الجزء السابق للرقعة في متن البريد (‪“body”‬). مثلا إذا كانت هذه الرقعة هي المثال الذي ذكرناه عن صيغة mbox قبل قليل، فإن إيداعها سيكون مثل هذا:

معلومات المودِع (Commit) تبيّن الذي طبّـق الرقعة ومتى طبّـقها. ومعلومات المؤلف (Author) تبين الذي صنع التعديلات نفسها وأنشأ الرقعة، ومتى أنشأها.

لكن من الوارد ألا تطبق الرقعة بنظافة. ربما تفرّق فرعك الرئيس وشطّ بعيدًا عن الفرع الذي بُنيت الرقعة عليه. وربما تعتمد هذه الرقعة على رقعةٍ أخرى لم تطبّـقها بعد. فعندئذٍ سيفشل أمر التطبيق وسيسألك ماذا تريد أن تفعل:

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

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

في حالتنا هذه، بغير الخيار -3 فإن الرقعة كانت ستكون «متنازِعة». لكن بالخيار -3 استطاع جت تطبيقها بنظافة.

إذا كنت تطبق عددًا من الرقع من ملف mbox، فيمكنك تطبيقها تفاعليًّا، ليقف الأمر قبل كل رقعة ليسألك إذا ما كنت تريد تطبيقها؛ هذا بالخيار --interactive أو اختصاره -i:

هذا جميل إذا كان لديك عددٌ من الرقع المحفوظة، لأنك عندئذٍ تستطيع رؤية الرقعة أولا إن لم تتذكرها، وكذلك ألا تكرر تطبيقها إذا كنت قد فعلت سابقًا.

عندما تفرغ من تطبيق كل الرقع وتودِعها في فرع الموضوع، ابدأ في النظر فيما إذا كنت تريد دمجها في فرعٍ طويل العمر، وكيف.

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

مثلا لدينا مستودعٌ فرعه الرئيس master وفيه أعمال في فرعين اسمهما ruby_client و php_client مثل شكل تاريخ فيه فرعا موضوعين، فإذا دمجنا ruby_client ثم php_client، سيبدو التاريخ مثل شكل بعد دمج فرعيْ الموضوعين.

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

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

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

في مشروع مصدر جت أربعة فروع طويلة العمر: master و next و seen (سابقًا pu = «تحديثات مقترحة»)، و maint لحمل الإصلاحات إلى الإصدارات القديمة (backports). عند المساهمة، فإن المساهمات تُجمع في فروع موضوعات في مستودع المشرف بطريقة تشبه ما شرحنا سابقا (انظر إدارة مجموعة كبيرة من المساهمات المتوازية في فروع موضوعات). عندئذٍ تُقيَّم موضوعات المساهمات لتحديد صلاحيتها وصحتها، أم أنها تحتاج عملًا. فإذا كانت صالحة فإنها تدمج في next ويُدفع هذا الفرع إلى المستودع العمومي ليجرب الجميع الموضوعات المدموجة كلها معًا.

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

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

يحب مشرفون آخرون إعادة تأسيس المساهمات (rebase) على فرعهم الرئيس أو اصطفائها (cherry-pick)، بدلًا من دمجها فيه، ليبقوا تاريخ الإيداعات خطيًّا قدر الإمكان. فإذا عملت في فرع موضوع ورأيت أن تدمجه، فانتقل إلى هذا الفرع ونفّذ أمر إعادة التأسيس فيه لإعادة صناعة إيداعاته على الفرع الرئيس. فإذا تم هذا بنجاح، فيمكنك تسريع فرعك الرئيس، وسيكون تاريخ مشروعك خطيًّا.

والطريقة الأخرى لنقل تغييرات من فرع إلى آخر هي باصطفائه (cherry-pick). فالاصطفاء في جت هو مثل إعادة التأسيس لكن لإيداع وحيد. فإنه يتناول رقعة إيداع سابق ويحاول تطبيقها على الفرع الحالي. يفيد هذا إذا كان لديك عددٌ من الإيداعات في فرع موضوع وتريد دمج واحدٍ فقط منها، أو عندك إيداعٌ واحد فقط في فرع موضوع وترى أن اصطفاءه خيرٌ من إعادة تأسيسه. للمثال، قل إن لديك مشروعا مثل هذا:

فإذا أردت جذب الإيداع e43a6 إلى فرع master، فيمكنك تنفيذ هذا وأنت في الفرع الهدف master:

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

يمكنك عندئذٍ إزالة فرع الموضوع وهجر إيداعاته التي لم تردها.

إذا كنت كثير الدمج وإعادة التأسيس، أو فروع موضوعاتك طويلة العمر، ففي جت وسيلة نافعة اسمها ‪“rerere”‬.

إن ‪“rerere”‬ اختصار ‪“reuse recorded resolution”‬ أي «إعادة تطبيق الحل المسجل للنزاع». وهي لتقليل الجهد اليدوي في حل النزاعات. فعند تمكينها، سيلتقط جت صورة من المشروع عند حدوث نزاع وصورة بعد حله، وإن لمح جت هذا النزاع مرة أخرى فسيصلحه لك من نفسه كما أصلحته أنت أول مرة تماما.

هذه الميزة جزءان: إعداد تهيئة، وأمر. فأما الإعداد فهو rerere.enabled، وهو صغير ويسهل إضافته إلى تهيئة جت العامة في نظامك:

فمن الآن، وقتما واجهت نزاع دمج وحللته وأودعت، فسيسجل جت الحل إن احتجته في المستقبل.

وإن احتجت التعامل مع ذاكرة «مُعاودة المُصالحات المُسجلة»، فاستعمل الأمر git rerere. فعند تنفيذه منفردًا (بغير معاملات)، فإن جت ينظر في ذاكرة حلول النزاعات ويبحث عن ما يطابق النزاع الحالي ويحله (ولكن هذا يحدث تلقائيا إذا كان rerere.enabled بـ true). ولهذا الأمر أوامر فرعية لرؤية ما سيسجل، ولحذف حل نزاع معين، ولمسح ذاكرة الحلول كلها. سنفصّل الحديث عن هذا كله في فصل معاودة مصالحة مسجلة (rerere) في الباب السابع.

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

إذا كنت فعلًا توقّع وسومك، فقد يتعبك توزيع المفتاح العمومي الذي توقّع به. مشرف مشروع جت حل هذا بجعل مفتاحه العام كتلة رقْمية في المستودع (‪“blob”‬)، ووسمها بوسم يشير إليها مباشرةً. إذا أردت فعل هذا، فعليك أولا تحديد المفتاح الذي تريد التوقيع به، فاسرد مفاتيحك بأمر gpg --list-keys:

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

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

فإذا دفعت الوسوم بالأمر git push --tags، فإنك ستشارك الوسم maintainer-pgp-pub مع الجميع. وإذا أراد أحدٌ أن يتحقق وسمًا، فإنه يجذب من بيانات جت الكتلةَ الرقمية المشار إليها بالوسم ويستوردها إلى GPG:

فيمكنه بهذا المفتاح أن يتحقق كل وسومك الموقعّة. وحتى إنك تستطيع أن تشرح خطوات التحقق بدقة في رسالة الوسم نفسه، ليراها من يُظهره بالأمر git show «وسم-المفتاح».

لا يرافق إيداعات جت أرقامٌ متزايدة بإطراد مثل v123 أو نحوها. فإذا أردت لإيداعٍ اسمًا يلائم البشر، فيمكنك تنفيذ أمر git describe على هذا الإيداع. فيصنع لك جت اسمًا يتكون من اسم آخر وسم قبل هذا الإيداع، ثم عدد الإيداعات بينهما، ثم يختمه بمختصر بصمة الإيداع مسبوقة بحرف ‪“g”‬ (اختصار Git):

هكذا تستطيع تصدير لقطة أو بناء من مشروعك وتسمّيه اسمًا يفهمه الناس. بل إنك إذا بنيت جت من مصدره البرمجي المستنسخ من مستودعه الرسمي، فإن git --version سيجيب بشيء مثل هذا. وإذا طلبت وصف إيداع قد وسمته هو نفسه، فإن git describe يعطيك اسم الوسم فقط.

أمر الوصف بطبيعته لا يعتمد إلا على الوسوم المعنونة (وهي الوسوم المنشأة بخيارات أشهرها -a و -s). أما إذا أردته أن ينظر إلى الوسوم الخفيفة كذلك، فأضف خيار --tags إليه. ويمكنك كذلك استعمال هذا الاسم الوصفي مع أمر السحب git checkout وأمر الإظهار git show، على أن ذلك يعتمد على مختصر البصمة الذي في آخره فقد لا يدوم صلاحه. فمثلا انتقل مشروع نواة لينكس من ثماني محارف إلى عشرة محارف لضمان تفرّد بصمات الكائنات، فأُبطلت الأسماء القديمة الناتجة من git describe.

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

فإذا فتح أحدٌ هذه الحزمة، سيجد آخر نسخة من مشروعك الذي في مجلد project. وتستطيع كذلك إنشاء حزمة بصيغة zip، بأمر كبير الشبه بالسابق، لكن بالخيار --format=zip لأمر الحزم:

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

حان الآن موعد إخبار قائمتك البريدية بما حدث في مشروعك. أمر السجل الموجز git shortlog هو طريقة ظريفة سريعة لصياغة «سجل تغييرات» مشروعك منذ آخر إصدارة أو رسالة بريدية. فإنه يوجز كل الإيداعات التي في النطاق الذي تحدده. فمثلا الأمر التالي يخبرك بموجز الإيداعات جميعًا منذ آخر إصدارة، إذا كانت آخر إصدارة من هذا المشروع اسمها v1.0.1:

موجز واضح لكل الإيداعات منذ v1.0.1، ومجموعة بمؤلف الإيداع، حتى ترسلها إلى قائمتك البريدية.

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

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

ثم اختر تبويب ‪“SSH keys”‬ من القائمة اليسرى.

ثم اضغط زر ‪“Add an SSH key”‬ لإضافة مفتاحك، وأعطه اسمًا، وانسخ في الحقل النصي الكبير محتوى ملف مفتاحك العمومي (~/.ssh/id_rsa.pub أو كما سمّيته)، ثم اضغط ‪“Add key”‬.

الخطوة التالية، إن أردت، هي تغيير الصورة المولدة آليًّا إلى صورة من اختيارك. اذهب إلى تبويب ‪“Profile”‬ (فوق تبويب ‪“SSH Keys”‬) واضغط على ‪“Upload new picture”‬.

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

من الآن سيرى الناس صورتك بجوار اسمك عندما تتفاعل على الموقع.

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

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

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

وأخيرا، للمزيد من الأمان، يقينًا عليك إعداد «الاستيثاق الثنائي» (وتسمى كذلك «المصادقة الثنائية» أو «التحقق بخطوتين») (‪“2FA”‬، اختصار Two-factor Authentication). وهي طريقة استيثاق بدأت بالانتشار حديثًا لتقليل احتمال اختراق حسابك إن سُرقت كلمة مرورك بطريقةٍ ما. وتفعيلها يجعل جت‌هب يسألك عن طريقتين مختلفتين للاستيثاق، لكيلا يتعرض حسابك للاختراق إن استولى أحد على إحداهما.

يمكنك إعداد الاستيثاق الثنائي من تبويب ‪“Security”‬ في صفحة إعدادات حسابك.

إذا ضغطت زر ‪“Set up two-factor authentication”‬ ستنتقل إلى صفحة إعدادات يمكنك فيها اختيار تطبيق هاتف محمول لتوليد الرمز الثانوي («كلمة م‍رور استخدام واحد مؤقتة» ‪“time based one-time password”‬)، أو أن تجعل جت‌هب يرسل إليك الرم‍ز عبر رسالة محمول قصيرة (SMS) في كل م‍رة تحتاج إلى الدخول إلى الموقع.

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

تحفظ جميع الخطاطيف في مجلد hooks داخل مجلد جت. أي في .git/hooks في معظم المستودعات. وعندما تبتدئ مستودعًا جديدًا بأمر الابتداء git init، فإن جت يملأ مجلد الخطاطيف بأمثلة بُريمجات (التي قد يفيد بعضها بلا تغيير)، وفيها شرح مدخلات كل بريمج. أكثر الأمثلة مكتوبة بلغة الصدَفة (shell)، والبعض بلغة Perl. ولكن أي ملف تنفيذي بالاسم المناسب سيعمل؛ اكتبه بـ Python أو بـ Ruby أو بما تشاء. وإذا أردت استعمال بُريمجات الخطاطيف المرفقة مع جت، عليك تغيير أسمائها، فأسماؤها جميعًا تنتهي بالامتداد .sample.

لتفعيل بُريمج خطاف، ضع ملفًا تنفيذيًّا بالاسم المناسب (بغير امتداد) في مجلد hooks في مجلد .git في مستودعك، ومن وقتئذٍ فصاعدًا سيُنفّذ. نمرّ الآن على أهم الخطاطيف ونسرد أسماءها.

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

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

تجد على موقع Dulwich الرسمي توثيق الواجهة البرمجية ودروسًا وأمثلة كثيرة على فعل أمور معينة به.