Perbezaan Git dan GitHub untuk Pengguna VPS

Apakah itu GitHub?

GitHub ialah perkhidmatan hos yang menyimpan repositori Git dan membina laman web di sekelilingnya. Git ialah program kawalan versi yang berjalan pada komputer anda sendiri atau pelayan anda sendiri. GitHub merupakan produk sebuah syarikat yang dibina di atas Git, dan dimiliki oleh Microsoft sejak tahun 2018. Anda boleh menggunakan Git setiap hari tanpa perlu membuka GitHub. Anda tidak boleh menggunakan GitHub tanpa Git.

Baris tersebut menjadi penting sebaik sahaja anda memiliki VPS (virtual private server). Git ialah alat yang merekodkan sejarah fail konfigurasi dan skrip atur cara anda. GitHub ialah tempat di mana salinan sejarah tersebut disimpan apabila pelayan tidak tersedia, serta tempat untuk menjalankan binaan dan semakan. Panduan ini mengikuti satu contoh bermula daripada folder kosong sehingga proses deploy pada pelayan, dan mentakrifkan setiap istilah baharu apabila anda menemuinya buat kali pertama.

Apa yang dilakukan oleh Git secara kendiri

Git ialah sistem kawalan versi: ia merekodkan keadaan direktori dari semasa ke semasa, supaya anda boleh melihat perkara yang berubah, bila ia berlaku, dan sebabnya. Ia ditulis pada tahun 2005 untuk kerja kernel Linux. Ia bersifat teragih, yang bermaksud setiap salinan repositori menyimpan keseluruhan sejarah. Tiada pelayan pusat dalam reka bentuknya. Komputer riba rakan sekerja adalah salinan yang sama lengkap dengan mana-mana pelayan.

Pasang perisian ini dan tetapkan identiti anda. Git enggan merekodkan commit tanpa nama dan alamat e-mel, kerana kedua-duanya ditulis ke dalam commit itu sendiri.

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"

Pada Ubuntu 24.04, git --version mencetak git version 2.43.0. Mana-mana keluaran daripada beberapa tahun kebelakangan ini berkelakuan sama untuk semua perkara di bawah.

Contoh: repositori untuk fail deploy VPS anda

Repositori, yang biasanya disingkatkan sebagai "repo", ialah direktori yang dipantau oleh Git. Ia menjadi repositori apabila anda menjalankan git init, yang mencipta folder tersembunyi .git di dalamnya. Folder tersebut ialah repositori itu sendiri. Padamkan .git dan anda hanya akan mempunyai direktori biasa yang tidak menyimpan sebarang sejarah.

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

-b main menamakan cawangan pertama sebagai main. Jika ditinggalkan, Git akan memaparkan petunjuk panjang mengenai nama cawangan lalai. .gitignore menyenaraikan laluan yang tidak boleh dijejak oleh Git. Tulis fail rahsia anda ke dalamnya pada hari pertama, kerana fail yang telah di-commit sekali akan kekal dalam sejarah walaupun anda memadamkannya, dan membuangnya dengan betul bermakna menulis semula setiap commit yang dilakukan selepas itu.

Commit: unit sejarah

Sekarang, tambah satu skrip dan rekodkannya.

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

git add memindahkan perubahan ke dalam staging area, iaitu senarai perkara yang akan dimasukkan ke dalam commit seterusnya. git commit menulis senarai tersebut ke dalam sejarah sebagai satu entri. Satu commit menyimpan snapshot bagi setiap fail yang dijejak, mesej, penulis, cap masa, dan penunjuk kepada commit sebelumnya. git log --oneline mencetak satu baris bagi setiap commit, setiap satunya bermula dengan hash pendek seperti a1b2c3d. Hash tersebut ialah nama commit itu, dan hampir setiap arahan Git menerimanya.

Langkau langkah git add dan git commit akan menjawab no changes added to commit (use "git add" and/or "git commit -a"). Tiada apa-apa yang rosak. Git memberitahu anda bahawa staging area kosong, jadi tiada apa-apa untuk diambil snapshot. git status ialah arahan untuk dijalankan pada bila-bila masa anda keliru: ia menamakan cawangan semasa, perubahan yang telah di-stage, dan fail yang boleh dilihat oleh Git tetapi tidak dijejak.

Cawangan: barisan sejarah kedua

Cawangan (branch) ialah penunjuk yang bergerak ke arah commit. main ialah satu cawangan, dan ia tidak mempunyai sebarang keistimewaan dalam Git. Mencipta cawangan tidak memakan kos, kerana Git hanya menulis penunjuk baharu dan bukannya menyalin fail anda.

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

Selepas git switch main, backup.sh tiada dalam senarai. Tiada apa-apa yang dipadamkan. Fail tersebut wujud pada cawangan add-backup, dan main tidak pernah memilikinya, jadi Git membuangnya daripada direktori kerja anda apabila anda berpindah. Perkara ini mengejutkan semua orang pada kali pertama. git switch add-backup akan mengembalikan fail tersebut.

Remotes: tempat GitHub akhirnya muncul

Segala-galanya setakat ini dijalankan pada satu mesin tanpa sebarang rangkaian. Remote ialah URL bernama untuk salinan lain bagi repositori yang sama. GitHub mengehoskan salah satu salinan tersebut untuk anda. Nama konvensional bagi remote utama ialah origin.

Cipta repositori kosong melalui laman web GitHub, kemudian sambungkan kepadanya. Utamakan SSH berbanding HTTPS di sini: kunci SSH ialah fail yang anda kawal, dan ia tidak tamat tempoh seperti token akses peribadi.

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

Tampal kunci awam yang dicetak ke dalam halaman kunci SSH akaun GitHub anda, kemudian jalankan ujian itu sekali lagi. Kunci yang berfungsi akan menjawab Hi yourname! You've successfully authenticated, but GitHub does not provide shell access.. GitHub tidak memberikan anda shell, jadi penolakan itu adalah tanda kejayaan. git@github.com: Permission denied (publickey). bermakna kunci anda tidak pernah ditawarkan atau tidak diterima, jadi semak sama ada anda menampal fail .pub dan bukannya kunci peribadi di sebelahnya.

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

git push menghantar commit anda ke remote. -u merekodkan bahawa main tempatan menjejaki main remote, supaya kemudiannya git push sahaja sudah memadai. git clone <url> ialah proses songsang pada mesin baharu: ia menyalin keseluruhan repositori berserta sejarahnya dan menetapkan origin untuk anda. Remote HTTPS juga berfungsi, dan ia bergerak melalui protokol yang sama seperti mana-mana halaman web, yang membantu pada rangkaian yang menyekat port keluar 22. Jika ayat itu memerlukan penjelasan lanjut, daripada apakah permintaan HTTP sebenarnya terdiri merangkumi mekanismenya.

Pull request, issue dan fork: bahagian yang merupakan GitHub, bukan Git

Segala perkara di atas adalah Git, dan ia berfungsi dengan mana-mana pelayan. Tiga istilah di bawah adalah ciri GitHub. Hos lain menyalin ciri ini, dan Git sendiri tidak mengetahui tentangnya.

Pull request (PR) ialah permintaan untuk menggabungkan satu branch ke branch yang lain, yang dibungkus dalam satu halaman untuk perbincangan. Anda melakukan push add-backup, membuka PR terhadap main, dan laman tersebut memaparkan perbezaan mengikut commit. Pengguna boleh memberikan komen pada baris tertentu. Semakan automatik melaporkan status lulus atau gagal terhadap branch tersebut. Klik merge dan GitHub melakukan penggabungan pada salinannya sendiri, kemudian mengemas kini main. Nama ini berasal daripada aliran kerja asal, di mana anda meminta penyelenggara untuk pull (menarik) branch anda ke dalam branch mereka.

Issue ialah thread bernombor untuk pepijat atau tugasan. Ia berada dalam pangkalan data GitHub, bukan dalam repositori anda. Perkara ini perlu diketahui sebelum anda memilih hos: apabila anda melakukan clone repositori, anda mendapat setiap commit, tetapi bukan satu pun issue. Untuk mendapatkan issue keluar, anda perlu memanggil API.

Fork ialah salinan sebelah pelayan (server-side) anda sendiri bagi repositori orang lain. Anda mempunyai akses tulis pada salinan tersebut, anda melakukan push branch ke situ, dan anda membuka pull request daripada salinan anda kembali ke salinan mereka. Begitulah cara anda menyumbang kepada projek yang penyelenggaranya tidak mengenali anda. Fork ialah clone yang berada di GitHub dan menyimpan maklumat asal usulnya.

Perisian membaca ketiga-tiga perkara ini melalui API yang sama dengan yang digunakan oleh manusia. Satu ejen semakan pull request yang anda jalankan pada pelayan sendiri memantau PR baharu, membaca diff, dan menyiarkan komen pada baris. Konvensyen seperti fail AGENTS.md pada root repositori wujud kerana repositori kini dibaca oleh alatan dan juga manusia.

Apa yang GitHub sebenarnya lakukan untuk pemilik VPS

Mulakan dengan storan di luar pelayan. Skrip atur cara dan buku main (playbook) anda perlu disimpan di tempat selain daripada pelayan yang dikonfigurasikannya. Bina semula VPS daripada imej baharu, klon, kemudian jalankan. Pastikan repositori tersebut bersifat peribadi dan berikan pelayan tersebut deploy key: kunci SSH yang didaftarkan pada satu repositori sahaja dan bukannya keseluruhan akaun anda, serta ditetapkan kepada baca sahaja (read-only). Kunci deploy baca sahaja yang bocor hanya mendedahkan satu repositori. Kunci akaun yang bocor mendedahkan segala-galanya yang anda boleh tolak (push).

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

--ff-only enggan mencipta merge commit. Pada pelayan yang hanya menggunakan perubahan, proses merge sentiasa merupakan satu kesilapan, jadi flag ini menukarkan sejarah yang mengelirukan kepada ralat mudah fatal: Not possible to fast-forward, aborting. Sesuatu telah berubah pada pelayan yang sepatutnya tidak berlaku. Cari puncanya sebelum anda melakukan pull sekali lagi.

Klon sebagai root dan kemudian jalankan Git sebagai pengguna lain, anda akan mendapat fatal: detected dubious ownership in repository at '/srv/vps-deploy'. Git enggan membaca repositori yang dimiliki oleh pengguna berbeza, kerana .git/config yang berniat jahat boleh membuatkan Git menjalankan arahan. Betulkan pemilikan dengan chown daripada menambah pengecualian safe.directory, kerana pengecualian tersebut hanya mendiamkan semakan tanpa membuang punca masalah.

GitHub Actions: talian paip bina dan atur cara (build and deploy)

Actions ialah sistem CI/CD (integrasi berterusan dan penyampaian berterusan) milik GitHub. Lakukan komit fail YAML di bawah .github/workflows/ dan GitHub akan menjalankannya apabila peristiwa yang anda namakan berlaku.

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

Fail tersebut ialah workflow. Satu job berjalan pada satu mesin. Satu step ialah satu arahan atau satu action yang diterbitkan. uses: menarik masuk action daripada repositori lain, dan @v7 menetapkan versi utamanya (v7 adalah versi semasa untuk actions/checkout setakat Ogos 2026). Sentiasa tetapkan versi, kerana action yang tidak ditetapkan versinya bermakna kod yang tidak anda baca akan berjalan dengan akses kepada rahsia (secrets) anda.

runs-on: ubuntu-latest meminta mesin maya baharu daripada GitHub, yang akan dibuang apabila job tamat. Runner standard adalah percuma pada repositori awam, dan pelan percuma merangkumi 2,000 minit sebulan untuk repositori peribadi setakat Ogos 2026. Semak halaman harga semasa sebelum anda membina bajet berdasarkan angka tersebut.

Rahsia disimpan dalam tetapan repositori dan dibaca sebagai ${{ secrets.DEPLOY_KEY }}. Workflow yang dicetuskan oleh pull request daripada fork akan mendapat token baca sahaja dan tiada akses kepada rahsia tersebut, kerana jika tidak, orang asing boleh membuka PR yang tugas tunggalnya adalah untuk mencetak rahsia itu.

Menjalankan Actions runner pada VPS anda sendiri

runs-on: self-hosted menghantar tugasan ke mesin milik anda sebagai ganti. Halaman tetapan runner repositori memberikan anda baris muat turun, alamat web repositori, dan token pendaftaran yang sah selama satu jam. Masukkan dua maklumat terakhir tersebut ke dalam REPO_URL dan RUNNER_TOKEN, kemudian persediaan tersebut hanya memerlukan tiga arahan.

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

svc.sh status sepatutnya melaporkan servis sebagai aktif dan menunjukkan baris log terkini. Runner membuka sambungan HTTPS keluar ke GitHub dan meminta kerja, jadi anda tidak perlu membuka sebarang port masuk untuknya. svc.sh install menulis unit systemd, dan ini adalah langkah yang sering dilangkau oleh pengguna: tanpanya, runner akan ditamatkan apabila sesi SSH anda berakhir dan setiap tugasan seterusnya akan berada dalam baris gilir tanpa sebarang penjelasan. persediaan penuh self-hosted runner pada VPS membincangkan langkah pengukuhan (hardening) dan pembersihan yang diperlukan oleh runner yang berjalan untuk jangka masa panjang.

Kelebihannya ialah proses deploy tidak lagi memerlukan kunci SSH masuk yang boleh dicapai dari internet, kerana tugasan tersebut sudah pun berjalan pada mesin itu sendiri. Cache binaan juga kekal tersedia antara setiap larian, dan tiada pengiraan minit yang dikenakan.

Satu amaran adalah wajib. Dokumentasi GitHub sendiri mengesyorkan self-hosted runner hanya untuk repositori peribadi, kerana fork bagi repositori awam boleh menjalankan kod berbahaya pada runner anda dengan membuka pull request. Runner akan melaksanakan apa sahaja yang diarahkan oleh fail workflow pada cawangan tersebut. Pada repositori peribadi di mana anda mengawal siapa yang boleh membuat push, risikonya adalah kecil. Pada repositori awam, anggaplah mana-mana self-hosted runner sebagai mesin yang boleh digunakan oleh orang asing untuk melaksanakan kod.

Adakah anda benar-benar memerlukan GitHub?

Tidak. Git ialah standard, manakala GitHub hanyalah satu kemudahan. Forgejo dan Gitea ialah platform forge yang boleh dihoskan sendiri; forge bermaksud hos Git yang dilengkapi dengan fungsi isu (issues) dan pull request. Kedua-duanya diedarkan sebagai satu binari Go tunggal, kedua-duanya boleh dijalankan pada VPS bersaiz kecil, dan Forgejo ialah fork Gitea tahun 2022 yang kini menguasai Codeberg. Memindahkan repositori hanya memerlukan satu arahan, kerana protokol rangkaian yang digunakan adalah sama.

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

Setiap commit akan berpindah, kerana setiap clone sudah menyimpan keseluruhan sejarah. Apa yang tidak berpindah ialah lapisan yang dibina oleh GitHub di atasnya: isu dan thread pull request. CI juga tidak berpindah. Forgejo mempunyai implementasi Actions tersendiri yang membaca YAML yang serupa daripada .forgejo/workflows/, dan dokumentasinya menyatakan dengan jelas tentang hadnya, bahawa GitHub Actions dan Forgejo Actions tidak sama dan mungkin tidak berfungsi serta-merta. Ia juga memerlukan runner tersendiri. Rancang langkah tersebut sebagai proses porting, bukan sekadar salinan.

Sebab sebenar kebanyakan projek kekal di sana adalah penyumbang. Kod awam perlu diletakkan di tempat di mana orang ramai sudah mempunyai akaun. Skrip deploy peribadi anda tidak perlu berada di sana. Itu adalah dua keputusan yang berasingan, dan anda dibenarkan untuk memberikan jawapan yang berbeza bagi kedua-duanya.

Perkara yang tergendala dahulu, dan maksud ralat tersebut

Push ditolak. Anda melihat paparan ini:

 ! [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.

Sesuatu telah di-push sejak kali terakhir anda melakukan pull, biasanya suntingan yang anda buat dalam penyunting web. Jalankan git pull --rebase untuk memainkan semula commit anda di atas commit mereka, kemudian push semula. Elakkan git push --force pada cawangan (branch) yang dikongsi, kerana ia memadamkan commit lain daripada cawangan tersebut pada pelayan.

fatal: refusing to merge unrelated histories. Anda menjalankan git init secara setempat dan membiarkan GitHub mencipta repositori dengan README. Kedua-dua sejarah tidak berkongsi commit yang sama, jadi Git tidak akan meneka. Penyelesaian yang bersih adalah dengan melakukan clone salinan GitHub ke dalam folder baharu dan memindahkan fail anda ke dalamnya.

error: src refspec main does not match any. Cawangan yang anda namakan tidak wujud di sini. Biasanya repositori tersebut mempunyai sifar commit setakat ini, atau cawangan anda dinamakan master. git branch --show-current akan menyelesaikannya.

Rahsia sampai ke commit. Tukar kelayakan (credential) tersebut sekarang. Anggap ia sebagai awam sebaik sahaja ia di-push, kerana fork, mirror dan paparan cache menyimpan salinan yang tidak mungkin anda padamkan.

FAQ

Adakah GitHub sama dengan Git?

Tidak. Git ialah program kawalan versi yang anda pasang pada mesin, dan ia berfungsi tanpa rangkaian serta tanpa akaun. GitHub ialah perkhidmatan hos komersial yang menyimpan repositori Git dan menambah antara muka web, isu, pull request serta CI di sekelilingnya. Git dikeluarkan pada tahun 2005 dan GitHub dilancarkan pada tahun 2008 di atasnya. Anda boleh menjalankan Git selama-lamanya tanpa GitHub. Setiap ciri GitHub bergantung pada Git di peringkat asas.

Adakah saya memerlukan akaun GitHub untuk menggunakan Git pada VPS saya?

Tidak. git init, git commit dan git log berfungsi pada pelayan tanpa sebarang konfigurasi remote, yang sudah memadai untuk menjejak perubahan pada fail /etc atau skrip penggunaan. Akaun menjadi berguna apabila anda mahukan salinan sejarah yang kekal jika pelayan rosak, atau mesin kedua yang boleh melakukan clone. Forge yang dihoskan sendiri seperti Forgejo dan Gitea memenuhi keperluan yang sama pada perkakasan milik anda, dan remote SSH biasa yang menghala ke repositori bare pada mesin lain berfungsi tanpa sebarang perisian forge.

Apakah itu pull request?

Pull request ialah permintaan untuk menggabungkan satu branch ke branch yang lain, dengan halaman perbincangan disertakan. Anda melakukan push pada satu branch, membuka PR terhadap main, dan hos akan memaparkan perubahan tersebut commit demi commit supaya penyemak boleh memberi komen pada baris tertentu dan semakan automatik boleh melaporkan lulus atau gagal. Ia merupakan ciri GitHub dan bukannya ciri Git, jadi Git sendiri tidak mempunyai arahan untuknya. Hos lain melaksanakan idea yang sama, kadangkala memanggilnya sebagai merge request.

Patutkah saya menjalankan GitHub Actions runner pada VPS saya sendiri?

Untuk repositori peribadi, selalunya ya. Tugasan dijalankan pada perkakasan yang anda sudah bayar, tiada had masa yang dikira, cache binaan kekal aktif, dan proses deploy tidak lagi memerlukan kunci SSH masuk yang terdedah kepada internet, kerana runner membuat sambungan keluar ke GitHub untuk meminta tugasan. Untuk repositori awam, GitHub menasihatkan agar tidak melakukannya: sesiapa sahaja boleh melakukan fork pada repositori anda dan membuka pull request yang aliran kerjanya menjalankan kod pada mesin anda.

Bolehkah saya memindahkan repositori saya keluar dari GitHub kemudian hari?

Kodnya, ya, dengan mudah. Setiap clone menyimpan sejarah lengkap, jadi git remote set-url origin <new url> diikuti dengan push akan memindahkan segala-galanya yang terkandung dalam sesuatu commit. Apa yang tertinggal ialah lapisan yang dimiliki oleh GitHub: isu, perbincangan pull request dan sejarah Actions berada dalam pangkalan datanya, bukan dalam folder .git anda. Alat migrasi boleh menyalin isu melalui API, dan fail aliran kerja biasanya perlu disunting untuk CI hos baharu. Mengingati perkara ini adalah hujah untuk meletakkan dokumentasi sebenar di dalam repositori dan bukannya dalam thread isu.