Gitflow: فرع الميزة مع التزام واحد مدمج باستخدام التقديم السريع

فقط وجدت هذا بنفسي اليوم أيضًا. كانت هناك مشكلة أثيرت بالفعل وأغلقت لهذا هنا: https://github.com/nvie/gitflow/issues/100 لكنني أوافق على أنها لا تتطابق مع نموذج التطوير. نأمل إذا أثار عدد كافٍ من الناس ضجة يمكننا تغيير شيء ما هنا. (لست خبيرًا بما يكفي لإجراء هذا التغيير بشكل خاص.)

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

يتم تقديم علامة لهذه الميزة في fork git-flow (إصدار AVH)
تباعدت شوكة بلدي كثيرًا لجعل ذلك طلب سحب سهل لـ nvie's gitflow ،

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

متفق. على الأقل أود أن أرى الأساس المنطقي وراء ذلك.

متفق عليه - السلوك ليس واضحًا ، خاصة لمستخدمي git flow الجدد.

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

لقد كنت سيئًا جدًا في التعليق ، ولكن بصرف النظر عن ملاحظتي الأصلية ، أعتقد أن العديد من الآخرين قد ساهموا في حالات الاستخدام الخاصة بهم وقاموا بتبرير الأداة المساعدة.

كما هو الحال على الرغم من أن الشيء الذي أشعر بالارتباك بشأنه هو المكان الذي سأساهم فيه بالتصحيحات والتحسينات - حيث يبدو أن مشروع git-flow الأصلي لم تتم صيانته ولم ينعم أي من الشوكات كخليفة.

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

• متأخر -> كبير

+1 لإضافة خيار على الأقل للسماح للمستخدم بفرض --no-ff حتى مع وجود الفرع يحتوي على التزام واحد فقط: +1:

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

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

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

يحتوي My fork git-flow (AVH Edition) على خيار تعيين العلامات كإعدادات افتراضية ، وبهذه الطريقة يمكنك دائمًا القيام بـ --no-ff دون كتابته. راجع ويكي لمزيد من المعلومات.

تباعدت شوكة بلدي كثيرًا لجعل ذلك طلب سحب سهل لـ nvie's gitflow ،

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

تضمين التغريدة

في الواقع لكي نكون منصفين ، فأنا لا أستخدم سطر أوامر gitflow ولكن واجهة المستخدم الرسومية SourceTree التي يبدو أنها تستخدم سطر أوامرnvie 's gitflow داخليًا. لست متأكدًا مما إذا كان بإمكاني جعل SourceTree يستخدم إصدارًا / قابل للتنفيذ من git-flow بديل وكيف؟

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

سيكون من الجميل معالجة هذا

سأميل إلى إزالة الخيار الصريح --ff من حالة الالتزام الفردي. بعد ذلك ، يمكن استخدام تكوين دمج git المدمج merge.ff = false لتعيين - no-ff لجميع عمليات الدمج (بما في ذلك عمليات الدمج عن طريق إنهاء التدفق) ، مع تكوين git الافتراضي الذي يكرر السلوك الحالي.

+1

على أقل تقدير ، سيكون من الجيد أن يتم توثيق هذه "الميزة".

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

+1

+1

راجع "هل هذا المستودع ميت؟ # 6340"

اتضح أنه يمكنك فقط استخدام git بدون هذا! 😝

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

كل إصدار جديد ، هذا هو أول شيء أتحقق منه: D ولا يوجد أبدًا: /

وجدت للتو أن هناك أيضًا مربع اختيار لهذا في التفضيلات. لذلك لا داعي للتحقق من ذلك عند دمج كل فرع.