Git rebase: كل ما تريد معرفته

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

انفجار جيت

محبطًا من أنظمة التحكم في الإصدارات الأخرى والتحديثات والالتزامات البطيئة الخاصة بها ، وضع Linus Torvalds ، من شهرة Linux kernel ، جانباً شهرًا في عام 2005 لكتابة برنامجه الخاص. أطلق عليها اسم Git.

لقد روجت مواقع مثل GitHub و GitLab و BitBucket بشكل تكافلي واستفادت من Git. يتم استخدام Git اليوم على مستوى العالم ، مع 98 في المائة من 71 ألف مستجيب في استطلاع عام 2022 باستخدام Git كنظام التحكم في الإصدار.

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

ذات صلة كيفية اختيار نموذج Git لسير العمل والتفريع المناسب لفريقك

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

يعد الأمر Git rebase طريقة أخرى لنقل التغييرات من فرع إلى فرع آخر. أمرا merge وإعادة التأسيس لهما أهداف متشابهة ، لكنهما rebase بطرق مختلفة ويؤديان إلى نتائج مختلفة قليلاً.

ما هو Git merge؟

إذن ما هو أمر merge Git؟ لنفترض أنك قمت بإنشاء فرع يسمى dev-branch للعمل على ميزة جديدة.

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

يمكننا التأكد من أننا في الفرع master عن طريق التحقق صراحة من ذلك قبل الدمج.

 بوابة الخروج سيد

يمكننا الآن إخبار Git بدمج dev-branch الحالي ، وهو الفرع master .

 git merge dev-Branch 

لقد اكتمل merge بالنسبة لنا. إذا قمت بتسجيل الخروج من الفرع master وقمت بتجميعه ، فسيحتوي على الميزة المطورة حديثًا فيه. ما قام به Git في الواقع هو دمج ثلاثي. يقارن أحدث عمليات الارتباطات في الفروع master dev-branch التطوير ، والالتزام في الفرع master مباشرة قبل إنشاء dev-branch . ثم يقوم بتنفيذ التزام على الفرع master .

تعتبر عمليات الدمج غير مدمرة لأنها لا تحذف أي شيء ولا تغير أيًا من محفوظات Git. لا يزال dev-branch موجودًا ، ولم يتم تغيير أي من عمليات التنفيذ السابقة. يتم إنشاء التزام جديد يلتقط نتائج الدمج ثلاثي الاتجاهات.

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

تم دمج فرع dev-branch master .

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

ذات صلة كيف تعمل فروع جيت؟

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

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

كنت ستستخدمهم مثل هذا:

 خبأ

git merge dev-Branch

خبأ البوب

النتيجة النهائية هي فرع مدمج ، مع استعادة التغييرات غير المحفوظة.

ما هو Git rebase؟

يحقق أمر Git rebase أهدافه بطريقة مختلفة تمامًا. يستغرق الأمر جميع الالتزامات من الفرع الذي ستعيد تأسيسه ويعيد تشغيلها في نهاية الفرع الذي تعيد التأسيس عليه.

بأخذ مثالنا السابق ، قبل تنفيذ أي إجراء ، يبدو مستودع Git الخاص بنا على هذا النحو. لدينا فرع يسمى dev-branch ونريد نقل هذه التغييرات إلى الفرع master .

بعد تغيير العنوان الأساسي ، يبدو rebase زمني واحد وخطي تمامًا للتغييرات.

تمت إزالة dev-branch dev ، وأضيفت dev-branch الفرع الرئيسي. والنتيجة النهائية هي نفسها كما لو أن الالتزامات في dev-branch قد تم الالتزام بها فعليًا مباشرة إلى الفرع master في المقام الأول. لا يتم تعليق الالتزامات على الفرع master فقط ، بل يتم "إعادة تشغيلها" وإضافتها جديدة.

هذا هو السبب في أن الأمر rebase يعتبر مدمرًا. لم يعد الفرع المعاد تأسيسه موجودًا كفرع منفصل ، وتمت إعادة كتابة محفوظات Git لمشروعك. لا يمكنك في وقت لاحق تحديد الالتزامات التي تم إجراؤها في الأصل dev-branch .

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

كيفية تغيير مكان إقامته في فرع آخر

لنجرب مثال git rebase . لدينا مشروع بفرع يسمى new-feature . سوف rebase تأسيس هذا الفرع على الفرع master مثل هذا.

أولاً ، نتحقق من عدم وجود تغييرات معلقة في الفرع master .

 حالة بوابة

نتحقق من فرع new-feature .

 بوابة الخروج ميزة جديدة

نطلب من rebase إعادة تعيين الفرع الحالي إلى الفرع الرئيسي.

 git rebase master

يمكننا أن نرى أنه لا يزال لدينا فرعين.

 فرع بوابة

نعود إلى الفرع master

 بوابة الخروج سيد

نقوم بدمج فرع الميزة الجديدة في الفرع الحالي ، وهو في حالتنا الفرع master .

 بوابة دمج ميزة جديدة 

ومن المثير للاهتمام ، أنه لا يزال لدينا فرعين بعد الدمج النهائي.

يتمثل الاختلاف الآن في أن رأس فرع new-feature ورئيس الفرع master قد تم تعيينهما للإشارة إلى نفس الالتزام ، ولا يظهر سجل Git أنه اعتاد أن يكون فرع new-feature منفصلة ، بصرف النظر عن تسمية الفرع.

Git Rebase مقابل Merge: أيهما يجب أن تستخدمه؟

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

إذا كنت المطور الوحيد الذي يستخدم مستودعًا ، فهناك فرصة أقل للقيام بشيء ما باستخدام rebase بيانات جديدة تكون كارثية. لا يزال بإمكانك إعادة تحديد rebase في الاتجاه الخاطئ على سبيل المثال ، وإعادة تحديد موقع rebase الرئيسي الخاص بك إلى فرع new-feature . لاستعادة الفرع master الخاص بك ، ستحتاج إلى إعادة rebase مرة أخرى ، هذه المرة من فرع new-feature إلى فرعك master . سيؤدي ذلك إلى استعادة فرعك master ، وإن كان ذلك بتاريخ غريب المظهر.

لا تستخدم rebase في الفروع المشتركة حيث من المحتمل أن يعمل الآخرون. ستتسبب التغييرات التي أجريتها على المستودع الخاص بك في حدوث مشكلات لكثير من الأشخاص عندما تدفع التعليمات البرمجية المعاد تأسيسها إلى مستودعك البعيد.

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

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

ذات صلة كيفية الإصلاح أو التحرير أو التراجع عن التزامات Git (تغيير سجل Git)

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

هل تريد إعادة التأسيس أم لا؟

قد يتم حظر Rebase في مشروعك. قد تكون هناك اعتراضات محلية وثقافية. تعتبر بعض المشاريع أو المنظمات تغيير العنوان الأساسي rebase من أشكال البدعة وفعل تدنيس. يعتقد بعض الناس أن تاريخ Git يجب أن يكون سجلًا دائمًا لا يمكن انتهاكه لما حدث. rebase ، قد تكون إعادة الأساسي غير مطروحة على الطاولة.

ولكن ، عند استخدامها محليًا ، في الفروع الخاصة ، rebase عملية تغيير العنوان الأساسي أداة مفيدة.

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

افعل ذلك وستتجنب أي مشاكل.

ذات صلة: كيفية التحقق من إصدار Git الخاص بك وتحديثه