git - गिट वर्कफ़्लो और रीबेस बनाम प्रश्नों को विलय करें




version-control git-merge (7)

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

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

मुझे लगता है कि आपको क्या हुआ पर ध्यान से देखने की जरूरत है। क्या किसी और के पास (जानबूझकर या नहीं) स्थानीय शाखा के निर्माण और उस बिंदु पर रिमोट मास्टर शाखा को रिवाउंड कर सकता है जिस पर आपने उसे स्थानीय शाखा में वापस लाने का प्रयास किया था?

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

मैं अब एक अन्य डेवलपर के साथ एक परियोजना पर कुछ महीनों के लिए गिट का उपयोग कर रहा हूं। मेरे पास SVN साथ कई वर्षों का अनुभव है, इसलिए मुझे लगता है कि मैं रिश्ते में बहुत सामान लेता हूं।

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

मेरा साथी मुझे बताता है कि मेरी समस्याएं मेरी इच्छा से विचलित हो गई हैं, और मुझे कई परिस्थितियों में विलय करने के बजाय रिबेस का उपयोग करना चाहिए। उदाहरण के लिए, यहां वर्कफ़्लो है जिसे उन्होंने निर्धारित किया है:

clone the remote repository
git checkout -b my_new_feature
..work and commit some stuff
git rebase master
..work and commit some stuff
git rebase master
..finish the feature
git checkout master
git merge my_new_feature

अनिवार्य रूप से, एक फीचर शाखा बनाएं, हमेशा मास्टर से शाखा में रीबेस करें, और शाखा से वापस मास्टर में विलय करें। ध्यान रखना महत्वपूर्ण है कि शाखा हमेशा स्थानीय रहता है।

यहां वर्कफ़्लो है जिसके साथ मैंने शुरुआत की थी

clone remote repository
create my_new_feature branch on remote repository
git checkout -b --track my_new_feature origin/my_new_feature
..work, commit, push to origin/my_new_feature
git merge master (to get some changes that my partner added)
..work, commit, push to origin/my_new_feature
git merge master
..finish my_new_feature, push to origin/my_new_feature
git checkout master
git merge my_new_feature
delete remote branch
delete local branch

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

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

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

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

इस तरह के कुछ के लिए "सही" वर्कफ़्लो क्या है? गिट को ब्रांचिंग करना और सुपर-आसान विलय करना है, और मैं इसे देख नहीं रहा हूं।

2011-04-15 अपडेट करें

यह एक बहुत ही लोकप्रिय सवाल प्रतीत होता है, इसलिए मैंने सोचा कि मैं अपने दो साल के अनुभव के साथ अपडेट करूंगा क्योंकि मैंने पहले पूछा था।

यह पता चला है कि मूल वर्कफ़्लो कम से कम हमारे मामले में सही है। दूसरे शब्दों में, हम यही करते हैं और यह काम करता है:

clone the remote repository
git checkout -b my_new_feature
..work and commit some stuff
git rebase master
..work and commit some stuff
git rebase master
..finish the feature, commit
git rebase master
git checkout master
git merge my_new_feature

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

clone the remote repository
git checkout -b my_new_feature
..work and commit some stuff
git rebase master
..work and commit some stuff
git rebase master
..finish the feature, commit
git rebase master
git checkout master
git merge --squash my_new_feature
git commit -m "added my_new_feature"
git branch -D my_new_feature

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

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

clone the remote repository
git checkout -b my_new_feature
..work and commit some stuff
git rebase master
..work and commit some stuff
git rebase master
..finish the feature, commit
git rebase master
git push # May need to force push
...submit PR, wait for a review, make any changes requested for the PR
git rebase master
git push # Will probably need to force push (-f), due to previous rebases from master
...accept the PR, most likely also deleting the feature branch in the process
git checkout master
git branch -d my_new_feature
git remote prune origin

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


टी एल; डॉ

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

संघर्ष समाधान के लिए वर्कफ़्लो रीबेज बेहतर नहीं है!

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

यदि यह विलय के दौरान "नरक में" जाता है, तो यह एक रिबेस के दौरान "नरक में" जाएगा, और संभावित रूप से बहुत अधिक नरक भी! यहाँ पर क्यों:

कारण # 1: प्रत्येक प्रतिबद्धता के लिए एक बार के बजाय संघर्षों को हल करें

जब आप मर्ज करने के बजाए रीबेज करते हैं, तो आपको उसी संघर्ष के लिए जितनी बार पुनर्विचार करना पड़ता है, उतना बार संघर्ष समाधान करना होगा!

वास्तविक परिदृश्य

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

जब मेरी शाखा वापस मास्टर के साथ विलय करने का समय है, तो मेरे पास दो विकल्प हैं:

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

गिट रिबेस: मुझे अपनी पहली प्रतिबद्धता के साथ संघर्ष मिलता है। मैं संघर्ष को हल करता हूं और रिबेस जारी रखता हूं। मुझे अपनी दूसरी प्रतिबद्धता के साथ संघर्ष मिलता है। मैं संघर्ष को हल करता हूं और रिबेस जारी रखता हूं। मुझे अपने तीसरे प्रतिबद्धता के साथ संघर्ष मिलता है। मैं संघर्ष को हल करता हूं और रिबेस जारी रखता हूं। मुझे अपनी चौथी प्रतिबद्धता के साथ संघर्ष मिलता है। मैं संघर्ष को हल करता हूं और रिबेस जारी रखता हूं। मुझे अपनी पांचवीं प्रतिबद्धता के साथ संघर्ष मिलता है। मैं संघर्ष को हल करता हूं और रिबेस जारी रखता हूं। मुझे अपने छठे प्रतिबद्धता के साथ संघर्ष मिलता है। मैं संघर्ष को हल करता हूं और रिबेस जारी रखता हूं। मुझे अपने सातवें प्रतिबद्धता के साथ संघर्ष मिलता है। मैं संघर्ष को हल करता हूं और रिबेस जारी रखता हूं। मुझे अपनी आठवीं प्रतिबद्धता के साथ संघर्ष मिलता है। मैं संघर्ष को हल करता हूं और रिबेस जारी रखता हूं। मुझे अपनी नौवीं प्रतिबद्धता के साथ संघर्ष मिलता है। मैं संघर्ष को हल करता हूं और रिबेस जारी रखता हूं। मुझे अपनी दसवीं प्रतिबद्धता के साथ संघर्ष मिलता है। मैं संघर्ष को हल करता हूं और रिबेस जारी रखता हूं। मुझे अपने ग्यारहवें प्रतिबद्धता के साथ संघर्ष मिलता है। मैं संघर्ष को हल करता हूं और रिबेस जारी रखता हूं। मुझे अपनी बारहवीं प्रतिबद्धता के साथ संघर्ष मिलता है। मैं संघर्ष को हल करता हूं और रिबेस जारी रखता हूं। मुझे अपने तेरहवें प्रतिबद्धता के साथ संघर्ष मिलता है। मैं संघर्ष को हल करता हूं और रिबेस जारी रखता हूं। मुझे अपनी चौदहवीं प्रतिबद्धता के साथ संघर्ष मिलता है। मैं संघर्ष को हल करता हूं और रिबेस जारी रखता हूं। मुझे अपने पंद्रहवीं प्रतिबद्धता के साथ संघर्ष मिलता है। मैं संघर्ष को हल करता हूं और रिबेस जारी रखता हूं।

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

आपके द्वारा किए जाने वाले सभी अतिरिक्त संघर्ष समाधानों के साथ, यह संभावना बढ़ जाती है कि आप कोई गलती करेंगे । लेकिन गलतियों में गलतियां ठीक हैं क्योंकि आप पूर्ववत कर सकते हैं, है ना? पाठ्यक्रम के अलावा ...

कारण # 2: रिबेस के साथ, कोई पूर्ववत नहीं है!

मुझे लगता है कि हम सभी सहमत हैं कि संघर्ष समाधान मुश्किल हो सकता है, और यह भी कि कुछ लोग इसमें बहुत बुरे हैं। यह गलतियों के लिए बहुत प्रवण हो सकता है, यह इतना अच्छा क्यों है कि गिट इसे पूर्ववत करना आसान बनाता है!

जब आप शाखा को विलय करते हैं, तो गिट एक विलय प्रतिबद्ध बनाता है जिसे विवाद समाधान खराब होने पर त्याग दिया जा सकता है या संशोधित किया जा सकता है। यहां तक ​​कि यदि आपने पहले से ही सार्वजनिक / आधिकारिक रेपो में खराब विलय प्रतिबद्धता को धक्का दिया है, तो आप मर्ज द्वारा पेश किए गए परिवर्तनों को पूर्ववत करने के लिए git revert का उपयोग कर सकते हैं और नए विलय प्रतिबद्धता में विलय को सही ढंग से फिर से शुरू कर सकते हैं।

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

एक रिबेस के बाद, यह निर्धारित करना असंभव है कि मूल रूप से कामों का हिस्सा क्या था और खराब संघर्ष समाधान के परिणामस्वरूप क्या पेश किया गया था।

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

संघर्ष संकल्प से बाहर निकलें: diff3 का उपयोग करें

उदाहरण के लिए इस संघर्ष को लें:

<<<<<<< HEAD
TextMessage.send(:include_timestamp => true)
=======
EmailMessage.send(:include_timestamp => false)
>>>>>>> feature-branch

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

बचाव के लिए diff3!

git config --global merge.conflictstyle diff3

जब आप diff3 का उपयोग करते हैं, तो प्रत्येक नए संघर्ष में तीसरा खंड होगा, मर्ज किए गए आम पूर्वज।

<<<<<<< HEAD
TextMessage.send(:include_timestamp => true)
||||||| merged common ancestor
EmailMessage.send(:include_timestamp => true)
=======
EmailMessage.send(:include_timestamp => false)
>>>>>>> feature-branch

सबसे पहले मर्ज किए गए आम पूर्वज की जांच करें। फिर प्रत्येक शाखा के इरादे को निर्धारित करने के लिए प्रत्येक पक्ष की तुलना करें। आप देख सकते हैं कि HEAD ने टेक्स्ट मैसेज में ईमेल मैसेज बदल दिया है। इसका उद्देश्य टेक्स्ट पैरासेज में उपयोग की जाने वाली कक्षा को उसी पैरामीटर को पार करना है। आप यह भी देख सकते हैं कि फीचर-शाखा का इरादा गलत के बजाय गलत है: include_timestamp विकल्प। इन परिवर्तनों को मर्ज करने के लिए, दोनों के इरादे को गठबंधन करें:

TextMessage.send(:include_timestamp => false)

सामान्य रूप में:

  1. प्रत्येक शाखा के साथ आम पूर्वजों की तुलना करें, और यह निर्धारित करें कि कौन सी शाखा में सबसे सरल परिवर्तन है
  2. उस कोड के दूसरे शाखा के संस्करण में उस साधारण परिवर्तन को लागू करें, ताकि इसमें सरल और अधिक जटिल परिवर्तन दोनों शामिल हों
  3. विवाद कोड के सभी अनुभागों को हटाएं, जिनके अलावा आपने एक साथ परिवर्तनों को एक साथ विलय कर दिया है

वैकल्पिक: शाखा के परिवर्तनों को मैन्युअल रूप से लागू करके हल करें

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

आइए देखते हैं कि हम उस परिदृश्य में किसी संघर्ष को कैसे हल कर सकते हैं जहां origin/feature1 विलय हो रहा है जहां lib/message.rb संघर्ष है।

  1. यह तय करें कि हमारी वर्तमान में चेक की गई शाखा ( HEAD , या --ours ) या जिस शाखा में हम विलय कर रहे हैं ( origin/feature1 , या --theirs ) लागू करने के लिए एक सरल परिवर्तन है। ट्रिपल डॉट के साथ diff का उपयोग करना ( git diff a...b ) git diff a...b से होने वाले परिवर्तनों को दिखाता है, जो कि इसके अंतिम विचलन के बाद से, या दूसरे शब्दों में, बी के साथ पूर्व बी के बी और बी के साथ तुलना करता है।

    git diff HEAD...origin/feature1 -- lib/message.rb # show the change in feature1
    git diff origin/feature1...HEAD -- lib/message.rb # show the change in our branch
    
  2. फ़ाइल के अधिक जटिल संस्करण देखें। यह सभी संघर्ष मार्करों को हटा देगा और आपके द्वारा चुने गए पक्ष का उपयोग करेगा।

    git checkout --ours -- lib/message.rb   # if our branch's change is more complicated
    git checkout --theirs -- lib/message.rb # if origin/feature1's change is more complicated
    
  3. जटिल परिवर्तन की जांच के साथ, सरल परिवर्तन के अंतर को खींचें (चरण 1 देखें)। इस बदलाव से विरोधाभासी फ़ाइल में प्रत्येक परिवर्तन लागू करें।


"संघर्ष" का अर्थ है "एक ही सामग्री के समानांतर विकास"। तो यदि यह विलय के दौरान "नरक में" जाता है, तो इसका मतलब है कि आपके पास फ़ाइलों के एक ही सेट पर भारी विकास है।

एक विलय से बेहतर होने का कारण यह है कि:

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

मैं पुष्टि करता हूं कि उस मामले में सही वर्कफ़्लो (फ़ाइलों के सामान्य सेट पर विकास) पहले छूट है, फिर विलय करें

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

उस विषय पर (फिर वर्कफ़्लो विलय करें), barraponto ने टिप्पणियों में दो रोचक पोस्टों का उल्लेख किया है, दोनों randyfay.com :

इस तकनीक का उपयोग करके, आपका काम हमेशा सार्वजनिक शाखा के शीर्ष पर जाता है जैसे पैच जो वर्तमान HEAD साथ अद्यतित है।

( बाज़ार के लिए एक समान तकनीक मौजूद है )


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

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

आप अभी भी बैकअप के लिए रिमोट रिपोजिटरी में अपनी निजी विकास शाखा को धक्का देना जारी रख सकते हैं, लेकिन दूसरों को इसे "सार्वजनिक" शाखा के रूप में नहीं माना जाना चाहिए क्योंकि आप पुन: प्रतिक्रिया देंगे। बीटीडब्ल्यू, ऐसा करने के लिए एक आसान कमांड git push --mirror origin

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


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


मेरे वर्कफ़्लो में, मैं जितना संभव हो उतना रिबेस करता हूं (और मैं इसे अक्सर करने की कोशिश करता हूं। विसंगतियों को जमा करने से शाखाओं के बीच टकराव की गंभीरता और गंभीरता कम हो जाती है)।

हालांकि, यहां तक ​​कि ज्यादातर रीबेस-आधारित वर्कफ़्लो में भी विलय के लिए एक जगह होती है।

याद रखें कि विलय वास्तव में एक नोड बनाता है जिसमें दो माता-पिता हैं। अब निम्न स्थितियों पर विचार करें: मेरे पास दो स्वतंत्र फीचर ब्रांड्स ए और बी हैं, और अब फीचर शाखा सी पर सामान विकसित करना चाहते हैं जो ए और बी दोनों पर निर्भर करता है, जबकि ए और बी की समीक्षा की जा रही है।

मैं तब क्या करता हूं, निम्न है:

  1. ए के शीर्ष पर शाखा सी बनाएं (और चेकआउट)।
  2. बी के साथ इसे मर्ज करें

अब शाखा सी में ए और बी दोनों में परिवर्तन शामिल हैं, और मैं इसे विकसित करना जारी रख सकता हूं। अगर मैं ए में कोई बदलाव करता हूं, तो मैं निम्नलिखित तरीकों से शाखाओं के ग्राफ का पुनर्निर्माण करता हूं:

  1. ए के नए शीर्ष पर शाखा टी बनाएं
  2. बी के साथ टी विलय करें
  3. सी पर टी सी rebase
  4. शाखा टी हटाएं

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


गिट पुश उत्पत्ति का उपयोग न करें - किसी भी परिस्थिति के तहत मिररर।

यह नहीं पूछता कि क्या आप सुनिश्चित हैं कि आप यह करना चाहते हैं, और आप बेहतर सुनिश्चित करेंगे, क्योंकि यह आपकी सभी दूरस्थ शाखाओं को मिटा देगा जो आपके स्थानीय बॉक्स पर नहीं हैं।

http://twitter.com/dysinger/status/1273652486





git-rebase