როგორ გამოვიყენოთ Git AI-ით აგებულ აპთან

AI-ით აგებული აპის Git-თან გამოსაყენებლად, დააკავშირეთ პროექტი Git რეპოზიტორიასთან, ჩაიწერეთ commit ყოველი კარგად მომუშავე ცვლილების შემდეგ, დაწერეთ ერთი სტრიქონიანი შეტყობინება იმის შესახებ, რა შეიცვალა, და საიდუმლოებები .gitignore-ით გაიტანეთ გარეთ. რისკიანი სამუშაო ცალკე branch-ში გააკეთეთ, თუ ვინმემ სხვამ შეცვალა კოდი, მოთხოვნამდე ჯერ გაწიეთ ცვლილებები (pull), და როცა AI რამეს გააფუჭებს, დაუბრუნდით ბოლო კარგ commit-ს და არ დააწეროთ ახალი მოთხოვნა ზედ არეულ კოდზე.

Git არის ვერსიების კონტროლი: ისტორია თქვენი კოდის ყოველი შენახული ვერსიის შესახებ. GitHub არის ვებსაიტი, რომელიც Git რეპოზიტორიებს ონლაინ ინახავს. თუ ეს ახალია, დაიწყეთ რა არის GitHub გვერდით. ეს სახელმძღვანელო იმ ჩვევებზეა, რომლებიც Git-ს სასარგებლოს ხდის, როცა კოდის უმეტესობას AI წერს.

რატომ არის Git უფრო მნიშვნელოვანი AI-თან ერთად

AI ერთ ბრუნში ოცდაათი ფაილის შეცვლა შეუძლია. ეს სწრაფია, მაგრამ ნიშნავს, რომ ერთმა მოთხოვნამ შეიძლება ფარულად გააფუჭოს ის, რაც გუშინ გატესტეთ. Git გაძლევთ:

• გზას უკან. ნებისმიერი ჩაწერილი ვერსია შეიძლება აღდგეს.
• ჩანაწერს იმის შესახებ, რა შეიცვალა. ხედავთ ზუსტად, რომელი ფაილები და სტრიქონები შეეხო მოთხოვნას.
• კოპიას ბილდერის გარეთ. თქვენი კოდი იმ ადგილას ინახება, რომელსაც თქვენ აკონტროლებთ.
• სტანდარტულ გადაცემას. ნებისმიერი დეველოპერი, ჰოსტინგი ან ინსტრუმენტი შეძლებს Git რეპოზიტორიიდან მუშაობას.

ნაბიჯი 1: დააკავშირეთ რეპოზიტორია

შექმენით რეპოზიტორია (ჩვეულებრივ, პირადი) GitHub-ზე ან მსგავს სერვისზე და დააკავშირეთ თქვენი პროექტი მასთან. უმეტესი AI აპ-ბილდერი, რომელიც Git-ს უჭერს მხარს, ამას პარამეტრების გვერდზე ღილაკით „Connect GitHub“ აკეთებს. თუ თქვენთან ასე არ არის, შეგიძლიათ კოდი ექსპორტით გადმოიტანოთ და თავად ატვირთოთ, ან სთხოვოთ დეველოპერს, ერთხელ დააყენოს.

პირველ ატვირთვამდე დარწმუნდით, რომ რეპოზიტორია იგნორირებს იმას, რაც მასში არ უნდა იყოს:

შეამოწმე .gitignore ფაილი. დარწმუნდი, რომ მასში არის .env ფაილები, node_modules, build-ის გამოსავალი საქაღალდეები და ყველა ფაილი, რომელიც საიდუმლოებს შეიცავს. მითხარი, რა დაამატე.

ნაბიჯი 2: ჩაწერეთ commit ყოველი მუშა ცვლილების შემდეგ

Commit არის შენახული სნეპშოტი შეტყობინებით. მთავარი ჩვევა ასეთია: ჩაწერეთ commit, როცა რამე მუშაობს, სანამ მომდევნო რამეს მოითხოვდეთ.

1. მოითხოვეთ ერთი ცვლილება.
2. შეამოწმეთ იგი preview-ში.
3. თუ მუშაობს, ჩაწერეთ commit (ან სინქრონიზაცია) შეტყობინებით.
4. შემდეგ გადადით მომდევნო საკითხზე.

პატარა commit-ები ნიშნავს, რომ როცა რამე გაფუჭდება, იცით, რომელმა ცვლილებამ გამოიწვია, და მისი გაუქმება სხვა სამუშაოს არ წაშლის.

ნაბიჯი 3: დაწერეთ შეტყობინებები, რომლებსაც მოგვიანებით წაიკითხავთ

კარგი შეტყობინება ერთ სტრიქონში ამბობს, რა შეიცვალა და რატომ:

• კარგი: Add CSV export to the orders page
• კარგი: Fix booking form rejecting times after 6pm
• არასასარგებლო: update, changes, fix stuff

შეგიძლიათ AI-ს სთხოვოთ მათი დაწერა:

შეაჯამე ბოლო commit-ის შემდეგ ყველა ცვლილება ერთ სტრიქონად, დაწყებული ზმნით, 70 სიმბოლოზე ნაკლებად.

ნაბიჯი 4: გამოიყენეთ branch-ები რისკიანი სამუშაოსთვის

Branch არის სამუშაოს ცალკე ხაზი. შეგიძლიათ რამე სცადოთ branch-ზე და თუ არ გამოვიდა, მთავარ ვერსიას არ შეეხოთ.

გამოიყენეთ branch, როცა:

• ცვლილება დიდია (რედიზაინი, ახალი გადახდის ნაკადი, მონაცემთა ბაზის ცვლილება).
• სხვა ვინმე მუშაობს იმავე აპზე.
• გინდათ, რომ ვინმემ ცვლილება გადახედოს, სანამ ცოცხალი გახდება.

როცა სამუშაო დასრულდება და გატესტილია, ის merge-დება მთავარ branch-ში. GitHub-ზე ეს ჩვეულებრივ pull request-ით ხდება — გვერდი, რომელიც ცვლილებებს გადასახედად აჩვენებს. თუ თქვენი ბილდერი მხოლოდ ერთ branch-ს სინქრონიზებს, branch-ების მართვა დეველოპერს შეუძლია GitHub-ის მხრიდან.

ნაბიჯი 5: გააუქმეთ უსაფრთხოდ

როცა მოთხოვნა აპს გააფუჭებს, არ დაწეროთ კიდევ ხუთი მოთხოვნა ზედ. დაუბრუნდით ბოლო კარგ ვერსიას და სცადეთ უფრო მკაფიო მოთხოვნა.

• ბილდერში: გამოიყენეთ მისი checkpoint ან აღდგენის ფუნქცია, თუ აქვს.
• Git-ში: git revert ქმნის ახალ commit-ს, რომელიც ძველს აუქმებს და ისტორიას ინარჩუნებს. ეს უსაფრთხო არჩევანია კოდისთვის, რომელსაც სხვები უკვე წამოიღებენ.
• თავი შეიკავეთ git push --force-ისგან საერთო branch-ზე, თუ ზუსტად არ იცით რატომ. ის ყველასთვის ისტორიას გადაწერს.

თუ არ ხართ დარწმუნებული, იკითხეთ:

ბოლო ცვლილებამ შესვლის გვერდი გააფუჭა. აჩვენე, რომელი ფაილები შეცვალა წინა commit-თან შედარებით, და ახსენი, რას აკეთებდა თითოეული ცვლილება. ჯერ არაფერი შეცვალო.

ნაბიჯი 6: წამოიღეთ ცვლილებები მოთხოვნამდე

თუ დეველოპერი ან სხვა ინსტრუმენტი GitHub-ზე კოდს ცვლის, AI ბილდერს ამის შესახებ არაფერი იცის, სანამ ცვლილებებს (pull) არ წამოიღებთ. ძველ კოდზე მოთხოვნა კონფლიქტებსა და დაკარგულ სამუშაოს იწვევს.

• წამოიღეთ ცვლილებები სესიის დაწყებისას.
• შეთანხმდით, ვინ რას არედაქტირებს, და აირიდეთ ორივე მხარე ერთდროულად ერთსა და იმავე ფაილებს რომ ცვლიდეს.
• თუ მიიღებთ merge conflict-ს (ორი ცვლილება ერთსა და იმავე სტრიქონებზე), სთხოვეთ დეველოპერს ან AI-ს მისი მოგვარება და არჩევანის ახსნა.

მაგალითი მოთხოვნები

სანამ დავიწყებთ: რა შეიცვალა რეპოზიტორიაში ჩემი ბოლო სესიის შემდეგ? შეაჯამე commit-ები.

გააკეთე შემდეგი ცვლილება ცალკე: დაამატე „Duplicate“ ღილაკი თითოეულ ინვოისს. არაფერი სხვა არ შეცვალო, რომ მისი ცალკე commit-ი შევძლო.

შეამოწმე, რომ GitHub-ზე არცერთი API გასაღები, პაროლი ან .env ფაილი არ იყოს თვალყურის ქვეშ, მათ შორის წინა commit-ებშიც. მხოლოდ ფაილების სახელები მითხარი, მნიშვნელობები — არა.

ხშირი შეცდომები

• საიდუმლოების commit-ი. როგორც კი გასაღები Git ისტორიაშია, ის გამჟღავნებულია, მაშინაც კი, თუ ფაილი წაშალეთ. შეცვალეთ გასაღები.
• ერთი დიდი commit კვირაში. ერთი ცვლილების გაუქმება მხოლოდ ყველას გაუქმებას შეძლებს.
• შეტყობინებები, როგორიცაა „update“. ისტორია უსარგებლო ხდება იმის საპოვნელად, რა გააფუჭა.
• მოთხოვნა ძველ კოდზე. თუ ვინმე სხვა არედაქტირებს, ჯერ წამოიღეთ ცვლილებები.
• Force push შეცდომის გასასწორებლად. შეიძლება სხვების სამუშაო წაშალოს. გამოიყენეთ revert.
• node_modules-ის commit-ი. ის უზარმაზარია და ისედაც ხელახლა იქმნება lock ფაილიდან.

ჩეკლისტი

• პროექტი დაკავშირებულია პირად რეპოზიტორიასთან.
• .gitignore გამორიცხავს .env-ს, node_modules-ს, build-ის გამოსავალს და საიდუმლოებს.
• ყოველი მუშა ცვლილების შემდეგ ვაკეთებ commit-ს.
• commit-ის შეტყობინებები ერთ სტრიქონში ამბობს, რა შეიცვალა.
• დიდი ან რისკიანი ცვლილებები branch-ზე მიდის და გადაიხედება.
• მოთხოვნამდე ვწევ ცვლილებებს (pull), თუ სხვა ვინმე არედაქტირებს კოდს.
• ვაუქმებ checkpoint-ებით ან git revert-ით და არა force push-ით.
• ყველა გასაღები, რომელიც ოდესმე აიტვირთა, შეცვლილია.

Git Mythex-ზე

Mythex ყოველი წარმატებული აგენტის ბრუნის შემდეგ ინახავს git checkpoint-ს, ხოლო Revert to this point პროექტს ამ წერტილამდე აბრუნებს — ეს არის ბილდერის მხარის გაუქმება, რომელიც ნაბიჯ 5-ში აღვწერეთ. იხილეთ Iterate without rebuilding.

Pro-ზე GitHub sync აკავშირებს რეპოზიტორიას პროექტის პარამეტრებიდან, რათა შეძლოთ push და pull, ხოლო export ჩამოტვირთავს პროექტს, საიდუმლოებისა და node_modules-ის გარეშე. იხილეთ GitHub, export, and import. GitHub-ის დაკავშირება დეველოპერისთვის პროექტის გადაცემამდე გააადვილებს გადაცემას — იხილეთ როგორ ვიმუშაოთ დეველოპერთან AI-ით აგებულ აპზე და როგორ ავაექსპორტოთ და დავაჰოსტოთ AI-ით აგებული აპი.

კითხვები