احترف Git

ماذا يحدث عندما تنشئ فرعًا جديدًا؟ الإجابة: ينشئ جت إشارة جديدة لك لتحركها كما تشاء. لنقُل إنك أردت إنشاء فرع جديد اسمه 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 ليحكون القصة بالطريقة الأنسب للقراء في المستقبل.

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

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