Gitflow: ميزة إنهاء عدم القيام بدمج - no-ff

تم إنشاؤها على ١٤ فبراير ٢٠١١  ·  12تعليقات  ·  مصدر: nvie/gitflow

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

لقد لاحظت للتو أن git-flow قد يستخدم دمج - no-ff ، وفي أوقات أخرى قد لا يستخدمه. لماذا هذا؟ هل هو حسب التصميم؟

هل يجب أن أقوم بتقسيم git-flow حتى يعمل مع - no-ff دمج الميزات ، أم أن هناك طريقة ما لتهيئة ذلك؟

شكرا،
سكوت

التعليق الأكثر فائدة

مرحبا فنسنت ،

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

في النهاية ، أعتقد أن الاختيار يجب أن يكون للمستخدم ، وأعتقد أن المستخدم يعبر عن خيار مختلف باستخدام فرع الميزة مقابل الالتزام السريع بفرع التطوير.

أي مؤشرات حول المكان الذي قد أذهب إليه في قاعدة التعليمات البرمجية لإجراء هذا التغيير في نموذج خاص سيكون موضع تقدير كبير جدًا!

شكرا جزيلا على الأداة الرائعة!
سكوت

ال 12 كومينتر

مرحبا سكوت ،

حسب التصميم ، يستخدم git-flow الخيار --no-ff عند الدمج من أجل تسجيل أن الالتزامات تنتمي معًا تاريخيًا. ومع ذلك ، عندما يحتوي فرع الميزة على التزام واحد فقط ، فإن التزام الدمج الإضافي لا يضيف أي شيء ويؤدي فقط إلى تعقيد شجرة الفرع دون داع. لذلك بالنسبة إلى الفروع أحادية الالتزام ، يتم إجراء عمليات الدمج السريعة كما لو أن الالتزام قد تم على develop مباشرة.

هتافات،
فنسنت

مرحبا فنسنت ،

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

في النهاية ، أعتقد أن الاختيار يجب أن يكون للمستخدم ، وأعتقد أن المستخدم يعبر عن خيار مختلف باستخدام فرع الميزة مقابل الالتزام السريع بفرع التطوير.

أي مؤشرات حول المكان الذي قد أذهب إليه في قاعدة التعليمات البرمجية لإجراء هذا التغيير في نموذج خاص سيكون موضع تقدير كبير جدًا!

شكرا جزيلا على الأداة الرائعة!
سكوت

هذا هو المكان الذي يحدث فيه السحر: https://github.com/nvie/gitflow/blob/develop/git-flow-feature#L310

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

هتافات،
فنسنت

شكرا فنسنت! أنا أقدر المؤشر!

الأفضل،
سكوت

إذا كان بإمكاني إضافة 5 سنتات ،

أرغب بشدة في خيار الحصول على التزام دمج حتى عند الانتهاء من إحدى ميزات الالتزام.

في الطريقة التي أستخدم بها git flow ، تتضمن ميزاتي في أسمائها رقم التذكرة الذي أعمل عليه. عندما أنتهي من ميزة أود أن أرى التزام الدمج الذي يحدد اسم الميزة (الذي يتضمن رقم التذكرة).

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

DonGiulio لا أعرف ما إذا كنت قد قمت

شكرًا ، لم أكن أعرف ذلك ، سأتحقق من ذلك.

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

(لست متأكدًا مما هو موجود أيضًا في إصدار AVH).

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

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

هل أنت حريص على التفصيل؟ يجب أن نتفق على أنه ، قد لا يرغب الجميع في تفريع مثل هذا العمل الصلب بسبب هذه التغييرات الطفيفة.

Mehradzie لم يكن هناك أي التزام بهذا الريبو منذ 5 سنوات. لطالما كان إصدار AVH بمثابة مفترق طرق الانتقال لبعض الوقت الآن وهو مستقر تمامًا. لن أحبس أنفاسي للرد هنا ، ناهيك عن تغيير الرمز.

jawshooah لأكون صادقًا ، لم أتحقق حتى من اسم الريبو عندما انتهى بي الأمر هنا لأنني كنت أطارد نفس المشكلة في SourceTree.
هل gitflow هو ما تستخدمه SourceTree للقيام بالتدفقات؟ أنا في حيرة من أمري الآن: د
وإذا كان الأمر كذلك ، فهل يمكنني الفرم والتغيير كما اقترحت لاستخدام بعض أعمال إعادة الشراء الأخرى بدلاً من ذلك!

تضمينMehradzie AFAIK SourceTree نسخة معدلة قليلاً من إصدار nvie الأصلي. هناك طلبات معلقة عليهم للتحديث إلى إصدار AVH (انظر هنا وهنا ).

هل كانت هذه الصفحة مفيدة؟
0 / 5 - 0 التقييمات