जीआईटी के साथ एक परियोजना पर काम कर रहे कई लोगों को प्रबंधित करना

Question

मैं GIT / GitHub (कल से शुरू होने के रूप में नया) के लिए बहुत नया हूं। मैं जानना चाहूंगा कि गितुब के साथ एक ही प्रोजेक्ट पर काम करने वाले कई लोगों को प्रबंधित करने का सबसे अच्छा तरीका क्या है। वर्तमान में मैं चार डेवलपर्स के साथ एक परियोजना का प्रबंधन कर रहा हूं।

1. मैं वर्कफ़्लो के बारे में कैसे जाना और यह सुनिश्चित करना कि सब कुछ सिंक में है?

   (नोट: सभी डेवलपर्स के पास एक सार्वभौमिक खाता होगा।)

2. क्या प्रत्येक डेवलपर को एक अलग शाखा पर होना चाहिए?

3. क्या मैं एक ही फाइल पर काम करने वाले 2 लोगों को संभाल पाऊंगा?

कृपया एक विस्तृत उत्तर दें, मैं एक शर्मीला पाठक नहीं हूं। मुझे इसे अच्छी तरह से समझने की जरूरत है।

Comments

सभी डेवलपर्स के लिए एक खाता? यह काम हो सकता है लेकिन यह सबसे अच्छा विचार नहीं है।

— marstato

देखें nvie.com/posts/a-successful-git-branching-model

— ब्रैड थॉमस

GitFlow और ट्रंक आधारित विकास में देखने लायक हो सकता है । व्यक्तिगत रूप से मुझे बाद में बड़ी सफलता मिली है

— जे लुईस

Answer 1

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

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

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

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

अपने विशिष्ट प्रश्नों के लिए:

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

3. हां, git वास्तव में अच्छी तरह से संघर्ष को संभालता है, इसलिए लोगों को एक ही फाइल पर काम करने में कोई समस्या नहीं है। यदि कोई फ़ाइल एक से अधिक सदस्यों द्वारा संपादित की गई है, तो मूलभूत परिवर्तन होने पर, विरोधाभास को छोड़कर कोई समस्या हमेशा तुच्छ नहीं हो सकती है। यह हालांकि ऐसा कुछ भी नहीं है जिसे एक साथ बात करके दूर नहीं किया जा सकता है। संस्करण नियंत्रण संचार को प्रतिस्थापित नहीं करता है।

सौभाग्य!

Comments

कुछ बिंदु जो आपने बनाए हैं वे वास्तविक आंखें खोलने वाले हैं, मुझे एक साथ एक अलग दिशा में सोचने के लिए मिला, धन्यवाद!

— बैडजोक

अगर यह आपकी मदद कर सकता है तो चिकित्सा। Git और DVCS को कुछ उपयोग करने की आवश्यकता होती है, लेकिन जब आप उनकी आदत डाल लेते हैं तो वे बहुत लचीले होते हैं।

— हराल

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

— इस्वर राजेश पिनपाला

नहीं, हर बार नहीं, बस जब आप सिंक करना चाहते हैं। अपनी निजी शाखा के रूप में शाखा की अपनी स्थानीय प्रति और अपस्ट्रीम शाखा के रूप में जिस पर आप विलय करना चाहते हैं, पर विचार करें। अपने स्थानीय प्रतिबद्ध इतिहास को फिर से लिखने के बिना आपके git fetch upstreamद्वारा पीछा किया git merge upstream/branchजाना चाहिए जैसे कुछ का उपयोग करना । यदि यह कोई समस्या नहीं है, तो बस git pull --rebaseअपने स्थानीय अप्रकाशित परिवर्तनों को अपस्ट्रीम शाखा के शीर्ष पर ले जाएँ।

— हराल

@badZoke .... आपने अपने 3 प्रश्न (एक ही फाइल पर काम करने वाले 2 लोगों को संभालने के लिए) क्या किया ...

— मोउमिता

Answer 2

हम 2 डेवलपर्स के साथ काम करते हैं और हम इस वर्कफ़्लो का उपयोग करते हैं:

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

Comments

अच्छा और सरल, बहुत बहुत धन्यवाद! मैं इसके साथ शुरू करूँगा, इससे पहले कि मैं जटिल सामान में

— जाऊं

क्या होगा यदि, जब अन्य देव नए बदलाव लाते हैं, तो अपने कोड को धक्का देने से पहले, नए परिवर्तन कोड को बदल देते हैं जो वह पहले से बदल चुका है?

— Wayofthefuture

+1, यह वास्तव में शुरू करने के लिए सबसे सरल है, और पूरी तरह से ठीक काम करता है। आप जो प्रयोग कर रहे हैं उसे सरलीकृत gitflow कहा जाता है: marcgg.com/assets/blog/git-flow-before.jpg

— Jelle

Answer 3

मुझे यहाँ केवल पाठ उत्तर मिलते हैं, इसलिए मैंने सोचा कि मैं एक अच्छी gitflow की तस्वीर पोस्ट करूँ। एक तस्वीर एक हजार से अधिक शब्दों का वर्णन करती है:

• यह प्रवाह निरंतर तैनाती के साथ भी अच्छा काम करता है।
• आपकी मास्टर शाखा में कोड होता है जो वर्तमान में आपके उत्पादन सर्वर पर चल रहा है।
• आपकी विकसित शाखा में कोड होता है जो वर्तमान में एक स्टेजिंग / परीक्षण सर्वर पर चल रहा है।

Comments

+1, git flow, या ऐसा ही कुछ इस प्रश्न का सही उत्तर है।

— शायद_फैक्टर

Answer 4

मैं 3 अन्य डेवलपर्स के साथ काम करता हूं, और हम इसके साथ काफी संघर्ष करते हैं। डेवलपर्स कभी-कभी उत्पादन में कमिट्स को धक्का देंगे जो वास्तव में प्राइम-टाइम के लिए तैयार नहीं हैं, क्योंकि वे अन्य बदलावों को अपने परिवर्तनों में खींच लेंगे और फिर उत्पादन में धक्का देंगे। संस्करण शाखाएँ हमारे लिए ठीक काम करती हैं। इसलिए, यदि संस्करण 1.0 वर्तमान स्थिर संस्करण है, तो हम v1.1-विकास के लिए एक शाखा बनाएंगे। डेवलपर्स इस शाखा में बदलाव करेंगे। हमारे परीक्षण सर्वर इस शाखा की जाँच करते हैं और आवश्यकतानुसार परिवर्तन को खींचते हैं। जब v1.1 के लिए सभी विशेषताएं जाने के लिए तैयार हैं और परीक्षण किया जाता है, तो हम मास्टर और पुश के साथ v1.1 को मर्ज करेंगे। शाखाओं के साथ, डेवलपर टीम A v1.1 पर काम कर सकती है और डेवलपर टीम B v1.2 पर काम कर सकती है। दोनों टीमें एक-दूसरे को प्रभावित किए बिना काम कर सकती हैं। अगर टीम A कुछ ऐसा विकसित करती है जो B उपयोग कर सकता है,

हम एक हॉटफ़िक्स शाखा का भी उपयोग करते हैं जिसका उपयोग तत्काल परिवर्तन के लिए किया जाता है।

यहाँ एक तस्वीर की एक कड़ी है जो यह दिखता है। http://nvie.com/img/[e-mail]

Comments

यह मेरे लिए ध्वनि नहीं है जैसे आप वास्तव में गिट प्रवाह को लागू कर रहे थे जैसा कि यह इरादा था - जो प्रत्येक स्वतंत्र सुविधा को विभाजित करने या अपनी शाखा पर ठीक करने के लिए है, बल्कि प्रत्येक रिलीज के बजाय

— ब्रैड थॉमस