AI سے بنی ایپ کے ساتھ Git کیسے استعمال کریں

AI سے بنی ایپ کے ساتھ Git استعمال کرنے کے لیے پروجیکٹ کو ایک Git repository سے جوڑیں، ہر کامیاب تبدیلی کے بعد commit کریں، ایک لائن کا پیغام لکھیں کہ کیا بدلا، اور .gitignore کے ذریعے secrets کو باہر رکھیں۔ کسی خطرناک تبدیلی کے لیے branch استعمال کریں، اگر کوئی اور کوڈ بدل چکا ہو تو دوبارہ prompt دینے سے پہلے pull کریں، اور جب AI کچھ توڑ دے تو اس گڑبڑ پر مزید prompt دینے کے بجائے آخری اچھے commit پر واپس جائیں۔

Git version control ہے: آپ کے کوڈ کے ہر محفوظ ورژن کی history۔ GitHub ایک ویب سائٹ ہے جو Git repositories آن لائن رکھتی ہے۔ اگر یہ نیا ہے تو GitHub کیا ہے سے شروع کریں۔ یہ گائیڈ ان عادات کے بارے میں ہے جو Git کو مفید بناتی ہیں جب زیادہ تر کوڈ AI لکھ رہا ہو۔

AI کے ساتھ Git زیادہ اہم کیوں ہے

ایک AI ایک ہی جواب میں بیس فائلیں بدل سکتا ہے۔ یہ تیز ہے، اور اس کا مطلب یہ بھی ہے کہ ایک prompt خاموشی سے کوئی ایسی چیز توڑ سکتا ہے جو کل آپ نے ٹیسٹ کی تھی۔ Git آپ کو یہ دیتا ہے:

• واپسی کا راستہ۔ کوئی بھی commit کیا ہوا ورژن بحال کیا جا سکتا ہے۔
• تبدیلیوں کا ریکارڈ۔ آپ دیکھ سکتے ہیں کہ کسی prompt نے کون سی فائلیں اور کون سی لائنیں چھوئیں۔
• بلڈر سے باہر کی کاپی۔ آپ کا کوڈ ایسی جگہ رہتا ہے جس پر آپ کا کنٹرول ہو۔
• معیاری handoff۔ کوئی بھی developer، host یا tool کسی Git repository سے کام کر سکتا ہے۔

مرحلہ 1: repository جوڑیں

GitHub یا کسی ملتی جلتی سروس پر repository بنائیں (عموماً private)، اور اپنے پروجیکٹ کو اس سے جوڑیں۔ زیادہ تر AI ایپ بلڈرز جو Git سپورٹ کرتے ہیں یہ کام ایک settings صفحے کے “Connect GitHub” بٹن سے کرواتے ہیں۔ اگر آپ کے بلڈر میں یہ نہیں ہے تو آپ کوڈ export کر کے خود push کر سکتے ہیں، یا ایک بار کسی developer سے سیٹ اپ کروا سکتے ہیں۔

پہلا push کرنے سے پہلے یقینی بنائیں کہ repository وہ چیزیں نظر انداز کرے جو اس میں نہیں ہونی چاہئیں:

.gitignore فائل چیک کریں۔ یقینی بنائیں کہ وہ .env فائلوں، node_modules، build output فولڈرز اور secrets والی ہر فائل کو خارج کرے۔ بتائیں آپ نے کیا شامل کیا۔

مرحلہ 2: ہر کامیاب تبدیلی کے بعد commit کریں

Commit ایک محفوظ شدہ snapshot ہے جس کے ساتھ ایک پیغام ہوتا ہے۔ سب سے اہم عادت یہ ہے: جب کوئی چیز کام کرے، تو اگلی چیز مانگنے سے پہلے commit کریں۔

1. ایک تبدیلی کا prompt دیں۔
2. preview میں چیک کریں۔
3. اگر کام کرے تو ایک پیغام کے ساتھ commit (یا sync) کریں۔
4. پھر آگے بڑھیں۔

چھوٹے commits کا مطلب ہے کہ جب کچھ ٹوٹے تو آپ جانتے ہیں کہ کون سی تبدیلی نے توڑا، اور اسے واپس کرنے سے دوسرا کام ضائع نہیں ہوتا۔

مرحلہ 3: ایسے پیغام لکھیں جو بعد میں پڑھے جا سکیں

ایک اچھا پیغام ایک لائن میں بتاتا ہے کہ کیا بدلا اور کیوں:

• اچھا: Add CSV export to the orders page
• اچھا: Fix booking form rejecting times after 6pm
• بے کار: update، changes، fix stuff

آپ AI سے یہ لکھوا بھی سکتے ہیں:

آخری commit کے بعد کی تبدیلیوں کا ایک لائن میں خلاصہ لکھیں، فعل سے شروع کریں، 70 حروف سے کم۔

مرحلہ 4: خطرناک کام کے لیے branches استعمال کریں

Branch کام کی ایک الگ لائن ہے۔ آپ کسی branch پر کچھ آزما سکتے ہیں، اور اگر وہ کام نہ کرے تو مرکزی ورژن کو چھوئے بغیر اسے چھوڑ سکتے ہیں۔

Branch استعمال کریں جب:

• تبدیلی بڑی ہو (redesign، نیا payment flow، database کی تبدیلی)۔
• کوئی اور اسی ایپ پر کام کر رہا ہو۔
• آپ چاہتے ہوں کہ لائیو ہونے سے پہلے کوئی اس تبدیلی کا جائزہ لے۔

جب کام مکمل اور ٹیسٹ ہو جائے تو اسے مرکزی branch میں merge کیا جاتا ہے۔ GitHub پر یہ عموماً pull request کے ذریعے ہوتا ہے، یعنی ایک صفحہ جو جائزے کے لیے تبدیلیاں دکھاتا ہے۔ اگر آپ کا بلڈر صرف ایک branch sync کرتا ہے تو developer GitHub کی طرف سے branches سنبھال سکتا ہے۔

مرحلہ 5: محفوظ طریقے سے واپس کریں

جب کوئی prompt ایپ توڑ دے تو اس پر پانچ مزید prompts دینے کی خواہش کو روکیں۔ آخری اچھے ورژن پر واپس جائیں اور زیادہ واضح prompt آزمائیں۔

• بلڈر میں: اگر اس میں checkpoint یا restore کی سہولت ہو تو وہ استعمال کریں۔
• Git میں: git revert ایک نیا commit بناتا ہے جو پرانا commit واپس کرتا ہے، اور history محفوظ رہتی ہے۔ جن کوڈ کو دوسرے pull کر چکے ہوں، ان کے لیے یہی محفوظ انتخاب ہے۔
• مشترکہ branch پر git push --force سے بچیں جب تک آپ کو پوری وجہ معلوم نہ ہو۔ یہ سب کے لیے history دوبارہ لکھ دیتا ہے۔

اگر آپ کو یقین نہ ہو تو پوچھیں:

آخری تبدیلی نے login صفحہ توڑ دیا ہے۔ مجھے دکھائیں کہ پچھلے commit کے مقابلے میں اس نے کون سی فائلیں بدلیں، اور ہر تبدیلی نے کیا کیا۔ ابھی کچھ نہ بدلیں۔

مرحلہ 6: prompt دینے سے پہلے pull کریں

اگر کوئی developer یا کوئی اور tool GitHub پر کوڈ بدلتا ہے تو AI بلڈر کو اس کا علم نہیں ہوتا جب تک آپ وہ تبدیلیاں pull نہ کریں۔ پرانے کوڈ پر prompt دینے سے conflicts اور کام کا ضیاع ہوتا ہے۔

• ہر سیشن کے آغاز پر pull کریں۔
• طے کریں کہ کون کیا بدلتا ہے، اور ایک ہی وقت میں دونوں طرف سے ایک ہی فائلوں میں تبدیلی نہ کریں۔
• اگر آپ کو merge conflict ملے (ایک ہی لائنوں میں دو تبدیلیاں)، تو developer یا AI سے کہیں کہ اسے حل کرے اور انتخاب کی وضاحت کرے۔

مثالی prompts

شروع کرنے سے پہلے: میرے آخری سیشن کے بعد repository میں کیا بدلا؟ commits کا خلاصہ دیں۔

اگلی تبدیلی الگ سے کریں: ہر invoice میں ایک “Duplicate” بٹن شامل کریں۔ کچھ اور نہ بدلیں، تاکہ میں اسے الگ commit کر سکوں۔

چیک کریں کہ کوئی API key، password یا .env فائل Git میں track نہیں ہو رہی، پرانے commits سمیت۔ صرف فائل کے نام بتائیں، قیمتیں نہیں۔

عام غلطیاں

• secrets commit کرنا۔ ایک بار key Git history میں جائے تو فائل ڈیلیٹ کرنے کے بعد بھی وہ ظاہر ہو جاتی ہے۔ اسے rotate کریں۔
• ہفتے میں ایک بڑا commit۔ آپ ایک تبدیلی واپس نہیں کر سکتے بغیر باقی سب کو واپس کیے۔
• “update” جیسے پیغام۔ History یہ ڈھونڈنے کے لیے بے کار ہو جاتی ہے کہ کیا ٹوٹا۔
• پرانے کوڈ پر prompt دینا۔ جب کوئی اور بدل رہا ہو تو پہلے pull کریں۔
• غلطی ٹھیک کرنے کے لیے force push کرنا۔ یہ دوسروں کا کام مٹا سکتا ہے۔ اس کے بجائے revert کریں۔
• node_modules commit کرنا۔ یہ بہت بڑا ہوتا ہے اور lock فائل سے ویسے بھی دوبارہ بن جاتا ہے۔

چیک لسٹ

• پروجیکٹ ایک private repository سے جڑا ہے۔
• .gitignore میں .env، node_modules، build output اور secrets شامل ہیں۔
• میں ہر کامیاب تبدیلی کے بعد commit کرتا ہوں۔
• Commit پیغامات ایک لائن میں بتاتے ہیں کہ کیا بدلا۔
• بڑی یا خطرناک تبدیلیاں branch پر ہوتی ہیں اور ان کا جائزہ لیا جاتا ہے۔
• جب کوئی اور کوڈ بدل رہا ہو تو میں prompt سے پہلے pull کرتا ہوں۔
• میں checkpoints یا git revert سے واپس کرتا ہوں، force push سے نہیں۔
• جو key کبھی commit ہوئی ہو وہ rotate ہو چکی ہے۔

Mythex پر Git

Mythex ہر کامیاب agent turn کے بعد ایک git checkpoint محفوظ کرتا ہے، اور Revert to this point پروجیکٹ کو اس نقطے پر واپس لے جاتا ہے، یعنی وہ بلڈر کی طرف سے 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 اور self-host کیسے کریں۔

سوالات