इतनी सारी परियोजनाएं "गिट मर्ज" पर "गिट रीबेस" को क्यों पसंद करती हैं?

Question

DVCS का उपयोग करने के फायदों में से एक एडिट-कमिट-मर्ज वर्कफ़्लो (ओवर एडिट-मर्ज-कम अक्सर CVCS द्वारा लागू) है। मर्जों के स्वतंत्र भंडार में दर्ज किए जाने वाले प्रत्येक अनूठे बदलाव की अनुमति देना सुनिश्चित करता है कि DAG परियोजना की सही वंशावली को दर्शाता है।

क्यों कई वेबसाइटें "मर्ज कमिट्स से बचने" के बारे में बात करना चाहती हैं? प्री-कमिट या मर्जिंग पोस्ट-मर्ज को मर्ज नहीं करने से रिग्रेसन को अलग करना, पिछले बदलावों को वापस करना, इत्यादि मुश्किल हो जाता है?

स्पष्टीकरण के प्वाइंट: एक DVCS के लिए डिफ़ॉल्ट व्यवहार है मर्ज करता है बनाने के लिए। इतने सारे स्थान एक रैखिक विकास के इतिहास को देखने की इच्छा के बारे में क्यों बात करते हैं जो इन मर्जों को छुपाता है?

Comments

उपकरण हमेशा इसे सही नहीं मिलता है। और जब वे गलत हो जाते हैं, तो हे लड़के, क्या वे इसे गलत पाते हैं।

— Oded

@ क्या आप स्वचालित मर्ज कमिट्स का जिक्र कर रहे हैं (जैसे कि उनके द्वारा बनाया गया git pull)? मैं देख सकता हूं कि यह समस्याग्रस्त क्यों हो सकता है, लेकिन मेरा सवाल सभी मर्ज कमिट के बारे में है।

— Jace Browning

संभव जटिल समस्याओं का संकेत है? "विलय और विद्रोह के कारण सटीक समान संघर्षों का कारण होना चाहिए, उन अंतर्निहित संघर्षों के लिए जो एक मानव को हल करना चाहिए (अर्थात दो डेवलपर्स कोड की एक ही लाइन को बदलते हैं) ..."

— gnat

एक विचार जो मैंने अपने उत्तर को पोस्ट करने के बाद कहा था, कि IMO एक उत्तर के रूप में बिल्कुल फिट नहीं है: git pull --rebase == svn up(ढीले-बराबर, सख्त-समान नहीं)

— इज़्काता

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

— एंडीज स्मिथ

Answer 1

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

Comments

आप केवल एक हैं जिन्होंने मेरे प्रश्न को सही ढंग से समझा है। मैं इसे और अधिक स्पष्ट कैसे कर सकता हूं?

— जैस ब्राउनिंग

शायद "एक रैखिक विकास के इतिहास के लाभ क्या हैं?"

— कार्ल बेवेलफेल्ट

"अक्सर, आप यह सुनिश्चित करने के लिए ऐसा करेंगे कि आपके कमेंट्स रिमोट ब्रांच पर सफाई से लागू हों - शायद एक ऐसे प्रोजेक्ट में जिसमें आप योगदान करने की कोशिश कर रहे हैं लेकिन आप इसे बनाए नहीं रखते हैं। इस मामले में, आप अपना काम करेंगे। जब आप मुख्य परियोजना के लिए अपने पैच प्रस्तुत करने के लिए तैयार थे, तो एक शाखा में और फिर अपने काम को मूल / मास्टर पर फिर से लागू करें। इस तरह, अनुचर को कोई एकीकरण कार्य करने की ज़रूरत नहीं है - बस एक तेज़-फ़ॉरवर्ड या क्लीन अप्लाई। " git-scm.com/book/en/Git-Branching-Rebasing

— एंडीज़ स्मिथ

आप इसे ध्वनि की तरह बनाते हैं जैसे यह सिर्फ कॉस्मेटिक है, लेकिन यह वास्तव में व्यावहारिक है: यह समझना आसान है कि रेखीय इतिहास में जटिल डीएजी से लाइनों और विलय के साथ क्या हो रहा है।

— डेनियल हर्शकोविच

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

— आर्कगॉन

Answer 2

दो शब्दों में: git bisect

एक रैखिक इतिहास आपको बग के वास्तविक स्रोत को इंगित करने की अनुमति देता है।

---

एक उदाहरण। यह हमारा प्रारंभिक कोड है:

def bar(arg=None):
    pass

def foo():
    bar()

ब्रांच 1 कुछ रिफ्लेक्टिंग करती है जो argअब मान्य नहीं है:

def bar():
    pass

def foo():
    bar()

शाखा 2 में एक नई सुविधा है जिसका उपयोग करने की आवश्यकता है arg:

def bar(arg=None):
    pass

def foo():
    bar(arg=1)

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

ओह बकवास। यह वही है जो इसे देखता है:

(master: green)
|             \_________________________
|                \                      \
(master: green)  (branch 1: green)     (branch 2: green)
|                 |                     |
|                 |                     |
(master/merge commit: green)            |
|                         ______________/
|                        /
(master/merge commit: red)
|
...days pass...
|
(master: red)

इसलिए जब हम git bisectउस कमिट को खोजने के लिए भेजते हैं जिसने बिल्ड को तोड़ दिया है, तो यह एक मर्ज कमिट को इंगित करने जा रहा है। ठीक है, यह थोड़ा मदद करता है, लेकिन यह अनिवार्य रूप से कमिट्स के पैकेज पर इंगित करता है, एक भी नहीं। सभी पूर्वज हरे हैं। दूसरी ओर, रिबासिंग के साथ, आपको एक रैखिक इतिहास मिलता है:

(master: green)
|
(master: green)
|
(all branch 1 commits: green)
|
(some branch 2 commits: green)
|
(branch 2 commit: red)
|
(remaining branch 2 commits: red)
|
...days pass...
|
(master: still red)

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

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

---

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

Comments

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

— फिलिप

@Philip मुझे ऐसा करने में थोड़ी झिझक हो रही है, क्योंकि मैंने केवल कुछ महीनों के लिए छोटे व्यक्तिगत प्रोजेक्ट्स पर git का उपयोग किया है, कभी किसी टीम पर नहीं। लेकिन जब मैंने हाल ही में जो कुछ किया है, उस पर नज़र रखने के लिए, शाखाओं के पार आवागमन का प्रवाह देखने में सक्षम होना gitk --allबेहद उपयोगी है (विशेषकर जब से मेरे पास आमतौर पर किसी भी समय 3-ईश शाखाएं हैं, और प्रत्येक दिन मेरे मूड के आधार पर उनके बीच स्विच करता है समय)।

— इज़काता

लेकिन मर्ज समस्या है, इसलिए आप परिणाम के रूप में मर्ज कमिटमेंट चाहते हैंbisect । यदि आप गहरी खुदाई करना चाहते हैं तो यह एक blameया एक अलग के साथ आने वाले व्यक्ति को खोजने के लिए पर्याप्त आसान है bisect। एक रैखिक इतिहास के साथ, मर्ज ऑफ बुक किया जाता है, इसलिए आप अब नहीं बता सकते कि एक बुरा मर्ज समस्या थी। यह सिर्फ एक तर्क का उपयोग करने के लिए एक बेवकूफ की तरह दिखता है जो मौजूद नहीं है, खासकर अगर तर्क को हटा दिया गया था पिछले कई हिट। यह जानने की कोशिश करना कि वह ऐसा क्यों करेगा जब आप इतिहास को नष्ट कर देंगे।

— कार्ल बेवेलफेल्ट

वास्तव में इस जवाब से असहमत हैं। रिबासिंग कई बार बिसेक्ट की उपयोगिता को नष्ट कर देता है। एक रिबास के सिर के अलावा, एक रिबेस से आने वाले रन नहीं हो सकते हैं। उदाहरण: आपने A पर शाखा लगाई और B, C, D को बनाया, किसी ने E को धक्का दिया। आप B और C हैं और काम करते हैं, लेकिन E पर बगावत कर रहे हैं, तो आप B और C के अयोग्य हैं या चलाने योग्य नहीं हैं और काम नहीं करते हैं। सबसे अच्छा मामला आप हार मान रहे हैं, सबसे खराब स्थिति आपको लगता है कि बी या सी में यह मुद्दा है जब वास्तव में यह डी।

— लैन

@Izkata आप बिसेक्ट का उपयोग क्यों कर रहे हैं? क्योंकि बग / गलतियाँ होती हैं। यह एक हकीकत है। हो सकता है कि "माउस को बाईं ओर खींचना" पहले स्वचालित / मैन्युअल परीक्षण सूची का हिस्सा नहीं था और अब हम देखते हैं कि यह सुविधा टूट गई है, लेकिन हम जानते हैं कि यह काम करता था।

— लैन

Answer 3

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

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

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

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

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

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

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

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

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

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

Comments

आश्चर्यजनक रूप से कहा, श्रीमान!

— साउथपॉव हरे

यह जवाब देता है कि लोग विलय से डरते हैं, इसलिए नहीं कि विलय को इतने से ही बुरा माना जाता है।

— जय

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

— डेवॉर्ड

मैंने इस जवाब को अस्वीकार कर दिया क्योंकि यह अभी भी स्पष्ट है क्योंकि यह बिंदु से परे है, इम्हो।

— यूजीन

यह रिबेज़ बनाम मर्ज-मर्ज पर हिट नहीं लगता है।

— एंडिज स्मिथ

Answer 4

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

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

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

Comments

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

— एंडिज स्मिथ

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

— बिलचोर

ठीक है, इसलिए यदि आप सुनिश्चित नहीं हैं कि आपकी आधार रेखा क्या है, अर्थात, क्या आपने जो पहले से ही विलय के लिए तैयार है बदल दिया है वह 'सही बात' है तो फिर से न करें।

— एंडिज स्मिथ

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

— एंडिज स्मिथ

Answer 5

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

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

दो उपर्युक्त समस्याओं को एक साथ लें, और आप अपने आप को एक ऐसी स्थिति में पा सकते हैं जहां यह सरल और आसान है कि हर कोई एक ही ट्रंक से बाहर काम करे और लगातार संघर्षों को हल करें क्योंकि वे ऊपर आते हैं, भले ही वे सक्रिय विकास को थोड़ा धीमा कर दें।

Comments

यह जवाब देता है कि लोग विलय से डरते हैं, इसलिए नहीं कि विलय को इतने से ही बुरा माना जाता है।

— जे

तो, यह ट्रंक आप को संदर्भित करता है, क्या इसमें रिबास शामिल है? कृपया कृपया।

— एंडिज स्मिथ

@AndyzSmith "ट्रंक" git की "मास्टर" शाखा के समतुल्य के लिए svn का शब्द है

— इज़काता

@ इज़काटा तो यह जवाब या तो मर्ज या रिबेज का उपयोग नहीं करने की वकालत करता है?

— एंडीज स्मिथ

@AndyzSmith हाँ, यह है कि मैं इसे कैसे पढ़ा, भी। और मैं इससे असहमत हूं; सुझाए गए फैशन में 7 अन्य डेवलपर्स के साथ एक टीम पर काम करने के बाद, मैं इसका सुझाव नहीं देता। हमें सुविधा शाखाओं का उपयोग करना चाहिए जितना हमने किया, लेकिन उनमें से अधिकांश विलय से डरते हैं (जैसा कि ब्रायनहॉल उनके जवाब में मिलता है)।

— इज़्काता

Answer 6

एक अतिरिक्त प्रासंगिक बिंदु यह है: रीबेसिंग के साथ मैं अपनी रिलीज़ शाखा में आसानी से चेरी चुन सकता हूं या किसी सुविधा को वापस ला सकता हूं।

Comments

यह इस पर विस्तृत है?

— अकवाल

यकीन है कि :-) प्रवाह में, हम नियमित रूप से नई रिलीज शाखाएँ बनाते हैं। यदि निर्माण के बाद, विकास शाखा में एक बग तय किया जाता है, तो हम git cherry-pick -x <commit>इसे रिलीज शाखा में लागू करने के लिए उपयोग करते हैं। या, हम रिलीज के लिए कुछ पूर्ववत करना चाह सकते हैं, साथ git revert <commit>। यदि <commit>मर्ज है, तो यह बालों को मिलता है। यह है मुझे पता है, लेकिन ऐसा करने के लिए आसान नहीं के रूप में जहाँ तक संभव हो। रिबास का उपयोग करते समय, हर 'मर्ज' एक विशाल लेकिन नियमित रूप से प्रतिबद्ध, आसानी से चेर-पिकबल और रिवर्टेबल होता है।

— ब्रूनो शेपर

Answer 7

किसी भी उत्तर में तीन बातें नहीं कही गई हैं:

• एक शाखा के अंदर मुश्किल:

  • मर्ज किए जाने पर ब्रांच में कमिटेड जोड़ी के बीच मुश्किलें बेहद मुश्किल हो जाती हैं।

• एक समय में एक आइटम मर्ज करना:

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

• पुश से पहले सफाई:

  • यदि आपने कोई गलती की है जिसे आपको बाद में ठीक करने की आवश्यकता है, यदि आपने इंटरैक्टिव रिबास को धक्का नहीं दिया है, तो आपको कमिट / विभाजन / परिवर्तन / संचार करने की अनुमति देगा। जब आप अभी भी कर सकते हैं कि यदि आप विलय कर चुके हैं, तो यह बहुत मुश्किल हो जाता है यदि आप मर्ज सीमा के पार / विभाजन / परिवर्तन / स्थानांतरित करना चाहते हैं।