GitHub क्या है? नॉन-डेवलपर्स के लिए Version Control

GitHub एक website है जो software projects का code उसके पूरे history के साथ रखती है, ताकि आप हर बदलाव देख सकें, गलतियाँ वापस ले सकें और उसी project पर दूसरे लोगों के साथ काम कर सकें। यह Git पर बनी है, जो एक free software है और समय के साथ project की फाइलों के snapshots रिकॉर्ड करता है। Git history को संभालता है; GitHub वह online जगह है जहाँ वह history साझा, backup और चर्चा के लिए रखी जाती है।

अगर आप AI से app बनाते हैं, तो GitHub का काम मुख्य रूप से दो चीज़ों के लिए है: code की अपनी कॉपी रखना उस tool के बाहर जिससे आपने उसे बनाया, और उसे developer को सौंपना उस format में जिसमें वे पहले से काम करते हैं।

AI से बनाने में यह क्यों ज़रूरी है

एक AI app builder तेज़ी से बहुत सारा code लिखता और बदलता है, और हर बदलाव सुधार नहीं होता। Version control से आप उसे सुरक्षित रखते हैं।

• भरोसे के साथ वापस लें। हर सहेजा गया बदलाव एक snapshot है। अगर AI कुछ तोड़ दे, तो आखिरी अच्छे वर्ज़न पर लौट जाएँ।
• मालिकाना हक। आपके अपने GitHub account में रखा code आपका रहता है, भले ही आप tool बदल दें, उसका भुगतान बंद कर दें या दूसरी राय लेना चाहें।
• Developers के साथ काम। लगभग हर developer रोज़ Git इस्तेमाल करता है। Repository से वे AI के लिखे code की समीक्षा कर सकते हैं, उसे ठीक कर सकते हैं और बदलाव वापस भेज सकते हैं।
• कहीं और deploy। कई hosting platforms सीधे GitHub repository से deploy कर सकते हैं।

रोज़ की मिसाल: track changes और shared drive

सोचिए एक document है जिसमें track changes चालू है, और वह एक shared drive में रखा है।

• Git track changes है: हर edit दर्ज होता है, किसने किया, कब और क्यों, और आप किसी भी वर्ज़न पर लौट सकते हैं।
• GitHub shared drive है: document online रहता है, दूसरे लोग उसकी कॉपी ले सकते हैं, और टिप्पणी करने व मंज़ूरी देने की जगह होती है।
• Branch ऐसा है जैसे “draft — नया pricing section” नाम से एक कॉपी सेव करना, ताकि आप वह वर्ज़न छुए बिना प्रयोग कर सकें जिस पर सब भरोसा करते हैं। प्रयोग सफल हो तो उसे वापस merge कर देते हैं।

Document से फर्क पैमाने का है। एक app में सैकड़ों फाइलें होती हैं, और Git उन सबको एक साथ ट्रैक करता है, इसलिए एक snapshot पूरे project की उस समय की हालत होता है।

Git और GitHub के वे शब्द जो आपको मिलेंगे

दो बातें खास तौर पर याद रखें। पहली, Git का history स्थायी होता है: अगर कोई password commit होकर push हो गया, तो बाद के commit में उसे मिटाने से वह history से नहीं हटता। दूसरी, commit उतना ही उपयोगी है जितना उसका संदेश। “Two people एक साथ book करें तो booking double-count होना ठीक किया” बाद में मदद करता है; “update” नहीं करता।

उदाहरण: AI से बना app freelancer को सौंपना

आपने AI app builder से एक client portal बनाया है। वह चलता है, पर आप चाहते हैं कि एक freelance developer आपके accounting software के साथ एक जटिल integration जोड़े।

1. Project को एक नई private GitHub repository से जोड़ें और push करें। अब repo में code और उसका history है।
2. जाँचें कि उसमें क्या है। GitHub पर repo खोलें। वहाँ कोई .env फाइल नहीं होनी चाहिए और code में कोई API key नहीं होनी चाहिए। Secrets आपके platform की settings में रहते हैं और ज़रूरत हो तो freelancer के साथ अलग से साझा किए जाते हैं। देखें environment variables और secrets।
3. Freelancer को सिर्फ उस repository पर collaborator के रूप में बुलाएँ।
4. वे accounting-sync जैसे branch पर काम करते हैं, काम के साथ commit करते हैं, और पूरा होने पर pull request खोलते हैं।
5. आप pull request की समीक्षा करते हैं। Code पढ़े बिना भी आप description पढ़ सकते हैं, देख सकते हैं कि कौन-सी फाइलें बदलीं, और comments में सवाल पूछ सकते हैं।
6. खुश होने पर merge करें, फिर बदलाव अपने builder में pull करें, ताकि आप और AI नए वर्ज़न से आगे बढ़ें।

इस पूरे रास्ते में आप देख सकते हैं कि क्या बदला, और ज़रूरत हो तो उसे वापस ले सकते हैं। एक workflow में version control की पूरी कीमत यही है। अगर आप अभी सोच रहे हैं कि developer लाएँ या नहीं, तो देखें developer से बनवाएँ या AI से।

आम गलतफहमियाँ और गलतियाँ

• “GitHub और Git एक ही चीज़ हैं।” Git GitHub के बिना भी चलता है; GitLab और Bitbucket जैसे विकल्प भी Git repositories होस्ट करते हैं।
• “GitHub मेरा app चलाएगा।” GitHub code संभालता है। उसे जनता के लिए चलाना web hosting है, जो एक अलग सेवा है (हालाँकि कुछ hosts GitHub से सीधे deploy कर देते हैं)।
• Secrets commit करना। यह सबसे नुकसानदेह और सबसे आम गलती है। .env फाइलों के लिए .gitignore इस्तेमाल करें, और जो key कभी push हो गई हो उसे तुरंत बदल (rotate) दें।
• एक ही branch और कोई संदेश नहीं। अकेले प्रयोगों के लिए ठीक है, पर commits को साफ संदेश दें और जोखिम भरे काम के लिए branch बनाएँ।
• एक साथ दो जगह edit करना। अगर आप GitHub और अपने AI builder दोनों में बिना pull किए code बदलते हैं, तो conflicts बनते हैं। एक समय में एक ही जगह edit करें, और बदलने से पहले sync करें।
• सोचना कि private repo हर चीज़ का backup है। उसमें code है, database की सामग्री या अपलोड की गई फाइलें नहीं। उनका अपना backup चाहिए।

अपने AI builder से क्या माँगें

• “एक .gitignore जोड़ो जो .env, dependency folders और build output को बाहर रखे।”
• “एक README लिखो जो बताए कि कैसे install करें, कौन-से environment variables चाहिए (सिर्फ नाम), और app कैसे चलाएँ।”
• “एक .env.example जोड़ो जिसमें हर variable का नाम हो और कोई असली value न हो।”
• “हर बदलाव के लिए साफ, स्पष्ट commit messages इस्तेमाल करो।”

ये चार अनुरोध एक ऐसा repository बनाते हैं जिसे कोई developer कुछ मिनटों में समझ ले। App को अपने servers पर ले जाने के लिए देखें AI से बने app को export और self-host कैसे करें, और real users से पहले उसे मज़बूत करने के लिए AI prototype को production तक कैसे ले जाएँ।

GitHub और Mythex

Mythex हर plan पर आपके लिए history रखता है: हर सफल agent turn के बाद यह एक checkpoint सहेजता है, जो एक Git snapshot है और जिस पर आप लौट सकते हैं। Pro पर आप GitHub जोड़कर अपने repository के साथ project push या pull कर सकते हैं, या पूरे project का archive डाउनलोड कर सकते हैं; exports में secrets और installed dependencies शामिल नहीं होते। यहाँ GitHub code sync के लिए है, Mythex में sign-in के लिए नहीं। देखें docs में GitHub, export और import, और हर plan में क्या है यह जानने के लिए pricing page।

सवाल