احترف Git

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

للينكس:

لماك أو إس:

لويندوز:

ثم اكتب:

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