गिट वर्कफ़्लो: हर ​​किसी के पास शाखा है, या हर किसी के पास मास्टर है?

Question

जब Git के साथ कई लोगों के साथ काम है, यह बेहतर

1. के लिए हर किसी के बस मास्टर में काम करते हैं, और एक दूसरे के स्वामी के बीच विलय करने के लिए, या
हर किसी के लिए
2. अपने स्वयं के शीर्षक से शाखा में काम करने के लिए है?

जैसा कि मैंने इसे देखा है, (1) के मामले में, हालांकि प्रत्येक मास्टर शाखा के रूप में कार्य करता है, हर किसी को एक दूसरे के काम के बीच अधिकतर रैखिक प्रवाह के साथ विलय करने की उम्मीद है, जबकि (2) में, हर कोई है में शाखा में एक सामान्य मास्टर को विलय करने की उम्मीद है, और जब वे तैयार हों तो उनकी शाखा से एक सामान्य मास्टर में परिवर्तन को दबाएं।

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

मुझे कल्पना है कि दोनों (1) और (2) में, एक व्यक्ति "आधिकारिक" मास्टर में परिवर्तन खींचने के लिए ज़िम्मेदार है। यदि एक से अधिक व्यक्ति आधिकारिक मास्टर तक पहुंच पहुंचते हैं तो यह कैसे होगा?

Answer 1

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

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

Answer 2

डीवीसीएस प्रकाशन को othogonal dimension to branching के रूप में प्रस्तुत करता है।

इसका मतलब है कि एक DVCS में शाखाओं दो भूमिकाएं हैं:

1. क्लासिक एक: code isolation: प्रकाशन: यदि आप एक शाखा
2. नया एक में एक कोड के इतिहास (संशोधन की सूची) को अलग: आप रिपो से रिपो तक अपने कामों को दोहराते हैं।

गिट "निजी प्रतिबद्धता" के लिए अनुमति देता है, यानी आप जितना चाहें उतना प्रतिबद्ध करते हैं (और फिर आप clean your history of commits) कर सकते हैं।
यदि आप मास्टर में ऐसा करते हैं, तो यह प्रकाशन के लिए अच्छा नहीं है: चूंकि मास्टर रेपो क्लोन होने पर डिफ़ॉल्ट रूप से दिखाई देता है, इसलिए आपके रेपो को क्लोन करने वाला कोई भी स्थिर स्थिति नहीं प्राप्त करेगा, लेकिन एक काम का एक स्नैपशॉट प्रगति पर होगा ।

निजी प्रतिबद्धता का अर्थ है: प्रकाशित नहीं होने वाली शाखाओं में प्रतिबद्ध।
आप जो कुछ भी चाहते हैं उसे कॉल कर सकते हैं।

किसी भी शाखा है जो धक्का दिया जा रहा है/खींच लिया एक संसाधन के नाम के बाद (जैसे 'VonC_branch'), लेकिन हमेशा एक सुविधा या एक अधिक सामान्य रिहाई प्रबंधन विषय के बाद (जैसे 'public', 'next' कभी नहीं कहा जाना चाहिए, 'patchV1', ...)

निजी शाखाओं और सार्वजनिक लोगों के बीच अंतर के इतिहास करता है आपको प्रत्येक में अनुमति देते हैं:

• के रूप में कई करता है आप के लिए एक निजी शाखा में चाहते हैं (आपके माध्यम से भविष्य के पुन: आदेश की सुविधा के लिए सही टिप्पणी असाइन करने की आवश्यकता है!fixup साथ और !squash कार्यों)
• "संगत" सार्वजनिक शाखाओं में करता है (प्रत्येक पूरा हो गया है के लिए प्रतिबद्ध है, एक स्थिर राज्य कि कम से कम संकलन और परीक्षण किया जा सकता, भले ही उन परीक्षण असफल प्रतिनिधित्व करते हैं)
  उदाहरण के लिए एक मास्टर शाखा होगा तो आपको कैसे Git के साथ शाखाओं का उपयोग करेगा पर फैसला करने के लिए उससे भी सख्त मानक (जैसे "परीक्षण चाहिए पास)

है, तो आप प्रकाशन पहलू को ध्यान में रखना करने की आवश्यकता है।

Answer 3

एक मध्यम से बड़ी आकार की टीम के लिए, आप "आधिकारिक" master शाखा के साथ केंद्रीयकृत भंडार चाहते हैं।

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

एक साझा रेपो के साथ जा रहे हैं, यह डेवलपर्स व्यक्तिगत पसंद (और कुछ टीम समझौते) क्या सीधे उनके स्थानीय master के लिए प्रतिबद्ध, या एक अलग dev शाखा का उपयोग करने के लिए नीचे आता है। मेरा विचार यह है कि dev शाखा में स्थानीय परिवर्तनों को रखने का एक बेहतर विकल्प है, लेकिन केंद्रीकृत एससीएम के लिए उपयोग किए जाने वाले डेवलपर्स के लिए थोड़ा अधिक बोझिल है।

अलग dev शाखा के लाभ यह है कि यह आसान सिर्फ master पर git pull चलाकर कोड बेस में नए प्रतिबद्ध ट्रैक करने के लिए बनाता है। स्वच्छ मास्टर देवताओं को हमेशा आवश्यक होने पर नवीनतम सार्वजनिक कोड की जांच करने देता है। यदि आप master में परिवर्तन के साथ, तो यह आपके अप्रकाशित कामों पर origin/master शाखा में विलय करेगा। यह master में एक नई विलय प्रतिबद्धता बनाएगा और यदि दृश्य कभी भी master पर धक्का दिया जाता है तो दिखाई देगा। हो सकता है कि आप यही चाहते हैं, लेकिन यह प्रतिबद्धता इतिहास को कुछ हद तक गड़बड़ कर सकता है।

dev शाखा के साथ आप प्रतिबद्ध इतिहास रैखिक रखने के लिए आसानी से master के खिलाफ रीबेस कर सकते हैं। dev शाखा के बिना, git pull --rebasemaster में समान प्रभाव होगा, लेकिन इस चरण को भूलना आसान है।

असल में, एक निजी ट्रैकिंग शाखा (जैसे dev) का उपयोग करके एक डेवलपर को अपनी स्थानीय शाखाओं में सार्वजनिक परिवर्तनों को स्वीकार करने के बारे में थोड़ा अधिक लचीलापन देता है। यह केंद्रीकृत रेपो को अत्यधिक विलय प्रतिबद्धताओं से मुक्त रखना भी आसान बनाता है। केवल नकारात्मक बात यह है कि इसे डेवलपर्स से कुछ अतिरिक्त प्रयास की आवश्यकता है, लेकिन लंबी अवधि में गिट के अंतिम उपयोग में वृद्धि होगी।