2016-03-16 10 views
14

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

जब मैं इस, मेरे अर्ध स्वचालित तंत्र करना अप्रतिबद्ध परिवर्तन और मर्ज ना किए गए शाखाओं को खोजने के लिए अक्सर झूठे सकारात्मक दिखाई देते हैं:

  • अगर मैं परिवर्तन अप्रतिबद्ध छोड़ देते हैं, या सिर्फ गंदे के रूप में मंचन मेरी चेकर स्क्रिप्ट झंडे तो, ऊपर रेपो।
  • यदि मैं उन्हें "अस्थायी परिवर्तन प्रतिबद्ध" के रूप में प्रतिबद्ध करता हूं, तो उन्हें 'रिमोट शाखा से पहले परिवर्तन' के रूप में ध्वजांकित किया जाता है
  • यदि मैं उन्हें बिना किसी रिमोट के एक नई शाखा पर प्रतिबद्ध करता हूं, तो उन्हें ' रिमोट के बिना शाखा '।

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

ध्यान दें कि मैं --assume-unchanged नहीं चाहता क्योंकि एक ही फ़ाइल में अक्सर अस्थायी परिवर्तन (जो मैं याद नहीं करना चाहता) और स्थायी परिवर्तन (जो मैं करता हूं), और Handling temporary changes (not to be committed) in Git के माध्यम से देख रहा है सुझाव जो इन सभी आवश्यकताओं को संबोधित करते हैं।

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

कार्यशील निर्देशिका में परिवर्तन करने वाले किसी भी दृष्टिकोण के साथ समस्या यह है कि यह लाइव सिस्टम के व्यवहार को प्रभावित करेगा - उदाहरण के लिए, हमारी लॉगिंग सिस्टम प्रत्येक 10 सेकंड या तो लॉगिंग कॉन्फ़िगरेशन के अपडेट के लिए जांचती है।

तो, मैं कैसे गिट को इंगित कर सकता हूं कि कुछ बदलाव क्षणिक हैं और उन्हें प्रतिबद्ध नहीं किया जाना चाहिए और/या विलय नहीं किया जाना चाहिए, जबकि अन्य को चाहिए?

+1

कोड को बदले में सभी बदलावों को अनवरोधित कॉन्फ़िगरेशन फ़ाइलों में बदल दिया गया है? – choroba

+0

मैं इस उपयोग के मामले में उलझन में हूं - आप कहते हैं कि आप एक लाइव सिस्टम में बदलाव कर रहे हैं, लेकिन संकेत देते हैं कि स्थानीय रूप से उस शाखा को रिमोट के रूप में नहीं रखने के आपके स्थानीय चेकर्स के साथ समस्या का कारण बनता है। क्या आप इस स्थानीय रेपो, किसी भी लाइव सेवाओं और रिमोट के बीच संबंधों के बारे में कुछ विवरण दे सकते हैं - यानी रिमोट की तुलना में स्थानीय का कार्य क्या है? – LightCC

+0

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

उत्तर

2

उन फ़ाइलों में से प्रत्येक के लिए, आप एक स्वच्छ स्क्रिप्ट सेट कर सकते हैं जो उन फाइलों की मूल सामग्री को पुनर्स्थापित करने के प्रभारी होंगे क्योंकि उन्हें प्रारंभ में चेक आउट किया गया था।
वह स्क्रिप्ट केवल अपनी सामग्री को HEAD (किसी स्थानीय परिवर्तन को छोड़कर) को पुनर्स्थापित करने के लिए git checkout -- afile निष्पादित कर सकती है।

कि स्क्रिप्ट के माध्यम से फ़ाइल की बहाली एक content filter driver के माध्यम से स्वचालित है, एक .gitattributes declaration का उपयोग कर।

https://i.stack.imgur.com/tumAc.png
("Pro Git book" से "Customizing Git - Git Attributes" से छवि))

एक बार जब आप घोषणा करते हैं कि अपने स्थानीय Git config में सामग्री filer ड्राइवर, यह स्वतः ही, git commit पर, फ़ाइल को पुनर्स्थापित करेगा।
या यह फ़ाइल को git diff/git status पर अपरिवर्तित माना जाएगा।

"Best practice - Git + Build automation - Keeping configs separate" में एक पूरा उदाहरण देखें।

+0

इस समय मैं नहीं देखता कि यह कैसे मदद करेगा, लेकिन मैं जांच करूँगा और शायद मेरे प्रश्न को अपडेट करूँगा। –

+0

@ मार्कबुथ यह कैसे * मदद * करेगा? अनुरोध के अनुसार, आपके सभी स्थानीय संशोधन को अनदेखा कर दिया जाएगा। – VonC

+0

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

1

अंधेरे में कुछ शॉट, आपके अंतिम लक्ष्य/उपयोग मामले के साथ लाइनों के बीच पढ़ने की कोशिश कर रहे हैं। यह इस बात पर निर्भर करता है कि आप अपने सिस्टम या अर्द्ध स्वचालित "रेपो स्वास्थ्य" प्रणाली में क्या बदल सकते हैं/बदलने के इच्छुक हैं।

  1. प्रणाली को संशोधित करें ताकि विन्यास आइटम है कि आप को बदलने की जरूरत दोनों एक "मास्टर/डिफ़ॉल्ट" कॉन्फ़िग फ़ाइल, और एक ट्रैक न किए गए स्थानीय/उपयोगकर्ता कॉन्फ़िग फ़ाइल है। उपयोगकर्ता कॉन्फ़िगरेशन में कोई भी सेटिंग डिफ़ॉल्ट को ओवरराइड करती है।

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

    • उदाहरण - शाखाओं कि कब्जा कुछ खास के साथ इन (हमेशा "tempsetting-", ".tmp" के साथ अंत, आदि के साथ शुरू), या उन्हें एक tmp शाखा के साथ प्रतिबद्ध नाम है, तो उन्हें टैग (फिर से , शायद कुछ विशेष नामकरण सम्मेलन के साथ)।
    • लाभ: अपने अस्थायी सेटिंग्स, रेपो में कब्जा कर रहे हैं कि वांछित है
    • नुकसान: यहाँ करने के लिए अधिक - सक्रिय रूप से सिर्फ एक कॉन्फ़िग फ़ाइल या उपयोगकर्ता सेटिंग्स की तुलना में अधिक का प्रबंधन करने की जरूरत है, आदि
+0

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

+0

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

2

एक ही फाइल अक्सर दोनों अस्थायी परिवर्तन (जो मैं के बारे में याद दिलाया जाना नहीं चाहते हैं) और स्थायी परिवर्तन (जो मैं करता हूँ)

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

अगर मैं तेज मैं एक पैच में नगण्य परिवर्तन कर दिया, और विश्लेषण से पहले यह पॉप मर्क्युरियल कतार प्रयोग करेंगे के साथ इस कर रहे थे, यह पीठ पर बाद में धक्का।

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

जो आपने यहां दिया है, उससे एक सामान्य "स्थानीय" शाखा जो कॉन्फ़िगर परिवर्तनों को समर्पित एक टिप प्रतिबद्ध करती है, इसे तब करना चाहिए जब आप "महत्वपूर्ण" परिवर्तन करते हैं, परिवर्तन को रिकॉर्ड करने के लिए इंटरैक्टिव या ऑटोस्क्वैश रीबेस का उपयोग करते हैं और उपयोग करते हैं टिप के पीछे। स्थानीय चेक की नोक में कुछ भी अनदेखा करने के लिए अपने चेकर को बताएं; स्थानीय कॉन्फ़िगरेशन को अपडेट करने के लिए, इसे बदलें और git commit --amend --no-edit इसे बदलें, या यदि आप गुम हो जाते हैं और इसे अलग से प्रतिबद्ध करते हैं तो इसे इंटरैक्टिव रीबेस या समकक्ष रूप से git reset --soft @~ के साथ स्क्वैश करें और ऐसा करने के लिए --amend --no-edit प्रतिबद्ध करें। विशेष सुविधाओं की कोई ज़रूरत नहीं है, आप जो भी काम कर रहे हैं उसके लिए आपको पूर्ण टूलकिट मिलती है। यदि विशेष रूप से सार्थक माना जाता है, तो उन्हें किसी विशेष अर्थ के साथ कुछ जगह आरक्षित करने के लिए आरक्षित रखें।

+0

हम्म, मुझे आश्चर्य है कि 'गिट-रॉट' लिखना कितना आसान होगा जो * * * महत्वपूर्ण परिवर्तन * * टिप तक प्रतिबद्ध * घुमाएगा, * महत्वपूर्ण बदलाव * उनके पीछे चल रहा है। यह इस वर्कफ़्लो को आसान बना सकता है। मुझे इसके बारे में सोचना होगा। –

+0

यदि उनकी विषय पंक्ति से काम करने योग्य हैं, तो आप निकट-ऑनलाइन क्षेत्र में हैं, एक GIT_SEQUENCE_EDITOR sed स्क्रिप्ट जैसे (उंगलियों से टेक्स्टबॉक्स चेतावनी) 'GIT_SEQUENCE_EDITOR =" sed -i '/ महत्वहीन /! {एच; $! डी} ; //! पी; $ जी; पी; डी '"गिट रिबेस -आई' इसे करना चाहिए। – jthill

+0

ओह, यह चालाक है। * 8 ') इसमें अच्छी जानकारी है [मैं गिट रिबेस कैसे चला सकता हूं - गैर-इंटरैक्टिव तरीके से इंटरैक्टिव?] (Https://stackoverflow.com/q/12394166/42473) –

संबंधित मुद्दे

 संबंधित मुद्दे