गिट को अत्यधिक संघर्ष के कारण रिबेस के साथ खींचें। मैं अपने वर्कफ़्लो को कैसे ठीक कर सकता हूं?

Question

हमारे पास एक बेस सिस्टम है जो प्रत्येक ग्राहक के लिए अनुकूलित किया गया है। आधार अपने स्वयं के भंडार में रहता है, और प्रत्येक ग्राहक अपने स्वयं के भंडार में रहता है (मूल रूप से आधार से क्लोन)।

लक्ष्य लक्ष्य पर बग फिक्स/फीचर्स जोड़ने की क्षमता है, जिसे मांग पर ग्राहकों को प्रचारित किया जा सकता है।

अब तक कार्यप्रवाह इस प्रकार किया गया है:

• मेक करता/विषय शाखाओं आधार फिक्स/सुविधाओं के लिए: (आधार पर, मास्टर) git commit -m "Fix admin typo"
• ग्राहक में उन परिवर्तनों को सम्मिलित करें: (क्लाइंट, मास्टर पर) git merge base/master। जाहिर है, इसमें आधार और ग्राहक के अनुकूलन के बीच किसी भी विवाद को ठीक करना शामिल है।
• क्लाइंट की उत्पत्ति में विलय को पुश करें: (क्लाइंट, मास्टर पर) git push origin master
• हमारा सम्मेलन रीबेस (इतिहास को पढ़ने योग्य रखने के लिए) को खींचने के लिए किया गया है। तो, फिर किसी भिन्न डेवलपर ग्राहक परियोजना पर काम कर होगा (मास्टर क्लाइंट पर,) git pull --rebase origin master

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

यहां सबसे अच्छा समाधान क्या है?

मेरा एकमात्र विचार है कि मैला खींचने और कठोर और पढ़ने-पढ़ने वाले लॉगों से निपटने के दौरान रिबेस का उपयोग करना बंद करना है, लेकिन मुझे ऐसा करने की ज़रूरत नहीं है। ये ग्राहक परियोजनाएं वर्षों से रह सकती हैं, और मैं भविष्य में बेस सिस्टम विलय से कुछ समझने में सक्षम होना चाहता हूं।

Answer 1

मुझे इस सीधे अपने रेपोस पर प्राप्त करते हैं:

1. मुख्य परियोजना, अलग है base
2. प्रत्येक ग्राहक परियोजना base से क्लोन है, कहा जाता है केवल खींच अपडेट
3. devs जनता से काम client_foo रेपो, और push/pull कि

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

यदि यह क्लाइंट रेपो प्रति केवल एक देव था, तो शायद यह काम करेगा। मुझे लगता है कि यह मामला नहीं है।

विकल्प:

1. क्या आपके कर जारी है, लेकिन जब देव रिबेस client_foo शाखा (नई base प्रतिबद्ध के साथ) धक्का वापस सार्वजनिक client_foo रेपो के लिए, हर किसी पर एक reset --hard करना है origin/master। यदि वे अपने सभी अप्रचलित परिवर्तनों को किसी निजी विषय शाखा में रखते हैं, तो उन्हें rebase पर वापस client_foo/master पर वापस जाना होगा।

2. अपने देव mergebase से client_foo में परिवर्तन करें। यह आपको client_foo पर विलय प्रतिबद्धता देगा जो आपने कहा था कि आप इससे बचने की कोशिश कर रहे हैं, लेकिन यह आपको सबसे सटीक इतिहास देगा। जब आपके देव एक 'पुल --rebase' करते हैं, तो अब आपको अपने संघर्षों की लंबी सूची नहीं मिलनी चाहिए।

3. अपने देव cherrypickbase से client_foo पर परिवर्तन करें। यह आपके इतिहास को रैखिक रखता है, लेकिन गिट अब ट्रैक नहीं करेगा कि cherrypick 'डी काम base से आया था। इसे ट्रैक करने के लिए आपको एक और तरीके से आना होगा।

मैं # 2 के साथ छड़ी कहूंगा क्योंकि इस तरह से गिट काम करना है। हालांकि, कोई और बेहतर गैर-स्पष्ट समाधान के बारे में सोच सकता है।