Git at GitHub: ano ang pagkakaiba at paano sila magkaugnay

Madalas malito ang Git at GitHub, pero magkaiba ang antas ng dalawang ito. Ang Git ay version control program na ini-install ninyo sa computer: tinatandaan nito ang bawat naka-save na estado ng project at pinapayagan kayong bumalik dito. Ang GitHub ay web service kung saan nakalagay ang mga kopya ng Git repository at may mga kasangkapan para sa team work. Pinakamadaling tandaan: ang Git ang makina, at ang GitHub ang garahe na may serbisyo kung saan puwede ninyong ilagay ang makinang iyon.

Ano ang Git

Ang Git ay distributed version control system. Ginawa ito ni Linus Torvalds noong 2005 para sa development ng Linux kernel, at mula noon ay naging pamantayan na ng industriya. Ganap na lokal ang Git: nakatago ang history ng mga pagbabago sa nakatagong folder na .git sa loob ng project, at halos lahat ng operasyon ay hindi nangangailangan ng internet.

Mahalaga ang salitang "distributed". Bawat kalahok sa project ay may kumpletong kopya ng repository sa computer, kasama ang buong history, hindi lang ang huling mga file. Kung mawala ang server, maibabalik ang project mula sa alinmang working machine.

Ang kayang gawin ng Git mismo:

• i-record ang mga pagbabago bilang commit, mga snapshot ng project na may author, petsa, at paglalarawan;
• ipakita kung sino, kailan, at bakit binago ang isang linya (git log, git blame);
• magkaroon ng magkakahiwalay na linya ng development sa mga branch at pagsamahin ang mga ito;
• i-rollback ang mga pagkakamali nang hindi nawawala ang iba pang trabaho;
• magpalitan ng history sa ibang repository gamit ang git push, git pull, at git fetch.

Command-line utility ang Git. Ang mga graphical client at panel sa mga editor (VS Code, IntelliJ IDEA) ay mga balat lang sa parehong command.

Ano ang GitHub

Ang GitHub ay cloud platform para sa pag-host ng Git repository, at pagmamay-ari na ito ngayon ng Microsoft. Gumagawa kayo ng repository doon, ipinapadala ang lokal na code gamit ang git push, at nagiging accessible ito sa mga katrabaho, sa employer, o sa buong internet kung public ang repository.

Pero hindi lang pag-iimbak ang halaga ng GitHub. Sa paligid ng repository, nagdaragdag ang GitHub ng mga bagay na wala sa Git mismo:

• Pull request: kahilingang i-merge ang branch, may talakayan at line-by-line na code review;
• Issues: mga task at bug report na nakakabit sa project;
• GitHub Actions: CI/CD, awtomatikong pagpapatakbo ng test, build, at deploy sa bawat push;
• access control: sino ang puwedeng magbasa, magsulat, at mag-merge sa protektadong branch;
• profile ng developer: graph ng aktibidad at mga public project na tinitingnan ng recruiter;
• GitHub Pages: libreng hosting ng static na site direkta mula sa repository.

Ang mga query gaya ng "git com" at "git hub" ay kadalasang tumutukoy sa serbisyong ito, na nasa address na github.com. Ang opisyal na site ng Git mismo ay git-scm.com, doon ninyo kinukuha ang installer.

Git at GitHub: paghahambing sa talahanayan

Paano nagtutulungan ang Git at GitHub

Ang koneksyon sa pagitan nila ay ang remote, ang remote repository. Iniimbak ng lokal na repository ang address ng repository sa GitHub sa maikling pangalan, karaniwang origin. Pagkatapos, tatlong command ang nagpapalitan ng data:

• git push: ipadala ang inyong bagong commit sa server;
• git fetch: kunin ang commit ng iba nang hindi ginagalaw ang inyong mga file;
• git pull: kunin at agad na pagsamahin sa kasalukuyang branch (sa esensya, fetch + merge o rebase).

Mahalaga: hindi nakikita ng GitHub ang code ninyo hangga't hindi ninyo ito ipinapadala. Lokal lang ang commit hanggang sa unang git push. Kaya ang karaniwang pagkakamali ng baguhan: "nag-commit ako, pero wala namang laman sa GitHub."

Karaniwang daan: mula sa lokal na project patungong GitHub

# 1. Gumawa ng repository nang lokal
cd my-project
git init
git add .
git commit -m "Unang commit"

# 2. Gumawa ng walang lamang repository sa github.com (walang README),
#    kopyahin ang address nito, at ikabit bilang remote
git remote add origin git@github.com:username/my-project.git

# 3. Palitan ang pangalan ng branch sa main at i-push
git branch -M main
git push -u origin main

Ikinakabit ng flag na -u (buong anyo na --set-upstream) ang lokal na branch na main sa remote branch nito. Pagkatapos nito, sapat na ang simpleng git push at git pull nang walang argumento.

Kabaligtarang daan: magsimula sa repository sa GitHub

Kung nasa GitHub na ang project, hindi ito ginagawang muli. I-clone ito:

git clone https://github.com/username/my-project.git
cd my-project

Dinadownload ng command ang buong history at awtomatikong ino-configure ang remote na origin.

Authentication: SSH o HTTPS

Mula 2021, hindi tumatanggap ang GitHub ng password ng account para sa Git sa pamamagitan ng HTTPS. May dalawang gumaganang opsyon.

HTTPS + Personal Access Token. Ginagawa ang token sa settings ng account (Settings → Developer settings), at ito ang inilalagay sa halip na password. Para hindi ito i-type sa bawat pagkakataon, gumagamit ang Git ng credential manager; sa Windows, kasama ito ng Git for Windows.

SSH key. Inaasahan ng mga employer na kaya ninyong i-set up ito nang mag-isa:

# Gumawa ng key
ssh-keygen -t ed25519 -C "you@example.com"

# Ipakita ang public na bahagi at idagdag ito sa GitHub:
# Settings → SSH and GPG keys → New SSH key
cat ~/.ssh/id_ed25519.pub

# I-check ang koneksyon
ssh -T git@github.com

Kapag matagumpay, babati ang GitHub gamit ang username ninyo at magpapaliwanag na walang shell access na ibinibigay; normal ito. Ang address ng repository ay dapat nasa format na git@github.com:user/repo.git, hindi https://.

Kung naka-connect na ang repository sa HTTPS, puwede itong palitan sa SSH gamit ang isang command:

git remote set-url origin git@github.com:username/my-project.git

GitHub, GitLab, at iba pa: ano ang pagkakaiba

Hindi lang GitHub ang hosting para sa Git. Lahat sila ay gumagana sa iisang Git, kaya puwedeng ilipat ang repository mula sa isa papunta sa iba nang hindi nawawala ang history. Nagkakaiba sila sa mga kasangkapan sa paligid ng code.

Sa GitLab, tinatawag na merge request ang kahilingang pagsamahin; sa GitHub, pull request. Pareho ang diwa: mag-alok ng pagbabago mula sa branch at pag-usapan ito bago i-merge. Iba ang terminolohiya, pero pareho ang mga Git command.

Puwedeng magkaroon ng maraming remote ang iisang lokal na repository, halimbawa para i-mirror ang project sa GitHub at GitLab nang sabay:

git remote add gitlab git@gitlab.com:username/my-project.git
git push gitlab main
git remote -v

Kailangan ba ang GitHub kung mag-isa lang ako

Sa teknikal na aspeto, hindi: gumagana nang maayos ang Git nang lokal. Pero may tatlong malaking bentahe ang remote repository, kahit para sa solo project:

• Backup. Kung masira ang laptop, ligtas ang code at buong history sa server.
• Trabaho mula sa maraming device. Sa bahay at sa opisina, nagsi-sync kayo sa pamamagitan ng push at pull.
• Portfolio. Sa pagpili para sa junior na posisyon, madalas na mas nauuna pang tingnan ang profile sa GitHub kaysa resume: may buhay bang project, may makabuluhang mensahe ng commit, may README ba.

Saan magsisimula ang baguhan

Hindi kailangang sabay na matutunan ang Git at GitHub; mahalaga ang pagkakasunod-sunod. Unahin ang lokal na ikot: git init, git status, git add, git commit, git log, mga branch, at merge. Kapag kaya na ninyo ito nang walang gabay, mag-register sa GitHub, i-set up ang SSH, at matutunan ang push, pull, fetch. Ang huling hakbang ay ang team process: fork, branch para sa task, pull request, at review.

Ano ang tinitingnan ng employer sa GitHub ninyo

Hindi pangunahin ang mga berdeng parisukat ng aktibidad. Sa loob ng ilang minuto, ang bihasang reviewer ay tumitingin sa ibang bagay:

• malinaw na mensahe ng commit sa halip na "fix", "123", "mga pagbabago";
• maliliit at lohikal na commit, hindi isang malaking "idinagdag ang project";
• README na naglalarawan kung paano patakbuhin ang project;
• file na .gitignore: walang node_modules, walang .env na may password, walang file ng IDE;
• branch at pull request kahit sa mga project para sa pag-aaral: ipinapakita nito na pamilyar kayo sa team process.

Karaniwang pagkakamali ng baguhan

"fatal: not a git repository"

Nagpapatakbo kayo ng Git command sa labas ng repository. Pumunta sa folder ng project, o patakbuhin ang git init. Walang kinalaman dito ang registration sa GitHub; lokal na error ito ng Git.

"Permission denied (publickey)"

Hindi pa nagagawa ang SSH key, hindi pa naidadagdag sa GitHub, o hindi pa nalo-load sa ssh-agent. I-check ang ssh -T git@github.com at ang listahan ng mga key sa settings ng account.

"rejected … (fetch first)" sa push

May mga commit sa server na wala sa inyo, halimbawa, gumawa kayo ng repository sa GitHub na may README. Kunin muna ang mga pagbabago: git pull --rebase origin main, tapos ulitin ang git push. Huwag gamitin ang --force hangga't hindi ninyo alam kung kaninong trabaho ang mapapalitan.

Mga secret sa public na repository

Ang password o API key na minsang napasok sa commit ay mananatili sa history, kahit burahin pa ang file. Dapat palitan agad ang ganoong key, at idagdag nang maaga ang .env sa .gitignore.

Buod

Ang Git ay version control tool sa computer ninyo; ang GitHub ay serbisyo kung saan nakatira sa cloud ang mga repository at kung saan nagaganap ang team work. Ang GitLab, Bitbucket, at iba pa ay alternatibo sa GitHub, hindi sa Git: iisa ang mga commit, branch, at command sa ilalim ng lahat. Magsimula sa lokal na Git, saka ikabit ang remote at i-set up ang SSH. Ang pag-uugnay ng lokal na repository sa GitHub, push, pull, at fetch ay itinuturo nang praktikal sa kursong Git namin.