مقدمة إلى Git merge and rebase: ما هي ، وكيفية استخدامها

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

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

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

جيت دمج

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

الايجابيات

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

سلبيات

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

كيف افعلها

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

$ git checkout feature $ git merge master (or) $ git merge master feature

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

Git Rebase

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

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

إعادة الأسس هي الطريقة التي يجب أن تمر بها التغييرات من أعلى التسلسل الهرمي إلى أسفل ، وعمليات الدمج هي كيفية تدفقها إلى أعلى

الايجابيات

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

سلبيات

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

كيف افعلها

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

$ git checkout feature $ git rebase master

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

إعادة التأسيس التفاعلي

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

$ git checkout feature $ git rebase -i master

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

pick 22d6d7c Commit message#1 pick 44e8a9b Commit message#2 pick 79f1d2h Commit message#3

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

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

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

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

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

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

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

ماذا أوصي؟

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

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

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

استنتاج

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

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

code = coffee + developer

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