गेट बनाम टीम फाउंडेशन सर्वर [बंद]

262

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

7 साल पहले बंद हुआ ।

मैंने अपनी देव टीम में Git का परिचय दिया, और हर कोई इसे छोड़कर मुझसे नफरत करता है। वे इसे टीम फाउंडेशन सर्वर से बदलना चाहते हैं। मुझे ऐसा लगता है कि यह बहुत बड़ा कदम है, हालांकि मैं टीएफएस से बहुत परिचित नहीं हूं। क्या अनुभव वाला कोई व्यक्ति TFS पर Git शाखाओं में बँटने के समर्थन की तुलना कर सकता है? इसके अलावा, सामान्य तौर पर, टीएफएस के पेशेवरों और विपक्ष क्या हैं? मैं कुछ वर्षों के लिए गिट का उपयोग करने के बाद इसे नफरत करने जा रहा हूं?

git tfs tfvc

— Jacko
स्रोत

24

आप इस पर एक कठिन लड़ाई का सामना करते हैं। Git विंडोज पर svn / hg / tfs के रूप में परिपक्व नहीं है, जो git के दिग्गजों को ज्यादा परेशान नहीं करता है, लेकिन नए लोगों के लिए एक प्रमुख सिरदर्द है।

— मार्सेलो कैंटोस

7

@ जैको: मैं पिछले कुछ हफ्तों से गिट-फॉर-विंडोज का मूल्यांकन कर रहा हूं। जबकि मैंने लगभग एक साल पहले इसे देखा था, तब से इसमें सुधार हुआ है, यह अभी भी विंडोज विंडोज डेवलपर्स के साथ प्राइम टाइम के लिए तैयार होने का एक लंबा रास्ता है। उदाहरण के लिए, वीएस प्लगइन स्पष्ट रूप से कमजोर है। यह मुख्य मेनू बार के तहत मेनू विकल्पों का एक गुच्छा के अलावा कुछ भी नहीं है, जो एक परियोजना के बजाय समाधान का चयन करने पर चुपचाप विफल हो जाता है। मैं अनुक्रमणिका हूक और लाइनों को कमिट नहीं कर सकता, जो कि मुख्य कारण है जो मैं git का उपयोग करता हूं, और git gui (जो कि एक पूर्ण अत्याचार है, प्रयोज्य POV से) के लिए सबसे अच्छा है।

— मार्सेलो कैंटोस

6

मैं आपके साथ ईमानदार रहूँगा, हालाँकि; यह मुझे गिर छोड़ने के लिए मारता है। लोकप्रिय दृश्य के विपरीत कि दोनों बराबर हैं, मुझे गिट का मॉडल अधिक शक्तिशाली और तार्किक लगता है। मर्क्यूरियल के पास git के सूचकांक से मेल खाने के लिए कुछ भी नहीं है, और मैं शाखा के लिए इसके दृष्टिकोण से नफरत करता हूं। आपके द्वारा आगे बढ़ने और रेपो के बीच तालमेल रखने वाले लेबल की Git की अवधारणा बहुत ही सुंदर है। मर्क्यूरियल के बुकमार्क केवल एक चीज है जो करीब आता है और वे सभी के लिए स्थापित करने के लिए एक पीआईटीए हैं। लब्बोलुआब यह है, हालांकि, यह है कि सफलता svn → svur → मर्क्यूरियल से svn → git के साथ अधिक संभावना है, कर्मचारियों और उपकरण की सापेक्ष परिपक्वता को देखते हुए।

— मार्सेलो कैंटोस

4

हाँ, Git नियम जब यह सत्ता और लालित्य की बात आती है। लेकिन, हर कोई इसके लिए तैयार नहीं है।

— जैको

7

@JamesReategui: मुझे व्यक्तिगत रूप से लगता है कि ( stackoverflow.com/a/11362998/520162 ) कि एक IDE में VCS का एकीकरण एक निवाला है। सोचिए अगर आप अपना मुख्य आईडीई कल बदल रहे हों। क्या होगा यदि आप ग्रहण के लिए वी.एस. क्या आप वास्तव में एक नया वीसीएस एकीकरण सीखने के लिए तैयार हैं? Git कमांड लाइन पर बहुत अच्छा है ( stackoverflow.com/a/5645910/520162 )। इसे जानें और आप संस्करण नियंत्रण की एक अविश्वसनीय रूप से शक्तिशाली दुनिया की खोज करेंगे।

— जूल

272

मुझे लगता है, बयान

हर कोई इसे छोड़कर मुझसे नफरत करता है

आगे कोई चर्चा व्यर्थ करता है: जब आप Git का उपयोग करते रहेंगे, तो वे कुछ भी गलत होने पर आपको दोषी ठहराएंगे ।

इसके अलावा, मेरे लिए Git के एक केंद्रीकृत VCS पर दो फायदे हैं जिनकी मैं सबसे अधिक सराहना करता हूं (जैसा कि रॉब Sersers द्वारा आंशिक रूप से वर्णित है ):

पूरे रेपो का स्वचालित बैकअप: हर बार जब कोई केंद्रीय रेपो से खींचता है, तो उसे परिवर्तनों का पूरा इतिहास मिलता है। जब एक रेपो खो जाता है: चिंता न करें, हर वर्कस्टेशन पर मौजूद लोगों में से एक को लें।
ऑफ़लाइन रेपो पहुँच: जब मैं घर पर काम कर रहा हूँ (या किसी विमान या ट्रेन में), मैं परियोजना, हर एक चेकइन से भरा इतिहास देख सकते हैं, काम करने के लिए अपने VPN कनेक्शन प्रारंभ किए बिना और जैसे मैं काम कर सकते हैं कर रहे थे काम पर : चेकइन, चेकआउट, शाखा, कुछ भी।

लेकिन जैसा कि मैंने कहा: मुझे लगता है कि आप एक हारी हुई लड़ाई लड़ रहे हैं: जब हर कोई Git से नफरत करता है, तो Git का उपयोग न करें। यह आपको यह जानने में अधिक मदद कर सकता है कि वे उन्हें समझाने की कोशिश करने के बजाय गिट से नफरत क्यों करते हैं।

अगर वे बस यह नहीं चाहते हैं, क्योंकि यह उनके लिए नया है और कुछ नया सीखने को तैयार नहीं हैं: क्या आप सुनिश्चित हैं कि आप उस कर्मचारी के साथ सफल विकास करेंगे?

क्या वास्तव में हर एक व्यक्ति गिट से नफरत करता है या वे कुछ राय नेताओं से प्रभावित हैं? नेताओं को ढूंढें और उनसे पूछें कि समस्या क्या है। उन्हें मनाओ और तुम बाकी टीम को मनाओगे।

यदि आप नेताओं को मना नहीं सकते हैं: Git का उपयोग करने के बारे में भूल जाएं, TFS लें। आपके जीवन को आसान बना देगा।

— Eckes
स्रोत

22

बैंग ऑन, एकेस। जब भी कुछ गलत होता है तो वे मुझे दोषी ठहराते हैं। यह कैसे काम करता है यह जानने में विफल रहने के लिए खुद को नहीं। मेरे लिए, Git पूर्णता के करीब है जैसा कि मैंने कभी संस्करण नियंत्रण प्रणाली में अनुभव किया है।

— जैको

15

दूसरी ओर टीएफएस में दोष / कार्य मद ट्रैकिंग, रिपोर्टिंग, ... और अन्य कार्य शामिल हैं। तो वीसीएस कार्यक्षमता पर जीएसटी बनाम टीएफएस के बजाय केवल टीएफएस की बात याद आ रही है।

— रिचर्ड

5

@ देखें रिबास, फिल्टर-ट्री ...

— आर्टिफैक्टो

7

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

— दान सोलोवै

6

@ रिचर्ड मैं तर्क देता हूं कि यह TFS के लिए एक नकारात्मक पक्ष है: एक बार जब आप अंदर होते हैं, तो आप सभी में होते हैं। यह सब कुछ औसत दर्जे का करता है और आपको इसके बारे में कोई विकल्प नहीं देता है। काम की वस्तुओं पर नज़र रखने, रिपोर्टिंग और परियोजना प्रबंधन के लिए कहीं बेहतर उपकरण हैं।

— बेन कॉलिन्स

102

दो प्रणालियों के बीच महत्वपूर्ण अंतर यह है कि TFS एक केंद्रीकृत संस्करण नियंत्रण प्रणाली है और Git एक वितरित संस्करण नियंत्रण प्रणाली है।

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

सर्वर के मर जाने की स्थिति में आपके डेवलपर की मशीनों पर पूर्ण भंडार होने का एक लाभ अतिरेक है। एक और अच्छी बात यह है कि आप बिना सर्वर से बात किए बगैर संशोधनों के बीच अपनी वर्किंग कॉपी को आगे-पीछे कर सकते हैं, जो सर्वर डाउन होने या सिर्फ अगम्य होने पर मददगार हो सकता है।

मेरे लिए, वास्तविक वरदान है कि आप कर सकते हैं के लिए प्रतिबद्ध कभी सर्वर से बात कर या अपनी टीम पर संभावित अस्थिर परिवर्तन पहुंचाई (यानी, निर्माण तोड़ने) के बिना अपने स्थानीय भंडार को changesets।

उदाहरण के लिए, यदि मैं एक बड़ी सुविधा पर काम कर रहा हूं, तो मुझे इसे पूरी तरह से कोड करने और परीक्षण करने में एक सप्ताह लग सकता है। मैं अस्थिर-मध्य-सप्ताह में चेक-इन नहीं करना चाहता हूं और बिल्ड को तोड़ना चाहता हूं, लेकिन क्या होगा यदि मैं सप्ताह के अंत में पास हो जाऊं और मैं गलती से अपनी पूरी वर्किंग कॉपी को छोड़ दूं? अगर मैं अपने काम को पूरा करने के जोखिम के साथ खड़ा नहीं होता हूं। यह प्रभावी संस्करण नियंत्रण नहीं है, और TFS इसके लिए अतिसंवेदनशील है।

डीवीसीएस के साथ, मैं बिल्ड को तोड़ने की चिंता किए बिना लगातार प्रतिबद्ध कर सकता हूं, क्योंकि मैं स्थानीय रूप से अपने बदलाव कर रहा हूं । टीएफएस और अन्य केंद्रीकृत प्रणालियों में स्थानीय चेक-इन की कोई अवधारणा नहीं है।

मैं DVCS में कितना बेहतर ब्रांचिंग और मर्जिंग कर रहा हूं, लेकिन आप SO या Google के माध्यम से यहां पर कई स्पष्टीकरण पा सकते हैं। मैं आपको अनुभव से बता सकता हूं कि TFS में ब्रांचिंग और विलय अच्छा नहीं है।

यदि आपके संगठन में TFS के लिए तर्क यह है कि यह Git की तुलना में Windows पर बेहतर काम करता है, तो मैं Mercurial का सुझाव दूंगा, जो Windows पर बहुत अच्छा काम करता है - Windows Explorer (TortoiseHg) और Visual Studio (VisualHg) के साथ एकीकरण है।

— रोब सोबर्स
स्रोत

5

यदि आप मर्क्यूरियल के साथ जाने के बारे में सोचते हैं, जोएल स्पोलस्की के पास आपकी टीम को शिक्षित करने के लिए एक उत्कृष्ट ट्यूटोरियल साइट है: hginit.com

— मार्टिन ओवेन

3

यह ध्यान देने योग्य हो सकता है कि git पूरी तरह से एक केंद्रीकृत प्रणाली का अनुकरण करने योग्य है, और सभी उपयोगकर्ताओं के लिए एक प्राथमिक git सर्वर होना आम है, आपको बस इसे इस तरह से करने की आवश्यकता नहीं है ।

— टिम एबेल

7

यदि आप कार्यशीलता के एक टुकड़े पर काम कर रहे हैं जो अन्य सामानों को तोड़ सकता है - तो क्या आप टीएफएस में एक शाखा नहीं बना सकते हैं? ज़रूर - शाखा एक केंद्रीय सर्वर पर है - लेकिन क्या यह वास्तव में मायने रखता है? ऐसा लगता है कि आप दोनों में समान रूप से प्रभावी रूप से कर सकते हैं - ऐसा लगता है कि आप आईडीई का उपयोग कर रहे हैं और इसके साथ संस्करण नियंत्रण प्रणाली को कितनी अच्छी तरह से एकीकृत किया गया है

— विलियम

13

यदि आप एक बड़ी विशेषता पर काम कर रहे हैं जो संभावित रूप से टीम को बाधित कर सकती है तो उसे एक सुविधा शाखा का उपयोग करने की सिफारिश की जाती है और फिर तैयार होने पर विकास शाखा में विलय हो जाता है।

— माइक चेल

9

@MikeCheel यह एक शानदार टिप्पणी है। आप हर दिन अपने कोड का एक शेल्व भी बना सकते हैं और उन्हें हटा सकते हैं जब आप अंत में अपनी सुविधा में चेक-इन (लेकिन शाखा विचार यह करने का एक बेहतर तरीका है)

— RPDeshaies

86

लोगों को बंदूक से नीचे उतरने की जरूरत है, आगे बढ़ने से दूर, और एक मिनट के लिए सोचें । यह पता चलता है कि डीवीसीएस के उद्देश्य, ठोस और निर्विवाद फायदे हैं जो एक टीम की उत्पादकता में एक बड़ा अंतर बनाएंगे।

यह सभी ब्रांचिंग और विलय के लिए नीचे आता है।

डीवीसीएस से पहले, मार्गदर्शक सिद्धांत था "ईश्वर से प्रार्थना करें कि आपको ब्रांचिंग और विलय में शामिल होने की आवश्यकता नहीं है। और यदि आप ऐसा करते हैं, तो कम से कम भीख माँगने के लिए इसे बहुत, बहुत सरल होने दें।"

अब डीवीसीएस के साथ, ब्रांचिंग ( और विलय ) में बहुत सुधार हुआ है, मार्गदर्शक सिद्धांत यह है, "इसे एक टोपी की बूंद पर करो। यह आपको एक टन लाभ देगा और आपको कोई समस्या नहीं होगी।"

और यह किसी भी टीम के लिए एक बड़ा उत्पादकता बूस्टर है।

समस्या यह है कि लोगों को यह समझने के लिए कि मैंने अभी क्या कहा है और आश्वस्त होना चाहिए कि यह सच है, उन्हें पहले थोड़ा सीखने की अवस्था में निवेश करना होगा। उन्हें खुद Git या किसी अन्य DVCS को सीखने की आवश्यकता नहीं है ... उन्हें बस यह सीखने की जरूरत है कि Git कैसे ब्रांचिंग और विलय करता है। कुछ लेखों और ब्लॉग पोस्टों को पढ़ें और फिर से पढ़ें, इसे धीमी गति से लें, और जब तक आप इसे नहीं देखेंगे तब तक इसके माध्यम से काम करेंगे। यह पूरे 2 या 3 दिनों का बेहतर हिस्सा हो सकता है।

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

— चार्ली फूल
स्रोत

3

धन्यवाद, चार्ली। मैं इसे जानता हूं, और आप इसे जानते हैं, लेकिन उन लोगों के माध्यम से प्राप्त करना कठिन है जो "विजुअल स्टूडियो के साथ सोर्स कंट्रोल का एकीकरण" जैसी चीजें कहते हैं, मेरे लिए सबसे महत्वपूर्ण विशेषता है "

— जैको

58

मुझे पता है। एक मित्र और मैं इस सादृश्य को फेंक रहे थे - कल्पना कीजिए कि आपको एक गंभीर संबंधपरक डेटाबेस की आवश्यकता है। आप Sql Server, Oracle, और MS Access का मूल्यांकन करते हैं। आप एक्सेस को चुनना समाप्त करते हैं क्योंकि इसमें सबसे अच्छा GUI है, इस तथ्य के बावजूद कि यह स्केल नहीं कर सकता है, संदर्भात्मक अखंडता को बहुत अच्छी तरह से लागू नहीं करता है, आदि ब्रांचिंग और विलय एक संस्करण नियंत्रण प्रणाली के पूर्ण मांस और आलू हैं। किसी भी अन्य सुविधा के पक्ष में थोड़ा धुंधला है। लेकिन लोग ब्लिंग के आधार पर चुनाव कर रहे हैं।

— चार्ली फूल

17

जब मैं आपके कथनों से सहमत होता हूं, तो मैं यह नहीं देखता कि गीट की ब्रांचिंग और मर्जिंग "बेहतर" है क्योंकि यह एक "वितरित" प्रणाली है। मुझे यकीन नहीं है कि एक DVCS होने के नाते विलय करने की क्षमता के साथ कुछ भी करना है। मुझे इस बात का स्पष्टीकरण पसंद है कि किसी वितरित प्रणाली में विलय आसान क्यों है। मेरे अनुभव में, जो मुख्य रूप से Git और Svn है, SVN में विलय भयानक नहीं है क्योंकि यह एक केंद्रीकृत VCS है, लेकिन क्योंकि यह GIT जैसी शाखाओं के पार संशोधनों को ठीक से ट्रैक नहीं करता है।

— कोडिंगविथस्पाइक

8

@ rally25rs - मैं उस सबसे सहमत हूं। कोई कारण नहीं है कि VCS विलय में भी अच्छा नहीं हो सकता। वहाँ अभी तक कोई नहीं कर रहे हैं (कि मुझे पता है)। लेकिन जिस हिस्से से मैं असहमत हूं, वह "शुद्ध रूप से बेहतर मर्ज दिनचर्या लिखकर है जो संघर्षों को बेहतर तरीके से हल करता है।" गुप्त सॉस बेहतर होशियार मर्ज दिनचर्या में नहीं है, लेकिन एक मौलिक रूप से अलग दृष्टिकोण लेने में कि आप किस जानकारी को रेपो में संग्रहीत करते हैं और आप इसे कैसे व्यवस्थित करते हैं। मुख्य रूप से, कमिट्स को आंतरिक स्थिति की नींव बनाना। कमिट सिर्फ एक कूल बोल्ट-ऑन नहीं हैं ... वे क्षमताओं की नींव हैं।

— चार्ली फूल

10

@ rally25rs पूरी तरह से फिर से सहमत हैं: काम की परमाणु इकाई होने के लिए प्रतिबद्ध है। न केवल अधिकांश केंद्रीकृत प्रणालियां इस तरह से डेटा को व्यवस्थित नहीं करती हैं, बल्कि वे उस तरह के पल-पल के काम को हतोत्साहित करती हैं जो डेवलपर्स को वास्तव में अच्छी शाखा-और-मर्ज कार्य करने के लिए करना पड़ता है। वितरित प्रणालियां प्रोत्साहित करती हैं कि मैं "एपोसाइट" को क्या कहता हूं (स्व-निहित, अच्छे विवरण के साथ प्रासंगिक काम के छोटे-छोटे काम) और केंद्रीकृत सिस्टम इस बात को प्रोत्साहित करते हैं कि मैं "बम" को अलग करता हूं जहां आप तैयार होने तक गुफा में छेद करते हैं और फिर ड्रॉप करते हैं (या सप्ताह) प्रणाली पर काम के लायक। लगता है कि किस तरह का विलय सबसे अच्छा है?

— बेन कॉलिन्स

45

मूल : @Rob, TFS कुछ "कहा जाता है शेल्फ़ " है कि यह सरकारी निर्माण को प्रभावित किए बिना काम में प्रगति करने से के बारे में अपनी चिंताओं का समाधान भी। मुझे लगता है कि आप केंद्रीय संस्करण नियंत्रण को एक बाधा के रूप में देखते हैं, लेकिन टीएफएस के संबंध में, अपने कोड को शेल्फ में जांचना ताकत बी / सी के रूप में देखा जा सकता है, फिर केंद्रीय सर्वर में दुर्लभ घटना में आपके काम की प्रगति की एक प्रति है आपकी स्थानीय मशीन क्रैश हो जाती है या खो जाती है / चोरी हो जाती है या आपको गियर को जल्दी से स्विच करने की आवश्यकता होती है। मेरा कहना है कि टीएफएस को इस क्षेत्र में उचित प्रशंसा दी जानी चाहिए। इसके अलावा, TFS2010 में ब्रांचिंग और विलय को पहले संस्करणों से बेहतर किया गया है, और यह स्पष्ट नहीं है कि आप किस संस्करण का जिक्र कर रहे हैं जब आप कहते हैं "... अनुभव से कि टीएफएस में ब्रांचिंग और विलय अच्छा नहीं है।" अस्वीकरण: मैं TFS2010 का एक मध्यम उपयोगकर्ता हूं।

Dec-5-2011 को संपादित करें : ओपी के लिए, टीएफएस के बारे में मुझे परेशान करने वाली एक बात यह है कि यह आपके सभी स्थानीय फाइलों को "केवल पढ़ने के लिए" सेट करने पर जोर देता है जब आप उन पर काम नहीं कर रहे होते हैं। यदि आप एक बदलाव करना चाहते हैं, तो प्रवाह यह है कि आपको फ़ाइल को "चेक-आउट" करना होगा, जो कि फ़ाइल पर केवल आसानी से विशेषता को साफ़ करता है ताकि टीएफएस उस पर नज़र रखना जानता हो। यह एक असुविधाजनक कार्यप्रवाह है। जिस तरह से मैं इसे काम करने के लिए पसंद करूंगा वह यह है कि अगर मैंने कोई बदलाव किया है तो यह स्वतः ही पता लगा लेता है और फ़ाइल विशेषताओं के साथ चिंता / परेशान नहीं करता है। इस तरह, मैं फ़ाइल को विज़ुअल स्टूडियो, या नोटपैड, या जो भी उपकरण कृपया के साथ संशोधित कर सकता हूं। संस्करण नियंत्रण प्रणाली इस संबंध में यथासंभव पारदर्शी होनी चाहिए। एक विंडोज एक्सप्लोरर एक्सटेंशन ( टीएफएस पावरटूल) है) जो आपको विंडोज़ एक्सप्लोरर में अपनी फ़ाइलों के साथ काम करने की अनुमति देता है, लेकिन यह वर्कफ़्लो को बहुत सरल नहीं करता है।

— ली ग्रिसोम
स्रोत

2

यह सवाल का जवाब देता है, यह एक टिप्पणी नहीं होनी चाहिए, भले ही आपके पास प्रतिनिधि हों।

— एकलकरण २

8

FYI करें - TFS "11" को केवल तभी पढ़ने की आवश्यकता नहीं है यदि आप स्थानीय कार्यस्थानों का उपयोग कर रहे हैं जो अब डिफ़ॉल्ट है। यह समझदारी से पता चलता है कि किसी भी एप्लिकेशन से क्या फाइलें बदली जाती हैं। ब्रायन हैरी के यहाँ सुधार के बारे में कुछ और जानकारी है: blogs.msdn.com/b/bharry/archive/2011/08/02/…

— Ed Blankenship

2

@EdBlankenship, उस ब्लॉग लिंक के लिए आपका बहुत-बहुत धन्यवाद। यह देखना बेहतरीन खबर है कि टीएफएस के अगले संस्करण का उपयोग करने के लिए रीड-ओनली बिट बकवास को बहुत आसान बताया जा रहा है।

— ली ग्रिसोम

7

एक शाखा में करने के विपरीत, जैसे आप Git के साथ करते हैं, ठंडे बस्ते को समझना और प्रबंधित करना आसान नहीं है। आपको पता नहीं है कि प्रत्येक स्थान पर शेल्फ़ बनाया गया था और आपको अक्सर मर्ज की समस्या होती है (यदि आपके पास तब से किए गए संशोधन हैं, तो वे अक्सर खो जाते हैं)। गित शाखा ठंडे बस्ते में डालने की तुलना में बहुत अधिक शक्तिशाली और समझने योग्य है। शेल्विंग डेवेलपर्स के लिए है जो कभी किसी और चीज़ का अनुभव नहीं करते ...

— फिलिप

2

किसी फ़ाइल को 'चेक-आउट' करने का यह वर्कफ़्लो विजुअल सोर्ससेफ़ की याद दिलाता है, क्योंकि यह काम करने का सामान्य तरीका था; फ़ाइलें SourceSafe से पुनर्प्राप्त की गईं और स्थानीय रूप से केवल-पढ़ने वाली फ़ाइलों के रूप में संग्रहीत की गईं। फ़ाइल की जाँच करना, या फ़ाइलों का एक गुच्छा, अनन्य के रूप में चिह्नित किया जा सकता है, जिसका अर्थ है कि अन्य लोग फ़ाइल-सेट को देख सकते हैं कि कोई अन्य देव काम कर रहा है, जैसे कि ब्रांचिंग अक्षम होने पर विलय की आवश्यकता को रोकने के लिए (शायद एक होने के कारण सही सुअर VSS में)।

— ब्रेट रिग्बी

18

सब कुछ के ऊपर कहा गया है (

https://stackoverflow.com/a/4416666/172109

https://stackoverflow.com/a/4894099/172109

https://stackoverflow.com/a/4415234/172109

), जो सही है, TFS सिर्फ एक VCS नहीं है। एक प्रमुख विशेषता जो टीएफएस प्रदान करती है वह मूल रूप से एकीकृत बग ट्रैकिंग कार्यक्षमता है। परिवर्तनों को मुद्दों से जोड़ा जाता है और उन्हें ट्रैक किया जा सकता है। चेक-इन के लिए विभिन्न नीतियों के साथ-साथ विंडोज डोमेन के साथ एकीकरण का समर्थन किया जाता है, जो कि टीएफएस चलाने वाले लोग हैं। विजुअल स्टूडियो के साथ कसकर एकीकृत GUI एक और विक्रय बिंदु है, जो ~~औसत~~ माउस ~~से कम~~ और डेवलपर और उसके प्रबंधक पर क्लिक करने की अपील करता है ।

इसलिए GFS को TFS से तुलना करना उचित प्रश्न नहीं है। सही, हालांकि अव्यावहारिक, सवाल यह है कि GFS की तुलना TFS की VCS कार्यक्षमता से की जाए। उस समय, Git TFS को पानी से बाहर निकालता है। हालांकि, किसी भी गंभीर टीम को अन्य उपकरणों की आवश्यकता होती है और यह वह जगह है जहां टीएफएस एक स्टॉप गंतव्य प्रदान करता है।

— शर्लक
स्रोत

4

कृपया आप वही उपकरण प्राप्त कर सकते हैं जो किसी भी चुस्त टूल एप्लिकेशन में TFS प्रदान करता है। रैली, आप इसे नाम दें।

— पॉजिटिव

2

हालांकि मैं इस तथ्य से सहमत हूं कि टीएफएस का एक व्यापक उद्देश्य है, मैं इसे "वन स्टॉप डेस्टिनेशन प्रदान करने की कोशिश करता हूं" के लिए इसे फिर से लागू करूंगा, लेकिन यह किसी भी कार्य में पर्याप्त रूप से अच्छा नहीं है (कम से कम कोई सबसे अच्छा विकल्प नहीं)। हल; तो यह एक कुंद स्विस चाकू की तरह है।

— स्लैश कोडर

@PositiveGuy आपको काम और कॉन्फ़िगरेशन के बिना नहीं मिल सकता है। TFS आपको एक क्लिक के साथ पूरी चीज़ देता है। बिंदु में मामला, संपूर्ण पारिस्थितिकी तंत्र अब क्लाउड सेवा के रूप में उपलब्ध है, जिसमें शून्य कॉन्फ़िगरेशन आवश्यक है। अगर मुझे संस्करण नियंत्रण, स्क्रैम सपोर्ट, स्वचालित बिल्ड, टेस्ट लैब और टेस्ट प्लान प्रबंधन मिल सकता है, तो सभी अपने आप को और एक कॉर्पोरेट एलडीएपी (झूठ अजुराद) के साथ बॉक्स से बाहर एकीकृत, $ 10 / मो के लिए, मेरे दाहिने दिमाग में क्यों जाएगा? अपने दम पर टुकड़ों को एक साथ चिपकाने की कोशिश कर रहा हूं?

— क्रेग ब्रुनेटी

1

@ स्लैश कोडर किसी भी पूर्ण सुइट को प्रत्येक टुकड़े पर सर्वश्रेष्ठ होने की उम्मीद कैसे की जा सकती है? अपने गैर-एड-नेस की लागत क्या वास्तव में अपने दम पर घटकों के एकीकरण का प्रबंधन करने की लागत से आगे निकल जाती है? ... शायद कुछ स्थानों के लिए यह करता है, मैं देख सकता हूँ। लेकिन इस तरह की चीजों को चलाना शुद्ध उपरि है। यदि आपका कॉर्पोरेट जीआईटी ठीक चल रहा है, तो क्या होता है, लेकिन आपका JIRA उदाहरण नीचे चला जाता है, और आपके जेनकींस अपग्रेड उड़ान नहीं भरते हैं? सही? यह जंजीरों से जकड़ने जैसा है। जलता हुआ। अर्द्ध आंखों पर पट्टी। :) :)

— क्रेग ब्रुनेटी

17

यदि आपकी टीम TFS का उपयोग करती है और आप Git का उपयोग करना चाहते हैं तो आप "gfs to tfs" पुल पर विचार करना चाह सकते हैं। अनिवार्य रूप से आप अपने कंप्यूटर पर गिट का उपयोग करके दिन-प्रतिदिन काम करते हैं, फिर जब आप अपने परिवर्तनों को धक्का देना चाहते हैं तो आप उन्हें टीएफएस सर्वर पर धकेल देते हैं।

वहाँ (गीथूब पर) एक युगल बाहर हैं। मैंने अपनी अंतिम जगह पर (एक और डेवलपर के साथ) कुछ सफलता के साथ उपयोग किया। देख:

https://github.com/spraints/git-tfs

https://github.com/git-tfs/git-tfs

— bytedev
स्रोत

6

Microsoft अब Git रिपॉजिटरी और TFS के साथ एक सीधा एकीकरण प्रदान करता है: blogs.msdn.com/b/bharry/archive/2012/08/13/…

— Ed Blankenship

1

@EdBlankenship, आप अपनी टिप्पणी को उत्तर में बदलना चाह सकते हैं। यह ओपी के लिए एक महान समाधान प्रतीत होता है। मैं इसे वोट दूंगा। :)

— ली ग्रिसोम

1

सिवाय इसके कि अगर आप विंडोज की तुलना में किसी अन्य प्लेटफॉर्म पर हैं, तो आपको गिट-टीएफएस पसंद करना चाहिए! git-tf, git-tfs जितना अच्छा है ... से दूर है और दर्शन TFS उन्मुख है, जबकि git-tfs अधिक git ओरिएंटेड है (और यही हम चाहते हैं!)

— Philippe

15

समर्थक और विपक्ष के बीच कुछ जांच के बाद, मैं जिस कंपनी से जुड़ा था, उसने भी टीएफएस के लिए जाने का फैसला किया। इसलिए नहीं कि जीआईटी एक अच्छा संस्करण नियंत्रण प्रणाली नहीं है, लेकिन सबसे महत्वपूर्ण पूरी तरह से एकीकृत एएलएम समाधान के लिए है जो टीएफएस बचाता है। यदि केवल संस्करण नियंत्रण सुविधा महत्वपूर्ण थी, तो विकल्प संभवतः GIT हो सकता था। नियमित रूप से डेवलपर्स के लिए खड़ी जीआईटी सीखने की अवस्था को कम करके आंका नहीं जा सकता है।

एक सच्चे क्रॉस-टेक्नोलॉजी प्लेटफ़ॉर्म के रूप में मेरे ब्लॉग पोस्ट TFS में विस्तृत विवरण देखें ।

— पीटर गेयेंस
स्रोत

3

शायद, लेकिन टीएफएस का प्रत्येक भाग खराब है और प्रशासित करना मुश्किल है (वास्तव में, आपको टीएफएस के लिए एक वास्तविक व्यवस्थापक की आवश्यकता है)। Git> TFS (VCS), जेनकींस> TFS (CI), ननिट या xunit> mstest, IceScrum या ...> TFS (प्रोजेक्ट मैनेजमेंट) देखें। TFS शुरुआत में एक अच्छा विचार है, जब तक आप इसका उपयोग नहीं करते हैं !!!

— फिलिप

1

आपको टीएफएस की आवश्यकता क्यों है, बस एक अच्छा चुस्त ऐप प्राप्त करें। और फिर Git या तोड़फोड़ का उपयोग करें और आप अपने रास्ते पर हैं। TFS आपको समस्याओं से घेर कर आपके रास्ते में आ जाता है।

— पॉजिटिव

अद्यतन: TFS 2013 (सर्वर) [और VS12-13) अब संस्करण नियंत्रण के लिए git का समर्थन करता है। तो आप दोनों दुनिया के सर्वश्रेष्ठ प्राप्त कर सकते हैं

— DarcyThomas

2

यकीन है, यह पूरी तरह से एकीकृत ALM है अच्छा है। लेकिन लचीलेपन की कीमत पर नहीं। IMO। एएलएम का निर्माण यथासंभव "सर्वश्रेष्ठ नस्ल के" प्रौद्योगिकी के साथ किया जाना चाहिए ... या बहुत कम से कम, सबसे अच्छी नस्लों को एकीकृत करने का लचीलापन, क्योंकि वे समय के साथ बदलने की संभावना रखते हैं। टीएफएस चुनना मूल रूप से जमीन में एक हिस्सेदारी है, यह कहते हुए कि "माइक्रोसॉफ्ट मेरे एएलएम के सभी पहलुओं पर जीतने जा रहा है", जो मूर्खतापूर्ण है। मैंने उदाहरण के लिए Git w / Jira का उपयोग किया है, जिसने मुझे मेरे प्रतिबद्ध संदेश के आधार पर मुद्दों को अद्यतन / बंद करने की अनुमति दी। मेरे अनुभव में (टीएफएस के साथ भी बहुत कुछ), यह एक बहुत ही बेहतर वर्कफ़्लो है।

— स्कॉट सिल्वी

1

साइडबार - यहां तक कि टीएफएस / गिट एकीकरण के साथ, आप मूल रूप से कह रहे हैं "हमारे मुद्दे पर नज़र रखते हुए, वीसीएस को जीसीटी से बाहर करने की अनुमति देता है" - मूल रूप से गिट डब्ल्यू / किसी अन्य मुद्दे पर नज़र रखने वाले सॉफ़्टवेयर का उपयोग करने से अलग नहीं है। इसलिए मुझे यकीन नहीं है कि एएलएम तर्क अब वैध है, बशर्ते माइक्रोसॉफ़्ट लचीलेपन पर प्रयास करता है (जो मैं सराहना करता हूं)।

— स्कॉट सिल्वी

14

Git की पूरी वितरित चीज़ वास्तव में बहुत बढ़िया है। यह कुछ विशेषताएं देता है शेल्वसेट में (वर्तमान उत्पाद में) जैसे कि स्थानीय रोलबैक और प्रतिबद्ध विकल्प (जैसे कि एक्लिप्स की लोकलहिस्ट्र सुविधा ) नहीं है। आप डेवलपर शाखाओं का उपयोग करके इसे कम कर सकते हैं, लेकिन आपको ईमानदार होना चाहिए, कई डेवलपर्स एक बिट को ब्रांच करना और विलय करना पसंद नहीं करते हैं। मुझे टीएफएस में पुरानी शैली "एक्सक्लूसिव चेकआउट" सुविधा को कुछ समय पर चालू करने के लिए कहा गया है (और हर बार इसका खंडन किया गया)।

मुझे लगता है कि कई बड़े उद्यम एक देव को पूरे इतिहास को एक स्थानीय कार्यक्षेत्र में लाने की अनुमति देने के लिए काफी डरे हुए हैं और इसे अपने साथ ले जा रहे हैं (उदाहरण के लिए एक नए नियोक्ता के लिए) ... एक स्नैपशॉट चोरी करना बुरा है, लेकिन एक पूरे इतिहास को छीन लेना और भी ज्यादा तकलीफदेह है। (ऐसा नहीं है कि आप टीएफएस से पूरा इतिहास नहीं प्राप्त कर सकते थे जो आप चाहते थे) ...

यह उल्लेख किया गया है कि यह बैकअप का एक शानदार तरीका है, जो खुले स्रोत के लिए फिर से महान है जहां मूल अनुरक्षक अपने संस्करण की देखभाल और हटाने के लिए रुक सकता है, लेकिन एक उद्यम योजना के लिए यह फिर से कई उद्यमों के लिए कम हो जाता है क्योंकि जिम्मेदारी का कोई स्पष्ट कार्य नहीं है बैकअप रखने के लिए और यह पता लगाना मुश्किल होगा कि मुख्य 'प्रोजेक्ट' किसी भी तरह गायब हो जाए तो किस संस्करण का उपयोग करना है। जो एक रिपॉजिटरी को अग्रणी / केंद्रीय नियुक्त करेगा।

Git के बारे में मुझे जो सबसे ज्यादा पसंद है वह है पुश / पुल विकल्प, जहाँ आप आसानी से किसी परियोजना के लिए प्रतिबद्ध अधिकारों की आवश्यकता के बिना कोड का योगदान कर सकते हैं। मुझे लगता है कि आप इसे सीमित करने के लिए TFS में बहुत सीमित उपयोगकर्ताओं और अलमारियों का उपयोग कर सकते हैं, लेकिन यह Git विकल्प जितना शक्तिशाली नहीं है। टीम प्रोजेक्ट्स में ब्रांचिंग के रूप में अच्छी तरह से काम कर सकते हैं, लेकिन एक प्रशासनिक दृष्टिकोण से यह वास्तव में कई संगठनों के लिए संभव नहीं है क्योंकि टीम प्रोजेक्ट्स को जोड़ना बहुत अधिक प्रशासक ओवरहेड जोड़ता है।

मैं गैर स्रोत नियंत्रण क्षेत्र में उल्लिखित चीजों को भी जोड़ना चाहूंगा। वर्क आइटम ट्रैकिंग, रिपोर्टिंग और बिल्ड ऑटोमेशन (लैब प्रबंधन सहित) जैसी सुविधाएँ केंद्रीय अग्रणी भंडार से बहुत लाभान्वित होती हैं। जब आप शुद्ध वितरित मॉडल का उपयोग करते हैं, तो ये बहुत कठिन हो जाते हैं, जब तक कि आप किसी एक नोड को अग्रणी नहीं बनाते (और इस तरह कम गति वाले मॉडल पर वापस जाते हैं)।

टीएफएस बेसिक के साथ टीएफएस 11 के साथ आने से, वितरित टीएफएस की उम्मीद करना दूर नहीं हो सकता है जो आपको अपने स्थानीय टीएफएस बेसिक को टीएफएस 12+ के युग में एक केंद्रीय टीएफएस के साथ सिंक करने की अनुमति देता है। मैं अपने वोट के लिए नीचे uservoice में डालूँगा !

— jessehouwing
स्रोत

आपको Microsoft द्वारा लाई गई इस नई सुविधा में भी दिलचस्पी होगी: gittf.codeplex.com

— jessehouwing

1

git-tfs का उपयोग करें। फिलहाल, यह git-tf से बेहतर है !!! github.com/git-tfs/git-tfs

— फिलिप

3

यह पूरा उत्तर जल्दी से दिनांकित हो रहा है। Microsoft ने Git समर्थन को Team Foundation Service में जोड़ दिया है और Git के लिए टीम फाउंडेशन सर्वर की अगली प्रमुख रिलीज़ के लिए समर्थन जोड़ देगा।

— jessehouwing

1

@Pippippe: मैंने दोनों की कोशिश की है। कुछ अंतर: 1) git-tf क्रॉस-प्लेटफ़ॉर्म है, जबकि git-tfs केवल Windows पर चलता है। 2) git-tfs फिर से वर्णन करता है जब आप परिवर्तन संख्या को शामिल करने के लिए "पुश" करते हैं, जबकि git-tf आपके स्थानीय प्रतिबद्ध हैश को बरकरार रखता है।

— जॉय एडम्स

@JoeyAdams 1) +1, यह git-tf 2 चुनने का एकमात्र अच्छा कारण है) आप यह भी कर सकते हैं कि git-tfs checkinकमांड (rcheckin के बजाय) का उपयोग करें। लेकिन मैं rcheckin पसंद करता हूं क्योंकि यह चीजों को करने का अधिक तरीका है और इसलिए हम git का उपयोग करना चुनते हैं;)

— Philippe

9

मेरे लिए प्रमुख अंतर सभी सहायक फाइलें हैं जो टीएफएस आपके समाधान (.vssscc) में 'TFS' का समर्थन करने के लिए जोड़ देंगी - हमने हाल ही में इन फ़ाइलों के साथ गलत शाखा में मैप की गई समस्‍याओं को सम्‍मिलित किया है, जिससे कुछ रोचक उलटफेर होते हैं। ...

— धान
स्रोत

2

यहाँ अच्छी बात है। Git .gitसभी रिपॉजिटरी विवरण को ट्रैक करने के लिए फ़ोल्डर को जोड़ देगा । टीएफएस कम से कम आपके .sln(या यह है .csproj?) फ़ाइलों को दूरस्थ रिपॉजिटरी के स्थान को इसमें डालने के लिए संशोधित करेगा ।

— कोडिंगविट्स्पाइक

5

मुझे माफ करना, मैं कितना नफरत करता था कि वीएसएस आपकी फाइलों को 'आप' के लिए कैसे संशोधित करेगा।

— धान