مرنة مقابل ثابتة المتفرعة (بوابة مقابل Clearcase/Accurev)

Question

سؤالي هو عن طريقة بوابة مقابض فروع:كلما كنت في فرع من ارتكاب هذا الفرع لن تتلقى أي وقت مضى التغييرات من الوالد فرع إلا إذا كنت القوة مع دمج.

ولكن في الأنظمة الأخرى مثل Clearcase أو Accurev ، يمكنك تحديد كيف فروع الحصول على شغل مع نوعا من الميراث آلية:أعني مع Clearcase باستخدام config_spec ، يمكنك أن تقول "الحصول على كل الملفات المعدلة على فرع /الرئيسية/issue001 ثم تواصل مع تلك التي على /الرئيسية أو مع هذا محددة الأساس".

في Accurev لديك أيضا آلية مماثلة والتي دعونا تيارات تلقي التغييرات من الفروع العليا (تيارات كيف يطلقون عليها) دون دمج أو إنشاء جديد لارتكاب على الفرع.

لا تفوت هذه أثناء استخدام Git ؟ يمكنك تعداد سيناريوهات حيث هذا الميراث هو يجب أن يكون ؟

شكرا

التحديث يرجى قراءة VonC الإجابة أدناه فعلا التركيز على سؤالي.مرة واحدة ونحن نتفق "الخطية التخزين" ومجموعة جدول أعمال التنمية على أساس SCMs لديهم قدرات مختلفة, سؤالي هو: والتي هي سيناريوهات الحياة الحقيقية (خاصة بالنسبة للشركات أكثر من OSS) حيث الخطي يمكن أن تفعل أشياء لا يمكن داغ?هي قيمتها ؟

Answer 1

أن نفهم لماذا Git لا نقدم نوعا ما كنت في اشارة الى باعتبارها "آلية الميراث" (لا تنطوي على ارتكاب) ، يجب أن نفهم أولا أحد المفاهيم الأساسية تلك SCMs (بوابة مقابلClearCase على سبيل المثال)

• ClearCase يستخدم خطي نسخة التخزين:كل نسخة من عنصر (الملف أو الدليل) ويرتبط مباشرة الخطية العلاقة مع الإصدار السابق من نفس العنصر.

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

في نظام الخطي ، config المواصفات يمكن تحديد عدة قواعد تحقيق "الميراث" ترى (على ملف معين ، حدد أولا نسخة معينة, و إذا لم يكن موجودا ، ثم حدد إصدار آخر و إذا لم يكن موجودا ، ثم حدد الثالث ، وهلم جرا).

الفرع هو شوكة في الخطية تاريخ إصدار محدد معين حدد المادة (جميع حدد القواعد قبل أن واحدة لا تزال سارية, ومن ثم "الميراث" تأثير)

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

تطبيق في بوابة بعض الإصدارات الأخرى التي يجب أن إما:

• دمج فرع الأخرى ارتكاب (مثل في بوابة سحب" ذكرها stsquad الجواب) أو
• ريبس الفرع الخاص بك (كما جريج يذكر)

ولكن منذ Git هو مجموعة جدول أعمال التنمية على أساس SCM, وسوف يؤدي دائما في جديد يرتكبها.

ما كنت "فقدان" مع Git هو نوع من "التكوين" (عند اختيار إصدارات مختلفة مع مختلف المتعاقبة حدد القواعد) ، ولكن هذا لن يكون عمليا في Dفكس (كما في "توزيع"):عندما كنت صنع فرع مع بوابة ، تحتاج إلى القيام بذلك مع نقطة البداية و المحتوى بوضوح تكرارها بسهولة إلى مستودعات أخرى.

في بحتة المركزية فكس, يمكنك تحديد مساحة العمل الخاصة بك (في ClearCase ، "view" أي لقطة أو الديناميكي) مع أي قواعد تريد.

---

غير معروف-google ويضيف في تعليق (في السؤال أعلاه):

لذا عندما نرى اثنين من نماذج يمكن تحقيق أشياء مختلفة (خطي مقابل داغ), سؤالي هو:والتي هي سيناريوهات الحياة الحقيقية (خاصة بالنسبة للشركات أكثر من OSS) حيث الخطي يمكن أن تفعل أشياء لا يمكن داغ?أنها تستحق ذلك ؟

عندما يتعلق الأمر إلى "واقعية" في المدى من قواعد اختيار ما يمكنك القيام به في نموذج خطي هو أن يكون عدة قواعد اختيار نفس مجموعة من الملفات.

النظر في هذا "التكوين المواصفات" (أي"مواصفات التكوين" اختيار القواعد مع ClearCase):

element /aPath/... aLabel3 -mkbranch myNewBranch
element /aPath/... aLabel2 -mkbranch myNewBranch

فإنه يختار كل الملفات المسمى 'aLabel2'(وهي فرع من هناك) ، ما عدا تلك المسمى 'aLabel3'- و فرع من هناك - (لأن القاعدة التي تسبق واحدة بالذكر 'aLabel2').

هل الأمر يستحق ؟

لا.

في الواقع, UCM نكهة ClearCase ، ("موحدة إدارة التكوين"منهجية تضمينها مع ClearCase المنتج ، يمثلون جميع "أفضل الممارسات" استخلاصه من قاعدة ClearCase الاستخدام) لا تسمح بذلك لأسباب simplificity.مجموعة من الملفات يسمى "مكون" و إذا كنت ترغب في فرع معين التسمية (المعروف باسم "خط الأساس") ، التي من شأنها أن تترجم مثل هذا التكوين التالية المواصفات:

element /aPath/... .../myNewBranch
element /aPath/... aLabel3 -mkbranch myNewBranch
element /aPath/... /main/0 -mkbranch myNewBranch

لديك لاختيار واحد نقطة الانطلاق (هنا،'aLabel3') والذهاب من هناك.إذا كنت تريد أيضا الملفات منaLabel2', سوف تجعل من دمج جميع 'aLabel2 الملفات التي في myNewBranch'.

هذا هو "تبسيط" ليس لديك لجعل مع مجموعة جدول أعمال التنمية ، حيث كل عقدة الرسم البياني يمثل فريد تعريف "نقطة انطلاق" فرع ، أيا كان هو مجموعة من الملفات المعنية.

دمج ريبس يكفي أن الجمع بين نقطة البداية مع إصدارات أخرى من مجموعة معينة من الملفات ، من أجل تحقيق المطلوب "تكوين" ، مع الحفاظ على تاريخ معين في العزلة في فرع.

الهدف العام هو السبب في "متماسكة الإصدار عمليات مراقبة تطبيق متماسكة عنصر".و "متسق" مجموعة من الملفات في واضحة المعالم متماسكة الدولة:

• إذا وصفت, كل ملفات وصفت
• إذا تشعبت ، كل الملفات سوف فرع من نفس فريدة من نوعها نقطة الانطلاق

أن يتم بسهولة في جدول أعمال التنمية ؛ يمكن أن يكون أكثر صعوبة في نظام خطي (خاصة مع "القاعدة ClearCase" حيث "التكوين المواصفات" يمكن أن تكون خادعة) ، ولكن القسري مع UCM منهجية نفس الخطي القائم على أداة.

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

هذا يسمح لك أن تترك عالم فكس (نظام التحكم في الإصدار) وأدخل عالم SCM (برنامج إدارة التكوين), المعنية أساسا مع "استنساخ".وأن (SCM الميزات) لا يمكن أن يتحقق مع الخطية أو المستندة إلى مجموعة جدول أعمال التنمية على أساس فكس.

Answer 2

يبدو وكأنه ما تبحث عنه قد يكون git rebase. وبعد إعادة صياغة فرع ينفصه من الناحية النظرية عن نقطة الفروع الأصلية وريتها في بعض النقاط الأخرى. (في الواقع، يتم تنفيذ Rebase من خلال تطبيق كل تصحيح من الفرع بالتسلسل إلى نقطة الفروع الجديدة، وإنشاء مجموعة جديدة من التصحيحات.) في مثالك، يمكنك إعادة ربط فرع إلى الطرف الحالي من فرع العلوي سوف "يرث" أساسا جميع التغييرات التي تم إجراؤها على الفرع الآخر.

Answer 3

أنا لست واضحا تماما حول ما يطلبه ولكن يبدو وكأنه دلالات تتبع جيت هي ما تريد. عند فروع من أصل، يمكنك القيام بشيء ما:

git -t -b my_branch الأصل / ماجستير

ثم المستقبل "git pull" سوف دمج أصل السيارات / سيد في فرع العمل الخاص بك. يمكنك بعد ذلك استخدام "Git Cherry -v Origin / Master" لمعرفة الفرق. يمكنك استخدام "Git Rebase" قبل نشر تغييراتك لتنظيف السجل، ولكن يجب ألا تستخدم Rebase بمجرد أن يكون تاريخك عاما (أي الأشخاص الآخرين يتابعون ذلك الفرع).

Answer 4

بالنسبة إلى مخطط الوراثة المستخدمة من قبل AccuRtv: من المحتمل أن "الحصول على" GIT "على الأرجح كل شيء عند إلقاء نظرة على جيت التدفق (أنظر أيضا: http://github.com/nvie/gitflow. و http://jeffkreeftmeijer.com/0/Why-arent-you-using-git-flow/)

يحتوي هذا النموذج المتفرع من GIT أكثر أو أقل (يدويا / بمساعدة أداة تدفق GIT) ما يقوم Accurtv بالخروج من المربع تلقائيا ومع رائعة دعم واجهة المستخدم الرسومية.

وبالتالي يظهر بوابة يمكن أن تفعل ما يفعله أكورف. نظرا لأنني لم أستخدم فعليا في يوم من الأيام، إلا أنني لا أستطيع أن أقول حقا كيف يعمل لكنه يبدو واعدا. (ناقص دعم واجهة المستخدم الرسومية المناسبة :-)

Answer 5

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

"هل يمكنك تعداد السيناريوهات حيث هذا الميراث أمر لا بد منه؟"

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

السيناريو الوحيد الذي أستطيع رؤيته هو مفيد أن يكون هذا 'ميراث' السلوك واستخدام قوة المواصفات التكوين، هو عندما تريد مجموعة التغييرات الخاصة بك "معزول"تعيين إلى مهمة (devtask، cr، sr، أو كل ما يعرف الغرض / نطاق مجموعة التغيير الخاصة بك)

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

يجري الاهتمام بالارتقاء لارتكاب / دمج / Rebase فقط للحصول على "نقطة انطلاق محددة"، وأعتقد أنه "تلوث"فرعك وسوف ينتهي بك الأمر مع تغييراتك + أخرى يتغير في مجموعة فرع / تغيير.

متى / أين هذه العزلة مفيدة؟ النقاط رفع الصوت عاليا قد يكون منطقيا فقط في سياق الشركات التي تتبعها CMM وبعض شهادات ISO، وقد تكون ذات أهمية لنوع آخر من الشركات أو OSS

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

• يمكن أن يكون من الأسهل مراجعة التعليمات البرمجية في مراحل مختلفة، وجود الكود الخاص بك فقط في فرع واحد (غير لصقها مع التغييرات الأخرى)

في مشاريع كبيرة مع العديد من الفرق و +500 مطوري يعمل بنشاط بشكل متزامن على نفس الرمز الأساسي، (حيث تبدو أشجار إصدار العناصر الفردية الرسومية وكأنها شبكة متشابكة فوضوي مع العديد من خطوط Loadlines أو واحد لكل عميل كبير أو واحد لكل تقنية) تكوين كبير جعل المواصفات التي تستخدم تكوين العديد من الدرجات في العمق هذا القدر من الأشخاص يعملون بسلاسة لتكييف نفس المنتج / النظام (الرمز الأساسي) لأغراض مختلفة. باستخدام مواصفات التكوين هذه، أعطت ديناميكيا كل فريق أو فريق فرعي، وجهة نظر مختلفة لما يحتاجون إليه ومن حيث يحتاجون إلى فرع، (يتتالي في العديد من الحالات) دون الحاجة إلى إنشاء فروع التكامل الوسيطة، أو دمج جميعها واستمرارها باستمرار البتات التي تحتاج إلى البدء بها. كان الرمز من نفس المهمة / الغرض المتفرع من الملصقات المختلفة ولكن المنطقي. (يمكنك أن تجادل هنا "الأساس المعروفة" كمبدأ من SCM ولكن الملصقات البسيطة المنصوص عليها في خطة SCM المكتوبة فعلت العمل) يجب أن يكون من الممكن حل هذا مع GIT (أعتقد بطريقة غير ديناميكية) لكنني أجد من الصعب حقا الصورة دون سلوك "الميراث". أعتقد أن النقطة المذكورة من قبل VONC "إذا تفرع، فإن جميع ملفاتها ستفرع من نفس نقطة البداية الفريدة" تم كسرها هنا، ولكن بجانبها تم توثيقها جيدا على SCMP، أتذكر أنه كان هناك سبب تجاري قوي للقيام بذلك بهذه الطريقة.

نعم بناء مواصفات التكوين هذه التي ذكرتها أعلاه لم تكن مجانية، في البداية هناك حيث 4-5 أشخاص مدفوعون جيدا وراء SCM ولكن تم تخفيضها لاحقا عن طريق البرامج النصية الآلية التي طلبت منك ما تريد على شروط الملصقات / الفروع / الميزات اكتب CS لك.

تم تحقيق استنساخ هنا من خلال توفير مواصفات التكوين مع المهمة في نظام DevTask، لذلك تعيين كل مهمة تم تعيينها إلى متطلبات، ومصمبة المصب إلى مواصفات التكوين، وهي مجموعة من التغييرات (ملفات التعليمات البرمجية، وثائق التصميم، وثائق الاختبار إلخ)

حتى هنا قد يكون أحد الاستنتاج هنا، فقط إذا كان مشروعك كبيرا / معقد بما فيه الكفاية (ويمكنك شراء مديري SC على طول عمر المشروع :)) ثم ستبدأ التفكير فقط إذا كنت بحاجة إلى سلوك "الميراث" أو أداة تنوعية حقا، وإلا فسوف تذهب مباشرة إلى أداة AA المجانية والعناية بالفعل بتماسك SCM ... ولكن قد يكون هناك عوامل أخرى على أداة SCM التي قد تجعلك تلتصق بأحد أو إلى آخر .. .واصل القراءة..

بعض الملاحظات الجانبية، التي قد تكون خارج الموضوع، لكنني أعتقد في بعض الحالات مثل حاجة لي.

يجب أن أضيف هنا أننا نستخدم "Good-CC" غير UCM. أتفق تماما مع Vonc على تسمح المنهجية الجيدة ب "توجيه" المرونة تجاه تكوين أكثر تماسكا. وبعد الشيء الجيد هو أن CC مرنة للغاية ويمكنك أن تجد (ليس دون بعض الجهد) وسيلة جيدة للحصول على شيء متماسك أثناء وجوده في وكالة أخرى قد يكون لديك مجانا. ولكن على سبيل المثال هنا (وغيرها من الأماكن التي عملت مع CC) لمشاريع C / C ++، لا يمكننا تحمل تكلفة عدم وجود وينين ميزة (إعادة استخدام الكائنات الاستيقاظ)، التي تقلل عدة مرات تجميع مرات x مرات. يمكن القول أن وجود تصميم أفضل، رمز أكثر انفصالا، وتحسين الماكيين يمكن أن يقلل من الحاجة إلى ترجمة الأمر بأكمله، ولكن هناك حالات تحتاجها لتجميع الوحش بأكملها عدة مرات في اليوم، وتقاسم المحفوظات أكوام من الوقت / المال. حيث أنا الآن نحاول استخدام أكبر قدر ممكن من الأداة المجانية، وأعتقد أننا سنتخلص من CC إذا استطعنا العثور على أداة أرخص أو مجانية تنفذ وينين خاصية.

سوف تنتهي مع شيء ذكره بولس، أدوات مختلفة هي أفضل ذلك لأغراض مختلفة لكنني سأضيف أنه يمكنك الابتعاد عن بعض القيود للأداة من خلال وجود عملية متماسكة ودون تخويف الاستيلاء، والنقاط الرئيسية قبالة SCM في النهاية أعتقد الإجابة على تساوي؟ يعتمد على "مشكلتك"، تقوم SDLC بتشغيل، وعمليات SCM الخاصة بك، وإذا كانت هناك أي ميزة إضافية (مثل Winkin) قد تكون مفيدة في بيئتك.

بلدي 2 سنتا

Answer 6

النظرية جانبا، إليك نوعا عمليا واضحا هذا، من وجهة نظري باستخدام AccuRtV في بيئة إنتاج تجارية لعدة سنوات: يعمل نموذج الميراث جيدا طالما لم تباعد تدفقات الأطفال أكثر من اللازم من الأجداد لا يزال في التنمية. إنه ينهار عندما تيارات الوراء مختلفة جدا.

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

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

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

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

واحد لطيف حقا حول accuriv هو أن لديك هذا الاختيار، في كل وقت. إنه ليس قيود متأصلة من بنية برنامج SCM الخاص بك.

Answer 7

هل لاحظت أنه يمكنك الخروج من إصدارات الملفات المحددة مع GIT TOO؟

فقط استخدم هذا:

git checkout [< tree-ish >] [--] < paths >

مثل PER CONFIG SPEC أي إصدار موجود من الملف (المسارات) يمكن تحميلها في Worktree. اقتبس من مستندات git-checkout:

تتوقف التسلسل التالي من فرع الماجستير، يعود Makefile إلى مراجعتين، حذف hello.c عن طريق الخطأ، ويحصل عليه من الفهرس:

$ git checkout master             
$ git checkout master~2 Makefile             
$ rm -f hello.c            
$ git checkout hello.c            

Answer 8

ClearCase، بدون متعدد، هو مستودع واحد ولكن يتم توزيع GIT. يلتزم ClearCase على مستوى الملف ولكن الجيت يرتكب على مستوى المستودع. (هذا الاختلاف الأخير يعني أن السؤال الأصلي يعتمد على سوء فهم، كما هو مذكور في الوظائف الأخرى هنا.)

إذا كانت هذه هي الاختلافات التي نتحدث بها، فما أعتقد أن "خطي" مقابل "DAG" هو وسيلة مربكة لتمييز أنظمة SCM هذه. في Clearcase تتم الإشارة إلى جميع الإصدارات لملف الملف باسم إصدار الملف "Tree" ولكن في الحقيقة هو الرسم البياني AcyClic موجه! الفرق الحقيقي في GIT هو أن DAGS Clearcase موجودة لكل ملف. لذلك أعتقد أنه مضلل للإشارة إلى Clearcase كغير DAG و GIT كما DAG.

(إصدارات BTW Clearcase دليلها بطريقة مماثلة لملفاتها - ولكن هذه قصة أخرى.)

Answer 9

لست متأكدا مما إذا كنت تسأل أي شيء، لكنك توضح أن تدفقات AccuRtV هي أدوات مختلفة من فروع GIT (أو SVN). (أنا لا أعرف clearcase.)

على سبيل المثال، مع accuriv أنت قسري, ، كما تقول، لاستخدام سير عمل معينة، تمنحك تاريخ قابلة للتحويلات غير مدعومة في GIT. الميراث AccuRtV يجعل سير عمل معينة أكثر كفاءة وغير ذلك من المستحيل.

مع GIT، يمكنك الحصول على ترميز استكشافي منفصلا في Repos Repos أو في فروع ميزة، والتي لن تكون مدعومة بشكل جيد للغاية.

أدوات مختلفة جيدة لأغراض مختلفة؛ من المفيد أن نسأل ما هو كل واحد جيد بالنسبة.