गिट: मैं कुछ शाखाओं को एक शाखा में अनन्य रखते हुए शाखाओं के बीच कैसे विलय करूं?

Question

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

मुझे ऐसे वेब अनुप्रयोगों में से कुछ में कुछ छोटे बदलाव करना है। मैं एक नई शाखा features बनाता हूं, और वैश्विक खोज & को अपने स्थानीय वातावरण में पथ और प्रमाण-पत्र अपडेट करने के लिए प्रतिस्थापित करता हूं। मैं वह प्रतिबद्ध करता हूँ। मैं इसे local के रूप में भी टैग करता हूं।

मैं ख़ुशी से खतरनाक हैकिंग पश्चाताप में छलांग, और एक हैरान सौ पैच के बाद, मैं master शाखा में मेरी features परिवर्तन मर्ज करना चाहते हैं, लेकिन मैं एक local प्रतिबद्ध विलय हो नहीं करना चाहती।

आगे, मैं आगे और पीछे master और features के बीच विलय हो जाएगा, और मैं चाहता हूँ localfeatures में डाल रहने के लिए, और कभी कभी master में दिखाई देते हैं।

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

क्या ऐसा करने का कोई आसान तरीका है कि मुझे याद आ रही है?

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

यह विफल होने पर, मुझे स्थिति को संभालने के लिए अधिक दृढ़, मैन्युअल-आश तरीकों में दिलचस्पी है।

Answer 1

एक तकनीकी (गिट) समाधान विशेषता विलय का उपयोग करके git attributes का उपयोग करेगा।

merge 

विशेषता merge को प्रभावित करता है कि कैसे एक फ़ाइल के तीन संस्करण जब एक फ़ाइल-स्तर मर्ज git merge दौरान आवश्यक है विलय कर दिया है।

आप ऐसा सवाल "How do I tell git to always select my local version for conflicted merges on a specific file?" इस तरह के एक विशेषता का उपयोग, जब किसी शाखा में विलय कुछ फ़ाइलों का स्थानीय संस्करण रखने के लिए मजबूर करने का एक उदाहरण में मिल जाएगा।

विशेषताओं विलय स्थापित करने के साथ समस्या यह है कि फ़ाइलें जो पथ शामिल अन्य बदली हुई कोड है, जो मैं विलय कर दिया चाहते हो सकती है

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

• विन्यास फाइल केवल नाम बदला जाएगा
• कॉन्फ़िगरेशन मान रहे हैं शामिल हैं:

  ---

  एक कम-तकनीकी समाधान को अलग करने के विन्यास विन्यास फाइल से महत्व देता होगा प्रत्येक नाम के लिए वास्तविक मानों के साथ कई फाइलें (प्रति पर्यावरण एक)।

किसी दिए गए वातावरण के लिए आवश्यक कॉन्फ़िगरेशन मान फ़ाइलों में से किसी एक के मान द्वारा वास्तविक कॉन्फ़िगरेशन फ़ाइल में नाम को प्रतिस्थापित करने के लिए एक स्क्रिप्ट का उपयोग किया जाता है।

Answer 2

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

Answer 3

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

आप भी उपयोगी उपयोगी पा सकते हैं। वास्तव में पथ नाम फिक्सअप करने के बजाय आप उन्हें दूर कर सकते हैं। यदि इस दृष्टिकोण को आजमाएं तो आप How to reverse apply a stash पर प्रश्न देखना चाहेंगे।

Answer 4

ठीक है, क्योंकि कोई जवाब अब तक एक सीधा समाधान प्रदान की है, मैं मान लेंगे कि मैं क्या करना चाहते हैं असंभव है, और कभी कभी उपयोगी समाधान के ढेर में जोड़ने के लिए:

तो आप कभी भी विकसित कर रहे हैं features शाखा, तो आप features से master, और फिर master, git revert local में विलय कर सकते हैं।

अब आप मर्ज नहीं करना चाहिए features में master, क्योंकि वह रिवर्स local भी प्रतिबद्ध विलय होगा (कहाँ local टैग संदर्भित प्रतिबद्ध है जहां आप अपने स्थानीय पर्यावरण के लिए पथ, आदि अनुकूलित है।)।

इस मामले में master एक तैनाती शाखा के प्रकार बन जाता है, केवल कभी अन्य शाखाओं से विलय प्राप्त करता है। (आदर्श रूप से, केवल features शाखा से।)

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

Answer 5

मैं अगर यह काम करेगा पता नहीं है, लेकिन:

1. बनाएँ प्रतिबद्ध है कि, config फाइल के "मास्टर" संस्करण को देखते हुए उन्हें संस्करण आप स्थानीय रूप से की जरूरत बन जाता है। एसएचए -1 नोट करें। हम इसे MAKE_LOCAL
2. कॉन्फ़िगरेशन फ़ाइलों के स्थानीय संस्करण को देखते हुए प्रतिबद्धता बनाएं, उन्हें मास्टर के लिए उपयुक्त संस्करण में बदल दें। एसएचए -1 नोट करें।हम इसे MAKE_REMOTE
3. फोन करता हूँ Git हुक का प्रयोग, जब आप के लिए प्रतिबद्ध:
   1. git cherry-pick MAKE_REMOTE (या git diff और patch का उपयोग करें)
   2. अनुमति दें शुरू करने के लिए प्रतिबद्ध
   3. git cherry-pick MAKE_LOCAL (या git diff और patch)

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

Answer 6

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

• अपनी स्थानीय शाखा कर
• स्थानीय कर -only
• विकास जारी रखने के बदलने

जब गुरु के विलय कर:

• rebase -i master अपनी शाखा से और पैच श्रृंखला के END पर स्थानीय-केवल परिवर्तन को स्थानांतरित करें।
• प्रक्रिया में किसी भी विवाद का समाधान। यदि स्थानीय-केवल परिवर्तन कॉन्फ़िगरेशन फ़ाइलों में है और आप नियमित विकास में उन्हें छू नहीं रहे हैं, तो आपको कोई समस्या नहीं होगी। यदि, अन्यथा, आपके पास कोई संघर्ष है, तो यह एक ऐसा मामला है जब आप वास्तव में उसी क्षेत्र में बदलते हैं और इसे किसी भी तरह हल करने के लिए आपके ध्यान की आवश्यकता होती है।
• जांच मास्टर

• विलय अपने स्थानीय शाखा -1:

  Git विलय स्थानीय^

इस मास्टर पिछले के अलावा स्थानीय पर मौजूद सभी परिवर्तन होने के साथ आप छोड़ देंगे एक।

यदि आपके पास एकाधिक स्थानीय = केवल परिवर्तन हैं, तो मैं आपको स्क्वैश उन्हें रिबेस के दौरान एक साथ सुझाव देता हूं।

Answer 7

इस समस्या का समाधान मेरे rebase बजाय मर्ज

इस तरह एक प्रतिबद्ध पेड़ के साथ शुरू का उपयोग करता है:

a-b-c <-- master 
\ 
    d <-- local 
    \ 
    e-f-g <-- dev 

$ Git मास्टर स्थानीय देव

 master 
     V 
    a-b-c-e'-f'-g' <-- dev 
    \ 
     d <-- local 

$ --onto rebase गिट चेकआउट मास्टर

$ गिट विलय dev

   master 
       V 
    a-b-c-e'-f'-g' <-- dev 
    \ 
     d <-- local 

$ Git --onto मास्टर मास्टर स्थानीय

   master 
       V 
    a-b-c-e'-f'-g' <-- dev 
       \ 
       d' <-- local 

$ Git शाखा -f

   master 
       V 
    a-b-c-e'-f'-g' 
       \ 
       d' <-- local 
       ^
       dev 

Answer 8

निजी तौर पर स्थानीय देव rebase, अगर मैं कुछ इस तरह करना था और के लिए जो कुछ भी था जैसा कि मैं जाता हूं, क्रेडेंशियल्स को दोबारा करने से रोकता हूं, मैं दो और शाखाएं जोड़ता हूं, जो निम्न की तरह एक व्यवस्था के साथ समाप्त होता है:

master: आपके द्वारा विरासत में प्राप्त मूल कोड

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

feature: गुरु से शाखा है, और सभी सुधारों को यहां जाना

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

जब आपको लगता है अपने फिक्स प्रकाशन के लिए तैयार हैं, तो आप feature के अपने अंतिम रिबेस, इतिहास को साफ करने के लिए अपने अंतिम परीक्षा के लिए डंप और local पुन: बनाने, master में विलय feature, और एक बार है कि नदी के ऊपर स्वीकार कर लिया है, में विलय master करना localcred और शीर्ष पर अपने क्रेडेंशियल पैच को रीबेस करें, फिर local और feature को डंप करें और फिर से खेलें और गेम को फिर से चलाएं।

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

क्या आपकी आवश्यकताओं को पूरा करता है?

Answer 9

प्रश्न एक पुराना है, लेकिन मुझे अभी भी एक अच्छा जवाब नहीं मिला है। वर्तमान में मुझे एक ही समस्या का सामना करना पड़ रहा है और नीचे इसका समाधान करने के लिए मेरा कामकाज है:

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

अब मान लें कि मुझे पहले एक स्थानीय पथ के साथ फ़ाइल में "अच्छा" संशोधन जोड़ने की आवश्यकता है, लेकिन "अच्छा" संशोधन master शाखा में चाहता था। मैं अपने परिवर्तन करता हूं जब कामकाजी प्रति local_settings के लिए एक प्रमुख है, इसे छीनें और master देखें। स्टैश एक बदलाव रखता है, जो local_settings से संबंधित है, हालांकि मैं पहले से ही master पर हूं। git stash pop कार्यशील प्रतिलिपि में स्टैश किए गए परिवर्तन को लागू करता है और मास्टर के सापेक्ष एक अंतर होने पर समाप्त होता है, लेकिन केवल हाल ही में संशोधित स्थानीय पथ को छोड़कर जो हाल ही में जोड़ा गया था और हाल ही में किए गए परिवर्तन का हिस्सा नहीं था। इसलिए इसे master शाखा में पथों को गड़बड़ किए बिना किया जा सकता है। बाद में फिर से master से local_settings पर विलय करें।