स्रोत स्वरूपण को बदलते समय प्रतिबद्ध?

Question

क्या यह तब भी प्रतिबद्ध है जब आप व्हाइटस्पेस, कोड स्वरूपण इत्यादि जैसी चीज़ों को बदल रहे हों?

Answer 1

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

उस ने कहा, आपको इन प्रकार के परिवर्तनों को कम से कम रखने की कोशिश करनी चाहिए, और केवल तब ही करें जब यह आवश्यक हो और आपकी कंपनी/समुदाय/परियोजना/आदि में जो भी कोडिंग मानकों का उपयोग किया जा सके,

Answer 2

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

यदि यह "आपका" कोड नहीं है (यानी कुछ अन्य स्वरूपण मानक के साथ कुछ अन्य रेपो आपको जो भी कर रहे हैं उसे वापस विलय करना होगा), तो आप git attribute filter driver, और इसकी धुंध/साफ तंत्र का लाभ उठा सकते हैं।

^{(स्रोत: Pro Git book: Customizing Git - Git Attributes)}

आप धब्बा चरण के दौरान कोड को अपने प्रारूप लागू हो सकते हैं, और स्वच्छ चरण के दौरान आम प्रारूप मानक फिर से लागू।

Answer 3

हाँ! हाँ! एक अलग प्रतिबद्धता के रूप में, कृपया! (इस प्रकार के संपादन बहुत सारे कोड को छूते हैं, और लोगों को यह जानने की ज़रूरत है कि कोई प्रतिबद्ध/परिवर्तन/पैच/जो कुछ भी वास्तविक रूप से सुधार के कारण है, वास्तविक कोड के लिए कोई बदलाव नहीं है।)

Answer 4

जी 'दिन,

हां। लेकिन यह कृपया के रूप में एक समर्पित बताते हुए एक संदेश है कि आप

• बदली हुई स्वरूपण है साथ प्रतिबद्ध,
• एक कोड फ़ॉर्मेटर, उदा के माध्यम से कोड को चलाने Perltidy, सेटिंग वास्तव में इस्तेमाल किया बारे में एक नोट के साथ,
• आदि

कुछ भी नहीं है कार्यात्मक अपडेट इसलिए संस्करणों में एक diff कर एक गरीब S/N अनुपात प्रदान करता है के साथ संयुक्त स्वरूपण परिवर्तन होने से भी बदतर!

एक तरफ, मैं सोच रहा हूं कि आप मौजूदा कोड के स्वरूपण में परिवर्तन क्यों कर रहे हैं। अगर यह पहले स्थान पर खराब रूप से स्वरूपित किया गया था तो इसे चेक नहीं किया जाना चाहिए था!

कोई है जो कोई अन्य अन्य कारण के लिए अच्छी तरह फ़ॉर्मेट स्रोत को बदलने से माध्यम से चला जाता के साथ काम करने से भी बदतर कुछ भी नहीं है: ब्रेसिज़

• उन्हें लगता है कि "अगर" बयान की लाइन पर हैं, या
• वे "elses cuddled" नापसंद करते हैं, या
• आदि
• आदि

इस तरह के धार्मिक अभिव्यक्ति की " एक सच्ची शैली "आमतौर पर एक टीम में काम करने में कोडिंग अनुभव और अनुभव की कमी पर विश्वास करती है।

HTH

चियर्स,

Answer 5

जवाब पहले से ही यहाँ का कारण बताते हुए यह स्वरूपण परिवर्तन प्रतिबद्ध करने के लिए एक समस्या हो सकती का एक अच्छा काम करते हैं। मुझे लगता है कि फ़ाइल को सहेजते समय फ़ॉर्मेटिंग परिवर्तन को कम करने के दौरान एक समाधान अच्छी तरह से स्वरूपित कोड देखने की अनुमति देने के लिए एक समाधान संपादक समर्थन होगा।

मैं में इस बारे में एक संबंधित प्रश्न पूछा है ...

• Is there a text editor that will "pretty print" for display without changing the underlying text?

किसी भी अच्छे जवाब वहाँ आते हैं, इस सवाल के दर्शकों को भी रुचि हो सकती है।