नया डेवलपर शाखा मर्ज के साथ नहीं रख सकता है

222

मैं नया डेवलपर हूं - यह मेरी पहली प्रोग्रामिंग स्थिति है।

मेरा मुद्दा यह है: हम उपयोग करते हैं git- मैंने हमारी developशाखा से एक शाखा काट दी , फिर मैं उस मामूली कार्य पर काम करना शुरू कर देता हूं जिसे मुझे सौंपा गया है। यह बहुत धीमा है, क्योंकि मैं अनुभवहीन हूं। जब तक मैं अपनी शाखा developको दूसरों में विलय करने के लिए तैयार हूं, तब तक बहुत सारे बदलाव हो चुके हैं, जिससे टकरावों का समाधान हो रहा है। )।

इसका समाधान कैसे किया जा सकता है? क्या कोई युक्ति है जिसका उपयोग मैं 'कोडिंग में बेहतर होने' के अलावा कर सकता हूं? मैं अगले सप्ताह अपने पर्यवेक्षक के साथ इसे लाने का इरादा रखता हूं।

— गुलबहार
स्रोत

165

आपको अपनी शाखा को केवल तब विकसित करने की आवश्यकता नहीं है जब आप समाप्त कर लें। अंतिम मर्ज को छोटा करने के लिए आप अपनी सुविधा शाखा में विकसित कर सकते हैं।

— डेविड बीबीएस

16

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

16

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

32

यहां एक अजीब बात है "मैं मामूली काम पर काम करना शुरू कर देता हूं" और टनों मर्ज संघर्ष आम तौर पर मेल नहीं खाते हैं। मैंने अभी एक 2 सप्ताह की प्रमुख अपडेट शाखा को एक प्रायोगिक विकास में मिला दिया और हमारे पास 10 (!) संघर्ष थे जो ऑटो-रिसोल्यूबल नहीं थे। जब तक आपका कार्य "सभी फ़ाइलों पर परिवर्तनशील नामों को बदलना" नहीं है, तब तक आपको कई टकराव नहीं होंगे। माइनर कार्यों के लिए नहीं।

— टॉम टॉम

50

अप्रचलित xkcd: xkcd.com/1597

— ED

5

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

तो मर्ज संघर्ष की संभावना को कम करने के लिए, आप पहले विलय करने की कोशिश कर सकते हैं ताकि आपके सहयोगियों ने इस बीच कम लाइनें बदल दीं, या आप स्वयं कम लाइनों को बदलने का प्रयास कर सकें।

कम पंक्तियों को स्वयं बदलने के लिए, केवल अपने कार्य से संबंधित परिवर्तन करना सुनिश्चित करें।

यदि आपको अपने लक्ष्य को प्राप्त करने के लिए विभिन्न तरीकों के साथ प्रयोग करने की आवश्यकता है, तो शायद आपके कुछ प्रयोगों ने ऐसी लाइनें बदल दी हैं जिन्हें वास्तव में बदलने की आवश्यकता नहीं है? विलय से पहले इन परिवर्तनों को पूर्ववत करें।

कुछ Git कमांड्स भी हैं जो आपको यथासंभव कुछ लाइनों को बदलने में मदद कर सकती हैं:

git diffऔर git diff --stagedयह देखने के लिए कि आपने कौन सी लाइनें बदली हैं।
git add -p केवल एक फ़ाइल में अपने कुछ परिवर्तन जोड़ने के लिए।
git commit --amendऔर git rebase -iउन्हें अन्य Git रिपॉजिटरी में धकेलने से पहले आप अपने स्थानीय फीचर शाखा में पहले से ही काम कर रहे हैं।

(संभव के रूप में कुछ लाइनों को बदलने से भी आसान अपने काम की समीक्षा करने के लिए या उपकरण है कि इस तरह के रूप मतभेदों पर काम के बीच करता है का उपयोग करने के लिए कर सकते हैं git cherry-pick, git rebase, git bisect, और git blame।)

लेकिन भले ही आप मर्ज संघर्षों की संभावना को कम करते हैं, फिर भी आप कभी-कभी मर्ज संघर्षों में भाग लेंगे। इसलिए उनसे डरो मत, लेकिन संघर्षों को हल करना सीखो।

— Toxaris
स्रोत

1

विलय करने से पहले, एक git fetchऔर git diff origin/developआपको अपने मर्ज (प्रकार) का पूर्वावलोकन दिखाएगा। व्यर्थ के टकराव का एक टन पाने से पहले आपको अपने परिवर्तनों को साफ करने का मौका देता है।

— मैक्स

288

मुझे लगता है कि आप गिट का उपयोग कर रहे हैं। यदि हां, तो git rebase -i( -iमतलब संवादात्मक) का उपयोग करें। अपनी शाखा को विकसित शाखा के विरूद्ध करने के लिए इसे दैनिक कार्य (और भी अधिक बार, यदि आवश्यक हो) बनायें। यह आपकी सुविधा शाखा को अद्यतित रखने के लिए हर दिन (कम से कम) आकस्मिक रूप से परिवर्तन लाता है। यदि आपके दैनिक छूट के दौरान संघर्ष होते हैं, तो आपको अपनी टीम के साथ बात करने की आवश्यकता है कि कौन क्या काम कर रहा है।

यदि आप इसे दैनिक चलाते हैं, तो आपको संभवतः सहभागी भाग की आवश्यकता नहीं होगी। बस इसे अपनी बात करने दो।

मैं एक काफी अनुभवी डेवलपर हूं, और अभी भी मुझे एक नई परियोजना में तेजी लाने के लिए काफी समय लगता है। आपके मामले में, ऐसा लगता है कि आपके पास एक ही परियोजना पर कई लोग एक साथ काम कर रहे हैं, इसलिए यह या तो एक बहुत बड़ी परियोजना है, या एक नई परियोजना है जो जल्दी से विकसित हो रही है। किसी भी स्थिति में, यदि आपको प्रवाह में आने में कई महीने लगते हैं, तो चिंतित न हों । अगर मैं परियोजनाओं को 2 या 3 सप्ताह के लिए स्विच करता हूं और फिर वापस स्विच करता हूं, तो मुझे पूरी तरह से "वापस" एक प्रोजेक्ट प्राप्त करने में कुछ घंटे (या एक या दो दिन) लग सकते हैं, जो मैंने अपने दम पर 100% लिखा था!

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

संपादित करें:

या उपयोग करें merge। वह भी एक विकल्प है। तो, उपरोक्त होगा: " git rebase -i( -iमतलब इंटरैक्टिव) या git merge" का उपयोग करें। जिसके लिए किसी का उपयोग करना है, वह अपनी टीम के बाकी सदस्यों के साथ बात करें। उनके पास (या नहीं) मजबूत प्राथमिकताएं हो सकती हैं। यह स्पष्ट है कुछ लोगों करते मजबूत प्राथमिकताएं होती हैं।

— जैकब रॉबिंस
स्रोत

22

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

— user949300

95

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

— वेक्टरजोन

54

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

— एंट पी

14

@ user949300 git pullजिनमें से सिर्फ एक संयोजन है git fetchऔर git merge(या आप जोड़ सकते हैं --rebaseकिसी मर्ज के बजाय एक रिबेस करने के लिए)। मान लें कि आप केवल एक दिन पीछे हैं, तो LAN पर यह सेकंड से भी कम समय में पूरा हो जाएगा, यह इंटरनेट पर कुछ सेकंड का समय ले सकता है। यहां तक कि इंटरनेट पर और मामूली मर्ज संघर्ष के साथ, आप आम तौर पर अप-टू-डेट हो सकते हैं और एक मिनट से भी कम समय में सफाई से विलय कर सकते हैं। पूरे सप्ताह में पांच मिनट का समय बिताना एक सप्ताह के अंत में एक घंटे खर्च करने से बेहतर है जो एक मर्ज के साथ संघर्ष से निपटता है।

— डेरेक एलकिंस

66

मेरी तरफ से कोई नाराज़गी नहीं क्योंकि यह जवाब पूरी तरह से रिबासिंग पर तय किया गया है। रिबासिंग एक उपयोगी उपकरण हो सकता है, लेकिन इसका उपयोग कभी भी दिमाग से नहीं किया जाना चाहिए। अद्यतन करने के लिए दिन के लिए यह मर्ज करने के लिए बेहतर है। क्यों? क्योंकि हर छूट झूठ है । आप इतिहास को एक तरह से बता रहे हैं जैसा कि कभी नहीं हुआ। यह पूरी तरह से शक्तिशाली उपकरणों को पेंच कर सकता है git bisect: विद्रोही सामान भी संकलित नहीं कर सकता है, इसलिए git bisectपरिणामस्वरूप टूटे हुए कमिट पर बेकार है। @maaartinus: I, एक के लिए, रैखिक इतिहास पर सच्चा इतिहास पसंद करते हैं। यदि आप रिबेट करते हैं, तो आपको हानिकारक झूठ से बचने के लिए पवित्रता के लिए हर नई प्रतिबद्धता की जांच करनी चाहिए।

— सेमीस्टर

131

यह कंपनी की ओर से खराब सॉफ्टवेयर इंजीनियरिंग का संकेत हो सकता है। बहुत अधिक अंतर निर्भरताएं, अतिव्यापी सुविधाओं के साथ विभिन्न मुद्दे, गलत क्रम में मुद्दों से निपटने का प्रयास आदि आप जिस स्थिति का वर्णन कर रहे हैं, उसका कारण बन सकता है। मेरा सुझाव है developकि विकास के दौरान नियमित रूप से अपनी शाखा में विलय करें

— इवान अनातोलिविच
स्रोत

9

यह आपके द्वारा बताए गए 101 सामान को कोड कर रहा है। जरूरी नहीं कि नए कर्मचारी पर सटीक प्रतिबिंब हो।

— मिस्टर पॉजिटिव

2

@ इवान अनातोलिविच ओपी कहते हैं कि वे विकसित नहीं हैं, मास्टर नहीं, FYI करें

— मैथ्यू फिजराल्ड-चेम्बरलेन

6

यह उत्तर दिखाता है कि मुझे GIT क्यों पसंद नहीं है: टीमों के लिए फिर से एक उचित प्रबंधन और सभ्य योजना बनाने से बचने के लिए यह एक और उपकरण है। हर चीज का जवाब "कौन परवाह करता है, आप हमेशा उस आदेश का बाद में उपयोग कर सकते हैं", बजाय ऐसा होने से पहले समस्याओं से बचने के।

— motoDrizzt

7

मेरा पहला विचार भी बुरी प्रथाओं का संकेत था, अधिकांश भाग के लिए देवताओं को एक ही फाइल पर काम नहीं करना चाहिए। यदि एक छोटी सी परियोजना में कई संघर्ष हो रहे हैं, तो बाकी सभी को बिना काम किए दिन भर संघर्षों का समाधान करना चाहिए!

— असिताटस

14

@motoDrizzt क्या? मैंने कभी किसी को यह तर्क देते नहीं सुना।

— jpmc26

95

मुझे लगता है कि स्वीकार किए जाते हैं उत्तर मुझे लगता है कि एक तकनीकी "कैसे बेहतर Git का उपयोग करने के लिए" प्रकृति के हैं, मुझे लगता है कि यह एक इंजीनियरिंग या टूलींग समस्या की तुलना में टीम की समस्या का अधिक है।

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

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

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

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

— रोवाण
स्रोत

4

मुझे लगता है कि आपने सहकर्मी संघर्ष के साथ सिर पर नाखून मारा। विलय संघर्ष एक नियमित बात है, लेकिन वे आम तौर पर मुट्ठी भर फाइलों तक सीमित हैं।

— मैथ्यू एम।

10

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

— क्रिस वॉग

7

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

— डेरेक एल्किन्स

1

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

— रोवन

1

@ रोवन कूल हाँ, मैंने जितना सोचा था। फ़ंक्शनलिटी पृथक्करण फ़ाइल पृथक्करण (विभिन्न फ़ाइलों आदि में कार्यों के सेट) के साथ मदद कर सकता है और यह IMO विलय के साथ मदद करता है।

— साल्टीबस 2

28

विलय के बारे में सबसे महत्वपूर्ण बात यह है कि आप जितनी देर प्रतीक्षा करेंगे, उतना ही अधिक दर्द होगा। और समस्या रैखिक से अधिक बढ़ती है। तीन बार जितने संघर्ष होते हैं उतने ही काम से नौ गुना होते हैं। कुछ रणनीतियाँ हैं:

जब भी यह परिवर्तित होता है, तो विकास शाखा के साथ विलय करें, इसलिए आप हमेशा इसके करीब होते हैं, और कभी भी बड़ी संख्या में टकराव नहीं होते हैं।

यदि आप एक लंबा समय लेते हैं, तो यह हो सकता है क्योंकि आप ज्यादातर समय यह जानने में बिताते हैं कि परिवर्तन क्या हैं, और फिर परिवर्तनों को लागू करने में थोड़ी मात्रा में। यदि ऐसा है, तो वास्तविक कोड परिवर्तन शुरू करने से पहले विकास शाखा में विलय करें।

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

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

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

— gnasher729
स्रोत

फीचर शाखाएं खुद को तकनीकी ऋण के एक अन्य रूप की तरह प्रस्तुत करती हैं, जहां मूल शाखा से अप-स्ट्रीमिंग परिवर्तन को फिर से भरना जैसा है।

— डैन लियोन

सिवाय इसके कि आप है कि ऋण का भुगतान करने के लिए। अभी।

— gnasher729

15

जब तक मैं के लिए तैयार हूँ विलय अपनी शाखा में वापस बढ़ने लगता है (जोर मेरा)

इनसे निपटने में संघर्ष git mergeअक्सर सरल होता है git rebase। Git मर्ज में आप उन फ़ाइलों की पूरी सूची देख सकते हैं जिन्हें एक ही बार में संशोधित किया गया है। अन्य सहकर्मियों द्वारा चाहे जितने कमिट किए गए हों, आपको एक बार विलय करना होगा । रिबास वर्कफ़्लो के साथ, आप एक ही टकराव को समाप्त कर सकते हैं और उन्हें मैन्युअल रूप से समीक्षा करना होगा। आप 13 वीं प्रतिबद्धता को समाप्त कर सकते हैं और महसूस कर सकते हैं कि आप सुरंग से प्रकाश नहीं देख सकते हैं ।

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

मैं आपको कुछ तकनीकों का सुझाव देने जा रहा हूं, लेकिन वे केवल मर्ज को कार्य को स्वचालित करने की तुलना में आसान बनाने में मदद कर सकते हैं।

संसाधन / भाषा फ़ाइलें । यदि आपके पास संसाधन फ़ाइल में योगात्मक परिवर्तन हैं, तो सुनिश्चित करें कि आप हमेशा उन्हें फ़ाइल के अंत तक ले जाते हैं ताकि आप दूसरों के परिवर्तनों के विरुद्ध अपने परिवर्तनों को आसानी से याद कर सकें । आप नीचे अपने परिवर्तनों को कॉपी या पेस्ट करने में सक्षम हो सकते हैं, या बस संघर्ष मार्करों को हटा सकते हैं
करना। नहीं। पूर्ण रूप से। पुन: प्रारूप । दैनिक कार्य के दौरान न तो आप और न ही आपके साथी डेवलपर्स "बड़े पैमाने पर कोड सुधार" करेंगे। कोड सुधारक संघर्ष प्रबंधन में अत्यधिक सकारात्मक संख्या जोड़ते हैं। कोड सुधार किया जा सकता है
- आकस्मिक रूप से, जैसे प्रत्येक डेवलपर द्वारा प्रत्येक प्रतिबद्ध पर, जैसे ही वे एक स्वचालित उपकरण का उपयोग करते हैं (जैसे कि एक्लिप्स में सेव पर पुन: स्वरूपित करने का विकल्प है, वेनिला विज़ुअल स्टूडियो के पास कोई नहीं है)। बिल्कुल हर डेवलपर को एक समान कोड स्वरूपण मानकों का उपयोग करना चाहिए, जो आपके आईडीई द्वारा खाए गए प्रारूप फ़ाइल में कोडित है। आपको एक विचार देने के लिए, अगर यह 4 रिक्त स्थान या 2 टैब है तो यह कोई फर्क नहीं पड़ता, लेकिन यह वास्तव में मायने रखता है अगर हर कोई समान का उपयोग करता है।
- रिलीज से ठीक पहले, एक टीम लीडर द्वारा। यदि एक "कोड रिफॉर्मैट" कमिट होता है, जब लोग शाखाओं पर काम नहीं कर रहे होते हैं, यानी शाखा से पहले, चीजें आसान हो जाएंगी
सहकर्मियों के बीच विभाजन के कार्य की समीक्षा करें । यह एक ऐसा हिस्सा है जहां सबसे अधिक इंजीनियरिंग आती है। जैसा कि अन्य उत्तरों द्वारा बताया गया है, यह डिज़ाइन गंध है यदि विभिन्न कार्य करने वाले कई डेवलपर्स को समान संसाधनों को स्पर्श करना है। आपको अपने टीम लीडर से चर्चा करनी होगी कि प्रत्येक समवर्ती डेवलपर द्वारा किस हिस्से को संशोधित किया जाना है।

मैंने अपनी टीमों में गिट वर्कफ्लोज़ में कुछ बुरी आदतें देखी हैं। अक्सर लोग अपनी शाखाओं में ओवरकम करते हैं। मैंने व्यक्तिगत रूप से 10 "20" लेबल वाले एक डेवलपर को "फिक्स" के रूप में देखा, प्रत्येक एक या दो पंक्तियाँ। हमारी नीति यह है कि आपको विचार देने के लिए JIRA टिकटों के साथ कमिट किया जाता है।

@JacobRobbins git rebaseएक दैनिक कार्य करने का सुझाव देता है । मैं उनके दृष्टिकोण को आगे बढ़ाना चाहूंगा।

सबसे पहले, कम से कम एक बार कमिट की संख्या को कम करने के लिए रिबास का उपयोग करें। और मूल विकसित शाखा पर ही रिबास करें , जो आपके द्वारा शाखित की गई प्रतिबद्धता है। जब मैं मुट्ठी भर कहता हूं, तो मेरा मतलब 3 या 4 हो सकता है (जैसे सभी फ्रंट एंड, सभी बैक एंड, सभी डेटाबेस पैच) या कोई भी मानवीय-उचित आंकड़ा। आपके द्वारा उन्हें समेकित करने के बाद, fetchअपस्ट्रीम शाखा पर अपने रिबास का उपयोग करें और काम करें। यह आपको संघर्ष से नहीं बचाएगा जब तक कि आपकी टीम अपने दृष्टिकोण की समीक्षा नहीं करती है, लेकिन यह आपके जीवन को कम दर्दनाक बना देगा।

यदि आपके पास विशिष्ट कार्यों पर अतिरिक्त प्रश्न हैं, तो बेझिझक खोज करें और Stackoverflow पर पूछें।

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

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

— usr स्थानीय-ΕΨΗΕΛΩΝ
स्रोत

3

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

— user622505

3

सुधार के बारे में, जबकि वीएस इसे स्वचालित रूप से सहेजने पर नहीं कर सकता है, अगर आप "टूल्स" में "इंडेंट और फॉर्मेट" को "पेस्ट" में सेट करते हैं -> "विकल्प" -> "टेक्स्ट एडिटर" -> "< आपकी पसंद की भाषा> "->" फ़ॉर्मेटिंग ", अर्थात यह पेस्ट पर ऑटो प्रारूप है। यह तीन कीस्ट्रोक्स के अनुक्रम को अनुमति देता है: वांछित परिणाम के लिए ctrl-A, ctrl-C, ctrl-V। उस ने कहा, +1 फॉर डू। नहीं। पूर्ण रूप से। पुन: स्वरूपित। सिवाय इसके कि आप बहुत सावधानी से नियंत्रित स्थितियों के तहत रूपरेखा बनाते हैं।

— dgnuff

1

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

— जूनियर

2

आपको कोड को सुधारने या हल्का करने की आवश्यकता महसूस होती है, इसे अपनी सार्थक प्रतिबद्धता से पहले या बाद में करें। यह न केवल संघर्ष को कम करेगा, बल्कि आपकी प्रतिबद्धताओं के भविष्य के पाठक की भी मदद करेगा, जिसमें समीक्षक शामिल हैं

— अधिकतम ६३०

1

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

— सुधारित

5

सबसे पहले, अपने परिवर्तनों को छोड़ने के बारे में मत सोचो। आप मर्ज प्रक्रिया सीखने के अवसर खो देंगे।

दूसरा, एक ऐसे व्यक्ति को खोजें जिसने संघर्ष के कारण फाइलों पर काम किया। आप इतिहास देख सकते हैं। व्यक्ति से बात करें और उन फाइलों में संघर्ष को हल करें। अन्य संघर्षों के लिए भी यही करें।

यदि बहुत अधिक संघर्ष हैं, तो आपका कार्य एक छोटा हो सकता है, लेकिन दोहराव वाला। एक पैटर्न खोजने की कोशिश करें। यह Git UI क्लाइंट टूल द्वारा संघर्षों को हल करने में मदद करेगा। मैं TortoiseGit का उपयोग करता हूं। यह मर्ज करने में मदद करता है।

और भविष्य में बचने के लिए,

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

— PKV
स्रोत

1

+1 Git का बेहतर उपयोग करने के लिए अन्य सुझाव अच्छे हैं, लेकिन वास्तव में अन्य डेवलपर्स के साथ मर्ज संघर्ष के बारे में बात करना ओपी की प्रभावशीलता को विकसित करने का एक और महत्वपूर्ण पहलू है।

— ड्रैगनेल

1

"आप इतिहास देख सकते हैं" शायद! निर्भर करता है कि सब कुछ स्क्वैश और रिबूट कैसे होता है: P

— लाइटनेस दौड़ ऑर्बिट में

1

आपको अपनी विकास शाखा से नियमित रूप से (दैनिक) कमांड 'git fetch' (git पुल नहीं) चलाना चाहिए। इससे अन्य लोगों को प्रतिबद्ध परिवर्तन मिलेंगे और उन्हें अपनी शाखा में परिवर्तन को एकीकृत करने का प्रयास किए बिना अपनी सुविधा शाखा में लाना होगा।

यह वह चीज है जिसके बारे में आपको लीडर डेवलपर से बात करनी चाहिए (जरूरी नहीं कि आपका मैनेजर), क्योंकि आपकी कंपनी के अपने मानक हो सकते हैं या इस मुद्दे से निपटने के अनुशंसित तरीके; यह बहुत आम है। अगले सप्ताह तक प्रतीक्षा न करें - अब प्रक्रिया का पता लगाएं, और पूछें कि क्या आप कुछ तुच्छ काम कर सकते हैं (जैसे कि कोड स्वरूपण या टिप्पणी जोड़ना) ताकि आप प्रक्रिया का परीक्षण कर सकें।

21

मुझे यकीन नहीं है कि यह सही है। Git fetch को रीमोट / ओरिजिन / मास्टर / अप टू डेट मिलेगा लेकिन फिर आपको remotes / मूल / मास्टर को अपनी सुविधा शाखा में मर्ज करने की आवश्यकता है (या यदि वे जिस फ्लो का उपयोग कर रहे हैं, उसका रीमेक / उत्पत्ति / विकास हो)

— रिचर्ड टिंगल

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

@RichardTingle सही, वह एक रिबेस विकल्प के बारे में सोच रहा है। आप बस अपनी शाखा को देव शाखा के साथ लाते हैं और रिबेट करते हैं। वह सब कुछ समेट देगा।

6

@ मुझे लगता है कि यह एक राय का विषय हो सकता है। व्यक्तिगत रूप से मुझे बड़े पैमाने पर नफरत है। कोशिश git bisecting कि!

— रिचर्ड टिंगल

2

@PeteCon "और अपनी शाखा में परिवर्तनों को एकीकृत करने का प्रयास किए बिना उन्हें अपनी सुविधा शाखा में लाएं"। यह एक विरोधाभासी बयान की तरह लगता है। मुझे लगता है कि आप उन्हें अपनी सुविधा शाखा में एकीकृत किए बिना उन्हें अपने स्थानीय भंडार में ला सकते हैं, लेकिन मुझे यकीन नहीं है कि यह कैसे मदद करता है ...

— जेसन गोएमाट

1

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

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

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

— Kafein
स्रोत

1

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

यह जोड़ी प्रोग्रामिंग के लिए एक आदर्श परिदृश्य की तरह लगता है !

लाभों और बुनियादी तरीकों के बारे में अधिक जानकारी:
https://gds.blog.gov.uk/2018/02/06/how-to-pair-program-effectively-in-6-steps/

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

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

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

तेज, अधिक अनुभवी देव के साथ बैठने से मदद करने की क्षमता होती है:

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

क्या कोई युक्ति है जिसका उपयोग मैं 'कोडिंग में बेहतर होने' के अलावा कर सकता हूं? मैं अगले सप्ताह अपने पर्यवेक्षक के साथ इसे लाने का इरादा रखता हूं।

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

— जेम्स
स्रोत

ईमानदारी से, जिन्होंने यह नकार दिया :( यह कुछ जंगली अनुमान नहीं है, यह मेरे कार्यस्थल में होता है और काम करने के लिए सिद्ध होता है! संयोग से, मैंने इस साइट पर अन्य प्रश्नों के अन्य उत्तरों पर कड़ी मेहनत की, जो 10 प्रतिनिधि (मेरे संबद्ध प्रतिनिधि के ऊपर) करने में सक्षम हैं ) बस इस में "जोड़ी प्रोग्रामिंग" का सुझाव देने में सक्षम होने के लिए क्योंकि कोई भी इसका सुझाव नहीं देता है। मैंने इसका जवाब देने के लिए वास्तव में कड़ी मेहनत की।

— जेम्स

1

यहां कुछ अंतर्निहित समस्याएं हैं। आपकी समस्याओं को मर्ज करना आपकी गलती नहीं है और आमतौर पर बुरे व्यवहार का एक लक्षण है।

1) आदर्श रूप से आप हर दिन अपनी शाखा का विकास करेंगे। कोशिश करें कि दिन में कम से कम एक बार कोड काम करें जो सभी परीक्षणों को पास करता है ताकि आप विकसित हो सकें।

2) यदि आपके पास अपने सामान्य कार्य दिवस के दौरान किसी भी बिंदु पर काम करने का कोड नहीं है, तो संभवतः आपके पास काम करने के लिए कोड के बहुत बड़े हिस्से हैं। आपको अपने काम को छोटे-छोटे कामों में तोड़ने की जरूरत है, जिन्हें खत्म किया जा सकता है (आदर्श रूप से एक दूसरे से स्वतंत्र) ताकि आप विलय कर सकें।

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

4) आपकी टीम बहुत बड़ी हो सकती है। यदि आपको एक संपूर्ण सुविधा को फेंकना और शुरू करना आसान लगता है, तो संभव है कि बहुत से लोग एक ही रिपॉजिटरी के लिए कोड कमिट कर रहे हों।

5) आपके पास लगातार कोड स्वरूपण मानक नहीं हो सकते हैं। यदि आप सभी समान कोड प्रारूप का लगातार उपयोग नहीं करते हैं तो आपको एक ही कोड के लिए कई अलग-अलग संघर्ष मिलेंगे। इस बात पर निर्भर करता है कि आपका git कैसे सेट किया गया है ये व्हाट्सएप संघर्ष (लाइन एंडिंग, इंडेंटेशन, टैब्स बनाम स्पेस) के लिए भी नीचे आ सकते हैं।

6) लोग अपने बदलावों को सीधे विकसित शाखा में धकेल सकते हैं।

यहाँ आप क्या कर सकते हैं: 1) यदि आप हर दिन विकसित होने में विलय नहीं कर सकते हैं, तो हर दिन आपकी शाखा में मर्ज / रिबेस विकसित होता है (या अधिक बार)।
2) कोशिश करें कि आपका कोड हर एक के कोड से अलग हो।
3) छोटी विशेषताओं, सुसंगत कोडिंग मानकों और बेहतर कोड संगठन (छोटी फाइलें, छोटे कार्य) के बारे में बाकी टीम से बात करें।

— xyious
स्रोत

1

यह वास्तव में मेरे काम को स्क्रैप करना आसान लगता है और कार्य पर शुरू होता है, जो निश्चित रूप से एक स्थायी समाधान नहीं है)

ज्यादातर समय, यह वही है जो मैं करता हूं, पहली बार मैं बग को ठीक करता हूं या सिस्टम में बदलाव करता हूं, मैं यह सीख रहा हूं कि यह कैसे करना है। अगली बार जब मैं एक ही बग ठीक करता हूं तो केवल 1% समय लगता है क्योंकि अब मैं समस्या को समझता हूं।

मुझे यह भी पता चलता है कि जब मैं थोड़ा काम करता हूं, तो बेहतर कोड लिखता हूं ....।

इसलिए मास्टर से एक नई शाखा बनाने, इसमें आपके काम को फिर से करने, जबकि आपकी "निजी शाखा" का उपयोग करके आपको यह याद दिलाने के लिए कुछ भी गलत नहीं है कि आपको क्या करना है।

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

— इयान
स्रोत

1

यदि आप विकसित शाखा को अक्सर शाखा में विलय नहीं करना चाहते हैं, तो आप एक वर्कफ़्लो प्राप्त कर सकते हैं जो कि उपयोग करके svn की तरह अधिक है git pull --rebase। यह नए कमिट्स को खींचेगा और उन पर आपके कमिट्स को रीबेज करेगा। इसका मतलब यह है कि जब आप अपनी शाखा को विकसित करते हैं, तो यह एक तेजी से आगे बढ़ने वाला मर्ज होगा (जैसे कि आपने एक ही समय में एक ही समय में अपने सभी पुराने कामों को जोड़ दिया होगा) और किसी भी मर्ज का विरोध नहीं होगा, क्योंकि आपने उन सभी को हल कर लिया है git pull --rebase।

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

— allo
स्रोत

1

जब आप सामान्य फ़ाइलों में काम करते हैं, तो किसी भी तरह से आपको या आपके साथियों को विलय खत्म करने से पहले सभी संघर्षों को हल करने की आवश्यकता होती है इसलिए पहली जगह पर कृपया परेशान न हों । आप अभी भी परियोजना का काम कर रहे हैं और अपने काम पर गर्व कर रहे हैं। अब एक बेहतर चाल बनाने के लिए, आप नीचे कुछ सुझावों का पालन कर सकते हैं।

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

रिमोट के साथ अपनी स्थानीय शाखा में बार-बार छूट देने का अभ्यास करें। आप अपनी स्थानीय शाखा को दूरस्थ एक के साथ बार-बार रिबूट करने के लिए नीचे दिए गए आदेश का उपयोग कर सकते हैं,
```
git pull --rebase #or
git pull --rebase origin dev #when dev is remote branch
```
मेरे विकास जीवन में मेरे लिए यह अब तक का सबसे उपयोगी कार्य है।
टीम के साथियों के साथ मिलकर काम करें:

यदि आपको वास्तव में अपने टीममेट के साथ समान कार्य में समानांतर रूप से काम करने की आवश्यकता है, तो कृपया सहयोगात्मक रूप से काम करें। वह कुछ समय के लिए आपकी सुविधा के लिए जटिल संघर्ष समाधान से बचने के लिए इंतजार कर सकती है क्योंकि आप नौसिखिया हैं और वह एक विशेषज्ञ है।
Git विकल्पों के साथ उपयोग किया जा सकता है:

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

— सज्जाद हिसैन खान
स्रोत

नया डेवलपर शाखा मर्ज के साथ नहीं रख सकता है

स्वतंत्र रूप से कार्यों को विभाजित करें:

मर्ज दानेदार लगातार करता है:

अपनी शाखा को बार-बार रिबेस करें:

टीम के साथियों के साथ मिलकर काम करें:

Git विकल्पों के साथ उपयोग किया जा सकता है: