Git: إصلاح الخلل والتزامات التثبيت

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


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

إصلاح الخلل في عمليات ارتكابها

هنا سنلقي نظرة على العديد من السيناريوهات للأخطاء في عمليات التنفيذ وتصحيحها.

▍ السيناريو رقم 1

لنفترض أنك ارتكبت الكثير من الملفات وأدركت أن رسالة الالتزام لم تكن واضحة جدًا. بعد ذلك ، قررت تغيير هذه الرسالة. للقيام بذلك ، استخدم الأمر git commit --amend . هنا مثال على تطبيقه:

 git commit --amend -m "New commit message" 

▍ السيناريو رقم 2

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

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

 git add file6 git commit --amend --no-edit 

علامة --no-edit يعني أن رسالة الالتزام لا تتغير.

▍ السيناريو رقم 3

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

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

 git config user.email "your email id" 

لنفترض أنك نسيت القيام بهذا الإعداد وقمت بالفعل بالالتزام الأول. تصحيح الوضع يمكن بالفعل مألوف لنا amend الفريق. باستخدامه ، يمكنك تغيير المعلومات حول مؤلف الالتزام السابق:

 git commit --amend --author "Author Name <Author Email>" 

▍ ملاحظة

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

وضع النظام في تاريخ ارتكابها

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

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

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


تاريخ الإلتزامات في المستودع المحلي

كيفية ترتيب تاريخ الالتزام؟ لحل هذه المشكلة ، يمكنك استخدام git rebase .

الأمر ▍Git rebase

اعتبر git rebase كمثال.


تلتزم في فرع الإصدار وفي فرع الميزة

هناك ثلاث عمليات تنفيذ في فرع Release : Rcommit1 و Rcommit2 و Rcommit3 . قمت بإنشاء فرع Feature الخاص بك من فرع Release عندما يكون لديه التزام واحد فقط - Rcommit1 . بعد ذلك ، أضفت التزامين إلى فرع Feature . هذان هما Fcommit1 و Fcommit2 . هدفك هو تحميل الالتزامات من فرع Release إلى فرع Feature الخاص بك. للقيام بذلك ، ستستخدم الأمر rebase .

سنستخدم release الأسماء feature للفرعين قيد النظر.

ونتيجة لذلك ، سيبدو استخدام rebase كما يلي:

 git checkout feature git rebase release 

▍ ميزات الأمر rebase

rebase استخدام الأمر rebase للتأكد من أن فرع Feature لديه كود جديد من فرع Release .

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


فرع ميزة وثلاث خطوات من الأمر rebase

الخطوة الأولى

عند استدعاء الأمر ، يشير فرع Feature إلى رأس فرع Release . بعد ذلك ، هناك ثلاث عمليات تنفيذ في فرع Feature : Rcommit1 و Rcommit2 و Rcommit3 . ربما هنا سيكون لديك سؤال حول ما حدث مع Fcommit1 و Fcommit2 . لم تختف هذه الالتزامات ، وسيتم استخدامها في الخطوات التالية.

الخطوة الثانية

يحاول Git الآن إضافة التزام Fcommit1 إلى فرع Feature . إذا لم يكن هناك تعارض ، Fcommit1 إضافة Rcommit3 بعد Rcommit3 . إذا تم الكشف عن وجود تعارض ، فسيبلغ Git عنه وسيتعين عليك حل هذا التعارض يدويًا.

الخطوة الثالثة

بعد إضافة الالتزام Fcommit1 إلى فرع Feature ، يحاول Git إضافة Fcommit2 هناك Fcommit2 . هنا ، مرة أخرى ، في حالة عدم وجود تعارضات ، Fcommit2 إضافة Fcommit1 بعد Fcommit1 ويتم إكمال العملية بنجاح. إذا تم الكشف عن وجود تعارض ، فإن Git ، كما كان من قبل ، سيبلغ عن هذا ويعرض التعامل معه.

بعد rebase الأمر rebase يمكنك أن ترى أن فرع Feature لديه Rcommit3 Fcommit1 و Fcommit2 و Fcommit2 و Fcommit2 و Fcommit2 .

▍ ملاحظة

عند العمل باستخدام Git ، يتم استخدام كل من أمر merge والأمر rebase . هذا لا يعني أن أحدهما أفضل من الآخر.

إذا استخدمت أمر merge ، فستتلقى التزامًا merge . إذا كنت تستخدم rebase ، فلن يكون لديك أي rebase إضافية.

من المستحسن استخدام هذه الأوامر في مواقف مختلفة. لذا ، يعد rebase مناسبًا لتحديث رمز المستودع المحلي بناءً على أحدث رمز من المستودع البعيد. استخدم أمر merge لتنفيذ طلبات السحب لدمج فرع Feature مع الفرع Release أو Master .

الملخص

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

أعزائي القراء! هل واجهت فوضى في عمليات git؟