أفهم من الصفحة http://nvie.com/posts/a-successful-git-branching-model/ ، حيث تعلمت لأول مرة نموذج git-flow منذ حوالي عامين ، أن tag
سيكون دائمًا ضمن الالتزام حيث تم دمج الفرع release
مع master
.
لقد قمت مؤخرًا بتثبيت المكون الإضافي git-flow لـ Git Extensions ويتم تطبيق tag
على آخر التزام في الفرع release
وليس على الالتزام المدمج في master
فرع.
هذا الخلل؟ هل يهم حقًا أيهما يستخدمه tag
؟ الحل الخاص بي هو عملية يدوية لحذف tag
وإعادة إنشائه حيث تعلمت إنشاءه.
لقد واجهت للتو نفس المشكلة بنفس الفهم الذي لديكRoLYroLLs. هذا اقتباس من المقال:
عندما تكون حالة فرع التحرير جاهزة لتصبح إصدارًا حقيقيًا ، يجب تنفيذ بعض الإجراءات. أولاً ، يتم دمج فرع الإصدار في
master
(نظرًا لأن كل التزام فيmaster
هو إصدار جديد بحكم التعريف ، تذكر). بعد ذلك ،
آمل أن يتم إصلاح هذا ، حيث يجب أن أفعل نفس الحذف وإعادة إنشاء الرقص ، كما ذكرت.
حسنًا ، لقد لعبت بعض الشيء مع هذا واكتشفت كيفية إصلاحه ، إذا صح التعبير ، إلى المنهجية المكتوبة على
أشعر أنه تم التخلي عن هذا المشروع منذ آخر مرة تم التطرق إليه في عام 2012 ، لذلك لن أقوم بإنشاء علاقات عامة ، لكنني سأترك هذه المشكلة نشطة.
ومع ذلك ، يمكنك تعديل الملفات التالية لمن هم من أمثالي:
https://github.com/nvie/gitflow/blob/15aab26490facf285acef56cb5d61025eacb3a69/git-flow-release#L253
و
https://github.com/nvie/gitflow/blob/15aab26490facf285acef56cb5d61025eacb3a69/git-flow-hotfix#L297
تغيير $BRANCH
إلى $MASTER_BRANCH
من وجهة نظري ، فإن وضع العلامة على فرع التحرير قبل الدمج (وليس على الفرع الرئيسي) هو في الواقع الشيء الصحيح الذي يجب القيام به لذلك يمكن العثور عليه بواسطة git describe --tags
من فرع التطوير أيضًا. انظر # 374
من وجهة نظري ، فإن وضع العلامة على فرع التحرير قبل الدمج (وليس على الفرع الرئيسي) هو في الواقع الشيء الصحيح الذي يجب القيام به لذلك يمكن العثور عليه بواسطة
git describe --tags
من فرع التطوير أيضًا. انظر # 374
كانت هذه حجة غريبة.
تم تعيين إصدار للمصدر بحيث يمكنك ربط التطبيقات المنشورة بالمصدر الذي أنشأه ، وأنت تقوم بالنشر من الرئيسي -> يجب وضع علامات على الرئيسي.
التعليق الأكثر فائدة
من وجهة نظري ، فإن وضع العلامة على فرع التحرير قبل الدمج (وليس على الفرع الرئيسي) هو في الواقع الشيء الصحيح الذي يجب القيام به لذلك يمكن العثور عليه بواسطة
git describe --tags
من فرع التطوير أيضًا. انظر # 374