ملاحظة perev. : قبل بضعة أيام ، ظهرت ملاحظة صغيرة ولكنها مفيدة جدًا في المدونة لمهندسي مشروع GitLab المفضل لدينا مع تعليمات تساعد على توفير الوقت والأعصاب في حالة حدوث مشاكل مختلفة أثناء العمل مع Git. من غير المرجح أن تكون جديدة للمستخدمين ذوي الخبرة ، ولكن سيكون هناك بالتأكيد أولئك الذين سوف تكون مفيدة لهم. وفي نهاية هذه المادة ، أضفنا مكافأة صغيرة من أنفسنا. يوم جمعة جيد!جميعنا نرتكب أخطاء ، خاصة عند العمل مع أنظمة معقدة مثل Git. لكن تذكر: يحدث Git!
إذا كنت قد بدأت للتو مع Git ، فتعلم
أساسيات العمل معها في سطر الأوامر. وهنا سأتحدث عن كيفية إصلاح الأخطاء الستة الأكثر شيوعًا في Git.
1. عفوًا ... لقد أخطأت في الرسالة حتى آخر التزام
بعد عدة ساعات من الترميز ، من السهل ارتكاب خطأ في رسالة الالتزام. لحسن الحظ ، من السهل إصلاح ذلك:
git commit --amend
باستخدام هذا الأمر ، سيتم فتح محرر نصوص ويسمح لك بإجراء تغييرات على الرسالة حتى آخر التزام. ولن يعلم أحد أنك كتبت "مضاف" بثلاث "ds".
2. عفوًا ... نسيت إضافة الملف إلى آخر التزام
خطأ شائع آخر في Git هو التزام متسرع للغاية. هل نسيت إضافة الملف ، أو نسيت حفظه ، أو هل يجب إجراء تغيير بسيط لجعل الالتزام ذا معنى؟ سوف يكون
--amend مرة أخرى.
أضف الملف المفقود وقم بتشغيل هذا الأمر الصحيح:
git add missed-file.txt git commit --amend
يمكنك الآن إما تصحيح الرسالة ، أو ببساطة حفظها في شكلها الأصلي (مع إضافة الملف).
3. عفوًا ... أضفت ملفًا لا يجب أن يكون في هذا المستودع
ولكن ماذا لو كان لديك موقف معاكس؟ ماذا لو أضفت ملفًا لا تريد تنفيذه؟ ملف ENV خادع أو إنشاء دليل أو صورة مع قطة تم حفظها عن طريق الخطأ في الدليل الخاطئ ... تم حل كل شيء.
إذا كنت قد فعلت
المرحلة فقط للملف ولم تلتزم بها بعد ، فسيتم كل شيء من خلال
إعادة تعيين بسيطة للملف المطلوب (الموجود في المرحلة):
git reset /assets/img/misty-and-pepper.jpg
إذا كنت لا تزال تقوم بالتغيير ، فستكون هناك حاجة إلى خطوة أولية إضافية:
git reset --soft HEAD~1 git reset /assets/img/misty-and-pepper.jpg rm /assets/img/misty-and-pepper.jpg git commit
سيتم إرجاع التراجع إلى الوراء ، وسيتم حذف الصورة ، ثم يتم إجراء تعهد جديد.
ملاحظة perev. : كما لوحظ في التعليقات على المقال الأصلي ، يمكن أيضًا حل هذه المشكلة باستخدام - --amend المذكور بالفعل. على ما يبدو ، مع هذه الفقرة ، أراد المؤلف أن يوضح ما هي الطرق الأخرى لتغيير تاريخ الالتزامات لإصلاح الخطأ.4. عفوًا ... لقد ارتكبت تغييرات في التحكم
لذلك ، أنت تعمل على ميزة جديدة وسارعت ، متناسين إنشاء فرع جديد لها. لقد ارتكبت بالفعل مجموعة من الملفات وجميع هذه العمليات في سيد. لحسن الحظ ،
يمكن لـ GitLab
منع push'y مباشرة في الماجستير. لذلك ، يمكننا استرجاع جميع التغييرات اللازمة لفرع جديد بالأوامر الثلاثة التالية:
ملاحظة : تأكد من تنفيذ أو حذف الأصفار أولاً - وإلا ستفقد! git branch future-brunch git reset HEAD~ --hard git checkout future-brunch
سيتم إنشاء فرع جديد ، بشكل رئيسي - يتم التراجع عن الحالة التي كان عليها قبل التغييرات الخاصة بك ، ثم يتم إجراء
السحب من الفرع الجديد بكل التغييرات.
5. عفوًا ... لقد ارتكبت خطأً باسم الفرع
يمكن أن تلاحظ الأكثر انتباهًا في المثال السابق وجود خطأ في اسم الفرع. إنها الساعة الثالثة مساءً تقريبًا ، وما زلت لم أتناول العشاء ، لذلك أطلق جوعي اسم الفرع الجديد (
br n nch ) على أنه
المستقبل . الأشياء الجيدة!
إعادة تسمية هذا الفرع بنفس الطريقة التي يتم استخدامها عند إعادة تسمية ملف باستخدام الأمر
mv ، أي وضعه في مكان جديد بالاسم الصحيح:
git branch -m future-brunch feature-branch
إذا قمت بالفعل بدفع هذا الفرع ، فستحتاج إلى بضع خطوات إضافية. سنقوم بإزالة الفرع القديم من
جهاز التحكم عن
بعد ودفع الفرع الجديد:
git push origin --delete future-brunch git push origin feature-branch
ملاحظة perev. : لا يزال بإمكانك إزالة فرع من جهاز التحكم عن بعد باستخدام: git push origin :future-brunch
6. عفوا ... لقد فعلت ذلك مرة أخرى!
الأمر الأخير في حالة حدوث كل شيء خطأ. عندما جمعت ودفعت مجموعة من الحلول باستخدام Stack Overflow ، وبعد ذلك أصبح كل شيء في المستودع أسوأ مما كان عليه في البداية. كلنا واجهنا ذات مرة ذات مرة ...
git reflog قائمة بجميع العمليات التي قمت بها. ثم يسمح لك باستخدام إمكانات السفر عبر الزمن السحرية من Git ، أي العودة إلى أي لحظة من الماضي. يجب أن أشير إلى أن هذا هو أملك الأخير - لا يجب عليك اللجوء إليه في حالات بسيطة. لذا ، للحصول على القائمة ، قم بما يلي:
git reflog
كل خطوة من خطواتنا تقع تحت عين Git الساهرة. أنتجت إدارة الفريق في المشروع أعلاه ما يلي:
3ff8691 (HEAD -> feature-branch) HEAD@{0}: Branch: renamed refs/heads/future-brunch to refs/heads/feature-branch 3ff8691 (HEAD -> feature-branch) HEAD@{2}: checkout: moving from master to future-brunch 2b7e508 (master) HEAD@{3}: reset: moving to HEAD~ 3ff8691 (HEAD -> feature-branch) HEAD@{4}: commit: Adds the client logo 2b7e508 (master) HEAD@{5}: reset: moving to HEAD~1 37a632d HEAD@{6}: commit: Adds the client logo to the project 2b7e508 (master) HEAD@{7}: reset: moving to HEAD 2b7e508 (master) HEAD@{8}: commit (amend): Added contributing info to the site dfa27a2 HEAD@{9}: reset: moving to HEAD dfa27a2 HEAD@{10}: commit (amend): Added contributing info to the site 700d0b5 HEAD@{11}: commit: Addded contributing info to the site efba795 HEAD@{12}: commit (initial): Initial commit
انتبه إلى العمود الموجود في أقصى اليسار - هذا هو الفهرس. إذا كنت تريد العودة إلى أي نقطة في السجل ،
dfa27a2 بتشغيل الأمر التالي ، واستبدل
{index} بالقيمة المناسبة (على سبيل المثال ،
dfa27a2 ):
git reset HEAD@{index}
لذا ، لديك الآن ست طرق للخروج من أكثر Gitfalls الأكثر شيوعًا
(التورية: المفسق
يترجم على أنه "فخ ، خطأ" - ترجمة تقريبًا ) .
مكافأة من المترجم
أولاً ، تعليق قيم على كل شيء مكتوب أعلاه (باستثناء الفقرة 5). ضع في اعتبارك أن هذه الإجراءات تغير تاريخ الالتزامات ، لذلك لا يجب تنفيذها إلا إذا لم يتم إرسال التغييرات إلى
جهاز التحكم عن بعد (push'nut). خلاف ذلك ، فإن الإساءة السيئة القديمة ستكون موجودة بالفعل على الفرع
البعيد ، وسيكون عليك إما تنفيذ
git pull (الذي سيؤدي إلى
الدمج ، ثم محاولة "مسح" التاريخ سيؤدي إلى عواقب أسوأ) ، أو
git push --force ، وهو أمر محفوف بفقدان البيانات عند العمل مع فرع من عدة أشخاص ...
الآن - إضافات مفيدة صغيرة من تجربتنا:
- إذا قمت (عن طريق الخطأ أم لا) بتغيير الفرع وتحتاج إلى العودة إلى الفرع السابق ، فإن أسرع طريقة هي استخدام
git checkout - . - إذا قمت عن طريق الخطأ بإضافة ملف إلى عملية التنفيذ لا يجب إضافته هناك ، ولكن لم يتم الالتزام به بعد ، استخدم
git reset HEAD path/to/file . ويرد وصف حالة مماثلة في الفقرة 3 ، لكنها في الواقع أوسع ، لأنه يشير إلى أي تغييرات غير ضرورية في الالتزام (وليس فقط في حالة ملف إضافي). - من الممارسات الجيدة عدم الالتزام أكثر من اللازم ، باستخدام الخيار
-p عند إضافة ملف إلى الالتزام ( git add -p ). يسمح لك هذا بمراجعة كل تغيير يتم في الالتزام. ولكن من الجدير بالذكر أنه لا يضيف ملفات غير متتبعة إلى عملية التنفيذ - يجب إضافتها بدون هذه المعلمة. - يمكن العثور على عدد من التوصيات الجيدة (بما في ذلك التوصيات الأكثر تعقيدًا) في مقالة 2014 " Git Tutorial: 10 مشكلات Git الشائعة وكيفية إصلاحها ". على وجه الخصوص ، لاحظ استخدام
git revert و git rebase -i .
ملاحظة من المترجم
اقرأ أيضا في مدونتنا: