टीएफएस: सर्वोत्तम प्रथाओं को मर्ज करें

Question

हमारे पास एक मानक शाखा वास्तुकला है जहां हमारे पास प्रत्येक टीम के लिए एक विकास शाखा है, सामान्य एकीकरण शाखा (जहां से सभी विकास शाखाएं ब्रांच की जाती हैं) और उत्पादन शाखा एकीकरण से ब्रांच की जाती है।

विकास चरण के दौरान मैं विकास शाखा में बहुत से काम करता हूं। चरण के अंत में मैं अपने परिवर्तन एकीकरण में और बाद में उत्पादन में विलय करता हूं।

क्या मूल प्रतिबद्धता विवरण की प्रतिलिपि बनाने और मूल कार्य से लिंक करने के लिए व्यक्तिगत रूप से प्रत्येक प्रतिबद्धता को मर्ज करने का अर्थ होता है? एक और विकल्प एक ही विलय ऑपरेशन के साथ, एक ही समय में सभी कामों को मर्ज करने के लिए है। मेरे प्रश्न का कारण यह है कि पहली बार बहुत समय लगता है। मुझे टीएफएस में कोई स्वचालन उपकरण नहीं दिख रहा है जो अन्य शाखा में मूल प्रतिबद्धता में विलय करेगा।

मैं सर्वोत्तम प्रथाओं पर आपकी राय सुनना चाहता हूं।

Answer 1

1. देव * -> एकीकरण और एकीकरण से विलय -> उत्पादन हमेशा "प्रतिलिपि" विलय होना चाहिए। यह आपकी डाउनस्ट्रीम शाखाओं की स्थिरता को संरक्षित करने का सबसे सुरक्षित तरीका है।
   1. लक्ष्य शाखा से नवीनतम परिवर्तन लेने के लिए पहले दूसरी दिशा (उदा। एकीकरण -> देव 2) में विलय करें।
   2. यदि विवाद हैं, तो केस के आधार पर भिन्नता को संभालें। AcceptMerge (या तो ऑटो या मैन्युअल) आमतौर पर वांछित परिणाम होता है लेकिन कभी-कभी आप एक या दूसरी शाखा की प्रति अपरिवर्तित लेना चाहते हैं।
   3. इन परिवर्तनों को पूरी तरह से शामिल करने, प्रतिक्रिया करने और स्थिर करने के लिए स्रोत शाखा (हमारे मामले में देव # 2) का उपयोग करें।
   4. वांछित दिशा में मर्ज करें (उदा। देव 2 -> एकीकरण)। AcceptTheirs [उर्फ "स्रोत से प्रतिलिपि"] के रूप में सभी संघर्षों को हल करें।
   5. सुनिश्चित करें कि चरण # 1-4 के बीच लक्ष्य शाखा में कोई बदलाव नहीं है। यदि देव शाखा & की शुरुआत में विलय स्वीकार कर रही है, तो यह होना चाहिए, तो यह आशावादी-छोटी प्रक्रिया के दौरान लक्ष्य शाखा को लॉक करने के लिए बोझिल नहीं होना चाहिए। यदि आप किसी भी कारण से मृत्यु के "बड़े धमाके" विलय की उम्मीद करते हैं, तो एक सभ्य मौका लॉकिंग अन्य टीमों को समानांतर में एक ही चीज़ करने से रोक देगा, इसलिए जब तक आप तैयार न हों तब तक आपको चरण 1-4-4 के माध्यम से बार-बार प्रयास करना पड़ सकता है ।
2. जब भी संभव हो विलय "पकड़ो" करें। यही है, वही क्रम में चीजें मर्ज करें जिनकी जांच की गई थी। यदि परिवर्तन 10, 20, और 30 उम्मीदवार ए -> बी से विलय करने के लिए हैं, तो इनमें से कोई भी विलय श्रृंखला "पकड़ो:" 10 ~ 10, 10 ~ 20, 10 ~ 30। # 10 को छोड़ने वाली कोई भी परिवर्तन सीमा "चेरी पिक" के रूप में जानी जाती है।"एक बार जब आप उठा चेरी शुरू आपको कुछ खतरों में चलाने:। अकेले
   1. आप merge down, copy up मॉडल ऊपर वर्णित का उपयोग नहीं कर सकते हैं कि के लिए, लौरा Wingerd कहेंगे आप एक रोकने के ऊपर कूद रहे
   2. अगर किसी भी। आपकी सीमा में छूए गए फ़ाइलों को पहले भी स्पर्श किया गया था, आपको 3-तरफा सामग्री विलय करना होगा ताकि केवल चेरी-चुने हुए अंतर प्रसारित हो जाएं। कोई भिन्न उपकरण सही नहीं है; आप लाने का एक गैर-जोखिम जोखिम जोड़ रहे हैं इरादे से अधिक कोड पर, लक्ष्य में किए गए परिवर्तनों को गलती से ओवरराइट करना, तर्क कीड़े को प्रस्तुत करना, जहां दो शाखाएं अलग हो रही हैं, आदि
   3. आपके द्वारा अनुमानित रूप से अधिक स्थिर शाखा में प्रचार करने वाले परिवर्तनों का सेट कॉन्फ़िगरेशन था टी कभी बनाया गया या पहले परीक्षण किया गया था। आप लक्ष्य शाखा की अंतिम स्थिति के बारे में एक सभ्य अनुमान लगा सकते हैं। "मैं मॉड्यूल फू को प्रभावित करने वाले सभी परिवर्तनों में विलय कर रहा हूं, और मैंने देव में फू के नए संस्करण का परीक्षण किया, इस प्रकार फू एकीकरण में व्यवहार करेगा, है ना?" निश्चित रूप से ... शायद ... यदि आप अपने सिर में हर निर्भरता को ट्रैक कर सकते हैं (जिसमें आप परीक्षण का परीक्षण करते समय एकीकरण में बदल सकते हैं)। लेकिन इन अनुमानों को आपकी एससीएम उपकरण श्रृंखला द्वारा किसी भी तरह से जाना या मान्य नहीं किया गया है।
   4. विशेष रूप से टीएफएस में, चेरी चुनने जहां नामस्थान परिवर्तन शामिल हैं बस जला पाने के लिए कह रहे हैं। यदि आपकी संस्करण सीमा और/या पथ क्षेत्र में नाम के स्रोत को शामिल नहीं किया गया है, तो यह इसके बजाय शाखा के रूप में आ जाएगा। यदि आप लक्ष्य को बहिष्कृत करते हैं, तो यह एक हटा देगा। यदि आपके पथ के दायरे में अनावृत्त की जड़ शामिल नहीं है तो आपको गुप्त त्रुटियां मिलेंगी। यदि आपकी रेंज एक अनावृत & री-डिलीट के बीच एक समय बिताती है, तो आपको लक्ष्य में दिखाई देने वाली "प्रेत" फाइलें मिलेंगी, भले ही आप खुद को अनदेखा न करें। यदि आप अपने सभी पथ & संस्करण स्कॉप्स के साथ मूव को मर्ज करते हैं, लेकिन आदेश के बाहर ऐसा करते हैं, तो सभी उम्मीदवारों के परिवर्तन समाप्त होने के बाद भी स्रोत नाम से भिन्न लक्ष्य नाम समाप्त करना संभव है। मुझे यकीन है कि इस कॉम्बो को गलत होने के और तरीके हैं जो अभी ध्यान में नहीं आ रहे हैं ... बस मुझ पर भरोसा करें।
3. विलय से पहले हमेशा लक्ष्य शाखा पर जाएं। परम सुरक्षा के लिए उन्नत संस्करण: वर्कस्पेस को सिंक करें जहां आप टिप पर या उसके पास एक विशिष्ट परिवर्तन संख्या में विलय करेंगे, फिर भी [पकड़-अप] उसी परिवर्तन में विलय करें। ऐसा करने से बचा जाता है कुछ संभावित मुद्दों:
   1. , बासी कोड में मर्ज करना भ्रामक 3-जिस तरह से डिफ कि दिखाई देते हैं कि तुम क्या युक्ति पर देखने से परिवर्तनों को निकालने उपज। [आप उन्हें अंततः चेकइन + संकल्प पर वापस ले जाएंगे, लेकिन जब आप दोनों से बच सकते हैं तो दो जोखिम भरा अंतरों के माध्यम से जाने का कोई कारण नहीं है]
   2. संघर्ष समाधान प्रक्रिया के माध्यम से दो बार जाने के लिए: एक बार चेक पर एक बार मर्ज पर। सामान्य मामले में इससे बचने का कोई तरीका नहीं है, लेकिन अधिकांश समय में विलय + संकल्प करते समय एक साथ किए गए परिवर्तनों में से # आपके द्वारा कार्यक्षेत्र में होने वाले परिवर्तनों की तुलना में छोटा होता है जो कि दिन या सप्ताह हो सकता है तारीख।
4. लेबल (या वर्कस्पेस) द्वारा विलय न करें जबतक कि आप वास्तव में वास्तव में नहीं जानते कि आप क्या कर रहे हैं। आइए टीएफएस लेबल द्वारा दी गई सुविधाओं की समीक्षा करें और फिर विच्छेदन करें कि क्यों सुरक्षित & लगातार विलय के लिए प्रत्येक अनुचित है।
   1. लेबल समय पर कई बिंदुओं का प्रतिनिधित्व कर सकते हैं। यदि कोई लेबल वीसीएस के एक सतत स्नैपशॉट का प्रतिनिधित्व करता है - और हमेशा इस तरह का इरादा था - तो उसके पास तकनीकी कोई तिथि या परिवर्तन # पर लाभ नहीं है। दुर्भाग्यवश यह बताना मुश्किल है कि एक लेबल वास्तव में समय के साथ संगत है या नहीं।अगर सीमा एक लेबल है कि @ एक समय अपनी पहली उम्मीदवार
   2. अनजाने बहिष्कार के आगे एक आइटम के लिए अंक के साथ शुरू होता है,
      1. अनजाने चेरी पिकिंग, सीमा शुरू होती है, तो: यदि नहीं, तो लेबल के द्वारा विलय को जन्म दे सकता एक लेबल है कि @ एक समय सीमा के अंत से पहले एक आइटम के लिए अंक के साथ
      2. अनजाने बहिष्कार, सीमा एक लेबल है कि @ एक समय सीमा के शुरू होने से पहले एक आइटम के लिए अंक के साथ समाप्त होता है, तो
   3. लेबल संस्करणपीसी वस्तुओं के एक विशिष्ट सेट का प्रतिनिधित्व करते हैं। इन्हें जानबूझकर फ़ाइलों और फ़ोल्डरों को बाहर करने के लिए उपयोग किया जा सकता है कि एक शुद्ध रिकर्सिव क्वेरी अन्यथा देखेगी। यह सुविधा भी मर्ज ऑपरेशंस के लिए एक खराब मैच है। (और फिर, अगर तुम नहीं इस क्षमता की जरूरत है , तो आपको निम्न जोखिम से अधिक तारीखों & changesets कुछ भी प्राप्त किए बिना उठाने रहे हैं।)
      1. आइटम लेबल में मौजूद नहीं बस नजरअंदाज कर दिया जाएगा, न कि विलय कर दिया लंबित हटाए गए के रूप में। अभी तक कवर किए गए किनारे के कुछ मामलों के विपरीत, यह एक बड़ा सौदा है जो मुख्यधारा के परिदृश्यों में होने की संभावना है, लेकिन अधिकांश लोग याद करते हैं। आप लेबल है कि कुछ समय के लिए मौजूद है लेकिन ऊपर उल्लिखित ओर से एक की वजह से पहले आपस में विलय से बाहर रखा गया था करने के लिए एक आइटम जोड़ने अगर [नतीजतन, TFS 2010 समर्थन लेबल के अंदर हटाए गए आइटम के लिए कहते हैं।]
      2. अनजाने चेरी पिकिंग प्रभाव।
      3. जानबूझकर चेरी पिकिंग। इस सुविधा का पूरा लाभ मर्ज करने के लिए लाता है, हमारे दिशानिर्देशों में से एक को तोड़ना है, इसलिए जाहिर है कि यह एक अच्छा कारण नहीं है। इसके अलावा, यह फ़ाइल स्तर पर चेरी-पिकिंग का कारण बनता है, जो परिवर्तन द्वारा "साधारण" चेरी चुनने से भी अधिक खतरनाक है।
   4. लेबल अनुकूल अनुकूलन के नाम, मालिकों, और टिप्पणी है। इस प्रकार हमारे पास शुद्ध उपयोगिता अंतर बनाम दिनांक/परिवर्तन हैं; कोई तकनीकी लाभ प्रदान नहीं किया जाता है। लेकिन यहां तक ​​कि यह दिखने के रूप में आकर्षक नहीं है। टीएफएस वास्तव में यूआई में लेबल लेबल करने के लिए बहुत कुछ नहीं करता है, जबकि आप जगह पर परिवर्तन टिप्पणियां देख सकते हैं। मालिक द्वारा पूछताछ तेज़ (सर्वर पक्ष) है, लेकिन अधिकांश अन्य खोज धीमी (क्लाइंट साइड) हैं जबतक कि आप सटीक लेबल नाम नहीं जानते। प्रबंधन सुविधाएं लगभग अनौपचारिक हैं। कोई चेंजलॉग या ऑडिटिंग नहीं, केवल एक टाइमस्टैम्प। कुल मिलाकर, परिवर्तनों द्वारा प्रदान की गई गारंटी को छोड़ने के लिए शायद ही कभी कारण हैं।
5. हमेशा एक ही समय में पूरी शाखा को विलय करें। विलय करने वाली फाइलें या सबट्री कभी-कभी मोहक होती हैं, लेकिन आखिरकार केवल एक नई आराधना के तहत चेरी-पिकिंग की मात्रा होती है।
6. आगे की योजना बनाएं। दुर्भाग्य से, टीएफएस में फिर से पालन करने वाली शाखाएं एक दर्दनाक विषय है। कभी-कभी यह कठिन होता है, कभी-कभी यह केवल कुछ ही कदम होता है, लेकिन यह कभी भी स्पष्ट नहीं है; कमांड में कोई निर्मित नहीं है (2010 तक)। 2005/2008 में इसे खींचने के लिए आपकी वर्तमान शाखा संरचना, वांछित संरचना, और विभिन्न टीएफ कमांड के साइड इफेक्ट्स का दुरुपयोग करने के बारे में बहुत गहरा ज्ञान होना आवश्यक है।
7. शाखाओं के अंदर शाखाएं न बनाएं। उदाहरण के लिए, & विलय को शाखाओं को कभी-कभी समान मॉड्यूल या कमजोर युग्मित परियोजनाओं के बीच बाइनरी को बनाए रखने के तरीके के रूप में अनुशंसा की जाती है। मुझे नहीं लगता कि यह शुरू करने के लिए बहुत अच्छी सलाह है - अपने निर्माण प्रणाली को अपनी प्राथमिक नौकरी ठीक से करने के लिए बेहतर है, अपने स्रोत नियंत्रण प्रणाली को ऐसा करने में वास्तव में करने के लिए तैयार नहीं किया गया है। वैसे भी, यह "साझाकरण" रणनीतियां पूरी तरह से एससीएम प्रयोजनों के लिए व्यापक शाखा पदानुक्रम के अंदर रहने वाली परियोजनाओं के साथ संघर्ष करती हैं। यदि आप सावधान नहीं हैं, तो टीएफएस आपको खुशी से संस्करण नियंत्रण वस्तुओं के बीच कई शाखा संबंधों को मनमाने ढंग से बनाने देगा। शुभकामनाएं कि इसे बाहर निकालना (मुझे एक बार ग्राहक के लिए ऐसा करना था, सुंदर नहीं।)
8. स्वतंत्र रूप से दो शाखाओं में समान सापेक्ष पथ वाली फ़ाइलों को न बनाएं; उन्हें चारों ओर शाखा बनाने के लिए मर्ज का उपयोग करें या आप नेमस्पेस संघर्षों का पीछा करने में घंटों खर्च करेंगे। (2010 में एन/ए)
9. पथ के शीर्ष पर फ़ाइलों को दोबारा न जोड़ें जहां अन्य वस्तुओं का अस्तित्व था। क्या पुराने आइटम का नाम बदल दिया गया था/हटा दिया गया था, या बस हटा दिया गया है, आपको मर्ज समय पर दिलचस्प चुनौतियों का सामना करना पड़ेगा; कम से कम, इसे पूरी तरह प्रचार करने के लिए दो चेकइन की आवश्यकता होगी। (2010 में एन/ए, हालांकि अनुभव अभी भी कुछ हद तक खराब है, केवल 1 चेकइन की आवश्यकता है, आइटम सामग्री संरक्षित है, लेकिन नाम इतिहास उस शाखा में है & सभी डाउनस्ट्रीम शाखाएं)
10. /बल ध्वज का उपयोग न करें जब तक आप नहीं जानते कि आप क्या कर रहे हैं। सभी/बल विलय प्रभावी ढंग से चेरी चुनते हैं, जिससे बहुत ही समान जोखिम होते हैं (संकल्प प्रक्रिया के दौरान कोड खो जाना आदि)।
11. /बेकार ध्वज का उपयोग न करें जबतक कि आप वास्तव में वास्तव में नहीं जानते कि आप क्या कर रहे हैं। आप हटाए गए सामानों से चूक जाते हैं - लेबल के समान, सिवाय इसके कि नाम हमेशा दुर्भाग्यपूर्ण किनारे के मामलों की बजाय शाखाओं में फंस गए हैं। आपको कोई भी डेबिट/क्रेडिट सुरक्षा नहीं मिलती है। और सबसे डरावना, आप नए शाखा संबंध बनायेंगे। कभी कभी। (उपयोगकर्ता को कोई प्रतिक्रिया नहीं दिखायी जाती है कि क्या प्रत्येक लक्ष्य आइटम नए हैं, पुराने संबंध के साथ पुराने हैं, या मौजूदा रिश्तों के साथ पुराना है)
12. जब संभव हो तो से बचें/छोड़ दें (और समकक्ष, स्वीकार्य करें प्रस्ताव)। बाद में स्वीकार करने के लिए कुछ बदलावों को छोड़कर चेरी-पिकिंग के लिए अभी तक एक और नाम है :)
13. सामान्य रूप से अपने संकल्पों से सावधान रहें। प्रत्येक में मर्ज पर इसके प्रभाव के अलावा अद्वितीय डाउनस्ट्रीम प्रभाव होते हैं।
    1. स्वीकार करें एक त्वरित प्रतिलिपि में वकालत के रूप में एक "प्रतिलिपि" विलय प्राप्त करने के लिए शक्तिशाली & शक्तिशाली तरीका है। यदि आप इसे अन्य परिदृश्यों में भी उपयोग करते हैं, तो याद रखें कि आप बस फ़ाइल सामग्री को समान बनाने के लिए TFS को बता रहे हैं। आप यह कह रहे हैं कि दो फाइलें पूरी तरह से एक संस्करण पीओवी से सिंक में हैं। बुद्धिमानी के लिए, लक्ष्य फ़ाइल में किसी भी पूर्व परिवर्तन जो कि विपरीत दिशा में विलय हो सकता है, अब एक स्वीकार्य सिद्धांतों की जांच करने के बाद उम्मीदवारों को नहीं माना जाएगा।
    2. ध्यान दें कि एक AcceptMerge (ऑटो या मैन्युअल) जिसके परिणामस्वरूप सामग्री स्रोत फ़ाइल के समान है सर्वर द्वारा AcceptTheirs माना जाएगा। चेकइन webservice प्रोटोकॉल में कोई अंतर नहीं है।
    3. जब नाम शामिल होते हैं तो AcceptYours का उपयोग करके आपके दिमाग को मोड़ सकते हैं। आप जल्दी से ऐसी परिस्थिति में समाप्त हो जाएंगे जहां "समान" आइटम के अलग-अलग शाखाओं में अलग-अलग नाम हों। मान लीजिए कि आपके पास पहली जगह में बदलावों को छोड़ने का एक अच्छा कारण है, यह घटना असुरक्षित नहीं है - असल में, संभवत: आपके मेकफ़ाइल में ब्रेक या एक-ऑफ कस्टमाइज़ेशन बनाने से बचना आवश्यक है। यह मनुष्यों के लिए सिर्फ भ्रमित है, और आपके पास ऐसी किसी भी स्वचालन स्क्रिप्ट को तोड़ने की संभावना है जो मानते हैं कि वृक्ष संरचनाएं शाखा से शाखा तक सुसंगत हैं।
    4. AcceptMerge किसी कारण के लिए डिफ़ॉल्ट है। यह कभी-कभी सख्ती से जरूरी प्रतीत होने से अधिक संस्करण संघर्षों की ओर जाता है, लेकिन जब वास्तविक विलय की आवश्यकता होती है तो सबसे सुरक्षित विकल्प होता है। (प्राथमिक दिशानिर्देश के चरण # 1 "विलय करें, प्रतिलिपि बनाएं"।) जब तक आप अन्य दिशानिर्देशों का पालन कर रहे हों, तब तक विलय की संख्या जिसके लिए मैन्युअल ध्यान की आवश्यकता होती है - नाटकीय रूप से यदि आप किसी से आ रहे हैं वर्कफ़्लो जो चेरी-पिकिंग पर भारी है।
14. बग्स को उस परिवर्तन से जोड़ा जाना चाहिए जहां वास्तव में फ़िक्स बनाया गया था। यदि आपको बाद में डाउनस्ट्रीम शाखाओं में ड्रिल करने की आवश्यकता है, तो यह देखने के लिए कि, जहां (और संभवतः कैसे) बगफिक्स प्रसारित किया गया था, यह पूरी तरह से स्रोत नियंत्रण फ़ंक्शन है। अतिरिक्त सामान के साथ कार्य आइटम को प्रदूषित करने की कोई आवश्यकता नहीं है, जिस तरह से आप मौलिक रूप से विलय करते हैं।2005/2008 में आप 'tf merges' कमांड या अटारीस साइडकिक्स जैसे तृतीय पक्ष UI के साथ विलय इतिहास को पार कर सकते हैं। 2010 में आपको विजुअल स्टूडियो में निफ्टी विज़ुअलाइजेशन मिले। Instructions & screenshots on MSDN.

Answer 2

मैंने हमेशा एकीकरण शाखा में कई प्रकार की कमाई की है, जो केवल विलय किए गए परिवर्तनों की सीमा निर्दिष्ट करते हैं।

विकास चरण में व्यक्तिगत कार्य वस्तुओं से संबंधित कार्य आइटम विकास चरण कार्य आइटम हैं। मुझे नहीं लगता कि उन्हें एकीकरण या रिलीज पर रोल करने की आवश्यकता है।

आपने यह निर्दिष्ट नहीं किया है कि आप कहां से ग्राहकों से बग/फीचर अनुरोध रिकॉर्ड कर रहे हैं। यदि आप इसे रिलीज शाखा में असाइन कर रहे हैं तो आप शायद विकास शाखा के लिए अन्य, अधिक विस्तृत कार्य आइटम बना रहे हैं और जब आप विलय करते हैं तो आप जिस शाखा में विलय कर रहे हैं, उसके लिए बग फिक्स को हल करने के सभी मुद्दों को आसानी से चिह्नित करेंगे।

तो इसे संक्षेप में मुझे कोई कारण नहीं दिखता कि थोक विलय के साथ क्यों नहीं जाना है।