एकल डेवलपर के रूप में शाखा का उपयोग करने के क्या फायदे हैं?


117

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

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


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

8
जबकि मैं इस बात से सहमत हूं कि यह प्रश्न एक सटीक डुप्लिकेट नहीं है (स्कोप अंतर महत्वपूर्ण हैं), डुप्लीकेट टारगेट क्वेश्चन प्रश्न gnat लिंक्ड का उत्तर उस विषय को कवर करने से है जिसमें आप रुचि रखते हैं - क्या ऐसा कुछ है उन सवालों के जवाब नहीं मिले जिन्हें आप सुनना चाहते हैं?
jrh

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


3
डैन, फिर से ... आपके द्वारा जुड़ा सवाल पूछता है "एक एकमात्र डेवलपर के रूप में, क्या Git या GitHub विशेषताएँ मैं इसका लाभ उठा सकता था मुझे अभी लाभ होगा?"। इस सवाल का एक संभावित उत्तर, दूसरों के बीच, "शाखाओं में बँटना" हो सकता है। यह मेरे सवाल का जवाब नहीं होगा। इसके अलावा, यह उसी कारण से बहुत व्यापक था। कृपया मेरे प्रश्न के शीर्ष पर स्पष्टीकरण पढ़ें। मुझे अपनी पोस्ट को अब 3 बार संपादित करना है ...
flatterino

जवाबों:


199

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

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

DVCS द्वारा क्लोन पर किए जाने वाले निहितार्थ का अर्थ है कि आधिकारिक रिपॉजिटरी पर औपचारिक शाखाएं लोगों के समन्वय के बारे में कम हैं और विकास दिशाओं के समन्वय के बारे में अधिक हैं, और एक व्यक्ति भी उनमें से कई कर सकता है।


1
ठीक ठीक। समूहों को शाखाओं का उपयोग करने की आवश्यकता नहीं है , या तो मैंने टीमों के लिए काम किया है जो नहीं किया। दी गई, जो ज्यादातर गिट से अपरिचित था, और उन सभी टीमों ने शाखाओं का उपयोग करना सीखा क्योंकि उन्हें उपयोग नहीं करने के साथ समस्याएं दिखाई दीं, लेकिन उन समस्याओं को एक एकल डेवलपर पर भी लागू होगा।
केरान

42

लंबे समय से चल रहा विकास

एकल व्यक्ति टीम के लिए ब्रांचिंग लंबे समय से चल रहे विकास सुविधा के लिए उपयोगी होगी जो अन्यथा आपके रिलीज़ चक्र में फिट नहीं होती है।

आप अपने बहु-महीने के फैले हुए परिवर्तन के लिए एक शाखा ले सकते हैं और फिर भी नियमित अंतराल पर अपनी मुख्य शाखा से दिन-प्रतिदिन बग फिक्स या परिवर्तन को धक्का देने में सक्षम हो सकते हैं।

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

प्रायोगिक विशेषताएं

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


16

मैं इसे महत्वपूर्ण वेबसाइट रखरखाव के लिए उपयोग करता हूं। मैं एकमात्र डेवलपर हूं फिर भी मेरे पास एक मास्टर है, शाखाएं विकसित करना और जारी करना।

साइट सेटअप के लिए मेरी कार्य प्रक्रिया इस प्रकार है:

  1. काम करने योग्य गुरु शाखा बनाओ। प्रारंभिक कमिट करें।

  2. चेकआउट विकास शाखा। कुछ भी मत करो, मास्टर में विलय के लिए परीक्षण बफर के रूप में कार्य विकसित करें।

  3. चेकआउट समस्या शाखा। अपने मुद्दे को कोड करें, जब यह पूरा हो जाए, तो इसे विकसित करें, देखें कि क्या कोई समस्या उत्पन्न होती है, संघर्षों को मर्ज करें आदि ... उन्हें ठीक करें।

जब एक रिलीज के लिए पर्याप्त मुद्दों को विकास में विलय कर दिया जाता है और स्थिरता के लिए विकसित किया गया होता है, तो मास्टर में विकसित होता है।

   Master
     |
   Develop  - E
   / |  \  \
 A   B   C  D

इस तरह से आपको विकास में एक पूर्ण परीक्षण संग्रह प्राप्त होता है, जहाँ आप स्थिरता, मुद्दों आदि का परीक्षण कर सकते हैं ... मास्टर को जोखिम में डाले बिना और यदि वे हानिकारक थे, तो वापस आने में जोखिम होता है।

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

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

इस परिदृश्य पर विचार करें: आप हमेशा एक मुख्य शाखा पर काम करते हैं और आपके पास उन कार्यों में AwesomeCodeThing ™ है जो आपकी मास्टर शाखा को खुले दिल की सर्जरी में छोड़ देता है और एक YugeBug ™ पॉप अप करता है जिसे तत्काल फिक्सिंग की आवश्यकता होती है अन्यथा हजारों उपयोगकर्ता आपके लिए BigProblems ™ से शिकायत करेंगे
। ऐसे परिदृश्य में अपने मुद्दे को जल्दी हल करने का एकमात्र तरीका,

  1. अपने पिछले आवागमन की जाँच करें,
  2. देखें कि आपकी अंतिम स्थिर प्रतिबद्धता कब हुई (शापिंग वैकल्पिक है)
  3. उस कमिट पर वापस जाएं
  4. तय करना, उत्पादन के लिए बाहर तय धक्का
  5. उन सभी उलझनों और समस्याओं को हल करें, जिन्हें आप अब भयानक स्थिति में वापस लाने की कोशिश कर रहे हैं। ™
  6. रोना, रोना और काम शुरू करना। (वैकल्पिक)

यदि आप शाखाओं का उपयोग करते हैं:

  1. चेकआउट मास्टर
  2. शाखा UrgentFix ™ बनाएँ और सामान ठीक करें
  3. मास्टर में UrgentFix ™ खींचें
  4. उत्पादन के लिए धक्का
  5. मास्टर को विकसित करने में
  6. मर्ज AwesomeCodeThing ™ में विकसित होता है
  7. एक बीयर प्राप्त करें और काम करना जारी रखें।

13
जारी रखने से पहले बीयर प्राप्त करना गैर-वैकल्पिक है।
जेम्सबी

4
@JamesB शुरू होने से पहले एक बीयर प्राप्त करना गैर-वैकल्पिक है :)
क्रिस क्रेफ़िस

4

शाखाएँ एक साथ कई विशेषताओं पर काम करना आसान बनाती हैं, जो किसी परियोजना के दौरान प्राथमिकताओं को बदलने पर काफी मददगार हो सकती हैं।

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

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

एक वास्तविक प्रक्रिया के रूप में, मुझे लगता है कि git flow अच्छी तरह से काम करता है। डैनियल कुमेर की गिट प्रवाह धोखा शीट एक महान संसाधन है, यह देखने के लायक है भले ही आप गिट का उपयोग नहीं कर रहे हों।


2

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

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

हालाँकि, अगर मैं अपने द्वारा किए जा रहे बदलावों के बारे में कोई झिझक रखता हूँ, तो एक बार शाखा द्वारा अपेक्षित रूप से व्यवहार किए जाने के बाद मैं शाखा और केवल PR / मर्ज कर दूँगा। इस तरह, अगर मुझे कोई ऐसा मुद्दा मिल जाता है जिसके लिए रोलिंग बैक एक्शन का सबसे अच्छा कोर्स है, तो यह एक पूरी श्रृंखला के बजाय एक ही कमिटमेंट है (मैं कभी भी कमिटमेंट की श्रृंखला को रोलबैक करने के लिए सिंटैक्स को याद नहीं रख सकता लेकिन एक आसान है)।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.