مقدمة إلى Git Merge و Git Rebase: ماذا يفعلون ومتى يستخدمونها

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

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

هذا السؤال قد قسم مجتمع Git. يعتقد البعض أنه يجب عليك دائمًا إعادة الدحض والبعض الآخر يجب دمجه دائمًا. كل جانب لديه بعض الفوائد المقنعة.

جيت دمج

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

دمج ماستر -> فرع الميزة

الايجابيات

  • بسيطة ومألوفة
  • يحافظ على التاريخ الكامل والنظام الزمني
  • يحافظ على سياق الفرع

سلبيات

  • يمكن أن يصبح سجل الالتزام ملوثًا بسبب الكثير من عمليات الدمج
  • يمكن أن تصبح تصحيح الأخطاء باستخدام bitect git أصعب

كيف افعلها

دمج الفرع الرئيسي في فرع الميزة باستخدام أوامر السحب والدمج.

ميزة بوابة الخروج $
$ git merge master
(أو)
ميزة $ git merge master

سيؤدي هذا إلى إنشاء "التزام دمج" جديد في فرع الميزة الذي يحتفظ بتاريخ كلا الفرعين.

بوابة Rebase

Rebase هي طريقة أخرى لدمج التغييرات من فرع إلى آخر. يقوم Rebase بضغط كل التغييرات في "تصحيح" واحد. ثم يقوم بدمج التصحيح في الفرع المستهدف.

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

Rebases هي الطريقة التي يجب أن تمر بها التغييرات من أعلى التسلسل الهرمي للأسفل
Rebase فرع الميزة إلى سيد

الايجابيات

  • تبسيط تاريخ يحتمل أن تكون معقدة
  • من السهل التعامل مع التزام واحد (مثل التراجع عنها)
  • يتجنب دمج الالتزام "الضوضاء" في repos مشغول مع فروع مشغول
  • ينظف الالتزامات المتوسطة بجعلها التزامًا واحدًا ، مما قد يكون مفيدًا لفرق DevOps

سلبيات

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

كيف افعلها

إعادة قاعدة فرع الميزة على الفرع الرئيسي باستخدام الأوامر التالية.

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

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

إعادة الربط التفاعلية

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

ميزة بوابة الخروج $
$ بوابة rebase ، أنا سيد

سيؤدي هذا إلى فتح المحرر عن طريق سرد جميع الالتزامات التي على وشك أن يتم نقلها.

اختيار 22d6d7c رسالة الالتزام رقم 1
اختيار 44e8a9b رسالة الالتزام رقم 2
اختيار رسالة 79f1d2h الالتزام رقم 3

هذا يحدد بالضبط كيف سيبدو الفرع بعد إجراء rebase. من خلال إعادة ترتيب الكيانات ، يمكنك جعل السجل يبدو كما تريد. على سبيل المثال ، يمكنك استخدام أوامر مثل fixup أو squash أو edit etc ، بدلاً من الانتقاء.

أي واحد للاستخدام

إذن ما الأفضل؟ ماذا يوصي الخبراء؟

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

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

النظر في مستوى rebasing و Git الكفاءة في جميع أنحاء مؤسستك. حدد الدرجة التي تُقدر بها بساطة إعادة التسعير مقارنةً بإمكانية التتبع وتاريخ الدمج.

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

ماذا أوصي؟

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

من خلال مراعاة الظروف والإرشادات التالية ، يمكنك الحصول على أفضل النتائج من Rebase:

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

خاتمة

آمل أن يكون هذا التفسير قد أعطى بعض الأفكار حول Git merge و Git rebase. دمج مقابل استراتيجية rebase دائما قابلة للنقاش. ولكن ربما تساعد هذه المقالة في تبديد شكوكك وتسمح لك بتبني نهج مناسب لفريقك.

أنا أتطلع إلى الكتابة على سير عمل Git ومفاهيم Git. قم بالتعليق على المواضيع التي تريد أن أكتب عنها بعد ذلك. في صحتك!

كود = قهوة + مطور

هنا مرجع آخر مفيد

  • كيفية تبني استراتيجية Git المتفرعة

مدرسة الترميز لمطوري البرمجيات