يفشل Git rebase باستمرار ويتطلب تدخل الدمج اليدوي

Question

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

يتم إعداد الريبو الخاص بي على النحو التالي:

master - of course, the main branch
deploy - a branch created where files like Capfile, deploy.rb etc are created and configured - these changes will NEVER be merged back into Master

بشكل عام، سير العمل الخاص بي هو:

1. هل التطوير على الفرع الرئيسي ...اختبر، ابتسم، التزم.
2. تفحص ال deploy فرع
3. ينفذ git rebase master في فرع النشر - كان هذا يعمل بدون مشكلة
4. ادفع إلى جهاز التحكم عن بعد ثم قم بالتنفيذ cap deploy
5. يستريح

المشكلة التي أواجهها الآن هي أنه عندما أقوم بالتنفيذ git rebase master في فرع النشر، يظهر خطأ مطلوب دمج ثلاثي/دمج يدوي (لا أعتقد أن رسالة الخطأ عامة بما يكفي للنشر).يخبرني Git بإجراء الدمج ثم الاستخدام git rebase --continue للانتهاء - وهو ما لا يعمل أبدًا.

ما وجدته "يفعل" يعمل قيد التشغيل git rebase master --interactive, ، تنظيف قائمة الاختيار (توجد 5 "عمليات" متكررة أو نحو ذلك ولكن بأرقام مرجعية مختلفة (نفس الرسالة) في هذه القائمة، لذلك سأختار واحدة منها) ثم قم بإجراء الدمج يدويًا.بمجرد أن أفعل ذلك لكل التزام، يمكنني مواصلة عملية إعادة الأساس وكل ذلك سعيد ...

حتى المرة القادمة أحتاج إلى إجراء إعادة الأساس.

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

شكرًا

Answer 1

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

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

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

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

للعثور على الملفات التي تحتوي على تعارضات الدمج، قم بما يلي:

git status

أو

git ls-files -u

بمجرد معرفة الملفات التي بها تعارضات، إذا كان لديك إعداد أداة الدمج، فيمكنك القيام بما يلي:

git mergetool <file>

إذا كنت تفضل الدمج يدويًا، فيمكنك العثور على علامات وخطوط الدمج عن طريق القيام بما يلي:

grep -Hnr '^=\{7\}\|^<\{7\}\|^>\{7\}' *

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

git add <file>

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

git rebase --continue

لإكمال إعادة الأساس.

Answer 2

تحصل git rebase --continue للعمل عليك دمج الملفات المتعارضة فعليًا (تحريرها، واختيار الأجزاء التي تريدها من بين علامات التعارض “<<<<<<<”، “=======”، “>>>>> >>") وبعد ذلك git add إلى الفهرس (الفهرس هو المكان الذي يتم فيه تسجيلها على أنها متعارضة، وتؤدي إضافة ملف إلى مسح حالته المتعارضة).تحقق من الفرق الحالي مع git diff --cached, ، ثم git rebase --continue إذا كان يبدو صحيحا.

قبل أن تحاول إعادة تعيين قاعدة بياناتك (أو بعد إحباط محاولة مسببة للمشاكل)، قم بالخروج git log -p master..deploy لعرض الالتزامات التي تحاول إعادة تأسيسها.إنها واحدة من هذه التي تتعارض مع كل ما لديك يتقن.

يلتزم هؤلاء الأشخاص بإسقاطهم عن طريق حذف سطور "الاختيار" الخاصة بهم git rebase -i قد لا تكون هي نفسها تمامًا (على الرغم من أنها تحتوي على نفس "الموضوع" في رسالة الالتزام الخاصة بها).إن حقيقة اعتقادك بأنه يجب أن يكون هناك واحد منهم فقط تشير إلى أن شيئًا مريبًا يحدث معك نشر فرع.هل هذه الالتزامات "المكررة" في نهاية نشر أم أن هناك التزامات أخرى بعدهم؟ربما رؤية محتوى تلك الالتزامات "المريبة" (log -p, ، أعلاه) سيعطيك فكرة عن مصدرها.

Answer 3

يمكنك تحديد يصف في الدليل الأصلي لملفاتك "الخاصة بالنشر"، من أجل تحديد محتوى فرع النشر دائمًا في حالة الدمج.

للحصول على مثال لإدارة الدمج، راجع هذه الإجابة SO.

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