Git vs GitHub: Ano ang Kaibahan para sa VPS Owners

Ano ang GitHub?

Ang GitHub ay isang hosted service na nag-iimbak ng Git repositories at gumagawa ng website para sa mga ito. Ang Git ay ang version control program na tumatakbo sa sarili mong computer o server. Ang GitHub ay produkto ng isang kumpanya na nakapatong sa Git, at pagmamay-ari ito ng Microsoft mula noong 2018. Maaari mong gamitin ang Git araw-araw nang hindi binubuksan ang GitHub. Hindi mo magagamit ang GitHub nang walang Git.

Mahalaga ang puntong ito kapag mayroon ka nang VPS (virtual private server). Ang Git ang nagtatala ng history ng iyong config files at deploy scripts. Ang GitHub ang lugar kung saan nananatili ang kopya ng history na iyon kapag wala ito sa server, at nagbibigay rin ito ng lugar para magpatakbo ng builds at magsagawa ng reviews. Sinusundan ng gabay na ito ang isang halimbawa mula sa empty folder hanggang sa deployment sa server, at ipinapaliwanag ang bawat bagong termino sa unang paglitaw nito.

Ano ang awtomatikong ginagawa ng Git

Ang Git ay isang version control system: itinatala nito ang estado ng isang directory sa paglipas ng panahon, kaya makikita mo kung ano ang nagbago, kailan ito nagbago, at bakit. Isinulat ito noong 2005 para sa Linux kernel development. Distributed ito, na nangangahulugang hawak ng bawat kopya ng repository ang buong history. Walang central server sa disenyo nito. Ang laptop ng isang kasamahan ay kasingkumpletong kopya ng repository gaya ng nasa anumang server.

I-install ito at itakda ang iyong identity. Hindi nagre-record ang Git ng commit kung walang name at email address, dahil parehong isinusulat ang mga ito mismo sa commit.

sudo apt update && sudo apt install -y git
git --version
git config --global user.name "Your Name"
git config --global user.email "you@example.com"

Sa Ubuntu 24.04, ipinapakita ng git --version ang git version 2.43.0. Pareho ang behavior ng anumang release mula sa nakaraang ilang taon para sa lahat ng susunod na hakbang.

Ang halimbawa: isang repository para sa mga deploy file ng iyong VPS

Ang repository, na karaniwang pinaikli bilang “repo,” ay isang directory na mino-monitor ng Git. Nagiging repository ito kapag pinatakbo mo ang git init, na gumagawa ng nakatagong .git folder sa loob nito. Ang folder na iyon ang repository. Kapag dinelete mo ang .git, matitira ang isang ordinaryong directory na walang history.

mkdir vps-deploy && cd vps-deploy
git init -b main
printf '.env\n*.key\n' > .gitignore

Itinatakda ng -b main ang unang branch bilang main. Kapag hindi mo ito isinama, magpi-print ang Git ng mahabang hint tungkol sa default branch name. Inililista ng .gitignore ang mga path na hindi kailanman dapat i-track ng Git. Ilagay ang secrets file sa loob nito sa unang araw, dahil kapag na-commit na ang isang file kahit isang beses, mananatili ito sa history kahit dinelete mo na. Para maalis ito nang maayos, kailangang i-rewrite ang bawat commit na ginawa pagkatapos nito.

Mga commit: yunit ng history

Magdagdag ngayon ng script at i-record ito.

printf '#!/bin/sh\nsudo systemctl restart caddy\n' > restart.sh
git add restart.sh .gitignore
git commit -m "Add restart script and gitignore"
git log --oneline

Inililipat ng git add ang isang pagbabago sa staging area, ang listahan ng mga isasama sa susunod na commit. Isinusulat naman ng git commit ang listahang iyon sa history bilang isang entry. Naglalaman ang isang commit ng snapshot ng bawat tracked file, mensahe, author, timestamp, at pointer papunta sa commit bago nito. Nagpi-print ang git log --oneline ng isang linya para sa bawat commit. Nagsisimula ang bawat linya sa maikling hash gaya ng a1b2c3d. Ang hash na iyon ang pangalan ng commit, at tinatanggap ito ng halos lahat ng Git command.

Laktawan ang hakbang na git add, at sasagot ang git commit ng no changes added to commit (use "git add" and/or "git commit -a"). Walang nasira. Sinasabi ng Git na walang laman ang staging area, kaya walang snapshot na gagawin. Ang git status ang command na dapat patakbuhin kapag hindi mo alam ang susunod na gagawin. Ipinapakita nito ang kasalukuyang branch, ang mga staged change, at ang mga file na nakikita ng Git pero hindi nito tina-track.

Mga Branch: ikalawang linya ng history

Ang branch ay isang gumagalaw na pointer patungo sa isang commit. Ang main ay isang branch, at wala itong anumang natatanging katangian sa Git. Walang gastos ang paglikha nito dahil bagong pointer ang isinusulat ng Git sa halip na kopyahin ang iyong mga file.

git switch -c add-backup
printf '#!/bin/sh\nrestic backup /srv\n' > backup.sh
git add backup.sh
git commit -m "Add nightly backup"
git switch main
ls

Pagkatapos ng git switch main, nawawala ang backup.sh sa listing. Walang na-delete. Nasa branch na add-backup ang file, at hindi ito kailanman nagkaroon ng main, kaya inalis ito ng Git sa iyong working directory nang lumipat ka. Isang beses itong nakapagtataka para sa lahat. Ibinabalik ito ng git switch add-backup.

Remotes: kung saan sa wakas lumilitaw ang GitHub

Lahat ng ginawa natin hanggang dito ay tumakbo sa iisang machine na walang network. Ang remote ay isang pinangalanang URL para sa isa pang kopya ng parehong repository. Nagho-host ang GitHub ng isa sa mga kopyang iyon para sa iyo. Ang nakasanayang pangalan ng pangunahing remote ay origin.

Gumawa ng walang laman na repository sa website ng GitHub, pagkatapos ay ikonekta ito. Mas mainam dito ang SSH kaysa HTTPS: ang SSH key ay isang file na kontrolado mo, at hindi ito nag-e-expire gaya ng personal access token.

ssh-keygen -t ed25519 -C "vps-deploy"
cat ~/.ssh/id_ed25519.pub
ssh -T git@github.com

I-paste ang naka-print na public key sa SSH keys page ng iyong GitHub account, pagkatapos ay patakbuhin muli ang test. Sumasagot ang gumaganang key ng Hi yourname! You've successfully authenticated, but GitHub does not provide shell access.. Walang shell na ibinibigay sa iyo ang GitHub, kaya ang pagtangging iyon ang senyales ng tagumpay. Ibig sabihin ng git@github.com: Permission denied (publickey). na hindi kailanman naipasa ang iyong key o hindi ito tinanggap, kaya tiyaking na-paste mo ang file na .pub at hindi ang private key na nasa tabi nito.

git remote add origin git@github.com:yourname/vps-deploy.git
git push -u origin main

Ipinapadala ng git push ang iyong commits sa remote. Itinatala ng -u na sinusubaybayan ng lokal na main ang remote na main, kaya sapat na sa susunod ang isang simpleng git push. Ang git clone <url> naman ang kabaligtaran kapag nasa bagong machine: kinokopya nito ang buong repository kasama ang history nito at itinatakda ang origin para sa iyo. Gumagana rin ang HTTPS remote, at dumaraan ito sa parehong protocol na ginagamit ng anumang web page, kaya nakatutulong ito sa mga network na nagba-block ng outbound port 22. Kung kailangan pang ipaliwanag ang pangungusap na iyon, inilalarawan sa kung ano talaga ang laman ng isang HTTP request ang mga detalye.

Mga pull request, issue, at fork: mga bahagi ng GitHub, hindi ng Git

Git ang lahat ng nabanggit sa itaas, at gumagana ito sa anumang server. Ang tatlong terminong nasa ibaba ay mga feature ng GitHub. Kinokopya ito ng ibang host, at walang alam ang Git sa mga ito.

Ang pull request (PR) ay kahilingang i-merge ang isang branch sa isa pa, na may page para sa talakayan. Ipu-push mo ang add-backup, magbubukas ka ng PR laban sa main, at ipapakita ng site ang pagkakaiba commit bawat commit. Maaaring magkomento ang mga tao sa mga partikular na linya. Mag-uulat ang mga automated check kung pumasa o bumagsak ang branch. I-click ang merge at isasagawa ng GitHub ang merge sa sarili nitong kopya, pagkatapos ay ia-update ang main. Nagmula ang pangalan sa orihinal na workflow, kung saan hinihiling mo sa isang maintainer na i-pull ang branch mo papunta sa branch niya.

Ang issue ay may numerong thread para sa isang bug o task. Nasa database ito ng GitHub, hindi sa repository mo. Mahalagang malaman ito bago ka pumili ng host: kapag na-clone mo ang repo, nasa iyo ang bawat commit, pero wala roon ang kahit isang issue. Para makuha ang mga issue, kailangan mong tumawag sa API.

Ang fork ay sarili mong server-side na kopya ng repository ng ibang tao. May write access ka sa kopyang ito, nagpu-push ka ng branch dito, at nagbubukas ka ng pull request mula sa kopya mo pabalik sa repository nila. Ganito ka nakakapag-contribute sa isang project kahit hindi ka pa kilala ng mga maintainer nito. Ang fork ay clone na nasa GitHub at nakatala kung saan ito nagmula.

Binabasa ng software ang tatlo gamit ang parehong API na ginagamit ng isang tao. Isang pull request review agent na pinapatakbo mo sa sarili mong server ang nagmo-monitor ng mga bagong PR, nagbabasa ng diff, at nagpo-post ng mga line comment. Umiiral ang mga convention gaya ng AGENTS.md file sa root ng repository dahil binabasa na ngayon ang repo ng mga tool pati ng mga tao.

Ano talaga ang ginagawa ng GitHub para sa may-ari ng VPS

Magsimula sa storage na nasa labas ng server. Dapat nasa ibang lugar ang iyong deploy scripts at playbooks, hindi sa server na kino-configure ng mga ito. I-rebuild ang VPS mula sa bagong image, pagkatapos ay mag-clone at magpatakbo. Panatilihing private ang repository na iyon at bigyan ang server ng deploy key: isang SSH key na nakarehistro para sa isang repository lamang sa halip na sa buong account mo, at nakatakda bilang read-only. Kapag na-leak ang isang read-only deploy key, isang repository lamang ang malalantad. Kapag na-leak ang account key, malalantad ang lahat ng repository na maaari mong i-push-an.

sudo git clone git@github.com:yourname/vps-deploy.git /srv/vps-deploy
cd /srv/vps-deploy
git pull --ff-only

--ff-only ay tumatangging gumawa ng merge commit. Sa server na tumatanggap lamang ng mga pagbabago, palaging hindi sinasadya ang merge. Kaya ginagawa ng flag na ito na simpleng error ang dating nakalilitong history: fatal: Not possible to fast-forward, aborting. May nagbago sa server na hindi dapat nagbago. Hanapin ito bago ka muling mag-pull.

Kapag nag-clone ka bilang root at pagkatapos ay nagpatakbo ng Git bilang ibang user, makukuha mo ang fatal: detected dubious ownership in repository at '/srv/vps-deploy'. Tumanggi ang Git na magbasa ng repository na pagmamay-ari ng ibang user dahil maaaring magpatakbo ng mga command ang isang mapaminsalang .git/config. Ayusin ang ownership gamit ang chown sa halip na magdagdag ng exception na safe.directory, dahil pinatatahimik lamang ng exception ang pagsusuri at hindi nito inaalis ang sanhi.

GitHub Actions: mga pipeline para sa build at deployment

Ang Actions ay CI/CD system ng GitHub (continuous integration at continuous delivery). Mag-commit ng YAML file sa ilalim ng .github/workflows/, at tatakbuhin ito ng GitHub kapag nangyari ang event na tinukoy mo.

name: check
on:
  push:
    branches: [main]
jobs:
  shellcheck:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7
      - run: sudo apt-get update && sudo apt-get install -y shellcheck
      - run: shellcheck *.sh

Ang file ay isang workflow. Tumatakbo ang isang job sa isang machine. Ang isang step ay isang command o isang published action. Kinukuha ng uses: ang isang action mula sa ibang repository, at pini-pin ito ng @v7 sa major version nito (ang v7 ang kasalukuyang version para sa actions/checkout noong August 2026). Palaging mag-pin ng version, dahil kapag walang pin na version ang action, maaaring tumakbo ang code na hindi mo nasuri at magkaroon ito ng access sa iyong secrets.

Humihingi ang runs-on: ubuntu-latest ng bagong virtual machine mula sa GitHub. Itinatapon ang machine kapag natapos ang job. Libre ang standard runners sa mga public repository. Kasama rin sa free plan ang 2,000 minuto bawat buwan para sa private repositories noong August 2026. Suriin ang kasalukuyang pricing page bago magtakda ng budget batay sa halagang ito.

Naka-store ang secrets sa repository settings at binabasa bilang ${{ secrets.DEPLOY_KEY }}. Ang workflow na na-trigger ng pull request mula sa fork ay tumatanggap ng read-only token at walang access sa mga secret na iyon. Kung hindi, maaaring magbukas ang isang hindi kilalang tao ng PR na ang tanging layunin ay i-print ang mga ito.

Pagpapatakbo ng Actions runner sa sarili mong VPS

Ipinapadala ng runs-on: self-hosted ang job sa isang machine na pagmamay-ari mo. Sa runner settings page ng repository, makukuha mo ang download line, web address ng repository, at registration token na valid nang isang oras. Ilagay ang huling dalawang ito sa REPO_URL at RUNNER_TOKEN, at tatlong command na lang ang kailangan para sa setup.

./config.sh --url "$REPO_URL" --token "$RUNNER_TOKEN"
sudo ./svc.sh install
sudo ./svc.sh start
./svc.sh status

Dapat iulat ng svc.sh status na active ang service at ipakita ang mga kamakailang log line. Nagbubukas ang runner ng outbound HTTPS connection papunta sa GitHub at humihingi ng trabaho, kaya hindi mo kailangang magbukas ng inbound port para rito. Isinusulat ng svc.sh install ang systemd unit, at ito ang hakbang na madalas nilalaktawan: kung wala ito, lalabas ang runner kasabay ng SSH session mo at mananatiling queued ang bawat susunod na job nang walang paliwanag. Ipinapakita sa kumpletong setup ng self-hosted runner sa isang VPS ang hardening at cleanup na kailangan ng runner na matagal na tumatakbo.

Ang pakinabang nito ay hindi na kailangan ng deploy ng inbound SSH key na maaabot mula sa internet, dahil tumatakbo na ang job sa mismong machine. Nananatiling warm ang build cache sa pagitan ng mga run, at walang minute meter na nagbibilang.

May isang babala na hindi dapat balewalain. Inirerekomenda ng sariling documentation ng GitHub ang self-hosted runners para lamang sa private repositories, dahil maaaring magpatakbo ang forks ng public repository ng mapanganib na code sa runner mo sa pamamagitan ng pagbubukas ng pull request. Isinasagawa ng runner ang anumang sinasabi ng workflow file sa branch na iyon. Sa private repo kung kontrolado mo kung sino ang maaaring mag-push, maliit ang panganib. Sa public repo, ituring ang anumang self-hosted runner bilang machine na maaaring pagpatakbuhan ng code ng mga hindi mo kilala.

Kailangan mo ba talaga ang GitHub?

Hindi. Ang Git ang standard, at convenience lamang ang GitHub. Ang Forgejo at Gitea ay self-hosted forge; ang forge ay Git host na may kasamang issues at pull requests. Pareho silang nire-release bilang iisang Go binary, pareho silang tumatakbo sa maliit na VPS, at ang Forgejo ay fork ng Gitea mula 2022 na ngayon ay nagpapagana sa Codeberg. Isang command lang ang paglilipat ng repository dahil magkapareho ang wire protocol.

git remote -v
git remote set-url origin git@git.example.com:you/vps-deploy.git
git push origin main

Naililipat ang bawat commit dahil nasa bawat clone na ang buong history. Hindi naililipat ang layer na idinagdag ng GitHub: ang issues at mga thread ng pull request. Hindi rin naililipat ang CI. May sarili itong Actions implementation ang Forgejo na nagbabasa ng katulad na YAML mula sa .forgejo/workflows/, at malinaw ang dokumentasyon nito tungkol sa mga limitasyon: hindi pareho ang GitHub Actions at Forgejo Actions, at maaaring hindi agad gumana ang ilang bagay. Kailangan din nito ng sarili nitong runner. Ituring ang hakbang na iyon bilang port, hindi copy.

Ang tapat na dahilan kung bakit nananatili ang karamihan sa mga project ay ang contributors. Kailangang nasa lugar ang public code kung saan mayroon nang account ang mga tao. Hindi kailangan iyon ng iyong private deploy scripts. Magkahiwalay na desisyon ang dalawang ito, at maaari mong sagutin ang mga ito sa magkaibang paraan.

Ano ang unang nasisira, at ano ang sinasabi ng error

Na-reject ang push. Makikita mo ito:

 ! [rejected]        main -> main (fetch first)
error: failed to push some refs to 'github.com:yourname/vps-deploy.git'
hint: Updates were rejected because the remote contains work that you do
hint: not have locally.

May na-push mula noong huli mong pull, kadalasan ay isang edit na ginawa mo sa web editor. Patakbuhin ang git pull --rebase upang i-replay ang mga commit mo sa ibabaw ng mga commit nila, pagkatapos ay mag-push ulit. Iwasang gamitin ang git push --force sa isang shared branch dahil inaalis nito ang iba pang commit sa branch na iyon sa server.

fatal: refusing to merge unrelated histories. Pinatakbo mo ang git init nang lokal at hinayaan mo ring gumawa ang GitHub ng repository na may README. Walang magkakaparehong commit ang dalawang history, kaya hindi makapaghuhula ang Git. Ang malinis na paraan ay i-clone ang kopya sa GitHub sa isang bagong folder at ilipat doon ang mga file mo.

error: src refspec main does not match any. Hindi umiiral dito ang branch na pinangalanan mo. Karaniwan, wala pang commit ang repository, o ang pangalan ng branch mo ay master. Malulutas ito ng git branch --show-current.

May secret na napunta sa isang commit. I-rotate agad ang credential. Ituring itong public mula sa sandaling na-push ito dahil may mga kopya nito sa forks, mirrors, at cached views na wala kang paraan para burahin.

FAQ

Ang GitHub ba ay kapareho ng Git?

Hindi. Ang Git ay isang version control program na ini-install sa isang machine, at gumagana ito kahit walang network o account. Ang GitHub ay isang commercial hosted service na nag-iimbak ng Git repositories at nagdadagdag ng web interface, issues, pull requests, at CI. Inilabas ang Git noong 2005 at inilunsad ang GitHub noong 2008 bilang isang serbisyong nakabase rito. Maaari mong gamitin ang Git nang matagal nang walang GitHub. Nakadepende sa Git ang bawat feature ng GitHub.

Kailangan ko ba ng GitHub account para magamit ang Git sa aking VPS?

Hindi. Gumagana ang git init, git commit, at git log sa isang server kahit walang naka-configure na remote, at sapat na ito para subaybayan ang mga pagbabago sa mga file na /etc o sa mga deploy script. Nagiging kapaki-pakinabang ang account kapag gusto mo ng kopya ng history na mananatili kahit mawala ang server, o ng pangalawang machine na maaaring mag-clone nito. Tinutugunan ng mga self-hosted forge gaya ng Forgejo at Gitea ang parehong pangangailangan sa hardware na pagmamay-ari mo, at gumagana rin ang isang simpleng SSH remote na tumuturo sa isang bare repository sa ibang box kahit walang forge software.

Ano ang pull request?

Ang pull request ay isang kahilingang i-merge ang isang branch sa isa pang branch, na may kalakip na discussion page. Ipu-push mo ang isang branch, bubuksan ang PR laban sa main, at ipapakita ng host ang mga pagbabago commit by commit upang makapagkomento ang reviewers sa mga indibidwal na linya at makapag-ulat ang mga automated check kung pass o fail. Feature ito ng GitHub, hindi ng Git, kaya walang command ang Git para rito. Ipinatutupad din ng ibang host ang parehong konsepto at kung minsan ay tinatawag itong merge request.

Dapat ba akong magpatakbo ng GitHub Actions runner sa sarili kong VPS?

Para sa isang private repository, madalas ay oo. Tumatakbo ang job sa hardware na binabayaran mo na, walang sinisingil na minuto, nananatiling warm ang build cache, at hindi na kailangang maglantad sa internet ng inbound SSH key para sa deployment dahil kumokonekta palabas ang runner sa GitHub at humihingi ng trabaho. Para sa isang public repository, hindi ito inirerekomenda ng GitHub: maaaring i-fork ng kahit sino ang repo mo at magbukas ng pull request na ang workflow ay magpapatakbo ng code sa iyong machine.

Maaari ko bang ilipat sa ibang lugar ang aking repositories mula sa GitHub?

Ang code, oo, madali. Nasa bawat clone ang kumpletong history, kaya inililipat ng git remote set-url origin <new url> na sinusundan ng push ang lahat ng nilalaman ng isang commit. Ang maiiwan ay ang layer na pagmamay-ari ng GitHub: nasa database nito ang issues, pull request discussions, at Actions history, hindi sa iyong .git folder. Maaaring kopyahin ng mga migration tool ang issues sa pamamagitan ng API, at karaniwang kailangang i-edit ang workflow files para sa CI ng bagong host. Mahalaga itong tandaan bilang dahilan upang ilagay ang tunay na dokumentasyon sa repository sa halip na sa mga issue thread.