देखिए कि दो संस्करणों के बीच ठीक-ठीक क्या बदला।
दो पाठ या किसी फ़ाइल के दो संस्करणों की तुलना करें और ठीक-ठीक देखें कि क्या बदला: पंक्तिबद्ध स्तंभ, हर पंक्ति के भीतर बदले हुए शब्द उभरे हुए, और लागू करने लायक एकीकृत पैच।
अभी कोई तुलना नहीं
दोनों ओर एक-एक संस्करण रखें और तुलना दबाएँ। सब कुछ इसी टैब के भीतर होता है — कुछ भी भेजा नहीं जाता।
यह कैसे काम करता है
दोनों संस्करण लाएँ
उन्हें चिपकाएँ, दो फ़ाइलें छोड़ें, या किसी दूसरे औज़ार से एक भिजवा लें। कुछ भी भेजा नहीं जाता, और अभी तुलना शुरू भी नहीं हुई।
तय करें कि बदलाव किसे माना जाए
पंक्तियाँ, शब्द या अक्षर; इंडेंट, छोटे-बड़े अक्षर या खाली पंक्तियाँ अनदेखी करें। फिर तुलना दबाएँ — महँगा चरण तभी चलता है जब आप कहें।
परिणाम पढ़ें
पंक्तिबद्ध स्तंभ, जिनमें दोबारा लिखे शब्द उभरे हों, अछूते खंड मुड़े हुए, और एक ही कुंजी से अगले बदलाव पर छलाँग।
साथ ले जाएँ
ऐसा एकीकृत पैच जिसे git apply स्वीकार करता है, अपने आप में पूर्ण HTML रिपोर्ट, या संशोधित पाठ सीधे किसी दूसरे औज़ार में।
मायर्स, रैखिक स्मृति में
क्लासिक O(ND) एल्गोरिद्म, «बाँटो और जीतो» परिष्कार के साथ। दोनों फ़ाइलें कितनी भी दूर हों, स्मृति सपाट रहती है: 5,000 पंक्तियाँ लगभग 7 मि.से. में, जबकि सामान्य LCS मैट्रिक्स 590 मि.से. और 200 एमबी माँगती है।
शब्द-स्तर पर उभार
दोबारा लिखी पंक्ति की दूसरी बार, शब्द-दर-शब्द तुलना होती है, इसलिए वही तीन अक्षर जगमगाते हैं जो सचमुच हिले — न कि लाल का पूरा खंड हरे के पूरे खंड के सामने।
इंडेंट वैकल्पिक है
फ़ाइल दोबारा इंडेंट कीजिए और अक्षरशः तुलना हर एक पंक्ति को अलग बता देगी। अंत के रिक्त स्थान, सारे रिक्त स्थान, अक्षरों का आकार या खाली पंक्तियाँ अनदेखी कीजिए और केवल असली बदलाव बचते हैं।
अछूते खंड मुड़ जाते हैं
4,000 पंक्तियों की फ़ाइल में एक बदलाव का मतलब 4,000 पंक्तियाँ खंगालना नहीं होना चाहिए। एक, तीन या आठ पंक्तियों का संदर्भ रखिए और किसी भी मुड़े खंड को एक क्लिक में खोलिए।
मेल खुद तय कीजिए
जब दो खिसके हुए खंड गलत जोड़े बना लें, दोनों ओर एक-एक पंक्ति संख्या पर क्लिक करके उन्हें आपस में पिन कर दीजिए। उसके बाद पिन का हर पक्ष अलग हल होता है, इसलिए एक सुधार बाकी को कभी नहीं बिगाड़ता।
वाक्य-विन्यास के रंग बरकरार
बाईस व्याकरण, और वे भी तभी लदते हैं जब फ़ाइल को सचमुच ज़रूरत हो। किसी स्ट्रिंग के भीतर बदला हुआ शब्द स्ट्रिंग का रंग बनाए रखता है और ऊपर से बदलाव की पृष्ठभूमि पाता है, बजाय इसके कि एक दूसरे को मिटा दे।
ऐसा पैच जो सचमुच लगता है
सही खंड-शीर्षकों वाला असली एकीकृत डिफ़ आउटपुट, इसलिए git apply और patch उसे स्वीकार करते हैं। या ऐसी HTML रिपोर्ट निर्यात कीजिए जिसमें होस्ट करने लायक कोई फ़ॉन्ट, स्क्रिप्ट या संसाधन ही न हो।
बड़ी फ़ाइलें भी संभलती हैं
बड़ी तुलनाएँ वेब वर्कर में चली जाती हैं ताकि संपादक जवाब देते रहें, केवल पर्दे पर दिखने वाली पंक्तियाँ ही बनती हैं, और पूर्ववत करना दस्तावेज़ की नकल के बजाय बदले हुए अक्षर सहेजता है।
देखिए कि दो संस्करणों के बीच ठीक-ठीक क्या बदला।
तुलना अक्सर उसी चीज़ पर सबसे पहले चलाई जाती है जिसे साझा करने की इजाज़त ही नहीं होती: प्रमाण-पत्रों वाली कॉन्फ़िगरेशन, हस्ताक्षर से पहले का अनुबंध, चिकित्सा निर्यात, प्रतिद्वंद्वी का प्रस्ताव। DiffSnap यह गणना इसी टैब में करता है, इसलिए दोनों दस्तावेज़ उसी मशीन पर रहते हैं जहाँ आपने उन्हें खोला था।
मायर्स का एल्गोरिद्म, आपकी अपनी मशीन पर
यह तुलना मायर्स का O(ND) अंतर एल्गोरिद्म है, रैखिक-स्मृति परिष्कार के साथ, सादे JavaScript में लिखा और आपके अपने उपकरण पर चलता हुआ। न कोई अपलोड चरण, न कोई सर्वर, न कोई अनुरोध जो आपका पाठ ढोए: पृष्ठ लद जाने के बाद संपर्क काट दीजिए, सब कुछ चलता रहेगा।
उन फ़ाइलों के लिए बना तुलना औज़ार जिन्हें लोग सचमुच मिलाते हैं।
तैनाती से पहले जाँचना कि सहकर्मी ने कॉन्फ़िगरेशन में क्या छेड़ा; अनुबंध के दो मसौदों के बीच खिसकी हुई धारा ढूँढ़ना; साबित करना कि अनुवाद अपने मूल से मेल खाता है; बिना git वाली मशीन पर पैच पढ़ना; और तय करना कि दो निर्यातों में से चालू कौन-सा है।
जिन दस्तावेज़ों की तुलना करने लायक होती है वे शायद ही कभी सार्वजनिक होते हैं: कुंजियों वाली परिवेश फ़ाइलें, गोपनीयता के तहत हुए करार, ग्राहकों के आँकड़ों वाले निर्यात। उन्हें किसी होस्ट की गई तुलना सेवा में चिपकाना दोनों संस्करण पूरे के पूरे किसी और के सर्वर को सौंप देना है। यहाँ वे टैब से बाहर जाते ही नहीं, इसलिए न कुछ दर्ज होता है, न कैश होता है, न रिसता है।
अक्सर पूछे जाने वाले प्रश्न
Qयह कितनी बड़ी फ़ाइल संभाल लेता है?+
32 एमबी तक की फ़ाइलें खुलती हैं, और 512 केबी से बड़ी हर फ़ाइल बिना चेतावनी संपादक में गिरने के बजाय एक क्लिक के पीछे प्रतीक्षा करती है। लगभग 1,20,000 अक्षरों के बाद तुलना वेब वर्कर में चली जाती है ताकि पृष्ठ जवाब देता रहे। जिन दो फ़ाइलों में लगभग कुछ भी साझा नहीं है वे कार्य-सीमा से टकराती हैं और पूरी तरह दोबारा लिखी हुई बता दी जाती हैं — औज़ार यह पर्दे पर कहता है, छिपाता नहीं।
Qक्या मेरी फ़ाइलें किसी सर्वर पर भेजी जाती हैं?+
नहीं। यहाँ न कोई अपलोड है न कोई सर्वर: तुलना, रंग और हर निर्यात आपके ब्राउज़र टैब के भीतर चलते हैं। पृष्ठ लद जाने के बाद आप नेटवर्क से कट सकते हैं और काम जारी रख सकते हैं।
Qमैंने सिर्फ़ इंडेंट बदला, फिर यह सब कुछ बदला हुआ क्यों बताता है?+
क्योंकि तयशुदा रूप से हर अक्षर गिना जाता है, रिक्त स्थान और टैब समेत। रिक्त स्थान वाला विकल्प «सारे रिक्त स्थान अनदेखे करें» पर कर दीजिए, केवल असली बदलाव बचेंगे। छोटे-बड़े अक्षरों और खाली पंक्तियों के लिए भी वैसे ही विकल्प हैं।
Qक्या यह वाक्य-विन्यास को रंगता है?+
हाँ — बाईस व्याकरण, जो फ़ाइल के विस्तार या पाठ की बनावट से पहचाने जाते हैं और तभी लदते हैं जब किसी तुलना को उनकी ज़रूरत हो। वाक्य-विन्यास का रंग और बदले शब्दों का उभार साथ-साथ बनते हैं, इसलिए कोई दूसरे को नहीं ढकता।
Qक्या मैं परिणाम निर्यात कर सकता हूँ?+
हाँ। सही खंड-शीर्षकों वाला एकीकृत .patch, जिसे git apply और patch स्वीकार करते हैं; अपने आप में पूर्ण HTML रिपोर्ट जिसमें बाहर से कुछ लादना ही नहीं पड़ता; कमिट संदेश या टिकट के लिए सादे पाठ का सारांश; और अलग से संशोधित पाठ।
Qदोनों संस्करण गलत मिल गए। क्या मैं ठीक कर सकता हूँ?+
हाँ। एक ओर पंक्ति संख्या पर क्लिक कीजिए और फिर दूसरी ओर उस पंक्ति पर जिससे उसका मेल है — वह जोड़ी पिन हो जाएगी। हर पिन के पहले और बाद का हिस्सा स्वतंत्र रूप से मिलाया जाता है, इसलिए एक सुधार बाकी फ़ाइल को कभी नहीं खिसकाता।