गिट/सॉर्सेट्री मूल शाखाकरण और विलय

Question

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

हालांकि मेरी दूसरी कोशिश पर, मैं किसी भी शाखा को कल्पना नहीं कर सका, भले ही उनमें से दोनों में काम किया जा रहा था, वे एक ही शाखा में ('7 आगे' नोट के साथ), और जब मैं कुछ भी होने की कोशिश करता हूं और विलय करता हूं। उम्मीद है कि दूसरा स्क्रीनशॉट किसी के लिए यह बताने के लिए पर्याप्त है कि यहां क्या हो रहा है? यदि नहीं, तो मैं कोशिश करूंगा और कुछ और जानकारी दूंगा।

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

Answer 1

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

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

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

Answer 2

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

यह सेटिंग प्राथमिकता में गिट टैब पर पाई जाती है।

Answer 3

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

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

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

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

$ git checkout master 
$ git merge develop 

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

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

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

आखिरकार, आप गिट को हमेशा एक मर्ज प्रतिबद्ध बनाने के लिए मजबूर कर सकते हैं, हालांकि यह सख्ती से, तकनीकी रूप से आवश्यक नहीं है। कमांड लाइन में, आप फ्लैग --no-ff के साथ ऐसा नहीं कर सकते हैं, बिना किसी तेज़ आगे। ग्राफ़िकल क्लाइंट्स में एक चेकबॉक्स होगा जो एक ही चीज़ को पूरा करेगा (SourceTree में, वर्तमान में इसे "एक प्रतिबद्ध बनाएं" भले ही फास्ट-फॉरवर्ड के माध्यम से हल हो जाए)। कई (स्वयं सहित) वास्तव में केवल --no-ff के साथ विलय करने की अनुशंसा करते हैं, क्योंकि इस तरह विलय का कार्य हमेशा इतिहास में दर्ज किया जाता है, भले ही तकनीकीताएं हों, जैसे तकनीकी रूप से शाखा बिंदुओं को स्थानांतरित करना संभव हो।

Answer 4

आप को सक्षम करने से स्थायी रूप से स्रोत ट्री में गायब से शाखाओं को रोका जा सकतामें उपकरण/विकल्प "हमेशा प्रतिबद्ध बनाने के विलय के समय नहीं तेजी से आगे हैं,"।

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

इसके अलावा, मैं बात कर सुझाव देते हैं Eelke Blok 'तकनीकी जानकारी के लिए रों answer।