Git vs GitHub: Key Differences - Quiz

Git is a distributed version control system — a program you install on your machine. It keeps the full project history locally, handles commits, branches, merges and rollbacks, and works with no internet connection. Git was created by Linus Torvalds in 2005 for Linux kernel development.

GitHub is a cloud web service that hosts Git repositories. It launched in 2008 and has been owned by Microsoft since 2018. On top of Git it adds a web interface, pull requests, code review, an issue tracker, CI/CD (GitHub Actions), GitHub Pages and team permissions.

The short answer: Git is the technology, GitHub is a service built around that technology. Git works perfectly fine without GitHub, while GitHub makes no sense without Git — what it stores are Git repositories. Alternatives to Git are Mercurial, Subversion (SVN) and Perforce; alternatives to GitHub are GitLab, Bitbucket, Gitea and Azure Repos.

Git splits files into tracked ones (they were part of the last snapshot or have already been added to the index) and untracked ones (everything else). A file travels through three areas: working directory → index (staging area) → repository.

The states and the transitions between them:

Untracked — sits in the working directory, git status prints "Untracked files"; move it forward with git add file.
Modified — also in the working directory, git status prints "Changes not staged for commit"; move it forward with git add file.
Staged — already in the index, git status prints "Changes to be committed"; record it with git commit -m "...".
Committed — in the local repository, git status prints "nothing to commit, working tree clean"; publish it with git push.

One command shows the state of every file: git status, or the short form git status -s where ?? means untracked, M modified and A added to the index. Remember that git commit records only what reached the index through git add.

There is no separate set of "GitHub commands" in the terminal: you talk to GitHub with the same Git commands and simply point the remote at an address on github.com. First create an empty repository on GitHub (without a README), then run this inside the project folder:

git init
git add .
git commit -m "Initial commit"
git branch -M main
git remote add origin https://github.com/user/project.git
git push -u origin main

The -u flag links the local branch to the remote one, so from then on plain git push and git pull are enough. Check the configured remotes with git remote -v, and change the address (for example to switch to SSH) with git remote set-url origin [email protected]:user/project.git.

Important: since 13 August 2021 GitHub no longer accepts your account password over HTTPS — use a Personal Access Token (Settings → Developer settings → Tokens) instead of the password, or set up an SSH key.

Fork is the GitHub button that creates a copy of someone else's repository under your own account. You need it when you want to contribute to a project where you have no write access. The standard open-source workflow looks like this:

1. Press Fork on the project page — the copy appears in your account.
2. Clone your copy with git clone.
3. Create a branch, make the changes, commit and git push.
4. Open a pull request against the original repository.
5. The maintainer reviews the code and either merges or rejects it.

GitHub keeps the link between your copy and the original, so upstream changes can be pulled in with the Sync fork button or from the terminal:

git remote add upstream https://github.com/original/project.git
git fetch upstream
git merge upstream/main

A pull request is not the git pull command. git pull is a Git command that downloads changes from the server into your local branch. A pull request is a GitHub feature: a proposal to merge your branch into the main one, with discussion, line-by-line comments and CI checks. GitLab calls the same thing a merge request.

The error means the remote repository holds commits that you do not have: while you were working, a teammate pushed their changes and the two histories drifted apart. Git refuses the push rather than overwriting someone else's work.

The right fix is to bring the other commits down, replay yours on top and push again:

git pull --rebase
git push

The --rebase flag avoids an extra merge commit and keeps the history linear; you can make it the default once with git config --global pull.rebase true. What you must not do on a shared branch is git push --force — it overwrites your teammates' commits.

Related beginner traps: committing without git add (the changes simply are not part of the commit); running git add . without a .gitignore, which sends target/, .idea/ and passwords from config files into the repository; running git pull with uncommitted edits (use git stash and then git stash pop); and a detached HEAD after git checkout <commit hash>, which you leave with git switch -.