ما هي أخطاء Git الشائعة وكيفية إصلاحها؟

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

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

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

ملفات / أدلة غير مرحلية من الفهرس

أثناء إضافة و / أو تعديل الملفات ، غالبًا ما تميل إلى استخدام السلوك الافتراضي لأمر 'git add' ، وهو إضافة جميع الملفات والأدلة إلى الفهرس.في كثير من الأحيان تشعر بالحاجة إلى إلغاء ترتيب ملفات معينة أو تعديلها مرة أخيرة قبل الالتزام بها.

بناء الجملة: إعادة تعيين بوابة

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

قم بتحرير آخر رسالة ملتزمة

أمر: git الالتزام - تعديل
يمكنك تحرير أحدث رسالة الالتزام دون إنشاء رسالة جديدة. لسرد سجلات التنفيذ ، قمت بتعيين اسم مستعار 'Hist':
أمر: تكوين git - global alias.hist 'سجل - جميل = تنسيق: '٪ C (أصفر)٪ h٪ Creset٪ ad | ٪ C (أخضر)٪ s٪ Creset٪ C (أحمر)٪ d٪ Creset٪ C (أزرق) [٪ an] '- رسم بياني - تاريخ = قصير ×

ما هو مثيل جافا

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

نسيت بعض التغييرات في الالتزام الأخير

لنفترض أنك نسيت إجراء بعض التعديلات والتزمت بلقطة اللقطة الخاصة بك بالفعل ، كما أنك لا تريد الالتزام مرة أخرى لإبراز خطأك.
أمر: git الالتزام - تعديل

لقد أبرزت كيف تم إعادة إنشاء وتغيير معرّف sha-1 لكائن الالتزام الأخير. لقد تظاهرت بأنني قدمت التزامًا واحدًا مزج كل من التغييرات في واحد.

تجاهل التغييرات المحلية

إذن ، هذه حالة قمت فيها بتعديل ملف 'README' وقمت بإعداده. بعد ذلك ، قمت بتعديل نفس الملف مرة ثانية لكنني أدركت أنني لا أريد التغيير الثاني.

الآن ، اسمحوا لي بعدم التراجع عن التغيير بالكامل يدويًا ، يمكنني ببساطة سحب الإصدار المرحلي من الملف.
بناء الجملة:
بوابة الخروج -- التغييرات المحلية في ملف
بوابة الخروج -- التغييرات المحلية في جميع الملفات في الدليل & خجول & خجول

أمر: بوابة الخروج - README

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

الالتزام بالبيانات الشخصية إلى المستودع المحلي

أريد إزالة بعض البيانات من المستودع المحلي مع الاحتفاظ بالملفات في دليل العمل.
بناء الجملة:
إعادة تعيين بوابة - رأس مختلط ~
إعادة تعيين بوابة - مختلط

أمر: إعادة تعيين بوابة - رأس مختلط ~ 1
يشير HEAD ~ 1 إلى التزام قبل الالتزام الأخير الذي يشير إليه الفرع الحالي HEAD.

تمت إزالة الملفات الموجودة في اللقطة الحالية من كل من المستودع المحلي ومنطقة التدريج. أضف الأنماط التالية في ملف .gitignore العام لاستبعادها من التتبع بواسطة git.
vim ~ / .gitignore_global
# ملفات كلمة المرور #
*.البشري
*.مفتاح
* .passwd

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

الحذر: إذا فقدتها لا تستطيع git استعادتها لك لأنها لا تعرف عنها.

استبدل الالتزام الأخير بالتزام جديد

بناء الجملة: إعادة تعيين بوابة - لينة [/ HEAD ~ n>]

يقوم الخيار '–soft' فقط بإزالة الملفات الملتزمة من المستودع المحلي بينما لا تزال موجودة في الفهرس ويمكنك إعادة الالتزام بها بعد المراجعة. هي sha-1 من اللقطة التي تريد إزالتها من الريبو المحلي. حيث n هو عدد عمليات الالتزام قبل تنفيذ HEAD

أمر :إعادة تعيين البوابة - رأس ناعم ~ 1

تعديل الملفات وتنظيمها مرة أخرى

أمر: git الالتزام -m 'Adding index.html و style.css'
تبين الآن أن سجل الالتزام الخاص بك هو:

ارتكبت بيانات خاطئة

بناء الجملة:
إعادة تعيين البوابة - رأس صلب ~ n- أعد ضبط المشروع على 'n' قبل أحدث لقطة ملتزمة
إعادة تعيين بوابة - بجد- إعادة تعيين المشروع للحصول على لقطة معرّف الالتزام

أمر: إعادة تعيين البوابة - رأس صلب ~ 1

تتم إزالة أحدث الالتزام والملفات التالفة من المستودع المحلي ومنطقة التدريج وكذلك دليل العمل.

الحذر: إنه أمر خطير حيث ينتهي بك الأمر بفقدان الملفات في دليل العمل. غير مستحسن في مستودع مشترك عن بعد.

نعود إلى حالة مشروعي القديمة

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

استعادة فرع محلي محذوف

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

إذن ، HEAD @ {2} هو المؤشر عندما انتقلت إلى فرع 'old_code' ، فلنتحقق مما يلي:

بناء الجملة:بوابة الخروج -b
أمر:بوابة الخروج -b old_code HEAD @ {2}

يجب أن تكون الآن في فرع 'old_code' بأحدث أعمالك وقت إنشائها. بالإضافة إلى ذلك ، كان مؤشر 'reflog' في HEAD @ {1} هو الالتزام الأخير الذي تم إجراؤه في الفرع 'old_code'. لاستعادة هذا الفريد الالتزام فقط قم بتشغيل الأمر على النحو التالي:إعادة تعيين بوابة - hard HEAD @ {1}.يؤدي هذا أيضًا إلى استعادة الملفات المعدلة في دليل العمل.

إذا كنت تريد أن تعرف بالتفصيل كيف يعمل هذا الأمر وكيف يمكنك إدارة إدخالات 'إعادة التدوين' ، فيمكنك أيضًا قراءة رسالتي السابقة علىاستعادة الفرع المحذوف من git reflog.

التراجع عن التغييرات التي تم إجراؤها في الالتزام

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

أمر: بوابة العودة 827bc0d

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

يمكنك استخدام نفس منطق إحالة الالتزامات المتعلقة بمؤشر HEAD بدلاً من إعطاء معرف الالتزام ، كما هو الحال في HEAD ~ 3 أو HEAD ~ 4 وما إلى ذلك.

أعطيت اسمًا خاطئًا لفرعي

يمكنك إعادة تسمية اسم فرع محلي. يحدث في كثير من الأحيان أنك قد ترغب في إعادة تسمية فرعك بناءً على المشكلة التي تعمل عليها دون المرور بألم ترحيل كل عملك من مكان إلى آخر. على سبيل المثال ، يمكنك إما أن تكون في نفس الفرع أو في فرع مختلف ولا يزال بإمكانك إعادة تسمية الفرع المطلوب كما هو موضح أدناه:
بناء الجملة: فرع بوابة م
أمر: فرع بوابة - m old_code old_ # 4920

كما قد تتساءل هل يحتفظ git بمسار إعادة التسمية هذه؟ نعم ، إنها تشير إلى إدخالات 'إعادة التسجيل' الخاصة بك ، وهنا لي:

لن تؤثر إعادة تسمية فرع على فرع التتبع عن بعد. سنرى في القسم البعيد كيفية استبدال فرع في المستودع البعيد

أعد ترتيب سجلات المحفوظات قبل الدفع إلى جهاز التحكم عن بعد

كم أتمنى لو كنت قد قدمت بعض الالتزامات في وقت أبكر من غيرها ولم أكن لأقوم ببعض الالتزامات على الإطلاق. إعادة ترتيب وتحرير الالتزامات القديمة بشكل تفاعلي لإصلاح الشفرة أو تحسينها بشكل فعال
بناء الجملة: بوابة rebase -i
أمر: بوابة rebase -i fb0a90e- ابدأ في إعادة تأسيس الالتزامات التي تم إجراؤها بعد معرّف الالتزام fb0a90e

أعد زيارة git rebase الوثائق لفهم كيف تختلف إعادة تحديد القاعدة '- التفاعلية أو -' عن تغيير الأساس المعتاد.

ارتكبت تغييرات غير ذات صلة في التزام واحد

في هذه الحالة ، تحتاج إلى تقسيم الالتزام القديم المدفون إلى التزامات منطقية متعددة.
بناء الجملة: بوابة rebase -i
أمر: بوابة rebase -i fb0a90e
في محرر rebase ، يجب عليك اختيار معرف الالتزام e7aa9a5 وتغييره إلى 'تحرير' بدلاً من 'اختيار'.

ستكون الآن في إصدار المشروع من الالتزام id-e7aa9a5. أولاً ، قم بإعادة تعيين تاريخ الالتزام ومنطقة التدريج إلى أمر الالتزام السابق:إعادة تعيين بوابة HEAD ~ 1
ثانيًا ، قم بتحرير + المرحلة + تثبيت الملفات بشكل فردي
الأوامر:
git add code && git الالتزام -m 'إضافة الرموز الأولية'
git add newcode && git الالتزام -m 'Adding new code'

ثالثًا ، استمر في تغيير القاعدة الأساسية والنهاية.

أمر :git rebase - تابع
رابعًا ، اعرض التاريخ مع التزامات إضافية.

أمر: اذهب اصمت

تغيير البريد الإلكتروني للمؤلف في جميع الالتزامات في جميع الفروع

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

أولاً أحصل على قائمة معرفات البريد الإلكتروني لتحديد الأشخاص الذين أريد تغييرهم:
أمر: سجل git - all --pretty = التنسيق: '٪ an٪ d'- هذا يطبع اسم المؤلف (اسم المرجع / اسم الفرع)

ثانيًا ، أنا أجري كل التزام على كل فرع وأعد كتابة كائن الالتزام بمعرف البريد الإلكتروني الجديد
أمر:
git filter-Branch --env-filter '
إذا كان ['$ GIT_AUTHOR_NAME' = 'divya']
ثم
GIT_AUTHOR_EMAIL = 'divya@github.com'
يكون
' -- --الكل

الملفات المفقودة والمعثور عليها

لنفترض أنك فقدت ملفًا معينًا ولا تتذكر اسمه ، لكن يمكنك تذكر كلمات معينة في الملف. في هذه الحالة ، يمكنك اتباع هذه الخطوات-
الخطوة 1: ضع قائمة بجميع الالتزامات التي احتوت على لقطة الملف مع النمط الذي تم البحث عنه
أمر :قائمة مراجعة بوابة - الكل | xargs git grep -i 'الطابع الزمني'

الخطوة 2 : قم بإنشاء فرع جديد 'مفقود' من معرف الالتزام المميز هذا
بناء الجملة: بوابة الخروج -b المفقود d8c6a76a6dcb1fc6e8c3f6b097e1bd07e7cd328f

نسيت أي فرع له معرف الالتزام الخاص بي

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

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

لذلك ، الآن أعرف جميع الفروع التي لا تزال لديها الالتزام السيئ ، يمكنني إما العودة أو إعادة تعيين هذه التغييرات.

حذف التزام من التاريخ

أشعر أحيانًا بالحاجة إلى محو التزام من التاريخ وعدم ترك أي أثر له. لا أنصحك بتجربة هذه الحيلة في فرع مشترك ولكن فقط في فرعك المحلي.
بناء الجملة: بوابة rebase -i
أمر :بوابة rebase -i 93859d8
في محرر rebase-> استبدل 'تحرير' بـ 'إسقاط' لمعرف الالتزام المميز: 69f4813

في بعض الحالات ، قد تؤدي إعادة الكتابة هذه إلى تعارضات. يجب عليك حل النزاعات ثم المضي قدما.

تحذير : هذا أمر خطير لأن هذا يعيد كتابة التاريخ وقد يفقد البيانات. يختلف هذا الفرع عن نظيره البعيد وسيتعين دفعه باستخدام--فرضأو- إجباري مع عقد إيجاراختيار.

دفع فرع خاطئ إلى جهاز التحكم عن بعد

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

استنساخ بوابة https://github.com/greets/myProj.git
سي دي myProj

بمجرد حذف الفرع البعيد ، يجب أن يقوم الآخرون في الريبو المشترك بتحديث وتحديث المراجع البعيدة بامتداد--تقليمخيار لحذف مراجع الكائنات المفقودة:git fetch --prune-v origin

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

الآن بعد أن فهمت أخطاء Git الشائعة ، تحقق من هذا من Edureka ، وهي شركة تعليمية موثوقة عبر الإنترنت مع شبكة تضم أكثر من 250000 متعلم راضٍ منتشرين في جميع أنحاء العالم. تساعد الدورة التدريبية لشهادة Edureka DevOps المتعلمين على فهم ما هو DevOps واكتساب الخبرة في عمليات وأدوات DevOps المختلفة مثل Puppet و Jenkins و Nagios و Ansible و Chef و Saltstack و GIT لأتمتة خطوات متعددة في SDLC.

لديك سؤال لنا؟ يرجى ذكرها في قسم التعليقات في 'أخطاء Git الشائعة' وسنعاود الاتصال بك