10 مشاكل بوابة مشتركة وكيفية إصلاحها

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

1. تجاهل التعديلات الملف المحلي

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

بوابة الخروج - Gemfile # إعادة تعيين المسار المحدد
بوابة الخروج - ليب بن # يعمل أيضا مع وسائط متعددة

في حال كنت تتساءل ، فإن الشرطة المزدوجة (-) هي وسيلة شائعة لأدوات سطر الأوامر المساعدة للدلالة على نهاية خيارات الأمر.

2. التراجع عن الالتزامات المحلية

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

بوابة إعادة تعيين HEAD ~ 2 # التراجع عن آخر اثنين من الالتزامات ، والحفاظ على التغييرات
git reset - hard HEAD ~ 2 # تراجع عن آخر إثنين من الأوامر ، وتجاهل التغييرات

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

3. إزالة ملف من بوابة دون إزالته من نظام الملفات الخاص بك

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

git reset filename # or git rm - cached filename
اسم ملف الارتداد >> .gitignore # أضفه إلى .gitignore لتجنب إعادة إضافته

4. تحرير رسالة الالتزام

تحدث الأخطاء المطبعية ، ولكن لحسن الحظ في حالة إرسال رسائل ، من السهل جدًا إصلاحها:

git ارتكاب - تعديل # start $ EDITOR لتحرير الرسالة
git ارتكاب - تعديل -m "رسالة جديدة" # تعيين الرسالة الجديدة مباشرة

لكن هذا ليس كل شيء يمكن أن يفعله لك. هل نسيت أن تضيف ملف؟ فقط إضافته وتعديل الالتزام السابق!

git add forgotten_file git ارتكاب - تعديل

يرجى الانتباه إلى أن - سيؤدي التعديل فعليًا إلى إنشاء التزام جديد يحل محل الالتزام السابق ، لذلك لا تستخدمه لتعديل الالتزامات التي تم دفعها بالفعل إلى مستودع مركزي. يمكن إجراء استثناء لهذه القاعدة إذا كنت متأكدًا تمامًا من أنه لم يقم أي مطور آخر بسحب الإصدار السابق واستند إلى عملهم الخاص به ، وفي هذه الحالة ، قد تظل الدفعة القسرية (git push - Force) على ما يرام. يعد الخيار --force ضروريًا هنا نظرًا لأن سجل الشجرة تم تعديله محليًا ، مما يعني أنه سيتم رفض الدفعة من قبل الخادم البعيد نظرًا لعدم إمكانية دمج الدمج السريع.

5. تنظيف ارتكاب المحلية قبل الدفع

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

بوابة rebase - التفاعلية
# إذا لم تحدد أي معلومات تتبع لهذا الفرع
# سيتعين عليك إضافة معلومات فرع المنبع والبعيدة:
بوابة rebase - فرع الأصل التفاعلي

سيؤدي هذا إلى فتح المحرر المكوّن وتقديم القائمة التالية:

اختر إصدار 8a20121 Upgrade Ruby إلى 2.1.3
اختيار 22dcc45 إضافة بعض المكتبة الفاخرة
# Rebase fcb7d7c..22dcc45 على fcb7d7c
#
# الأوامر: # ع ، اختر = استخدام الالتزام
# r ، reword = استخدم الالتزام ، ولكن قم بتحرير رسالة الالتزام
# e ، تحرير = استخدام الالتزام ، ولكن توقف عن التعديل
# s ، الاسكواش = استخدام الالتزام ، لكن تمتزج بالالتزام السابق
# f ، fixup = like "squash" ، لكن تجاهل رسالة سجل الالتزام
# x ، exec = أمر تشغيل (بقية السطر) باستخدام shell
#
# هذه الخطوط يمكن إعادة ترتيبها ؛ يتم تنفيذها من أعلى إلى أسفل.
#
# إذا قمت بإزالة سطر هنا ، فسيتم فقد الالتزام.
#
# ومع ذلك ، إذا قمت بإزالة كل شيء ، سيتم إحباط rebase.
#
# لاحظ أنه يتم تعليق الالتزامات الفارغة

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

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

6. العودة ارتكبت ارتكبت

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

git revert c761f5c # يعيد الالتزام بالمعرف المحدد
بوابة العودة HEAD ^ # يعود الثاني إلى آخر التزام
بوابة العودة تطوير ~ 4.Develop ~ 2 # يعود مجموعة كاملة من ارتكابها

في حالة عدم رغبتك في إنشاء تعهدات إضافية للعودة ولكن فقط تطبيق التغييرات الضرورية على شجرة العمل الخاصة بك ، يمكنك استخدام الخيار --no-الالتزام / -n.

# التراجع عن الالتزام الأخير ، ولكن لا تنشئ التزامًا بالعودة
بوابة العودة - ن الرأس

تدرج الصفحة اليدوية في man 1 git-revert خيارات أخرى وتقدم بعض الأمثلة الإضافية.

7. تجنب تكرار دمج الصراعات

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

بوابة التكوين - العالمية rerere.enabled صحيح

بدلاً من ذلك ، يمكنك تمكينه على أساس كل مشروع عن طريق إنشاء الدليل .git / rr-cache يدويًا.

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

تحتوي صفحة man (man git-rerere) على مزيد من المعلومات حول حالات الاستخدام والأوامر الإضافية (git rerere status ، git rerere diff ، إلخ).

8. العثور على الالتزام الذي كسر شيء بعد دمج

تعقب الالتزام الذي أدخل خطأ بعد دمج كبير يمكن أن يكون مضيعة للوقت. لحسن الحظ git يقدم وسيلة بحث ثنائية كبيرة في شكل بوابة bitect. أولاً عليك إجراء الإعداد الأولي:

git bisect start # يبدأ جلسة bisecting
git bisect # علامات سيئة التنقيح الحالي سيء
git bisect good revision # يصور آخر مراجعة جيدة معروفة

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

بوابة bisect جيدة # أو بوابة bisec سيئة

تستمر هذه العملية حتى تصل إلى الالتزام الذي قدم الخطأ.

9. تجنب الأخطاء الشائعة مع السنانير بوابة

تحدث بعض الأخطاء بشكل متكرر ، ولكن سيكون من السهل تجنبها عن طريق إجراء عمليات فحص أو مهام تنظيف معينة في مرحلة محددة من سير عمل git. هذا هو بالضبط السيناريو الذي تم تصميم السنانير ل. لإنشاء ربط جديد ، أضف ملفًا قابلاً للتنفيذ إلى .git / hooks. يجب أن يتوافق اسم البرنامج النصي مع أحد السنانير المتاحة ، والتي تتوفر قائمة كاملة بها في الصفحة اليدوية (man githooks). يمكنك أيضًا تحديد روابط عامة لاستخدامها في جميع مشاريعك عن طريق إنشاء دليل قالب يستخدمه git عند تهيئة مستودع جديد (انظر man git-init لمزيد من المعلومات). إليك كيفية ظهور الإدخال ذي الصلة في ~ / .gitconfig ودليل قالب مثال:

[فيه]
    templatedir = ~ / .git_template
  
→ شجرة. git_template
  .git_template
  └── السنانير
      commit قبل الالتزام

عند تهيئة مستودع جديد ، سيتم نسخ الملفات الموجودة في دليل القالب إلى الموقع المقابل في دليل .git لمشروعك.

ما يلي هو مثال الالتزام مفتقد قليلاً ، والذي يضمن أن كل رسالة التزام تشير إلى رقم تذكرة مثل "# 123".

#! / usr / bin / env ruby
message = File.read (ARGV [0])

ما لم تكن الرسالة = ~ / \ s * # \ d + /
  يضع "[السياسة] رسالتك لا تشير إلى تذكرة."
  خروج 1
النهاية

10. عندما فشل كل شيء آخر

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

بوابة تصفية فرع - قوة - مرشح -exex \
  'git rm - مخبأة مؤقتًا - مجموعة من اللقطات غير المتطابقة secrets.txt' \
  القط --prune فارغة --tag- اسم مرشح القط - --all

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

يحتوي GitHub على برنامج تعليمي جيد للغاية حول إزالة البيانات الحساسة ، ويحتوي رجل git-filter-branch على جميع التفاصيل حول مختلف الفلاتر المتاحة وخياراتها.

نشرت أصلا في gist.github.com.