Ano ang GitHub? Version Control para sa Hindi Developer

Ang GitHub ay website na nag-iimbak ng code ng mga software project kasama ang buong kasaysayan nito, para makita mo ang bawat pagbabago, maibalik ang mga pagkakamali, at makatrabaho ang iisang proyekto kasama ng ibang tao. Nakabatay ito sa Git, libreng software na nagtatala ng mga snapshot ng mga file ng proyekto sa paglipas ng panahon. Ang Git ang tool na nagtatago ng kasaysayan; ang GitHub naman ang online na tahanan kung saan ibinabahagi, binibackup, at pinag-uusapan ang kasaysayang iyon.

Kung gumagawa ka ng app gamit ang AI, ang GitHub ay pangunahing para sa dalawang bagay: pagkakaroon ng sarili mong kopya ng code sa labas ng tool na ginamit mo sa paggawa nito, at pagbibigay nito sa developer sa format na gamit na nila.

Bakit mahalaga ito kapag gumagawa ka ng app gamit ang AI

Mabilis magsulat at magbago ng code ang isang AI app builder, at hindi lahat ng pagbabago ay pagpapabuti. Ang version control ang paraan para maging ligtas dito.

• Ibalik nang may kumpiyansa. Ang bawat na-save na pagbabago ay isang snapshot. Kung may nasira ang AI, babalik ka sa huling gumana.
• Pagmamay-ari. Ang code sa sarili mong GitHub account ay mananatiling sa iyo kahit magpalit ka ng tool, tumigil sa pagbabayad sa isa, o gusto mo lang ng pangalawang opinyon.
• Pakikipagtulungan sa developer. Halos lahat ng developer ay gumagamit ng Git araw-araw. Sa isang repository, kaya nilang suriin ang isinulat ng AI, ayusin ito, at ibalik ang mga pagbabago.
• Pag-deploy sa ibang lugar. Maraming hosting platform ang kayang mag-deploy direkta mula sa GitHub repository.

Halimbawang madaling maintindihan: track changes at shared drive

Isipin ang isang dokumento na may naka-on na track changes, na nakalagay sa shared drive.

• Ang Git ang track changes: bawat pag-edit ay naitatala, kasama kung sino ang gumawa, kailan, at bakit, at kaya mong bumalik sa alinmang bersyon.
• Ang GitHub ang shared drive: online nakatira ang dokumento, makakakuha ng kopya ang iba, at may lugar para sa komento at pag-apruba.
• Ang branch ay parang pag-save ng kopya na may pangalang “draft — bagong seksyon ng presyo” para makapag-eksperimento ka nang hindi ginagalaw ang bersyong umaasa ang lahat. Kapag gumana ang eksperimento, pinagsasama mo ito pabalik (merge).

Ang pagkakaiba sa dokumento ay sukat. Ang app ay daan-daang file, at sinusubaybayan ng Git ang lahat ng ito nang sabay, kaya ang isang snapshot ay ang estado ng buong proyekto sa iisang sandali.

Mga terminong Git at GitHub na makikita mo

Dalawang punto ang dapat bigyang-diin. Una, permanente ang kasaysayan ng Git sa disenyo: kapag na-commit at na-push ang isang password, hindi ito mawawala sa kasaysayan kahit burahin mo ito sa susunod na commit. Pangalawa, kasing-halaga lang ng mensahe nito ang isang commit. Ang “Ayusin ang double-count sa booking kapag sabay mag-book ang dalawang tao” ay makakatulong sa iyo sa hinaharap; ang “update” ay hindi.

Halimbawang sitwasyon: pagbibigay ng app na gawa sa AI sa isang freelancer

Gumawa ka ng client portal gamit ang AI app builder. Gumagana na ito, pero gusto mong dagdagan ng isang freelance developer ng mahirap na integration sa accounting software mo.

1. Ikonekta ang proyekto sa bagong private na GitHub repository at i-push. Nasa repository na ang code at ang kasaysayan nito.
2. Suriin kung ano ang nasa loob. Buksan ang repo sa GitHub. Dapat walang .env na file at walang API key sa code. Nananatili ang mga secret sa settings ng iyong platform at ibinabahagi sa freelancer nang hiwalay, kung kinakailangan — tingnan ang environment variables at secrets.
3. Imbitahan ang freelancer bilang collaborator sa repository na iyon lang.
4. Sa branch sila magtatrabaho, halimbawa ang pangalang accounting-sync, mag-commit habang gumagawa, at magbukas ng pull request kapag tapos na.
5. Ikaw ang mag-review ng pull request. Kahit hindi mo binabasa ang code, mababasa mo ang deskripsyon, makikita kung aling mga file ang nagbago, at makapagtatanong sa mga komento.
6. I-merge kapag masaya ka na, at pagkatapos ay i-pull ang mga pagbabago pabalik sa builder mo para magpatuloy ka at ang AI mula sa bagong bersyon.

Sa bawat hakbang, makikita mo nang eksakto kung ano ang nagbago at maibabalik mo ito kung kailangan. Iyon ang buong halaga ng version control sa iisang daloy ng trabaho. Kung pinag-iisipan mo pa kung kukuha ka ng developer, tingnan ang kumuha ng developer o gumawa gamit ang AI.

Mga karaniwang pagkakamali at maling akala

• “Pareho lang ang GitHub at Git.” Gumagana ang Git kahit walang GitHub; may iba pang nagho-host ng Git repository gaya ng GitLab at Bitbucket.
• “Patatakbuhin ng GitHub ang app ko.” Nag-iimbak lang ng code ang GitHub. Ang pagpapatakbo nito para sa publiko ay web hosting, na hiwalay na serbisyo (bagaman may ilang host na nagde-deploy mula sa GitHub).
• Pag-commit ng secret. Ito ang pinakamapanira at pinakakaraniwang pagkakamali. Gamitin ang .gitignore para sa mga .env na file, at palitan ang anumang key na na-push kahit minsan.
• Iisang branch at walang mensahe. Okay lang para sa solo na eksperimento, pero bigyan ng malinaw na mensahe ang mga commit at gumamit ng branch para sa anumang delikado.
• Pag-edit sa dalawang lugar nang sabay. Kapag binago mo ang code sa GitHub at sa AI builder mo nang hindi nagpu-pull sa pagitan, magkakaroon ng conflict. Pumili ng iisang lugar sa pag-edit sa bawat pagkakataon, at mag-sync bago magpalit.
• Pag-iisip na backup ng lahat ang private na repo. Code ang laman nito, hindi ang laman ng database mo o ang mga na-upload na file. Kailangan ng sarili nilang backup ang mga iyon.

Ano ang hihilingin sa AI builder mo

• “Magdagdag ng .gitignore na nag-e-exclude ng .env, mga dependency folder, at build output.”
• “Sumulat ng README na nagpapaliwanag kung paano i-install, anong environment variable ang kailangan (mga pangalan lang), at kung paano patakbuhin ang app.”
• “Magdagdag ng .env.example na may bawat pangalan ng variable at walang totoong value.”
• “Gumamit ng malinaw at naglalarawang commit message para sa bawat pagbabago.”

Ang apat na hiling na ito ay gagawa ng repository na kayang kunin ng developer sa loob ng ilang minuto. Para ilipat ang app sa sarili mong server, tingnan ang paano i-export at i-self-host ang app na gawa sa AI, at para patibayin ito bago gamitin ng totoong user, dalhin ang AI prototype sa production.

GitHub at Mythex

Kasaysayan ang itinatago ng Mythex para sa iyo sa bawat plan: pagkatapos ng bawat matagumpay na turn ng agent, nagse-save ito ng checkpoint, na isang Git snapshot na maibabalikan mo. Sa Pro, maikokonekta mo ang GitHub at maipu-push o mahihila ang proyekto mula o papunta sa sarili mong repository, o mada-download ang buong proyekto bilang archive; hindi kasama sa mga export ang mga secret at naka-install na dependency. Ginagamit dito ang GitHub para mag-sync ng code, hindi para mag-sign in sa Mythex. Tingnan ang GitHub, export at import sa docs, at ang pricing page para sa kasama sa bawat plan.

Mga tanong