2012-04-19 9 views
6

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

पर्सफोर्स में, मैंने इन फ़ाइलों के लिए "चेंजलिस्ट" बनाया होगा और इसे "COMMIT नहीं करें" के रूप में लेबल किया होगा। गिट में इसके बराबर क्या होगा? एक शाखा काम नहीं करती है क्योंकि इन डीबग-केवल संशोधनों को वर्तमान में किए जा रहे अन्य परिवर्तनों के साथ मौजूद होना चाहिए।

उत्तर

0

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

5

- अप्यूम-अपरिवर्तित विकल्प को देखो। एक ब्लॉग आलेख about this है जो चीजों को अच्छी तरह से बताता है। और this one जो बाद में ऐसी अनदेखी फ़ाइलों को ढूंढने का उल्लेख करता है।

+0

दूसरे लिंक में अच्छा और आसान स्पष्टीकरण है –

1

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

0

आप वास्तव में उन फ़ाइलों को अनदेखा नहीं करना चाहते हैं, लेकिन उन परिवर्तनों को अनदेखा करें।

मैं देख रहा हूँ यहाँ दो समाधान:

  1. पुनर्स्थापित प्रमुख

आदेश मैं ऐसी स्थिति के लिए उपयोग कर रहा हूँ है:

git checkout -- file ... 
सभी फाइलों को आप डीबगिंग के लिए संशोधित साथ

उद्देश्य।

यह फ़ाइल को HEAD के रूप में पुनर्स्थापित करता है। फिर आप सुरक्षित रूप से अपना git commit -a या जो भी कर सकते हैं।

  1. बताओ तुम्हें पूछने के लिए क्या (प्रति फ़ाइल)

    Git -p जोड़ने प्रतिबद्ध करने के लिए बदल जाता है Git।

#1085162 देखें।

लेकिन आपको अभी भी अपने डिबगिंग कोड को हटाने की आवश्यकता होगी।

0

उन समाधानों में से एक जो सार्वभौमिक नहीं है लेकिन कुछ वर्कफ़्लो परिदृश्यों के लिए उपयुक्त हो सकता है गिट के प्री-प्रतिबद्ध फ़िल्टर (manual, manual + samples) को लागू करना है।संक्षेप में, यह केवल एक प्रीप्रोकैसिंग उपकरण है जिसे वास्तविक प्रतिबद्धता से पहले सभी प्रतिबद्ध फ़ाइलों पर बुलाया जाएगा। आपके पास //<NOCOMMIT ... //NOCOMMIT> या जो भी आपको पसंद है, कुछ पैटर्न को अलग करने के लिए यह तंत्र हो सकता है। दोष यह है कि किसी भी प्रतिबद्धता को रीसेट करने या यहां तक ​​कि खींचने/विलय करने पर इन डीबग लाइन गायब हो सकती हैं (मैंने इसे जांच नहीं लिया)।

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

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