2013-06-25 6 views
9

मैंने केवल एकमात्र परियोजनाओं के लिए गिट का उपयोग किया है। अब मैं दो अन्य डेवलपर्स के साथ एक परियोजना पर काम करना जारी रखना चाहता हूं।क्या हर डेवलपर के लिए शाखा बनाने का अर्थ है?

यदि कोई डेवलपर परिवर्तन करना चाहता है तो क्या समस्याएं पैदा होंगी लेकिन एक अन्य डेवलपर द्वारा एक और प्रतिबद्धता बनाई गई थी? इसलिए क्या हममें से प्रत्येक के लिए एक शाखा बनाने का अर्थ होगा?

+3

आपके पास प्रत्येक के लिए एक शाखा है, जब तक कि आप सभी एक ही मशीन पर काम नहीं कर रहे हों। जब आप अपने रेपो को क्लोन करते हैं, तो आपको अपने * अपने * शाखाओं का सेट मिलता है, जिसे हर किसी की शाखाओं के समान नाम दिया जाता है, लेकिन वे अभी भी * आपकी अपनी शाखा * हैं। – meagar

+1

@ मीगर दिलचस्प लगता है, क्या आप इस पर विस्तृत जानकारी दे सकते हैं? – danijar

+1

भंडार का हर क्लोन उदाहरण पूरी तरह आत्मनिर्भर चीज है। आप अपनी शाखा के साथ * जो कुछ भी चाहते हैं * करने के लिए स्वतंत्र हैं, आप तब तक किसी और के पैर की अंगुली पर कदम नहीं उठाएंगे जब तक आप धक्का देने की कोशिश नहीं करते। जब आप पुश करते हैं और खींचते हैं, तो आप "स्थानीय" शाखा के रूप में दूरस्थ शाखा (या इसके विपरीत) सेटअप के साथ अपनी स्थानीय शाखा का विलय कर रहे हैं। यह आपकी स्थानीय मशीन पर किसी भी दो शाखाओं को विलय करने के समान है; वास्तव में, 'गिट पुल' वास्तव में एक विलय है, इसके बाद एक विलय होता है। सादगी के लिए, 'गिट पुश' तेजी से आगे विलय में विलय को प्रतिबंधित करता है, क्योंकि आप रिमोट टकराव को प्रभावी रूप से हल नहीं कर सकते हैं। – meagar

उत्तर

17

गिट, अधिकांश संस्करण नियंत्रण प्रणालियों की तरह, कई डेवलपर्स द्वारा उपयोग के लिए बेहद उपयुक्त है। वास्तव में, यह एक संस्करण नियंत्रण प्रणाली के मुख्य बिंदुओं में से एक है।

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

आपके द्वारा वर्णित प्रतिबद्ध स्थिति समस्याग्रस्त नहीं है। यदि किसी अन्य उपयोगकर्ता ने आपके जैसा ही शाखा पर एक नई प्रतिबद्धता बनाई है, तो आप push पर प्रयास करने पर रोक देंगे। इसके बजाय आपको पहले उपयोगकर्ता के प्रतिबद्धता के नीचे pull करना होगा और उन परिवर्तनों के साथ अपने काम को मर्ज (या रीबेस) करना होगा। यह git pull का मानक व्यवहार है।

सामान्य अभ्यास मुख्य रूप से सुविधाओं पर आधारित शाखाएं बनाना है। यदि आप ब्रांचिंग पर मार्गदर्शन चाहते हैं, this is a popular strategy

+0

यह इस बात पर निर्भर करता है कि आपका काम कैसे विभाजित है। एक जगह पर मैंने काम किया, हम एक ही समय में एक ही सुविधा पर दो लोगों को कोडिंग नहीं करेंगे।यदि आपके पास एक ही सुविधा पर काम कर रहे कई देव हैं, हालांकि, मैं पूरी तरह से आपसे सहमत हूं। – Renan

+1

आपको अभी भी अलग-अलग शाखाएं * प्रति व्यक्ति * नहीं बनाना चाहिए; यह ऐसी विशेषताएं होनी चाहिए जो शाखाओं के निर्माण को ड्राइव करें। प्रत्येक व्यक्ति के पास कई शाखाएं होनी चाहिए क्योंकि उनके पास सक्रिय विकास में विशेषताएं हैं। – meagar

+0

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

4

हम उस स्थान पर ऐसा करते थे जहां मैंने काम किया था। हम में से प्रत्येक में कम से कम एक व्यक्तिगत शाखा थी - मैंने वास्तव में हर काम के लिए एक शाखा बनाई थी जिसे मुझे करना था।

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

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

संबंधित मुद्दे