AI से बनी ऐप के साथ Git कैसे इस्तेमाल करें

किसी AI से बनी ऐप के साथ Git इस्तेमाल करने के लिए, प्रोजेक्ट को किसी Git repository से जोड़ें, हर उस बदलाव के बाद commit करें जो काम कर रहा हो, हर commit में एक पंक्ति में लिखें कि क्या बदला, और .gitignore की मदद से secrets बाहर रखें। जोखिम भरे काम के लिए branch इस्तेमाल करें, अगर कोई और code बदल रहा हो तो दोबारा prompt देने से पहले pull करें, और जब AI कुछ तोड़ दे तो उसके ऊपर और prompt देने के बजाय आखिरी अच्छे commit पर लौट जाएं।

Git एक version control है: आपके code के हर सेव किए गए version का इतिहास। GitHub एक वेबसाइट है जो Git repositories ऑनलाइन रखती है। अगर ये शब्द नए हैं, तो GitHub क्या है से शुरू करें। यह गाइड उन आदतों के बारे में है जो तब Git को उपयोगी बनाती हैं जब ज़्यादातर code AI लिख रहा हो।

AI के साथ Git क्यों ज़्यादा ज़रूरी है

AI एक ही turn में बीस फ़ाइलें बदल सकता है। यह तेज़ है, और इसका मतलब यह भी है कि एक prompt चुपचाप कुछ ऐसा तोड़ सकता है जो कल आपने जांचा था। Git आपको देता है:

वापस जाने का रास्ता। किसी भी commit किए गए version को फिर से लाया जा सकता है।
बदलावों का रिकॉर्ड। आप देख सकते हैं कि किसी prompt ने कौन सी फ़ाइलें और कौन सी lines छुईं।
Builder के बाहर एक कॉपी। आपका code ऐसी जगह रहता है जिस पर आपका नियंत्रण है।
एक मानक handoff। कोई भी developer, host या tool किसी Git repository से काम कर सकता है।

चरण 1: एक repository जोड़ें

GitHub या किसी मिलती-जुलती सेवा पर एक repository बनाएं (आमतौर पर private), और अपने प्रोजेक्ट को उससे जोड़ें। Git सपोर्ट करने वाले ज़्यादातर AI app builders यह अपनी settings वाले पेज पर “Connect GitHub” बटन से करते हैं। अगर आपके builder में ऐसा नहीं है, तो आप code export करके खुद push कर सकते हैं, या किसी developer से एक बार सेटअप करवा सकते हैं।

पहला push करने से पहले पक्का करें कि repository उन चीज़ों को अनदेखा करे जो उसमें नहीं होनी चाहिए:

.gitignore फ़ाइल जांचो। पक्का करो कि वह .env फ़ाइलों, node_modules, build output फ़ोल्डरों और secrets वाली किसी भी फ़ाइल को बाहर रखे। बताओ तुमने क्या जोड़ा।

चरण 2: हर काम कर रहे बदलाव के बाद commit करें

Commit एक message के साथ लिया गया सेव किया हुआ snapshot है। सबसे ज़रूरी आदत यह है: जब कुछ काम कर रहा हो, तभी commit करें, अगली चीज़ मांगने से पहले।

एक बदलाव के लिए prompt दें।
Preview में जांचें।
अगर काम करता है, तो message के साथ commit (या sync) करें।
फिर आगे बढ़ें।

छोटे commits का मतलब है कि कुछ टूटने पर आप जानते हैं कि किस बदलाव ने उसे तोड़ा, और उसे undo करने से आपका बाकी काम नहीं जाता।

चरण 3: ऐसे messages लिखें जो बाद में पढ़े जा सकें

अच्छा message एक पंक्ति में बताता है कि क्या बदला और क्यों:

अच्छा: Orders page में CSV export जोड़ा
अच्छा: Booking form में 6 बजे के बाद का समय रिजेक्ट होने का बग ठीक किया
काम का नहीं: update, changes, fix stuff

आप AI से इन्हें लिखवा भी सकते हैं:

पिछले commit के बाद के बदलावों का एक पंक्ति में सार लिखो, किसी क्रिया (verb) से शुरू करो, 70 अक्षरों से कम में।

चरण 4: जोखिम भरे काम के लिए branch इस्तेमाल करें

Branch काम की एक अलग लाइन है। आप किसी बात को branch पर आज़मा सकते हैं, और अगर वह नहीं चलती, तो मुख्य version को छुए बिना उसे छोड़ सकते हैं।

Branch तब इस्तेमाल करें जब:

बदलाव बड़ा हो (redesign, नया payment flow, database में बदलाव)।
कोई और उसी ऐप पर काम कर रहा हो।
आप चाहते हैं कि लाइव होने से पहले कोई बदलाव review हो।

जब काम पूरा और जांचा हुआ हो, तो उसे मुख्य branch में merge किया जाता है। GitHub पर यह आमतौर पर एक pull request के ज़रिए होता है, यानी एक ऐसा पेज जो review के लिए बदलाव दिखाता है। अगर आपका builder सिर्फ़ एक branch sync करता है, तो branch का काम GitHub की तरफ़ कोई developer संभाल सकता है।

चरण 5: सुरक्षित तरीके से undo करें

जब कोई prompt ऐप तोड़ दे, तो उसके ऊपर पांच और prompts देने की इच्छा को रोकें। आखिरी अच्छे version पर लौटें और एक ज़्यादा साफ़ prompt आज़माएं।

Builder में: उसकी checkpoint या restore सुविधा इस्तेमाल करें, अगर है।
Git में: git revert एक नया commit बनाता है जो पुराने commit को उलट देता है, और history सुरक्षित रहती है। जिन code को दूसरों ने pull कर लिया हो, उसके लिए यही सुरक्षित तरीका है।
साझा branch पर git push --force से बचें, जब तक आप ठीक-ठीक न जानते हों कि ऐसा क्यों ज़रूरी है। यह सबके लिए history फिर से लिख देता है।

अगर आप पक्का नहीं हैं, तो पूछें:

आखिरी बदलाव ने लॉगिन पेज तोड़ दिया है। पिछले commit की तुलना में बताओ कि उसने कौन सी फ़ाइलें बदलीं, और हर बदलाव ने क्या किया। अभी कुछ मत बदलो।

चरण 6: prompt देने से पहले pull करें

अगर कोई developer या दूसरा tool GitHub पर code बदलता है, तो AI builder को तब तक पता नहीं चलता जब तक आप वे बदलाव pull न करें। पुराने code पर prompt देने से conflicts और काम खोने की नौबत आती है।

हर session की शुरुआत में pull करें।
तय करें कि कौन क्या बदलेगा, और एक ही समय पर दोनों तरफ़ से एक ही फ़ाइलें न बदलें।
अगर आपको merge conflict मिले (एक ही lines पर दो बदलाव), तो developer या AI से उसे सुलझाने और चुनाव समझाने को कहें।

उदाहरण prompts

शुरू करने से पहले: मेरे पिछले session के बाद repository में क्या बदला? commits का सार बताओ।

अगला बदलाव अकेले करो: हर invoice में एक “Duplicate” बटन जोड़ो। कुछ और मत बदलो, ताकि मैं इसे अलग से commit कर सकूं।

जांचो कि Git में कोई API key, password या .env फ़ाइल track नहीं हो रही, पिछले commits सहित। सिर्फ़ फ़ाइलों के नाम बताओ, values नहीं।

आम गलतियाँ

Secrets commit करना। एक बार key Git history में चली जाए तो फ़ाइल हटाने के बाद भी वह उजागर रहती है। उसे बदल दें।
हफ़्ते भर में एक बड़ा commit। एक बदलाव को undo करने के लिए आपको सारे बदलाव undo करने पड़ते हैं।
“update” जैसे messages। फिर history यह ढूंढने में बेकार हो जाती है कि क्या टूटा।
पुराने code पर prompt देना। कोई और बदलाव कर रहा हो तो पहले pull करें।
गलती सुधारने के लिए force-push करना। यह दूसरों का काम मिटा सकता है। इसके बजाय revert करें।
node_modules commit करना। यह बहुत बड़ा होता है और वैसे भी lock file से दोबारा बन जाता है।

चेकलिस्ट

प्रोजेक्ट एक private repository से जुड़ा है।
.gitignore में .env, node_modules, build output और secrets बाहर रखे गए हैं।
मैं हर काम कर रहे बदलाव के बाद commit करता हूँ।
Commit messages एक पंक्ति में बताते हैं कि क्या बदला।
बड़े या जोखिम भरे बदलाव branch पर जाते हैं और review होते हैं।
जब कोई और code बदल रहा हो तो मैं prompt देने से पहले pull करता हूँ।
मैं checkpoints या git revert से undo करता हूँ, force-push नहीं।
जो key कभी commit हुई थी, उसे बदल दिया गया है।

Mythex पर Git

Mythex हर सफल agent turn के बाद एक git checkpoint सेव करता है, और Revert to this point प्रोजेक्ट को उस बिंदु पर वापस ले जाता है, यानी वही builder-side undo जो चरण 5 में बताया गया है। देखें Iterate without rebuilding।

Pro प्लान पर, GitHub sync प्रोजेक्ट settings से एक repository जोड़ता है ताकि आप उसके साथ push और pull कर सकें, और export प्रोजेक्ट को डाउनलोड करता है जिसमें secrets और node_modules शामिल नहीं होते। देखें GitHub, export, and import। किसी developer को प्रोजेक्ट सौंपने से पहले GitHub जोड़ना handoff को कहीं आसान बनाता है, देखें AI से बनी ऐप पर developer के साथ कैसे काम करें और AI से बनी ऐप को export करके खुद होस्ट कैसे करें।

सवाल

अगर मेरे AI ऐप builder में checkpoints हैं, तो क्या मुझे Git चाहिए?

Checkpoints आपको build करते समय undo की सुविधा देते हैं। Git builder के बाहर आपके code की एक कॉपी रखता है, एक ऐसा इतिहास देता है जिसे दूसरे लोग पढ़ सकते हैं, और उसी code पर किसी developer या दूसरे tool के काम करने का एक मानक तरीका देता है। अगर ऐप आपके लिए मायने रखती है, तो दोनों इस्तेमाल करें।

AI के साथ build करते समय मुझे कितनी बार commit करना चाहिए?

हर उस बदलाव के बाद जो काम कर रहा हो, आमतौर पर हर सफल prompt या छोटे prompts के समूह के बाद। छोटे commits से यह पता लगाना आसान होता है कि किस एक बदलाव ने कुछ तोड़ा और उसे undo करना भी आसान होता है।

Git में कभी क्या commit नहीं करना चाहिए?

API keys, passwords, असली values वाली .env फ़ाइलें, और installed dependencies के फ़ोल्डर जैसे node_modules। इन्हें अपनी पहली commit से पहले .gitignore में डालें, और जो key कभी commit हो गई हो, उसे बदल (rotate) दें।

क्या मैं GitHub पर code बदल सकता हूँ और AI के साथ build करना जारी रख सकता हूँ?

हाँ, अगर आपका builder GitHub से बदलाव pull कर सकता है। AI से दोबारा prompt देने से पहले pull करें, ताकि AI नवीनतम code पर काम करे, और दोनों तरफ़ से एक ही फ़ाइलों को एक साथ बदलने से बचें।