احترف 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 لهذا:

يمكنك إعطاء الأمر أسماء ملفات أو مجلدات أو أنماط توسيع المسارات (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 Demystified في تفاصيل أعمق كثيرا عن أمر الإرجاع وماذا يفعل وكيف تتقنه لتفعل أفعالا شيقة وممتعة جدا.

ماذا لو أدركت أنك لم تعد تريد تعديل ملف 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 إلى أمر الوسم:

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

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

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

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

تنفيذ 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.

يمكنك رؤية فرعَي 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.

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

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

عليك الآن العمل على الإصلاح العاجل. لننشئ فرع 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.

إذا كان لديك بالفعل فرعا محليا وتريد ضبطه ليجذب من فرع بعيد جذبته للتو، أو تريد تغيير الفرع المنبع الذي تتعقبه، استعمل الخيار -u أو --set-upstream-to مع أمر التفريع git branch لضبطه بأمر صريح في أي وقت.

لرؤية الفروع المتعقِّبة التي ضبطتها، استعمل الخيار -vv مع أمر التفريع git branch، ليسرد لك فروعك المحلية مع معلومات مزيدة فيها ما يتعقبه كل فرع وإذا كان فرعك متقدما عنه (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 سينظر أيّ مستودع وأيّ فرع يتعقبهما فرعك الحالي، ويستحضر ما في المستودع البعيد ويحاول دمجه في فرعك.

الأفضل عمومًا هو الاستخدام الصريح لأمرَي الاستحضار fetch والدمج merge، فالسحر الذي يقوم به أمر الجذب كثيرًا ما يكون مُلغِزًا.

لنقُل إنك قضيت ما تريد من فرع بعيد، مثلا انتهيت أنت وزملاؤك من إضافة ميزة جديدة ودمجتموها في الفرع الرئيس. يمكنك حذف فرع بعيد بالخيار --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 الذي ثبتَّ عليه جت‌لاب، ثم لُج بحساب المدير. اسم المستخدم المبدئي هو admin@local.host، وكلمة المرور المبدئية هي 5iveL!fe (والتي عليك تغييرها فورا). بعد الولوج، اضغط على رمز ‪“Admin area”‬ (منطقة الإدارة) في القائمة التي على اليمين بالأعلى.

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

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

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

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

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

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

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

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