Git vs GitHub: Wetin VPS Owners Need Know

Wetin be GitHub?

GitHub na hosted service wey dey store Git repositories and build website around dem. Git na version control program wey dey run for your own computer or your own server. GitHub na product of one company on top of Git, and Microsoft don own am since 2018. You fit use Git every day and never open GitHub. You no fit use GitHub without Git.

That line dey important once you get VPS (virtual private server). Git na wetin dey record the history of your config files and deploy scripts. GitHub na where copy of that history dey live when server no get am, plus place to run builds and reviews. This guide dey follow one example from empty folder reach deploy for server, and e go define each new word the first time you meet am.

Wetin Git dey do by itself

Git na version control system: e dey record the state of directory over time, so you fit see wetin change, when e change, and why. Dem write am for 2005 for Linux kernel work. E dey distributed, meaning say every copy of repository get the complete history. No central server dey for the design. Your colleague laptop get complete copy just like any server.

Install am, then set your identity. Git no go record commit without name and email address, because dem both dey write inside the 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"

For Ubuntu 24.04, git --version dey print git version 2.43.0. Any release from the last few years go behave the same way for everything wey follow.

Di example: one repository for your VPS deploy files

One repository, wey dem usually shorten to "repo", na directory wey Git dey watch. E become repository when you run git init, and e go create one hidden .git folder inside am. Na that folder be the repository. If you delete .git, wetin remain na ordinary directory wey no get history.

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

-b main name the first branch main. If you leave am out, Git go print long hint about the default branch name instead. .gitignore list the paths wey Git must never track. Put your secrets file inside am from day one, because once you commit file, e still dey inside history even after you delete am. To remove am properly, you go need rewrite every commit wey come after.

Commits: di unit for history

Now add one script and record am.

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 dey move one change go staging area, wey be the list of wetin go enter the next commit. git commit dey write that list enter history as one entry. One commit get snapshot of every tracked file, one message, one author, one timestamp, and pointer go the commit wey come before am. git log --oneline dey print one line for each commit, and each line start with short hash like a1b2c3d. That hash na the commit name, and almost every Git command fit accept am.

If you skip the git add step, git commit go answer no changes added to commit (use "git add" and/or "git commit -a"). Nothing spoil. Git dey tell you say staging area empty, so nothing dey to snapshot. git status na the command to run anytime you no know wetin dey happen: e name the current branch, the staged changes, and the files wey Git fit see but e never dey track.

Branches: second line of history

A branch na pointer wey dey move follow commit. main na branch, and e no get any special thing for Git. Creating one no cost anything, because Git dey write new pointer instead of copying your files.

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

After git switch main, backup.sh no dey for the listing again. Nothing delete. The file dey for add-backup branch, but main never get am, so Git remove am from your working directory when you move. Everybody dey find this surprising once. git switch add-backup go bring am back.

Remotes: where GitHub finally dey show

Everything wey we don do so far run for one machine, without any network. A remote na named URL for another copy of the same repository. GitHub dey host one of those copies for you. The conventional name for the main remote na origin.

Create an empty repository through the GitHub website, then connect to am. For here, prefer SSH instead of HTTPS: an SSH key na file wey you control, and e no expire like personal access token.

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

Paste the public key wey e print into the SSH keys page for your GitHub account, then run the test again. A working key go answer Hi yourname! You've successfully authenticated, but GitHub does not provide shell access. GitHub no give you shell access, so that refusal na the success case. git@github.com: Permission denied (publickey). mean say your key no ever get offered or GitHub no accept am, so check say you paste the .pub file, no be the private key wey dey beside am.

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

git push dey send your commits go the remote. -u dey record say local main dey track remote main, so later, bare git push go dey enough. git clone <url> na the reverse for a new machine: e dey copy the whole repository with its history and set origin for you. HTTPS remote dey work too, and e dey use the same protocol wey any web page dey use, so e fit help for networks wey block outbound port 22. If you need more explanation for that sentence, wetin an HTTP request really contain explain the mechanics.

Pull requests, issues and forks: parts wey be GitHub own, no be Git own

Everything wey dey above na Git, and e go work with any server. The three terms wey dey below na GitHub features. Other hosts dey copy dem, but Git itself no know anything about dem.

A pull request (PR) na request to merge one branch into another, with one page wey people fit use discuss am. You push add-backup, open PR against main, and the site go show the difference commit by commit. People fit comment for individual lines. Automated checks go report whether the branch pass or fail. When you click merge, GitHub go perform the merge for its own copy, then update main. The name come from the original workflow, where you ask maintainer to pull your branch enter their own.

An issue na numbered thread for bug or task. E dey inside GitHub database, no be inside your repository. You need know this before you choose host: when you clone the repo, you get every commit, but you no get any issue. To remove issues means say you need call the API.

A fork na your own server-side copy of another person repository. You get write access to the copy, push branch go there, then open pull request from your copy back to their own. Na so you fit contribute to project wey the maintainers never hear about you before. Fork na clone wey dey live for GitHub and remember where e come from.

Software dey read all three through the same API wey person dey use. A pull request review agent wey you run for your own server dey monitor new PRs, read the diff, and post line comments. Conventions like AGENTS.md file for repository root dey exist because tools and people dey read repo now.

Wetin GitHub really dey do for VPS owner

Start with storage wey dey outside server. Your deploy scripts and playbooks suppose dey somewhere wey no be the server wey dem dey configure. Rebuild the VPS from fresh image, clone, then run. Keep that repository private and give the server a deploy key: na SSH key wey you register for one repository instead of your whole account, and set am to read only. If person leak read-only deploy key, na one repo e expose. If person leak account key, na everything wey you fit push go expose.

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

--ff-only no gree create merge commit. For server wey only dey consume changes, merge always na mistake, so this flag turn confusing history into plain error fatal: Not possible to fast-forward, aborting. Something don change for the server wey no suppose change. Find am before you pull again.

If you clone as root and later run Git as another user, you go get fatal: detected dubious ownership in repository at '/srv/vps-deploy'. Git no gree read repository wey different user own, because hostile .git/config fit make Git run commands. Fix the ownership with chown instead of adding safe.directory exception, because the exception only silence the check and no remove the cause.

GitHub Actions: pipeline wey dey build and deploy

Actions na GitHub CI/CD system (continuous integration and continuous delivery). Put YAML file under .github/workflows/, and GitHub go run am when the event wey you name happen.

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

The file na workflow. A job dey run for one machine. A step na one command or one published action. uses: dey bring action from another repository, and @v7 lock the major version (v7 na current for actions/checkout as of August 2026). Always lock version for something, because action wey you no lock fit run code wey you never read, with access to your secrets.

runs-on: ubuntu-latest dey ask GitHub for fresh virtual machine, and dem go throw the machine away when the job finish. Standard runners free for public repositories, and free plan get 2,000 minutes every month for private repositories as of August 2026. Check the current pricing page before you use that figure plan budget.

Dem dey store secrets for repository settings, and workflow dey read dem as ${{ secrets.DEPLOY_KEY }}. Workflow wey pull request from fork trigger go get read-only token and no access to those secrets, because if not, stranger fit open PR wey only work na to print dem.

Run Actions runner for your own VPS

runs-on: self-hosted go send the job go one machine wey belong to you instead. The repository runner settings page go give you one download line, the repository web address, and one registration token wey dey valid for one hour. Put the last two inside REPO_URL and RUNNER_TOKEN, then na three commands go complete the setup.

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

svc.sh status suppose report say the service dey active and show recent log lines. The runner dey open outbound HTTPS connection go GitHub and ask for work, so you no need open any inbound port for am. svc.sh install dey write the systemd unit, and na the step wey people dey skip: without am, the runner go exit together with your SSH session, and every later job go remain queued without any explanation. the complete self-hosted runner setup for VPS dey explain the hardening and cleanup wey long-running runner need.

The benefit be say deploy no longer need inbound SSH key wey internet fit reach, because the job don already dey run for the machine. Build cache still dey warm between runs, and no minute meter dey count.

One warning dey mandatory. GitHub own documentation recommend self-hosted runners only for private repositories, because fork from public repository fit run dangerous code for your runner by opening pull request. The runner go execute anything wey the workflow file for that branch talk. For private repo where na you control who fit push, the risk small. For public repo, treat any self-hosted runner as machine wey strangers fit execute code on.

You really need GitHub?

No. Git na be the standard, while GitHub na convenience. Forgejo and Gitea na self-hosted forges; forge mean Git host wey get issues and pull requests join am. Both dey come as one Go binary, both fit run for small VPS, and Forgejo na 2022 fork of Gitea wey now dey power Codeberg. To move repository na one command, because the wire protocol dey identical.

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

Every commit dey move, because every clone already get the complete history. Wetin no dey move na the layer wey GitHub build on top: the issues and pull request threads. CI no dey transfer too. Forgejo get im own Actions implementation wey dey read similar YAML from .forgejo/workflows/, and im documentation talk clearly about the limits: GitHub Actions and Forgejo Actions no be the same, and some things fit no work immediately. E still need im own runner. Plan that step as port, no be copy.

The honest reason why most projects remain na contributors. Public code need stay where people wey already get account dey. Your private deploy scripts no need do that. Na two separate decisions be these, and you fit answer dem differently.

Wetin dey break first, and wetin the error dey talk

A push get rejected. You go see this:

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

Person push something since your last pull, often na edit wey you make for the web editor. Run git pull --rebase to replay your commits on top of their own, then push again. Avoid git push --force for shared branch, because e go remove the other commits from that branch for the server.

fatal: refusing to merge unrelated histories. You run git init locally and allow GitHub create the repository with a README. The two histories no share any commit, so Git no fit guess. The clean fix na to clone the GitHub copy into new folder, then move your files enter am.

error: src refspec main does not match any. The branch wey you name no dey here. Usually, the repository never get any commit yet, or your branch name na master. git branch --show-current go settle am.

A secret enter one commit. Rotate the credential now. Treat am as public from the moment you push am, because forks, mirrors, and cached views get copies wey you no get way to delete.

FAQ

GitHub na the same thing as Git?

No. Git na version control program wey you install for machine, and e dey work without network or account. GitHub na commercial hosted service wey dey store Git repositories and add web interface, issues, pull requests, and CI around dem. Git release for 2005, and GitHub launch for 2008 on top of am. You fit use Git forever without GitHub. Every GitHub feature depend on Git underneath.

I need GitHub account to use Git for my VPS?

No. git init, git commit and git log dey work for server wey no get remote configured at all. This don already reach to track changes for /etc files or deploy scripts. Account dey useful when you want copy of the history wey go survive the server, or second machine wey fit clone am. Self-hosted forges like Forgejo and Gitea cover the same need for hardware wey you own. Plain SSH remote wey point to bare repository for another box also work without forge software at all.

Wetin be pull request?

Pull request na request to merge one branch into another, with discussion page attached. You push branch, open the PR against main, and the host show the changes commit by commit. Reviewers fit comment on individual lines, and automated checks fit report whether e pass or fail. Na GitHub feature, no be Git feature, so Git itself no get command for am. Other hosts implement the same idea, and some dey call am merge request.

I suppose run GitHub Actions runner for my own VPS?

For private repository, often yes. The job run for hardware wey you already dey pay for. Nobody dey count minutes, build cache remain warm, and deploy no longer need inbound SSH key wey internet fit reach. This na because the runner connect outbound to GitHub and ask for work. For public repository, GitHub advise against am: anybody fit fork your repo and open pull request wey workflow go run code for your machine.

I fit move my repositories comot from GitHub later?

The code, yes, easily. Every clone get the complete history, so git remote set-url origin <new url> followed by a push go move everything wey one commit contain. Wetin remain behind na the layer wey GitHub own: issues, pull request discussions, and Actions history dey for its database, no be inside your .git folder. Migration tools fit copy issues through the API, and workflow files usually need editing for the new host CI. Keep this for mind: na reason to put real documentation inside repository instead of issue threads.